Padres de Requisitos para Especificao de Casos de Uso em Sistemas de Informao

Gabriela T. de Souza1, 2, Carlo Giovano S. Pires 2 e Arnaldo Dias Belchior1 Universidade de Fortaleza Av. Washington Soares, 1321 Fortaleza CE Brasil Instituto Atlntico Rua Chico Lemos, 946 60 822-780 Fortaleza CE Brasil
belchior@unifor.br, {gabi,cgiovano}@atlantico.com.br
2 1

Abstract. This work presents a set of requirement patterns for information systems. These patterns are based on the use case concept and present solutions for use cases specification problems, considering maintenance (insert, update and delete), transaction and query functionalities, which are a representative part of information systems scope. Resumo. Este trabalho apresenta um conjunto de padres de requisitos para sistemas de informao. Esses padres so fundamentados no conceito de casos de uso e apresentam solues para problemas de especificao de casos de uso, considerando funcionalidades de manuteno (incluso, alterao e excluso), transao e consulta, que representam um volume significativo do escopo de sistemas de informao.

1. Introduo
Este trabalho apresenta um conjunto de padres de requisitos para sistemas de informao, que so fundamentados no conceito de casos de uso. Esses padres abordam solues para problemas de especificao casos de uso considerando questes de manuteno, consultas, relatrios e operaes de transao. Isto representa um volume significativo do escopo de sistemas de informao. O relacionamento entre os padres apresentados pode ser visto na Figura 1. Caso de uso um conceito amplamente difundido e utilizado para a documentao e o desenvolvimento de requisitos. Segundo o RUP [5], caso de uso uma descrio de comportamento do sistema em termos de seqncias de aes. Um caso de uso deve produzir um resultado de valor observvel para um ator. Ele contm todos os fluxos de eventos referentes produo do "resultado de valor observvel". Mais formalmente, um caso de uso define um conjunto de instncias de casos de uso ou cenrios [5]. O CMMI indica que casos de uso podem ser usados na elicitao e anlise de requisitos para estabelecer os cenrios operacionais do sistema [3]. Ou seja, alm de representar os requisitos, os casos de uso tambm descrevem uma soluo em alto nvel.

1, 2

Copyright 2005, Gabriela T. de Souza, Carlo Giovano S. Pires e Arnaldo Dias Belchior. Permisso de cpia concedida para a Conferncia Sugarloaf-PLoP 2005. Todos os outros direitos reservados.

Este trabalho utiliza um formato de caso de uso definido pela Rational [5], que compreende sees como fluxos bsicos e alternativos, subfluxos de execuo, requisitos especiais e regras de negcio. Sero apresentados os seguintes padres: (i) padro caso de uso CRUD; (ii) padro documentao de atributos; (iii) padro caso de uso relatrio; (iv) padro caso de uso transao e (v) padro caso de uso assistente.
Caso de Uso CRUD Caso de Uso Transao

Documentao de Atributos

Caso de Uso Relatrio

Caso de Uso Assistente

Figura 1: Relacionamento entre os padres apresentados

2. Padro Caso de Uso CRUD

2.1. Contexto Este padro utilizado para a documentao dos requisitos de manuteno em sistemas da informao, por meio do uso de modelos e especificaes de casos de uso. Os requisitos de manuteno so caracterizados por operaes de Incluso, Consulta, Alterao e Excluso. 2.2. Problema Como documentar os requisitos funcionais de insero, atualizao, excluso e consulta de dados por meio de especificaes de casos de uso? 2.3. Foras - Todo caso de uso deve demonstrar um valor observvel [5]. Em alguns casos, o usurio identifica o valor observvel como a manuteno da entidade. Em outros casos, o valor observvel est nas operaes individuais de Incluso, Consulta, Alterao e Excluso. - As operaes de manuteno podem ocorrer tanto sobre entidades simples, com poucos atributos, como em entidades complexas, com vrios atributos e relacionamentos. - As operaes de incluso, alterao, remoo e consulta devem ser tratadas e seus requisitos documentados. Esses requisitos incluem validao de atributos e regras de negcio. - Os atributos mantidos de cada entidade devem ser documentados. - Os requisitos documentados devem ser de fcil entendimento para os usurios e para a equipe de desenvolvimento.

- Uma quantidade grande de casos de uso dificulta a gesto dos requisitos e pode indicar a existncia de decomposio funcional. 2.4. Soluo Organizar o fluxo de eventos do caso de uso em cinco subfluxos (Fluxo bsico, Incluir, Alterar, Remover e Consultar) como se segue: - O Fluxo bsico descreve a condio de incio e desvia o fluxo para um dos sub-fluxos, de acordo com as operaes disponveis: Incluir, Alterar, Excluir e Consultar. Condies de incio indicam os eventos que provocam a execuo do caso de uso. Por exemplo, em que situao a entidade deve ser mantida, se existe alguma periodicidade requerida ou alguma questo de permisso de acesso. - Cada subfluxo descreve o cenrio operacional de uma das funcionalidades: Incluir, Alterar, Remover e Consultar. - O subfluxo Incluir apresenta os atributos para a incluso e descreve o comportamento da incluso. - O subfluxo Alterar apresenta os atributos atualizveis, exibe seus valores e descreve o comportamento da atualizao. Se os atributos atualizveis forem os mesmos apresentados no subfluxo Incluir, pode-se referenciar este subfluxo. - O subfluxo Remover descreve o comportamento da remoo e documenta as restries da excluso da entidade. Por exemplo, se alguma regra de negcio deve ser acionada ou se uma confirmao para a excluso exigida. - O subfluxo Consultar documenta requisitos para localizao da entidade, que atributos devem ser filtros para a consulta, quais so obrigatrios e quais atributos so exibidos no resultado. - As validaes de atributos e regras de negcio so documentadas em uma seo independente dos fluxos e subfluxos, ver o padro Documentao de Atributo. A deciso sobre o momento no qual as validaes e regras so executadas far parte do projeto do caso de uso. No entanto, se esse momento j for identificado como um requisito claro da aplicao, a regra ou validao deve ser referenciada pelo subfluxo. As regras de negcio, tipicamente, representam requisitos de clculos e tratamento de relacionamentos com outras entidades. As validaes, tipicamente, documentam o tratamento para a obrigatoriedade de atributos e o tratamento de formato de atributos (datas, limites numricos, entre outros). 2.4.1 Estrutura Fluxo bsico (happy day) 1. O caso de uso inicia quando o <nome do ator> necessita fazer a manuteno (incluso, alterao, excluso ou consulta) de uma <nome da entidade>. <descrever a condio de incio do caso de uso> 2. De acordo com o tipo de manuteno desejado pelo <nome do ator>, um dos subfluxos executado:

a. Se o <nome do ator> deseja incluir uma nova <nome da entidade> , o sub-fluxo Incluir <nome da entidade> executado. b. Se o <nome do ator> deseja alterar informaes de uma <nome da entidade> j cadastrada, o sub-fluxo Alterar <nome da entidade> executado. c. Se o <nome do ator> deseja excluir uma <nome da entidade> j cadastrada, o sub-fluxo Remover <nome da entidade> executado. d. Se o <nome do ator> deseja consultar informaes sobre uma ou mais <nome da entidade> cadastradas, o sub-fluxo Consultar <nome da entidade> executado. Subfluxo Incluir <nome da entidade> 1. Este subfluxo inicia quando o <nome do ator> solicita incluir um <nome da entidade>; 2. O sistema solicita ao <nome do ator> o preenchimento dos seguintes atributos: 3. 4. 5. - <lista de atributos>. O <nome do ator> preenche os atributos acima e confirma a incluso; O sistema realiza a incluso dos dados informados pelo <nome do ator> no passo 3; O sistema exibe uma mensagem informando que a incluso da <nome da entidade> foi efetivada com sucesso;

Subfluxo Alterar <nome da entidade> 1. Este fluxo inicia quando o <nome do ator> solicita alterar um <nome da entidade>; 2. O <nome do ator> seleciona um nico <nome da entidade>; 3. O sistema solicita a alterao dos seguintes atributos: 4. 5. 6. - <lista de atributos que podem ser alterados> O <nome do ator> altera os dados desejados e confirma a alterao; O sistema realiza a alterao dos dados informados no passo 4; O sistema exibe uma mensagem de confirmao informando que a alterao do <nome da entidade> foi efetivada com sucesso;

Subfluxo Remover <nome da entidade> 1. Este subfluxo inicia quando o <nome do ator> solicita remover um ou mais <nome da entidade>; 2. O <nome do ator> seleciona quais <nome da entidade> deseja remover e solicita a remoo; 3. O sistema solicita a confirmao para a remoo; 4. O <nome do ator> confirma a remoo; 5. O sistema remove os <nome da entidade> confirmados; 6. O sistema exibe uma mensagem informando que a remoo dos <nome da entidade> foi efetivada com sucesso;

Subfluxo Consultar <nome da entidade> 1. Este fluxo inicia quando o <nome do ator> solicita consultar <nome da entidade>; 2. O sistema solicita o preenchimento dos seguintes filtros: 3. 4. - <lista de filtros>. O <nome do ator> preenche os filtros e solicita a consulta; O sistema apresenta as seguintes informaes dos <nome da entidade> obtidos na consulta: - <lista de atributos>. Validaes e regras de negcio - Esta regra se aplica a todos os sub-fluxos. Atributos obrigatrios. Se algum atributo obrigatrio no tiver sido preenchido, <descrever que aes o sistema deve tomar, por exemplo, o sistema no completar a operao e notificar ao <nome do ator>, solicitando o preenchimento>; - Esta regra se aplica a todos os sub-fluxos. Atributos com valores no permitidos. Se algum atributo for preenchido com valor no permitido, <descrever que aes o sistema deve tomar, por exemplo, o sistema no completar a operao e notificar ao <nome do ator>, solicitando o preenchimento>; - No subfluxo Remover, o sistema valida os <nome da entidade> selecionados de acordo com as seguintes regras: o <regras de remoo>. 2.5. Conseqncias - As operaes de manuteno e seus requisitos so documentadas de forma padronizada e estruturada para os diversos tipos de entidade, melhorando o entendimento do comportamento e dos requisitos, facilitando o desenvolvimento de produtos de trabalho das fases seguintes, como por exemplo, anlise, projeto e casos de teste; - As validaes e regras de negcio so documentadas de maneira estruturada, evitando omisses e destacando sua importncia; - Os atributos e informaes requeridos em cada operao so documentados, facilitando o entendimento da estrutura do sistema e facilitando a modelagem de dados e prototipao de telas; - Fornece suporte ao conceito de caso de uso definido em [5]: todo caso de uso deve demonstrar um valor observvel. A soluo utiliza o conceito de sub-fluxos para agrupar em um nico caso de uso as operaes de Incluso, Consulta, Alterao e Excluso. - Reduz o nmero de casos de uso do sistema por meio do agrupamento da especificao das operaes de manuteno em um nico caso de uso, facilitando a gesto dos requisitos.

2.6. Padres relacionados - Padro Documentao de Atributos: o Utilizado no subfluxo Inserir para listar os atributos da entidade; no subfluxo Alterar, para descrever os atributos que podem ser alterados; e no subfluxo Consultar, para descrever os filtros e atributos que sero exibidos no resultado da consulta.

3. Padro Documentao de Atributos

3.1. Contexto Em sistemas de informao, os atributos das entidades possuem diversas caractersticas como: nome, descrio, obrigatoriedade, validaes, semntica, entre outras. Portanto, a documentao desses atributos deve ser elaborada de forma que essas caractersticas no sejam esquecidas. 3.2. Problema Como definir e documentar de forma padronizada os diversos atributos das entidades, que so informaes necessrias durante operaes CRUD? 3.3. Foras - Atributos podem ser de tipos primitivos, enumerados, multivalorados ou de relacionamentos. Os atributos enumerados podem assumir um valor dentro de um domnio fixo de valores. Os atributos de relacionamentos podem assumir como valor uma referncia para outras entidades cadastradas no sistema. Os atributos multivalorados podem assumir um ou mais valores referentes a outras entidades cadastradas no sistema. - Os atributos de entidades podem fazer parte de um conjunto de parmetros ou filtros de consulta. - Alguns atributos podem ser opcionais e outros obrigatrios. Atributos obrigatrios devem ter tratamento adequado em caso de no preenchimento na incluso, alterao ou consulta. 3.4. Soluo - Documente os atributos como uma lista itemizada associada a uma operao de consulta, incluso ou alterao. No caso da alterao, se os atributos que podem ser alterados forem os mesmos da incluso pode-se apenas fazer uma referncia aos atributos listados na incluso. - Uma descrio breve do atributo deve ser fornecida, quando necessrio. - Marque com um caractere especial os atributos obrigatrios (*, por exemplo). - Para atributos que indicam relacionamento, indique que um campo de escolha fechada e indique a fonte origem dos dados de escolha. Por exemplo: Unidade federativa (campo de escolha fechada. Valores possveis: todas as unidades federativas cadastradas no sistema).

- Para atributos enumerados, indique que um campo de escolha fechada e indique os valores possveis. Por exemplo: Sexo (campo de escolha fechada. Valores possveis: feminino e masculino). - Para atributos multivalorados, indique que um campo de escolha mltipla e indique a fonte origem dos dados de escolha. Por exemplo: Autor do livro (campo de escolha mltipla. Valores possveis: todos os autores cadastrados no sistema). - Alguns atributos possuem restrio quanto aos valores aceitos. Neste caso, deve-se documentar esta restrio juntamente com o atributo. Por exemplo, o atributo temperatura corprea do paciente s poder assumir valores entre 35 e 42 graus. 3.4.1 Estrutura - <atributo>. <descrio do atributo> - <caractere> <atributo obrigatrio> - <atributo> (Campo de escolha fechada. Valores possveis: <entidade origem dos dados>). <descrio do atributo> - <atributo> (Campo de escolha fechada. Valores possveis: <valor 1>, <valor 2>, ... <valor n>). <descrio do atributo> - <atributo> (Campo de escolha mltipla. Valores possveis: <entidade origem dos dados>). <descrio do atributo> - <atributo>. <descrio da validao de valores aceitos> 3.5. Exemplo Este exemplo apresenta o subfluxo Incluir da entidade cliente de uma aplicao de CallCenter. Incluir Cliente 1. Este subfluxo inicia quando o Operador de Telemarketing solicita incluir um cliente; 2. O sistema solicita ao Operador de Telemarketing o preenchimento dos seguintes atributos: - * Nome; - * Logradouro. Descreve a rua ou a avenida em que o cliente reside; - * Nmero; - * Bairro; - * Cidade; - * Estado (campo de escolha fechada. Valores possveis: todas os estados cadastrados no sistema); - CPF; - Sexo (campo de escolha fechada. Valores possveis: feminino e masculino).

3. 4. 5.

O Operador de Telemarketing preenche os atributos acima e confirma a incluso; O sistema realiza a incluso dos dados informados pelo Operador de Telemarketing no passo 3; O sistema exibe uma mensagem informando que a incluso do cliente foi efetivada com sucesso;

3.6. Conseqncias - Os diversos tipos de atributos so documentados de forma simples e padronizada. - Os atributos obrigatrios so declarados claramente, facilitando sua identificao e tratamento da implementao e testes.

4. Padro Caso de Uso Relatrio

4.1. Contexto Em sistemas de informao, uma grande quantidade de dados armazenada freqentemente. Neste contexto, surge a necessidade de visualizar, exportar ou imprimir dados armazenados com o objetivo de conferir, analisar e tomar decises com base nesses dados. 4.2. Problema Como documentar os requisitos de relatrios que podem incluir a necessidade de visualizar, exportar ou imprimir dados de entidades de acordo com filtros especificados, agrupamentos, totalizaes e informaes a serem apresentadas? 4.3. Foras - O sistema deve permitir extrair dados em diversos formatos (tela, arquivo e impresso). - O sistema deve tratar a estrutura do relatrio, como por exemplo, disposio dos campos, cabealho e rodap, tamanho da fonte e orientao do papel. - O sistema deve tratar as necessidades para exibio dos dados, como por exemplo, se os dados devem ser agrupados, se devem ser apresentadas totalizaes e se existe a necessidade de algum filtro para restringir os dados que sero apresentados. 4.4. Soluo - O Fluxo bsico descreve que atributos devem ser filtros, quais so de preenchimento obrigatrio e quais atributos devem ser exibidos no cabealho, corpo ou rodap. - O Fluxo bsico descreve a condio de incio. Condies de incio indicam os eventos que provocam a execuo do caso de uso. Por exemplo: em que situao o relatrio deve ser visualizado ou impresso; ou se existe alguma periodicidade requerida.

- Os requisitos especiais so documentados em uma seo independente dos fluxos e subfluxos. Tipicamente, devem ser documentados requisitos de exportao para diversos formatos, regras das sees (regras de agrupamento, clculo para totalizao) e opes de ordenao. Um desenho esquemtico do relatrio e suas sees pode tambm ser apresentado. Descrever tambm o critrio para filtro ou extrao de dados. 4.4.1 Estrutura Fluxo bsico (happy day) 1. Este fluxo inicia quando o <nome do ator> solicita gerar o relatrio <nome do relatrio>. <descrever a condio de incio do caso de uso>; 2. O sistema solicita o preenchimento dos seguintes filtros: 3. - <lista de filtros>. Uma vez que o <nome do ator> fornea a informao solicitada, uma das seguintes aes executada: - Se o <nome do ator> selecionar Imprimir, <descrever ao que deve ser executada>; - Se o <nome do ator> selecionar Visualizar, <descrever ao que deve ser executada>; - Se o <nome do ator> selecionar Exportar, <descrever ao que deve ser executada>; O sistema apresenta o resultado na seguinte forma: - Cabealho. <descrever as informaes que devem est contidas no cabealho>; - Corpo. <descrever as informaes que devem estar contidas no corpo, informando lista de atributos, sees de agrupamento, e quebra de seo>; - Rodap. <descrever as informaes que devem estar contidas no rodap>; - Totalizao. <descrever que totalizaes devem ser exibidas>. Requisitos especiais - Exportar para diversos formatos. <descrever para que formatos o resultado do relatrio deve ser exportado, informando os requisitos necessrios para a exportao de cada formato>; - Regras das sees. <descrever quais so as regras de agrupamento de sees e as regras para o clculo das totalizaes>; - Opes de ordenao. <listar as opes de ordenao disponveis e descrever os requisitos para essas ordenaes>. - Regra de extrao. <expresso lgica descrevendo como os atributos de filtro e outros critrios devem ser combinados para extrair os dados corretamente> - Modelo de desenho esquemtico: <Logo><Sistema> <Ttulo>

4.

<Grupo1> <Campo 1> <Total grupo 1> <Campo 2> <Soma campo 2> <Pgina x de y> 4.5. Exemplo Este exemplo apresenta um relatrio de cliente de uma aplicao de CallCenter. O relatrio possui totalizaes por bairro. Fluxo bsico (happy day) 5. Este fluxo inicia quando o Operador de Telemarketing solicita gerar o relatrio de clientes por bairro. Este relatrio deve ser executado antes da avaliao da carteira de clientes; 6. O sistema solicita o preenchimento dos seguintes filtros: 7. - Cdigo da filial. Uma vez que o Operador de Telemarketing fornea a informao solicitada, uma das seguintes aes executada: - Se o Operador de Telemarketing selecionar Imprimir, o sistema deve apresentar a janela de configurao de impresso; - Se o Operador de Telemarketing selecionar Visualizar, o sistema deve apresentar uma janela com a visualizao do relatrio; - Se o Operador de Telemarketing selecionar Exportar, o sistema deve solicitar o tipo de arquivo a ser exportado e gerar o arquivo solicitado conforme padro definido nos requisitos especiais; O sistema apresenta o resultado na seguinte forma: - Cabealho. Deve conter o nome do relatrio, nome da empresa, nome da filial e a data em que o relatrio foi executado; - Corpo. Os clientes devem ser agrupados por bairro e as sees devem conter quebras de pgina a cada bairro. Os seguintes atributos devem ser apresentados: nome do bairro, nome, telefone e data de cadastro do cliente; - Rodap. Deve conter o nmero da pgina; - Totalizao. As totalizaes devem ser efetuadas por bairro, apresentando quantos clientes existem em cada bairro. Requisitos especiais - Exportar para diversos formatos. Os dados deste relatrio devem ser exportados para o Excel, apresentado as informaes em colunas; - Opes de ordenao. O relatrio deve ser ordenado por nome do bairro e posteriormente por nome do cliente.

8.

- Regra de extrao. Devem ser apresentados no relatrio todos os clientes cadastrados no sistema e que so relacionados filial selecionada no filtro. A identificao da filial encontra-se no cadastro do cliente. - Modelo de desenho esquemtico: Empresa de Telemarketing Filial Norte Amrica Relatrio de clientes por bairro 01/01/2005 Bairro: Varjota Nome Gabriela Souza Carlo Pires Telefone 32678950 29087654 Data de Cadastro 01/01/2004 23/04/2004 2 Pgina 1 4.6. Conseqncias - As opes e formatos para extrao so descritos. - A estrutura do relatrio e das sees documentada de forma clara e estruturada. - Os requisitos para extrao da informao so documentados. 4.7. Padres relacionados - Padro Documentao de Atributos: o Utilizado no Fluxo bsico para listar os filtros.

Total de clientes da Varjota:

5. Padro Caso de Uso Transao

5.1. Contexto Este padro utilizado para a documentao dos requisitos de operaes que so tratadas como um comando atmico que processa vrias transaes. Tipicamente operaes batch e operaes que requerem apenas um comando de inicio do caso de uso pelo usurio tendo pouca entrada de dados e iterao com o sistema. 5.2. Problema Como documentar os requisitos de operaes que possuem a execuo de longa durao ou que so executadas em formato de comando atmico, dando nfase para os requisitos especiais dessas operaes?

5.3. Foras - Transaes que ocorrem freqentemente em sistemas de informao possuem vrias caractersticas em comum e importante que fiquem documentadas de forma uniforme para facilitar o entendimento dos casos de uso. - O usurio necessita de informao sobre o progresso e o tempo estimado para a concluso da operao. - O usurio pode no ter familiaridade com a complexidade da tarefa. - Transaes complexas podem envolver algoritmos e clculos. - Durante a operao o usurio pode decidir interromp-la. 5.4. Soluo - Os requisitos devem documentar a durao mdia do tempo de execuo da operao. - O Fluxo bsico descreve que atributos devem ser fornecidos para a execuo da operao, indicando quais so obrigatrios. - O Fluxo bsico descreve a condio de incio. Condies de incio indicam os eventos que provocam a execuo do caso de uso. Por exemplo, em que situao o caso de uso dever ser executado ou se existe alguma periodicidade requerida. - O Fluxo bsico deve indicar que existe uma opo de cancelamento que pode ser solicitada a qualquer momento. - Os requisitos especiais descrevem como o progresso da operao ser apresentado. O progresso tipicamente o momento restante para o trmino, o nmero das unidades processadas ou a porcentagem do trabalho feita. Tipicamente deve ser fornecido para o usurio o status da execuo da operao, informando se a operao ainda est sendo executada, e quanto tempo o usurio necessitar esperar. 5.4.1 Estrutura Fluxo bsico (happy day) 1. Este fluxo inicia quando o <nome do ator> solicita executar a <nome da transao>. <descrever a condio de incio do caso de uso>; 2. O sistema solicita o preenchimento dos seguintes dados: 3. 4. - <lista de atributos de parmetro para a transao>. O <nome do ator> preenche os dados solicitados no passo 2 e confirma a execuo da operao; O sistema executa a operao: - <Operaes, indicaes de algoritmos e de clculos executados na operao> Requisitos especiais

- O progresso da operao dever ser apresentado em <descrever a unidade ou formato em que ser apresentado o progresso da operao>. Regras de negcio - Descrio de algoritmos e clculos eventualmente utilizados na operao. 5.5. Conseqncias - O retorno sobre o status da execuo da transao fornecido; - Os passos da transao, algoritmos e clculos so documentados de forma clara. 5.6. Variantes - Em transaes curtas, o tratamento do progresso da operao pode ser suprimido. 5.7. Padres relacionados - Padro Documentao de Atributos: o Utilizado no Fluxo bsico para listar os filtros.

6. Padro Caso de Uso Assistente

6.1. Contexto Este padro utilizado para a documentao dos requisitos de operaes complexas que so executadas em diversos passos, onde decises ou dados necessitam serem informados em cada passo atravs da iterao com o usurio. Por exemplo, o caso de uso Submeter Proposta de Seguro realizado em trs passos. No passo inicial o proponente informa a cidade e o estado onde o veculo ir circular e os dados do veculo. No segundo passo, o sistema apresenta uma lista de coberturas e preos existentes de acordo com os dados informados no passo 1. O proponente seleciona as coberturas desejadas e avana para o passo seguinte. No terceiro e ltimo passo o sistema apresenta o preo total do seguro e solicita a concluso da operao. 6.2. Problema Como documentar os requisitos de uma operao, na qual diversas decises devem ser tomadas antes que a operao possa ser concluda completamente? 6.3. Foras - Para concluir a operao, diversos passos precisam ser realizados. - Um determinado passo pode necessitar ser terminado antes que o passo seguinte possa ser feito.

6.4. Soluo - O Fluxo bsico descreve o objetivo da operao e quantos passos precisam ser executados. - O Fluxo bsico descreve a condio de incio. Condies de incio indicam os eventos que provocam a execuo do caso de uso. Por exemplo: em que situao o caso de uso dever ser executado ou se existe alguma periodicidade requerida. - O Fluxo bsico deve indicar que existe uma opo de cancelamento que pode ser solicitada a qualquer momento. - Cada Subfluxo Passo <n> deve determinar se o usurio no pode comear o passo seguinte antes de terminar o atual. 6.4.1 Estrutura Fluxo bsico (happy day) 1. O caso de uso inicia quando o <nome do ator> necessita <nome do caso de uso>. <descrever a condio de inicio do caso de uso>; 2. O sistema informa tipicamente o objetivo da operao e quantos passos precisam ser executados; 3. O sistema solicita que o <nome do ator> execute o Passo 1; 4. Uma vez que o <nome do ator> decida executar o Passo 1, subfluxo Passo 1 executado; 5. O caso de uso se encerra. Sub-fluxo Passo 1 1. Este subfluxo se inicia quando o <nome do ator> solicita <descrever as aes que sero executadas neste passo>; 2. O sistema solicita ao <nome do ator> o preenchimento dos seguintes atributos: 3. 4. 5. - <lista de atributos>. O <nome do ator> preenche os atributos do passo 2; O sistema solicita que o <nome do ator> execute o passo n; Uma vez que o <nome do ator> decida executar o passo <n>, subfluxo Passo <n> executado;

Sub-fluxo Passo <n> 1. Este subfluxo se inicia quando o <nome do ator> solicita <descrever as aes que sero executadas neste passo>; 2. Para este subfluxo ser executado os subfluxos <passo 1, passo 2, ... passo n> devem ter sido executados; (no est previsto haver passos opcionais (ou alternativos? Essa seqncia linear parece limitar o uso do padro...) 3. O sistema solicita ao <nome do ator> o preenchimento dos seguintes atributos: 4. 5. - <lista de atributos>. O <nome do ator> preenche os atributos do passo 2; O sistema solicita que o <nome do ator> execute o passo <n+1> ou conclua a operao;

6. 7.

Uma vez que o <nome do ator> decida executar o passo <n+1>, subfluxo Passo <n+1> executado; O caso de uso retorna para o passo 5 do fluxo bsico.

Sub-fluxo Passo <final> 1. Este subfluxo se inicia quando o <nome do ator> solicita <descrever as aes que sero executadas neste passo>; 2. Para este subfluxo ser executado os subfluxos <passo 1, passo 2, ... passo n> devem ter sido executados; 3. O sistema solicita ao <nome do ator> o preenchimento dos seguintes atributos: 4. 5. 6. - <lista de atributos>. O <nome do ator> preenche os atributos do passo 2; O sistema solicita que o <nome do ator> conclua a operao; O caso de uso retorna para o passo 5 do fluxo bsico.

6.5. Conseqncias - Organiza e documenta todos os passos que devem ser realizados para concluir uma operao complexa. - Permite que o usurio possa realizar intervenes, decises e configuraes em estgios intermedirios de uma operao complexa. 6.6. Padres relacionados - Padro Documentao de Atributos: o Utilizado no Fluxo bsico e subfluxos para listar os atributos.

7. Usos conhecidos
Os padres apresentados neste artigo tm sido utilizados na fase de elicitao de requisitos em diversos sistemas, tais como um sistema Imobilirio, um sistema de Portal web para administrado e publicao de informaes de acervos culturais e um sistema de CallCenter. Porm, por motivos de confidencialidade, mais detalhes dos usos conhecidos no podem ser fornecidos. Em [5], os exemplos de casos de uso CRUD seguem estrutura similar a proposta no padro Caso de Uso CRUD.

Referncias
[1] Alur, D.; Crupi, J.; Malks, D. Core J2EE Patterns: as melhores prticas e estratgias de design, Editora Campus, 2002. [2] Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P. Pattern-Oriented Software Architecture, John Wiley & Sons, 2001. [3] Chrissis, M. B., Konrad, M., Shrum, S. CMMI Guidelines for Process Integration and Product Improvement. Addison-Wesley, 2004.

[4] Gamma, E.; Helm R.; Johnson, R.; and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. [5] Rational Unified Process, Version 2002.05.00. Rational Software Corporation, 2001. [6] Souza, G. T. e Pires, C. G. Uma Famlia de Padres para Sistemas de Informao Baseada no Padro MVC. Sugarloaf-PloP, 2004. [7] Souza, G. T.; Pires, C.G.; e Barros, M. Padres MVC para Sistemas de Informao. Sugarloaf-PloP, 2003. [8] Yoder, J.W.; Johnson, R.E.; Wilson, Q.D. Connecting Business Objects to Relational Databases. Fifth Conference on Patterns Languages of Programs, Monticello, Illinois, EUA, 1998. (Relatrio tcnico n WUCS-98-25 da Universidade de Washington).