Requisitos de Software

Viso Geral

Professor: Osvaldo Kotaro Takai E-mail: otakai@uol.com.br

A Importncia dos Requisitos

A engenharia de requisitos um termo usado para descrever as atividades envolvidas na elucidao, documentao e manuteno de um conjunto de requisitos de um sistema de software. O objetivo descobrir o que os stakeholders necessitam que o sistema faa por eles. Estudos mostram que a falha no gerenciamento de requisitos a principal causa dos fracassos em projetos de software. Como o sistema baseado em requisitos, a engenharia de requisitos crtico para o sucesso de projetos de desenvolvimento de software.

Definindo Requisitos
Podemos definir um requisito como uma especificao que deve ser implementada. Existem dois tipos de requisitos:
Funcional: o que o sistema deve fazer. No-funcional: uma propriedade especfica ou restrio sobre o sistema.

Requisitos so (ou deveriam ser) a base de todo o sistema. So declaraes do que o sistema deve fazer. Requisitos devem ser apenas uma declarao do que o sistema deve fazer e no de como deve fazer. Ns podemos especificar o que um sistema deve fazer e qual comportamento deve exibir sem necessariamente dizer qualquer coisa sobre como esta funcionalidade deve ser realizada.

Especificao de Requisitos de Software (SRS)

Muitas empresas produzem um documento chamado SRS que contm a especificao do que o sistema de software deve fazer. Normalmente, esse documento escrito em linguagem natural, mas ferramentas de engenharia de requisitos, tais como RequisitePro ou DOORS (www.telelogic.com) so usados com grandes vantagens. O SRS o principal artefato de entrada para a fase de anlise e projeto OO.

Requisitos Bem-Formados
A UML no faz nenhuma recomendao sobre como escrever um documento SRS. A UML trata os requisitos usando use cases. No entanto, apenas use cases no so suficientes. Precisamos de SRS e ferramentas de gerenciamento. Recomendamos um formato muito simples para declarar requisitos:
<id> O <sistema> deve <funo>
Identificador nico Nome do sistema Palavrachave Funo a ser executada

Requisitos Funcionais e No Funcionais

Requisitos Funcionais
Um requisito funcional uma declarao de o que o sistema deve fazer (funo). Por exemplo, para um caixa eletrnico (ATM), alguns requisitos funcionais podem ser: 1. O sistema ATM deve verificar a validade do carto. 2. O sistema ATM deve validar a senha digitada pelo cliente. 3. O sistema ATM no deve liberar mais que R$ 1.000,00 por carto num perodo de 24 horas.

Requisitos Funcionais e No Funcionais

Requisitos No-Funcionais
Um requisito no-funcional uma restrio imposta ao sistema. Por exemplo, para um caixa eletrnico (ATM), alguns requisitos no-funcionais podem ser: 1. O sistema ATM deve ser escrito em C++. 2. O sistema ATM deve se comunicar com o banco usando um algoritmo de criptografia de 256 bits. 3. O sistema ATM deve validar a senha em trs segundos ou menos. Verifique que o requisito no-funcional especifica, ou restringe, como o sistema ser implementado.

Requisitos de Software
Modelagem Use Case

Professor: Osvaldo Kotaro Takai E-mail: otakai@uol.com.br

Modelagem Use Case

A Modelagem Use Case (MUC) uma forma de engenharia de requisitos. A MUC segue os seguintes passos:
1. 2. 3.

Definir a fronteira do sistema Encontrar os atores Encontrar os use cases

Especificar o use case Criar cenrios

Modelagem Use Case

O resultado da MUC o modelo Use Case. Existem quatro componentes nesse modelo:
1. 2. 3. 4.

Atores: papis interpretados por pessoas ou coisas que usam o sistema Use Cases: coisas que os atores podem fazer com o sistema Relacionamentos: associaes importantes entre atores e usa cases Fronteira do sistema: Conjunto de atores e use cases do sistema

A Fronteira do Sistema
A primeira coisa a ser feita quando pensamos em construir um sistema decidir onde est a fronteira do sistema. Isto , precisamos definir o que parte do sistema (dentro da fronteira do sistema) e o que externo (fora da fronteira do sistema). Isso parece bvio, mas muitos projetos sofrem de srios problemas devido incerteza sobre a fronteira do sistema.

A Fronteira do Sistema
A falta ou impreciso na definio da fronteira do sistema pode causar enorme impacto nos requisitos funcionais (e algumas vezes, no funcionais). Requisitos a mais ou a menos um grande problema. A fronteira do sistema definida por quem usar o sistema (isto , atores), e pelos benefcios especficos que o sistema ir fornecer a essas atores (isto , use cases).

A Fronteira do Sistema
A fronteira do sistema definido pelo conjunto de atores e use cases apresentados num Diagrama Use Case. Exemplo de um Diagrama Usa Case.

A Fronteira do Sistema
Diagram a Us e Cas e

Receber Pedidos

Cancelar Pedidos

Transportadora

Cliente Verificar a Sit uao do Pedido

Enviar Pedido

Supervisor de Entregas

Enviar Catlogo

O que so Atores?
Um ator especifica algum ou alguma coisa que interage diretamente com o sistema. O ator est sempre fora da fronteira do sistema. Um ator representado em UML como stick man:

Cliente

O que so Atores?
importante ficar muito claro e cristalino de que Atores so externos ao sistema, mas que o sistema pode manter informaes sobre esses Atores. Ou seja, uma representao interna de indivduos que utilizam o sistema.

Identificando Atores
As seguintes questes podem ajudar a identificar os atores do sistema:
1. 2. 3. 4. 5. 6. 7. 8.

Quem ou o que utiliza o sistema? Quais so os papis que eles interpretam durante a interao com o sistema? Quem instala o sistema? Quem inicia ou desativa o sistema? Quem mantm o sistema? Que outros sistemas interagem com o sistema? Quem obtm ou fornece informaes para o sistema? Existe alguma coisa que acontece em tempos determinados?

Identificando Atores
Pontos a serem lembrados durante a identificao de atores:
1. 2. 3.

4.

5. 6.

Atores so externos ao sistema portanto, eles esto fora do controle do sistema Atores interagem diretamente com o sistema Atores representam papis que pessoas ou coisas interpretam em relao ao sistema, no so pessoas ou coisas especficas Uma pessoa ou coisa pode interpretar vrios papis. Por exemplo, num sistema de biblioteca voc pode ser Usurio ou Bibliotecrio (caso voc trabalhe numa biblioteca) Cada ator deve ter um nome curto e que faa sentido na perspectiva de negcio Cada ator deve ter uma breve descrio que esclarea o qual o seu papel na perspectiva de negcio

Time como um Ator

Quando for necessrio modelar coisas que acontecem em tempos especficos, mas que no so ativados por quaisquer ator, voc pode introduzir um ator chamado Time. Um exemplo disso pode ser a funcionalidade de backup automtico que executado todas os dias s 19:00 horas.

Tim e

Fazer Bac kup

O que so Use Cases?

Um Use Case alguma coisa que um Ator quer que o sistema faa. Use Cases so sempre iniciados por um Ator Use Cases so sempre escritos do ponto de vista de um Ator. Use Cases podem descrever funcionalidade de sistemas e subsistemas (parte de um sistema). Usa Cases podem ser utilizados para modelar processos de negcio.

Cancelar Pedidos

10

Identificando Use Cases

A melhor forma de identificar Use Cases iniciar a partir da lista de Atores e considerar como cada Ator usa o sistema. Usando esta estratgia, pode-se obter uma lista de Use Cases candidatos. Cada Use Case deve ter num nome curto, iniciando com um verbo no infinitivo. Por exemplo: Solicitar, Fazer e Cancelar. Conforme os Use Cases vo sendo identificados, novos Atores podem ser descobertos. Isso timo!

Identificando Use Cases

importante considerar cuidadosamente os requisitos funcionais do sistemas antes de finalizar o processo de descobrir Atores e Use Cases. A Modelagem Use Case interativa e executada por um processo de refinamento sucessivo. As seguintes questes podem ajudar a identificar Use Cases:
1. 2. 3. 4.

Quais funes um ator especfico quer que o sistema tenha? O sistema armazena ou recupera informaes? Se sim, quais atores ativam esse comportamento? Algum ator tem que ser avisado quando o sistema muda seu estado? Existe algum evento externo que afete o sistema? Quem informa o sistema sobre esse evento?

11

Diagrama Use Case

No diagrama Use Case, ns representamos a fronteira do sistema. Ele mostra os Atores, que esto fora da fronteira do sistema, e Use Cases, que esto dentro da fronteira do sistema. O relacionamento entre um Ator e um Use Case mostrado usando uma linha. Essa linha indica que o Ator e Use Case se comunicam de alguma forma. Exemplo de um Diagrama Use Case

Diagrama Use Case

Diagram a Us e Cas e

Receber Pedidos

Cancelar Pedidos

Transportadora

Cliente Verificar a Sit uao do Pedido

Enviar Pedido

Supervisor de Entregas

Enviar Catlogo

12

O Glossrio do Projeto
O Glossrio do Projeto pode ser um dos principais artefatos do projeto. Todo domnio de negcio tem sua linguagem prpria e o principal propsito da engenharia e anlise de requisitos entender e capturar essa linguagem. O glossrio define um dicionrio dos principais termos de negcio. Ele deve ser conhecido por todos do projeto, inclusive pelos stakeholders. Alm da definio dos principais termos, o Glossrio do Projeto deve resolver sinnimos e homnimos.

O Glossrio do Projeto
Sinnimos so palavras diferentes com o mesmo significado.
Como analista OO voc deve escolher uma das palavras (aquele que seja a mais utilizada) e no usar nenhum outro sinnimo. Os outros sinnimos devem ser completamente excludos do modelo para evitar que se criem, por exemplo, duas classes com nomes distintos, mas que fazem mais ou menos a mesma coisa. Se fosse permitido o uso de sinnimos, a semntica das classes poderia, com o tempo, divergir.

13

O Glossrio do Projeto
Homnimos ocorrem quando a mesma palavra possui significados diferentes para pessoas diferentes.
Isso sempre traz problemas de comunicao e de desentendimentos. A maneira de resolver esse problema escolher apenas um significado para o termo.

O Glossrio do Projeto
No Glossrio de Projeto, deve-se registrar os termos preferidos, bem como quaisquer de seus sinnimos. Talvez voc tenha que convencer alguns stakeholders de que alguns termos so melhores do que outros. A UML no padroniza o formato para o Glossrio do Projeto. Assim, recomendamos que use um formato semelhante ao de um dicionrio, organizado em ordem lexicogrfica dos termos do glossrio.

14

Detalhar Use Cases

Aps criar o diagrama use case e identificar os principais atores e use cases, iniciamos a especificao de cada use case. Essa atividade conhecida como Detalhar Use Cases O resultado desta atividade a especificao de cada use case. No existe um padro na UML para uma especificao use case. No entanto comum usar o formato apresentado no prximo slide:

Especificao Use Case

Use Case: Pagar Taxa ID: UC1 Atores: Time Governo Pr-condies: 1. final de trimestre Fluxo de eventos: 1. O use case inicia quando for final de trimestre. 2. O sistema calcula o valor do importo devido ao Governo. 3. O sistema envia um pagamento eletrnico ao Governo. Ps-condies: 1. O Governo recebe o valor correto do imposto.
Nome do Use Case Identificador nico

Os atores envolvidos com o use case

O estado do sistema antes que o use case possa comear

Os passos reais do use case

O estado do sistema quando o use case finalizar

15

Especificao Use Case

Cada use case tem um nome e uma especificao. A especificao consiste de:
Pr-condies so coisas que devem ser verdadeiras antes que o use case possa ser executado eles so restries sobre o estado do sistema. Fluxo de eventos os passos do use case. Ps-condies coisas que devem ser verdadeiras ao final da execuo do use case. No exemplo, o Governo sempre recebe o imposto, de uma forma ou de outra; por isso a ps-condio do use case.

Pr e Ps-condies
Pr e Ps-condies so restries
As pr-condies restringem o estado do sistema antes que o use case possa iniciar sua execuo. Pense nelas como guardis que previnem que um ator inicie a execuo do use case at que todas as condies tenham sido atendidas. Ps-condies restringem o estado do sistema aps a finalizao da execuo do use case.

Uma outra maneira de pensar:

Pr-condies especificam o que deve ser verdadeiro antes que o use case possa ser executado Ps-condies especificam o que dever ser verdade aps a execuo do use case.

16

Pr e Ps-condies
Pr e Ps-condies nos ajudam a projetar sistemas que funcionem corretamente. Pr e Ps-condies sempre devem ser declaraes simples sobre o estado do sistema que podem ser testados como verdadeiro ou falso eles so conhecidos como condies booleanas.

Fluxo de Eventos
O fluxo de eventos lista os passos de um use case. Ele sempre comea com um ator fazendo alguma coisa para iniciar o use case. Uma boa maneira de iniciar um fluxo de eventos :
O use case inicia quando o <ator><alguma ao>

Lembre-se que o Time pode ser um ator, assim, o use case pode tambm ser iniciado com uma expresso de tempo no lugar do ator, como no exemplo do use case: Pagar Taxa. O fluxo de eventos consiste de uma seqncia de breves passos que so declarativos, numerados e ordenados no tempo.

17

Fluxo de Eventos
Cada passo no fluxo do use case deve ser da forma: <nmero>O <alguma coisa><alguma ao>
Exemplo: 1. O use case inicia quando o cliente seleciona a opo fazer pedido. 2. O cliente entra com seu nome e endereo no formulrio.

Esses passos so bem formatados. Em ambos os casos, temos uma declarao simples de alguma coisa executando alguma ao.

Fluxo de Eventos
O fluxo de eventos do use case pode tambm ser capturada como uma prosa. No entanto, ns no recomendamos isso, pois geralmente muito impreciso. (Takai quer a prosa) Ns podemos mostrar alternativas num fluxo do use case ramificando ou listando os fragmentos do comportamento sob o cabealho de um fluxo alternativo do use case. Veremos isso depois.

18

Ramificao dentro do fluxo

Com freqncia voc precisa indicar que existem algumas possibilidades dentro do fluxo de eventos de um use case. Um boa maneira de fazer isso usar o Portugus estruturado. Ns introduzimos um conjunto simples de palavraschaves que voc pode usar para expressar ramos, repeties e at fluxos alternativos. Vale a penas saber que alguns modeladores de use cases podem no gostar de ramos dentro de use cases.

Ramificao dentro do fluxo

Eles dizem que, se existe um ramo ento um novo use case deveria ter sido criado. Estritamente falando, esse argumento tem seu mrito no entanto, ns tomamos uma posio mais pragmtica: desejvel uma pequena quantidade de ramos pois isso reduz o nmero total de use cases e permite uma representao mais compacta dos requisitos. Voc ir ver tcnicas especficas para lidar com use cases realmente complicados, onde ramos podem ser totalmente inapropriados.

19

Ramificao dentro do fluxo

Palavra-Chave Se
Usada para indicar um ramo no fluxo de eventos.
Use Case: Gerenciar Carrinho de Compras ID: UC10 Atores: Cliente Pr-condies: 1. O Carrinho de Compras est visvel. Fluxo de Eventos: 1. O use case inicia quando o Cliente seleciona um item no Carrinho de Compras. 2. Se o Cliente selecionar remover item ento 2.1. O sistema remove o item do Carrinho de Compras. 3. Se o Cliente informar uma nova quantidade ento 3.1. O sistema atualiza a quantidade do item no Carrinho de Compras. Ps-condies: 1. O contedo do Carrinho de Compras foi atualizado.

Ramificao dentro do fluxo

A figura anterior mostra um fluxo de eventos muito bem estruturado com 2 ramos. Cada ramo prefixado com a palavra-chave Se, comea com uma simples expresso Booleana, tal como: Se o usurio informar uma nova quantidade, que verdadeira ou falsa. O texto identado sob a declarao Se o que ser executado se a expresso for verdadeira. O bloco da declarao Se definido pela identao e numerao, dispensando qualquer declarao explcita de final de bloco.

20

Ramificao dentro do fluxo

Fluxos Alternativos:
Algumas vezes no possvel usar o Se. Por exemplo: como usar a declarao Se para dizer que o Cliente pode sair da tela do Carrinho de Compras em qualquer momento? Pode-se perceber que, se quisermos indicar essa situao usando a declarao Se, teramos que faz-lo em quase todas as linhas do fluxo de eventos. Nada prtico! melhor expressar ramos que podem ocorrer em qualquer ponto do fluxo de eventos como um ou mais fluxos alternativos. Por exemplo:

Ramificao dentro do fluxo

Use Case: Exibir Carrinho de Compras ID: UC11 Atores: Cliente Pr-condies: 1. O Cliente efetuou login no sistema. Fluxo de Eventos: 1. O use case inicia quando o Cliente seleciona exibir Carrinho de Compras. 2. Se no existir itens no Carrinho de Compras ento 2.1. O sistema informa ao Cliente que ainda no existe itens no Carrinho de Compras. 2.2. O use case termina. 3. O sistema exibe uma lista com todos os itens do Carrinho de Compras do Cliente incluindo: ID, nome, quantidade e preo dos produtos. Ps-condies: Fluxo Alternativo 1: 1. Em qualquer momento, o Cliente pode sair da tela do Carrinho de Compras. Ps-condies: Fluxo Alternativo 2: 1. Em qualquer momento, o Cliente pode sair do sistema. Ps-condies:

21

Ramificao dentro do fluxo

Como pde ser visto, acrescentou-se uma nova seo no final do use case, para cada fluxo alternativo. Essa seo contm:
O fluxo de eventos do fluxo alternativo. Normalmente, este fluxo de eventos deve ser simples, com poucos passos, e sempre deve comear com uma condio Booleana indicando quando esse fluxo dever ser executado. As ps-condies do fluxo de eventos alternativo.

No coloque as ps-condies dos fluxos alternativos como ps-condies do fluxo principal.

Repetio no Fluxo: Para

Algumas vezes h a necessidade de repetir vrias aes dentro do fluxo de eventos. Isso no ocorre com freqncia na modelagem use case, mas quando ocorrer, til ter um estratgia. Pode-se modelar repeties usando a palavrachave Para. O formato :
n. Para (expresso de iterao) faa n.1. Alguma coisa. n.2. Outra coisa. n.3. ...

n+1.

22

Repetio no Fluxo: Para

Use Case: Encontrar Produtos ID: UC12 Atores: Cliente Pr-condies: Fluxo de Eventos: 1. O Cliente seleciona a opo encontrar produtos. 2. O sistema solicita o critrio de busca ao Cliente. 3. O Cliente informa o critrio solicitado. 4. O sistema procura por produtos de acordo com o critrio de busca informado pelo Cliente. 5. Se o sistema encontrar produtos que satisfaam o critrio de busca ento 5.1. Para cada produto encontrado faa 5.1.1. O sistema mostra uma pequena imagem do produto. 5.1.2. O sistema mostra um resumo dos detalhes do produto. 5.1.3. O sistema mostra o preo do produto. 6. Seno 6.1. O sistema informa ao Cliente que nenhum produto pde ser encontrado. Ps-condies: Fluxo Alternativo: 1. Em qualquer momento, o Cliente ir para uma pgina diferente. Ps-condies:

Repetio no Fluxo: Enquanto

A palavra-chave Enquanto usada para modelar uma seqncia de aes no fluxo de eventos que executado enquanto alguma condio Booleana for verdadeira. O formato :
n. Enquanto (Condio booleana) faa n.1. Alguma coisa. n.2. Outra coisa. n.3. ...

n+1.

23

Repetio no Fluxo: Enquanto

A palavra-chave Enquanto tambm pouco utilizada. A seqncia de linhas identadas aps a declarao Enquanto repetida at que a condio booleana torne-se falsa. Exemplo:

Repetio no Fluxo: Enquanto

Use Case: Exibir Detalhes da Empresa ID: UC13 Atores: Cliente Pr-condies: Fluxo de Eventos: 1. O use case inicia quando o Cliente seleciona a opo exibir detalhes da empresa. 2. O sistema exibe uma pgina web contendo os detalhes da empresa. 3. Enquanto o Cliente estiver navegando nos detalhes da empresa faa 3.1. O sistema toca alguma msica de fundo. 3.2. O sistema exibe ofertas especiais num banner ad Ps-condies:

24

Rastreando Requisitos
Com um documento SRS e um conjunto de use cases, ns temos efetivamente duas bases de dados de requisitos funcionais. muito importante relacionar essas duas bases para verificar se existe alguma no SRS no esteja coberto pelos use cases e vice-versa. Este um dos aspetos de rastrear requisitos. Rastrear requisitos funcionais para use cases complicado pelo fato de ser um relacionamento muitos-para-muitos entre eles.

Rastreando Requisitos
Isso pode ser feito com facilidade criando uma matriz de rastreabilidade de requisitos:
Use Cases Requisitos UC1 UC2 UC3 UC4 R1 R2 R3 R4 R5

25

Rastreando Requisitos
A matriz de requisitos uma ferramenta muito til para verificar consistncias. Se existir um requisito que no tenha sido mapeado para um use case, ento existe ao menos um use case faltando. Por outro lado, se existir um use case que no possa ser mapeado para algum requisito, ento os requisitos esto incompletos.

Use Cases Complexos

Como regra geral, use cases devem ser mantidos o mais simples possvel. No entanto, ocasionalmente, nos deparamos com um complexidade irredutvel, ao ponto de termos que criar use cases complexos. Ao invs de tentar capturar essa complexidade com ramos e fluxos alternativos, mais fcil, ou menos propenso a erros, modelar um fluxo bsico e sua teia de ramificaes usando cenrios separados.

26

Use Cases Complexos

Cenrios:
Cenrios so uma outra forma de ver um use case. Um cenrio um caminho especfico atravs do use case. Durante a documentao de um use case, pode-se explorar vrios caminhos especficos atravs do fluxo de eventos do use case, ento cada um dos caminhos um cenrio. A caracterstica importante de cenrios que eles no se ramificam. Assim, cada possvel ramo no fluxo de eventos do use case gera, potencialmente, um cenrio isolado. Cada use case tem exatamente um cenrio principal ou Fluxo Bsico. Esse o caminho feliz do use case.

Use Cases Complexos

Tudo, no Fluxo Bsico, ocorre como esperado e desejado, no existem erros, desvios, interrupes ou ramos. Um use case pode ter muitos cenrios secundrios, ou Fluxos Secundrios. Fluxos Secundrios podem capturar erros, ramos e interrupes no fluxo bsico.
Fluxo Bsico

FS 3 FS 1 FS 2

Interrupo

27

Use Cases Complexos

Especificando o Fluxo Bsico
Quando voc usa a abordagem de cenrios para documentar use cases, a especificao use case contm o Fluxo Bsico e uma lista de nomes dos Fluxos Secundrios numa seo apropriada. Os Fluxos Secundrios so normalmente documentados em separado e da mesma maneira que um use case documentado. A seguir um exemplo de um use case com seu Fluxo Bsico:

Use Case: Fechar Pedido ID: UC14 Atores: Cliente Pr-condies: Fluxo Bsico: 1. O use case inicia quando o Cliente seleciona a opo fechar pedido. 2. O sistema exibe o pedido do Cliente. 3. O sistema solicita a identificao do Cliente. 4. O Cliente entra com uma identificao vlida. 5. O sistema recupera e exibe os detalhes do Cliente. 6. O sistema solicita informaes do carto de crdito nome escrito no carto, nmero e data de expirao. 7. O Cliente informa os dados do carto conforme solicitado. 8. O sistema solicita confirmao do pedido. 9. O Cliente confirma o pedido. 10. O sistema debita no carto de crdito. 11. O sistema exibe a fatura. Fluxos Secundrios: Identificador do Cliente Invlido Detalhes do Carto Invlido Limite Excedido do Carto de Crdito Carto de Crdito Expirado Ps-condies:

28

Use Cases Complexos

Especificando Fluxos Secundrios
Voc deve especificar os Fluxos Secundrios da mesma forma que so especificados os use case. Deixe sempre claro de como o cada Fluxo Secundrio se inicia e assegure-se de que ele seja apenas uma caminho especfico atravs do fluxo de eventos do use case sem nenhuma ramificao. Cada Fluxo Secundrio deve ser rastrevel de volta para o seu use case. O exemplo a seguir ilustra uma boa maneira de especificar Fluxos Secundrios.

Use Cases Complexos

Use Case: Fechar Pedido Fluxo Secundrio: Identificador do Cliente Invlido ID: UC15 Atores: Cliente Pr-condies: Fluxo Secundrio: 1. O use case inicia no passo 3 do use case Fechar Pedido, quando o Cliente informa um identificador de Cliente invlido. 2. Enquanto identificador do Cliente invlido e o nmero de tentativas for menor que trs faa 2.1. O sistema solicita a identificao do Cliente 3. O sistema informa ao Cliente que a sua identificao no foi reconhecida. Ps-condies:

29

Use Cases Complexos

Encontrando Fluxos Secundrios
Os Fluxos Secundrios so identificados inspecionando o Fluxo Bsico. Em cada passo do Fluxo Bsico, procure por: Possveis fluxos alternativos; Erros que podem ocorrer; Interrupes que podem ocorrer coisas que podem acontecer em qualquer tempo.

Use Cases Complexos

Quantos cenrios existem?
Um use case possui apenas um cenrio principal (fluxo bsico) e pode ter vrios cenrios secundrios (fluxo secundrio). Voc deve tentar limitar o nmero de fluxos secundrios ao mnimo necessrio. Para isso, existem duas estratgias:
Pegue os fluxos secundrios mais importantes e documenteos. Onde existir grupos de fluxos secundrios muito similares, documente um deles como um exemplo e (se necessrio) adicione notas nesse exemplo sobre as diferenas entre eles.

30

Use Cases Complexos

O princpio bsico na modelagem use case manter a quantidade de informaes no mnimo necessrio. Isso significa que muitos fluxos secundrios nunca sero especificados. Lembre-se que o objetivo da modelagem use case identificar use cases e seus cenrios para entender o comportamento do sistema e no com o propsito de criar um modelo use case completo. Assim, a modelagem use case pra quando houver um sentimento de que atingiu o entendimento. Voc sempre poder retornar e acrescentar detalhes quando achar que algum aspecto do comportamento do sistema foi esquecido ou no foi realmente entendido.

Use Cases Complexos

Quando aplicar a modelagem use case
Pelo fato de use cases capturarem as funes do sistema sob o ponto de vista de seus atores, a modelagem use case no so to apropriados para sistema que tenha apenas um ou nenhum ator. Use cases capturam requisitos funcionais. Use cases no capturam requisitos no-funcionais.

31

Use Cases Complexos

Use cases so a melhor escolha quando:
O sistema dominado por requisitos funcionais O sistema tiver muitos tipos de usurios e que apresentem diferentes funcionalidades. O sistema tiver muitas interfaces.

Use cases no uma boa escolha quando:

O sistema dominado por requisitos no-funcionais O sistema tem poucos usurios. O sistema tiver poucas interfaces.

Requisitos de Software
Modelagem Use Case Avanada

Professor: Osvaldo Kotaro Takai E-mail: otakai@uol.com.br

32

Modelagem Use Case Avanada

Discutiremos relacionamentos que so possveis entre Atores e Atores e entre Use Cases e Use Cases. Tais relacionamentos so:
Generalizao de Atores: um relacionamento de generalizao entre um Ator mais genrico e um Ator mais especfico. Generalizao Use Case: um relacionamento de generalizao entre um Use Case mais geral e um Use Case mais especfico. <<include>>: relacionamento entre Use Cases que permite que um Use Case inclua comportamento de outro. <<extend>>: relacionamento entre Use Cases que permite que um dos Use Cases estenda seu comportamento com um ou mais fragmentos de comportamentos de outro.

Modelagem Use Case Avanada

muito importante manter todos os modelos to simples quanto possvel. Assim, esses relacionamentos devem ser usados com ponderao. Use-os somente quando a claridade do modelo Use Case for beneficiada. muito fcil saturar o modelo com <<include>> e <<extend>>, por isso, evite-os.

33

Modelagem Use Case Avanada

Generalizao de Atores
No exemplo da figura ao lado, voc pode ver que existem algumas coisas comuns entre os atores: Cliente e Vendedor, na maneira como eles interagem com o Sistema de Vendas. O Vendedor pode fazer um pedido no lugar de um Cliente.
Cliente
(f rom Actors)

Listar Produtos

Pedir Produtos

Aceitar Paga mento Vendedor

(f rom Actors)

Calcular Com is s o

Modelagem Use Case Avanada

Na realidade, existe apenas uma diferena entre os dois atores: o Vendedor interage com o use case Calcular Comisso. Deixando de lado o fato das vrias linhas cruzadas no diagrama, essas similaridades de comportamentos parecem indicar que existem alguns comportamentos de atores comuns e que devem ser fatorados (decompostos) a partir de um ator mais genrico. Os fatores comuns podem ser generalizados num novo ator como ilustra a seguinte figura:

34

Modelagem Use Case Avanada

Voc cria um ator abstrato chamado Comprador. Os atores Cliente e Vendedor so concretos. Os atores concretos herdam os comportamentos do ator abstrato.
Cl ien te
(f rom Actors)

Lis tar Produtos

Com prador

Pedir Produtos

Aceitar Pagam ento

Vendedor
(f rom Actors)

Calcular Com is s o

Modelagem Use Case Avanada

Generalizao Use Case
A generalizao usada quando tem um ou mais use cases que so especializaes reais de um caso mais genrico. Como na generalizao de atores, voc deve us-la somente quando isso simplificar o diagrama use case. Os use cases filhos podem:
Herdar caractersticas do use case pai Adicionar novas caractersticas Sobrepor (mudar) caractersticas herdadas

35

Modelagem Use Case Avanada

Cl iente
(f rom Actors)

Encontrar Produtos

Encontrar Livros

Encontrar CDs

Modelagem Use Case Avanada

Como documentar generalizao use cases numa especificao use case? A especificao UML no define isso. Ns preferimos usar uma simples conveno tipogrfica para destacar 3 possibilidades no use case filho:

A caracterstica Herdar sem mudar Sobrepor Adicionar

Conveno tipogrfica Texto normal Texto em itlico Texto em negrito

36

Modelagem Use Case Avanada

Use Case: Encontrar Produtos ID: UC12 Atores: Cliente Pr-condies:

Especificao do Use Case abstrato

Fluxo de Eventos: 1. O Cliente seleciona a opo encontrar produtos. 2. O sistema solicita o critrio de busca ao Cliente. 3. O Cliente informa o critrio solicitado. 4. O sistema procura por produtos de acordo com o critrio de busca informado pelo Cliente. 5. Se o sistema encontrar produtos que satisfaam o critrio de busca ento 5.1. O sistema mostra uma lista com os produtos encontrados 6. Seno 6.1. O sistema informa ao Cliente que nenhum produto pde ser encontrado. Ps-condies: Fluxo Alternativo: 1. Em qualquer momento, o Cliente ir para uma pgina diferente. Ps-condies:

Modelagem Use Case Avanada

Use Case: Encontrar Livro ID: UC16 ID do Use Case Pai: UC12 Atores: Cliente Pr-condies: Fluxo de Eventos: 1. O Cliente seleciona a opo encontrar livro. 2. O sistema solicita o critrio de busca do livro ao Cliente. 3. O Cliente informa o critrio solicitado. 4. O sistema procura pelo livro de acordo com o critrio de busca informado pelo Cliente. 5. Se o sistema encontrar o livro que satisfaam o critrio de busca ento 5.1. O sistema mostra uma pgina contendo os detalhes de no mximo 5 livros 5.2. Para cada livro da lista na pgina Faa 5.2.1 mostre o ttulo, autor, preo e ISBN 5.3. Enquanto existir mais livros Faa 5.3.1. O sistema d ao cliente a opo de mostrar a prxima pgina 6. Seno 6.1. O sistema informa ao Cliente que nenhum livro pde ser encontrado. Ps-condies: Fluxo Alternativo: 1. Em qualquer momento, o Cliente ir para uma pgina diferente. Ps-condies:

Especificao do Use Case Filho

37

Modelagem Use Case Avanada

<<include>>
Descrever use cases pode ser, algumas vezes, muito repetitivo. Suponha que se esteja desenvolvendo um sistema de RH:
cliente
<<include>>

stereotype

fornecedor
Mudar Detalh es Em pregados <<include>>

Ger ente

Ver Detalh es Em pregados

En contrar Detal hes Emp regad os <<include>>

Remover Detalh es Em pregados

Relacionamento de dependncia

Modelagem Use Case Avanada

Quase qualquer coisa que pedimos ao sistema envolve, primeiro, localizar os detalhes de um empregado especfico. Se voc tiver que descrever esta seqncia de eventos (autenticao do ID empregado, encontrar empregado, etc.) todas as vezes que voc precisar dos detalhes de um empregado, ento sua descrio de use cases pode ser tornar um tanto repetitiva. O relacionamento <<include>> entre use cases permite incluir o comportamento de um use case fornecedor dentro do fluxo de um use case cliente.

38

Modelagem Use Case Avanada

O use case que inclui chamado de cliente, e o includo como fornecedor. Isso porque, o use case includo fornece comportamento ao use case cliente. Voc deve especificar o ponto exato no use case cliente onde voc precisa que o use case fornecedor seja includo. A sintaxe do <<include>> muito parecida com a chamada de funo. A semntica do <<include>> muito simples, veja as seguintes descries:

Modelagem Use Case Avanada

Mudar Detalhes Empregados ID: UC1 Atores: Gerente Pr-condies: 1. O Gerente vlido no sistema Fluxo de eventos: 1. O Gerente entra com o ID do empregado. 2. Inclua (Encontrar Detalhes Empregados). 3. O Gerente seleciona parte dos detalhes de empregados para mudar. 4. ... Ps-condies: Ver Detalhes Empregados ID: UC2 Atores: Gerente Pr-condies: 1. O Gerente vlido no sistema Fluxo de eventos: 1. O Gerente entra com o ID do empregado. 2. Inclua (Encontrar Detalhes Empregados). 3. O sistema mostra os detalhes de empregados. 4. ... Remover Detalhes Empregados ID: UC3 Atores: Gerente Pr-condies: 1. O Gerente vlido no sistema Fluxo de eventos: 1. O Gerente entra com o ID do empregado. 2. Inclua (Encontrar Detalhes Empregados). 3. O sistema mostra os detalhes do empregado. 4. O Gerente remove os detalhes do empregado. 5. ... Ps-condies:

Ps-condies:

39

Modelagem Use Case Avanada

O use case cliente executa at encontrar o ponto de incluso, ento a execuo passa para o fornecedor. Quando o fornecedor termina, o controle volta ao cliente. O cliente no completo sem os seus fornecedores. O fornecedor parte integrante do cliente. No entanto, o use case fornecedor pode:
No ser completo: nesse caso, contm apenas a parte do fluxo de eventos que ter sentido apenas quando includo num cliente (fragmento de comportamento, no instancivel, no pode ser ativado diretamente por um ator). Ser completo, nesse caso ele atua como um use case normal (instancivel, pode ser ativado por um ator)

Modelagem Use Case Avanada

<<extend>>:
Fornece uma maneira de adicionar um novo comportamento a um use case existente. Veja a figura:
stereotype use case base
Devolver Livro <<extend>>

use case de extenso

Lanar Multa

Relacionamento De dependncia
Bibliotecrio
(from Actors)

Emprestar Livro

Encontrar Livro

40

Modelagem Use Case Avanada

O use case base fornece um conjunto de pontos de extenso que so ganchos onde novos comportamentos podem ser adicionados. Os use cases de extenso podem adicionar um conjunto de segmentos de insero que podem ser inseridos dentro do use case base em seus ganchos. O relacionamento <<extend>> pode ser usado para especificar exatamente qual ponto de extenso dentro do use case base ser estendido. O interessante do <<extend>> que o use case base no tem nenhum comhecimento sobre os use cases de extenso ele apenas fornece os ganchos. De fato, o use case base perfeitamente completo sem suas extenses, diferentemente do <<include>> onde os use cases clientes no so completos sem os seus use cases de incluso.

Modelagem Use Case Avanada

Mais ainda, os pontos de extenso no so verdadeiramente inseridos no fluxo de eventos do use case base; ao invs disso, eles ficam acima do fluxo de eventos. Pontos de extenso so indicados no fluxo de eventos do use case base como ilustra a figura ao seguinte:

41

Modelagem Use Case Avanada

use case base
ID: UC9 Atores: Bibliotecrio Devolver Livro

Devolver Livro

nome do ponto de extenso

<<extend>> (dataDevoluoVencid a)

Pr-condies: 1.O Bibliotecrio vlido no sistema Fluxo de eventos: 1. O Bibliotecrio entra com o ID do emprestador. 2. O sistema mostra os detalhes do emprestador incluindo a lista de livros emprestados. 3. O Bibliotecrio procura o livro devolvido nessa lista. <dataDevoluoVencida> 4. O Bibliotecrio d baixa no livro. 5. ... Ps-condies: O livro foi devolvido.

ponto de extenso
Lanar Multa

use case de extenso

Modelagem Use Case Avanada

Note que o ponto de extenso no fluxo base no numerado, ele aparece entre os passos numerados do fluxo. Portanto, eles no fazem parte do fluxo principal. Voc pode pensar nesta sobreposio como um filme de acetato sobre o fluxo principal, onde os pontos de extenso so registrados. Em outras palavras, o fluxo do use case base no sabe ou no se preocupa onde ele est sendo estendido. Isso permite que voc use o <<extend>> para fazer extenses arbitrrias para um fluxo do use case base. No exemplo, voc pode ver que o use case base Devolver Livro tem um ponto de extenso chamado <dataDevoluoVencida> entre os passos 3 e 4 do fluxo de eventos.

42

Modelagem Use Case Avanada

Voc pode ver que <<extend>> fornece uma boa maneira de lidar com casos excepcionais, ou casos em que voc precisa de uma estrutura flexvel porque voc no pode predizer (ou apenas no sabe) todas as possveis extenses.

Modelagem Use Case Avanada

Os Use Cases de Extenso
Geralmente, os use cases de extenso no so completos e, assim, no podem ser instanciados. Normalmente consistem apenas de alguns fragmentos de comportamento conhecidos como segmentos de insero. O relacionamento <<extend>> especifica os pontos de extenso no use case base onde o seguimento de insero ser inserido. As seguintes regras se aplicam:
O relacionamento <<extend>> deve especificar um ou mais pontos de extenso no use case base ou que o se refere a todos os pontos de extenso. O use case de extenso deve ter o mesmo nmero de segmentos de insero do que os pontos de extenso especificados no relacionamento <<extend>>. possvel que dois use cases de extenso estendam um mesmo use case base num mesmo ponto de extenso. Se isso ocorrer, a ordem de execuo das extenses indeterminada.

43

Modelagem Use Case Avanada

um nico segmento do use case Lanar Multa inserida no ponto de insero <dataDevoluoVencida> no use case Devolver Livro

Devolver Livro

<<extend>> (dataDevoluoVencid a)

Use case de extenso: Lanar Multa ID: UC10 Pr-Condies: 1. Existe livros em atrasado.

Lanar Multa

Segmento de Insero: 1. O Bibliotecrio usa o sistema para registrar e imprimir a multa. Ps-condies: Multa registrada.

Modelagem Use Case Avanada

Mltiplos Segmentos de Insero:
Voc pode ter mltiplos segmentos de insero num use case de extenso. Isso til quando voc no consegue capturar a extenso claramente num nico segmento de insero devido a necessidade de retornar ao fluxo principal do use case base para fazer alguma coisa.

44

Modelagem Use Case Avanada

o primeiro segmento de insero do use case Lanar Multa inserida no ponto de insero <dataDevoluoVencida> e o segundo segmento de insero no <pagamentoMulta>

Devo lve r Livro

Use case de extenso: Lanar Multa ID: UC10 Pr-Condies: 1. Existe livros em atrasado. Segmento de Insero 1: 1. O Bibliotecrio usa o sistema para registrar e imprimir a multa. Segmento de Insero 2: 1. Se o emprestador escolher pagar o total da multa imediatamente ento 1.1. O Bibliotecrio aceita o pagamento da multa. 1.2. ... Ps-condies: Multa registrada.

<<exten d>> (dataDevoluoVencida, pagam entoDaMulta)

Lanar Mul ta

Modelagem Use Case Avanada

No exemplo, voc pode imaginar que depois de registrar e imprimir a multa, voltamos para o fluxo principal para processar o prximo livro com data de vencimento em atraso e, ento, finalmente, no ponto de extenso <pagamentoDaMulta>, ns damos ao emprestador a opo de pagar toda a multa. Isto claramente mais eficiente do que ter que imprimir e receber o pagamento para cada multa individualmente, o que seria o caso se tivssemos combinado os dois seguimentos em um nico seguimento de Lanar Multa. Esse exemplo interessante porque voc pode ver o segundo seguimento de insero comeando com a declarao Se. Como tal, ele um fluxo condicional, e s por isso, torna-se um bom candidato para ser um use case de extenso. Use cases de extenso, por sua vez, podem ter extenses e incluses. Mas, cuidado; no muito bom ter muitos <<include>> e <<extend>> num modelo use case.

45

Modelagem Use Case Avanada

Extenses Condicionais
O exemplo a seguir ilustra um sistema de biblioteca um pouco mais agradvel onde o emprestador advertido na primeira vez em que um livro entregue em atraso e cobrado a multa nas outras vezes. Podemos modelar isso adicionando um novo use case de extenso, Advertir pelo Atraso, e ento colocar condies sobre os relacionamentos de extenso. As condies so expresses booleanas, e a insero feita, se e somente se, a expresso avaliada for verdadeira.

Modelagem Use Case Avanada

Devolver Li vro

<<extend>> ( dataDevol uoVen cida ) [ prim ei raVez ]

<<extend>> (dataDevoluoVencida, pagam entoDaMulta) [ !prim eiraVez ]

Advertir pelo Atras o

L anar Mul ta

46

Modelagem Use Case Avanada

Quando usar Caractersticas Avanadas
Use as caractersticas avanadas quando elas simplificarem o modelo use case. Lembre-se que o modelo use case uma declarao de requisitos e, como tal, deve ser acessvel aos stakeholders e modeladores. Com base em nossa experincia em vrias empresas:
Geralmente, os stakeholders entendem facilmente atores e use cases com pouco de treinamento e auxlio. Stakeholders acham difcil de entender a generalizao de atores. O uso abusivo de <<includes>> pode tornar o modelo difcil de entender. Stakeholders acham muito difcil entender o <<extend>>. Um nmero surpreendentemente grande de modeladores compreendem mal a semntica do <<extend>> A generalizao de use cases deve ser evitado.

47