Conceito Capitulo 5 - UML—Casos DE UTILIZACAO Topicos = Introducio = Casos de Utilizagio * Diagramas de Casos de Utilizacio * Proposta de Metodologia = Exemplos e Recomendagées = Exercicios 5.1 Introdug¢ao A engenharia de requisitos [Sommerville97, Kulak00, Cockburn00] é uma area que se preocupa entre outros aspectos com a captura, anidlise, especificacao, validacio, negociacao e gestio de requisitos de um sistema em geral e de sistemas de software ¢ hardware em particular. Um requisito é uma especificacio de uma determinada accio, condigio ou neces- sidade que o sistema devera satisfazer. Um requisito funcional descreve uma determinada acc&o (ou fungao) que o sistema devera providenciar. Por outro lado, um requisito nio funcional descreve um aspecto (nao funcional) que o sistema devera satisfazer. Requisitos nao funcionais, também designados por “propriedade emergentes”, referem-se a aspectos transversais, normalmente apli- caveis a todo o sistema, tais como: desempenho, robustez, fiabilidade, distribuicio, seguranca, integracdo com a Internet, facilidade de manutencio, usabilidade, ou suporte de standards. Por influéncia de métodos desenvolvidos na primeira metade da década de 1990, em particular pelo método de Ivar Jacobson, OOSE ou Objectory [Jacobson92J, 0132 CENTRO ATLANTIC ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | UML inclui os diagramas de casos de utilizagao (use cases) que permitem capturar os requisitos funcionais, segundo uma aproximagio focada primosdialmente na utilizagao do sistema, A modelagio de requisitos funcionais (¢ mesmo 0 préprio desenvolvimento de software) através de especificagio de casos de utilizagio € actualmente considerada como uma abordagem extremamente adequada, quer por facilitar a comunicagio entre a equipa de projecto ¢ os clientes/utilizadores, quer ainda por promover a comunicacio, gestio ¢ condugio no desenvolvimento do proprio projecto. Fista telagio entre casos de utilizagio e requisitos nio é pacifica ¢ clara, Antes pelo contritio, Ha autores, por exemplo D. Kulak ¢ E. Guiney [Kulak00] ou C. Larman [Larman99], que consideram que os casos de utilizagio sio uma boa forma de representar 08 requisitos. Por outro lado, hd outros autores, por exemplo D. Rosenberg [Rosenberg99], que consideram que requisitos ¢ casos de utilizagao sito conceitos distintos, existindo todavia relagdes entre si, que deverio ser captadas. Hé alguns aspectos importantes na especificagio de requisitos, que tém a ver com a sua apresentagio, organizagio ¢ nivel de detalhe. Quanto a sua apresentagio ¢ organizagao, hi autores que advogam que os requisitos devem ser apresentados visualmente através de diagramas de casos de utilizagio e seguidamente, cada caso em particular, devera ser especificado em detalhe através de uma descrigao textual (segundo um determinado formato defi- nido ¢ usado consistentemente pela equipa de projecto) ¢, opcionalmente, através de um ou mais diagramas de interaccéo ¢/ou desenhos de protétipos de interfaces homem-maquina (c.g, seeenshols de protétipos de aplicagdes). Quando os requisitos sio descritos textualmente, recomenda-se normalmente que sejam mumerados sequencialmente segundo, pelo menos, duas quéncias distintas: tama para os requisitos funcionais e outra para os requisites no funcionais. Por outro lado, quando os requisitos especificados com base nos casos de utilizagao, deve usar-se o elemento pacote do UML como clemento estrururante, ‘A nossa opiniio relativamente a estas duas posicdes (i.c., utilizagio de listas de items de textos, ou utilizagio de pacotes de casos de utilizagiio) € que qualquer uma é vilida desde que seja assumida ¢ usada consistentemente. Da nossa experiéncia «em projectos reais, concluimos que a aproximagio de representar ¢ organizar os requisitos através de casos de utilizagio facilita, em geral, a comunicacio com os utilizadores e clientes ¢ toma mais fécil ¢ eficiente a sua captura ¢ organizacio. ‘Todavia, uma solugio que integre as duas abordagens também é recomendada por alguns autores (vet a propésito deste assunto 0 processo Iconix, discutide no Capitulo 12).Conceito CapiTuLo 5 - UML —Casos DE UTILIZACAO 133 Quanto ao nivel de detalhe da especificagao de requisitos e casos de utilizacio, tal deve ter em consideragio o tipo de projecto em particular, o perfil ¢ exigéncia do cliente, 0 tipo de sistema a especificar, etc. Consoante essas variaveis, € perfei- tamente possivel a descricio de um caso de utilizagio tipico variar entre 1a 10 paginas; ¢, claro, consequentemente € possivel ter-se um sistema especificado numa dezena ou em algumas centenas de paginas. O compromisso da escolha de um nivel de detalhe adequado nem sempre € facil. Se € muito detalhado, o cliente acaba pot responder “é um bom trabalho, mas um pouco grande, talvex confuso, € capaz, de ter algumas incoeréncias, * © claro que normalmente tem dificuldade de o “digerir” convenientemente. Se, por outro lado, é muito geral, o cliente responde qualquer coisa como “sim, ¢ isto que ew quero, mas ni percebo muito bem 0 que ird fazer, nem as capa cidades que ird, de facto, apresentar...”. \ nossa experiéncia sugete que € importante uma teflexio, projecto a project, sobre o nivel de detalhe da especificacio de casos de utilizagio. Em geral, é preferivel a desctiglio de casos de utilizacao de forma nfo muito detalhada, variando, a descrigio de cada caso de utilizaglo entre meia pagina a quatro paginas. 5.2 Casos de Utilizagao Um caso de utilizag&o é “uma sequéncia de acces que um ou mais actotes reali- zam num sistema de modo a obterem um resultado particular” [OMG99}. O modelo de casos de utilizaco permite capturar os requisitos de um sistema atra- vés do detalhe de todos os cenérios que os utilizadores podem tealizar. Os casos de utilizagio, mais que iniciar a modelacao de requisitos de um sistema, podem conduzir todo o proceso de desenvolvimento. Um caso de utilizacio é representado graficamente através de uma oval com uma frase que representa uma determinada accio. A frase deve ser esctita na voz activa, com um verbo no infinitivo. Por exemplo, “Submeter Proposta”, “Criar factura”, “Calibrar toda” ou “Validar utilizador” conforme ilustrado na Figura 5.1. Note-se que tendo em consideracio a definigio de caso de utilizacio (acima especificada), “Validar Utilizador” nfo devera ser encarado como um “verdadeiro” caso de utili- zacio, j4 que por sis ndo produz qualquer “resultado particular” para o sistema. Contudo, nalgumas citcunstincias estes “pseudo” casos de utilizacio aparecem no modelo de forma a explicitar comportamentos comuns a varios casos de utilizacio. (Tais comportamentos poderio alternativamente ser especificados através de assungies, 20 nivel de cada caso ou mesmo ao nivel geral do modelo.)Conceito 134 CENTRO ATLANTICO—UMIL, METODOLOGIAS € FERRAMENTAS CASE ~ VOL. | Valider Utlizador ‘Submeter Proposta Figura 5.1: Representacio grifica de casos de utilizagio. eal Configurar Pagina Pessoa Oficina: Calibrar roda Outro aspecto distintivo dos casos de utilizacio tem a ver com o seu foco. Um caso de utilizagdio descteve um objectivo (ou “tesultado particular”) de um sistema, ow parte deste, mas niio como tal objectivo é realizado. © foco é na visio “externa” do sistema, ou seja, na visio que os utilizadores tém dele. 5.2.1 Casos de utilizagao e Cendrios Um cendrio é uma determinada sequéncia de acces que ilustra um comporta- mento do sistema. Numa definigio mais abstracta, deve-se entender um cenitio como uma instincia de um caso de utilizagio, sendo normal que um caso de utili- zacio possa set descrito por varios cendrios alternativos. Uma designacio alterna- tiva para cenatio por vezes utilizada é “fluxo de accées”. Deve-se especificar 0 comportamento de um caso de utilizacio descrevendo tex- tualmente um ou mais fluxos de acgdes, de modo que um utilizador nio técnico o possa entender sem dificuldade. Tal especificagio deve incluir: = Pressupostos = Assungdes = Pré-condicées = Inicializagdo: como e quando 0 caso de utilizagao comeca = Didlogo: quando é que o caso de utilizagio interactua com os actores * Conclusio: como e quando 0 caso de utilizagio termina = Pos-condigdes Outras formas altetnativas ou complementares, podem ainda incluir a especifica Gio dos actores que iniciam 0 caso de utilizacéo, os actores que beneficiam com 0 caso de utilizacdo, um ou mais diagramas de interaccio, um ou mais diagramas de actividade, etc.Capfruo 5 - UML - Casos DE UTILIZAGAO. 135 Como exemplo apresenta-se de seguida a especificacao textual do caso de util cio “Validar Utilizador” ilustrado na Figura 5.1. Considere-se que este caso de uti- lizagio pertence a um sistema tipo “caixa de multibanco”. Exemplo 5.1: Especificagao textual do caso de utilizagao “Validar Utilizador” no sistema de Caixa de Multibanco, Nome: Validar Utilizador Cenério Principal © caso de utilizagio inicia-se quando o sistema apresenta um ecri a pedir a0 cliente o scu cartao electrénico. O cliente introduz © cartio MB e, através de um pequeno teclado, o seu PIN. O cliente pode limpar a introdugo do seu PIN ind- meras vezes ¢ reintroduzit um novo mimero antes de activar o botio “Entrar”. O cliente activa o botio “Entrar” para confirmar. O sistema Ié o PIN ¢ a respectiva identificagio do cartio MB, ¢ verifica se é wélido. O sistema aceita a entrada ¢ 0 caso de utilizagio termina. Cenatio Alternativo 1 (Cliente cancela operagio) cliente pode cancelar a transaccio em qualquer momento activando 0 botio “Cancelar”, implicando a tcinicializagio do caso de utilizagio. Nio é realizada qualquer alteraciio & conta do cliente. Cenério Alternativo 2 (PIN invalido) Se o cliente introduz um PIN invalido, 0 cartio MB é ejectado € 0 caso de utiliza- io reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema cativa (ie., “reco- Ihe”) 0 cartio MB e cancela a transaccio; nao permitindo qualquer interacgao nos 2 minutos seguintes. Um aspecto importante na especificagio do caso de utilizagio tem a ver com 0 nivel de'detalhe do mesmo. A dimensio da especificacao de um caso de utilizagio varia significativamente consoante 0 tipo de projecto envolvido, os intervenientes do projecto, € as exigéncias impostas pelos clientes. Essa especificagio normal- mente é textual, de modo mais ou menos informal, mas pode ser complementada por diagramas de interaccao (para ajudar a clarificar as interacgdes entre os dife- rentes intervenientes); por diagramas de actividade (para clarificar 0 fluxo de con- trolo entre as varias acgdes); ou até por protétipos de interfaces com utilizadores (eg, desenho de ecriis ou de listagens tipo).Conceito 136 CeNTRO ATLANTICO— UML, MeToDoLoaias & FERRAMENTAS CASE — VoL. | Sempre que possivel, deve-se evitar adoptar um estilo linguistico com uma lingua- gem prdxima de implementagio ¢ de aspectos tecnolégicos. Designadamente, deve-se evitar referir explicitamente: pessoas, em vez de papéis desempenbados; departamentos especificos de uma organizacio; componentes de interface com 0 utilizador (e.g., botdes, menus, caixas de texto ou outros componentes especificos de um determinado paradigma de interagio pessoa-maquina); ou referéncias a dis- positives concretos de hardware, Deve-se igualmente evitar descrigoes em forma- tos técnicos ou formais, tais como pseudocddigo ou especificagées em OCL [Warmer99], ou Z [Diller94]. 5.2.2 Relacées entre Casos de Utilizagao Os casos de utilizagio podem encontrar-se relacionados através de trés tipos de telacdes: generalizacio, incluso e extensio. Estas relagbes permitem a especifica- gio de requisitos com algum nivel de reutilizacio ¢/ou de variabilidade, Ou seja, estas relacdes permitem ao analista aquilo que o programador de linguagens orien- tadas por objectos normalmente pratica: reutilizar trabalho ja efectuado. Este € um aspecto essencial da filosofia dos casos de utilizacio ¢ que normalmente nio ¢ facilmente apreendido pelos praticantes inexperientes. Repare-se que 0 objectivo, neste contexto, nao é a reutilizacao de cédigo, mas sim a reutilizagio de especificagdes (normalmente textuais), com todos os beneficios dai decorrentes. Generalizagao Uma telagio de generalizagio entre casos de utilizagio permite definir casos & custa de outros ja existentes, pelo mecanismo de especializagio, ou alternativa- mente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redugio ou generalizagao. © caso de utilizagio filho herda as propriedades ¢ semintica definidas para o seu pai, podendo substituir especificagdes definidas no seu pai, bem como, podendo introduzit novas especificagées que Ihe sejam especificas.Conceito CapfTuLo 5 - UML - CAsos DE UTILIZAGAO 137 Validar Utilizador Validar com base Yalidar com base sity eee em Password Figura 5.2: Relacao de generalizagio entre casos de utilixacao. A Figura 5.2 ilustra a relagio de generalizacio entre casos de utilizagio. Na pritica ilustra que o caso “Validar Utilizador” é especializado em outros dois, que utilizam diferentes mecanismos de identificagio do utilizador: “Validar com base em Password” e “Validar com base em Smartcard”. Deve-se evitar a utilizacio da relacio de generalizacio entre casos de utilizacio, sendo recomendado, alternativamente, a adopgao das relagdes de incluso © de extensao. Incluséo A relacio de incluso («include») entre casos de utilizagao corresponde a uma relacao tipica de delegacio, significando que 0 caso base incorpora 0 comporta- mento do outro caso telacionado. Usa-se a telacio de incluso pata evitar a descti- cio dos mesmos fluxos de accées intimeras vezes. A relagio de inclusio é repre- sentada por uma relagao de dependéncia (seta a tracejado) com o esterestipo «include».138 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE ~ VOL: ! Yalidar Utilizador ‘wwincludes Realizar Obter Extracto Conta Pagamentos Figura 5.3: Relagio de incluso entre casos de utilizagao. |A Figura 5.3 ilustra um exemplo de utilizagio da relago de inclasio. Considere-se ‘uma vex mais o exemplo da caixa de Multibanco acima apresentado, Os casos de utilizago “Obter Extracto de Conta” ou “Realizar Pagamentos” exigem due seja realizada previamente uma validagio do respectivo utilizador, Para que essa fun- cionalidade nfo seja especificada mais que uma vez, 0s casos anteriores incorpo- sam-na (como sua) a0 estabelecerem uma relacio de incluso com 0 caso “Validar Utilizador”. A questio importante que se coloca é como indiear, ¢ em que ponto da especifica- Gio, que caso de utilizagio relacionado deve ser incorporado no caso base. Este é tum aspecto essencial na compreensio € domfnio dos casos de utilizagio. A explicitagiio desta informagio deve ser efectuada na especificagao textual do respectivo caso de utilizagio. O Exemplo 5.2 clarifica esta questo com a desctigio textual do caso “Obter Extracto” em que € evidente a indicagio do ponto de inclusio através do texto “Incluir.. Exemplo 5.2: Especificagao textual do caso de utilizagao “Obter Extracto de Conta”. Nome: Obter Extracto de Conta Cenitio PrincipalConceito Novo Conceito Novo CaPiTULo 5 - UML —Casos DE UTILIZAGAo. 139 Incluit_caso_de utilizacio “Validar Utilizador”. Obter ¢ verificar © mimero da conta, Seleccionar todas as linhas de movimentos tealizados nos tltimos 30 dias. Produzit uma lista tesumo com esses movimentos, aptesentando a data, o tipo de movimento (débito ou crédito), uma breve descricio ¢ 0 valor do movimento. Produzit o saldo corrente da conta, Emitir um documento com essa informagio, ejectando no terminal de Multibanco o referido documento, Apresentar mensagem no visot do terminal para o cliente retirar 0 extracto. Registar na conta do cliente que esta operagio foi realizada com sucesso. Cenario Alternativo 1 Extensao Uma relagio de extensio («extend») entre casos de utilizagao significa que o caso base incorpora implicitamente 0 seu comportamento num local especificado indirectamente pelo caso que é usado. Ou seja, 0 caso destino pode ser estendido com © comportamento de outto(s) caso(s). Uma relagio de extensio permite representar: * A parte de um caso que um utilizador vé como opcional, ou como existindo varias alternativas. "Um subfluxo de acgdes que é executado apenas se determinadas condigées se verificarem. * Varios fluxos de acces que podem ser inseridos num determinado ponto de extenséo, de forma controlada, através de uma interac¢io explicita com um actor. O caso de utilizagio destino é estendido num ou mais pontos, designados por pontos de extensio os quais sio mecanismos de variabilidade [Jacobson97]. Ou seja, sio pontos de entrada do caso de utilizagao que lhe da algum nivel de confi- gurabilidade e versatilidade. (Nota: Os pontos de extensio sio um dos mecanismos de variabilidade mais comuns no desenho de sistemas de componentes, de frameworks aplicacionais ou de JSrameworks de middleware, que exigem exactamente um clevado grau de versatili- dade.)140 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | Validar Utilizador «includes ‘Seleccionar N° de Dias Extension points: N? de dias Seleccionar Ultimos 30 Dias Figura 5.4: Relayio de extensio entre casos de utilizar. Considere-se 0 caso “Obter Extracto de Conta” do exemplo anterior. Na descrigéo textual do Fxemplo 5.2, a especificagio do mimero de dias respeitantes & seleccio dos movimentos a visualizar era estatica (30 dias). Numa situagao mais flexivel, o ideal é que © cliente/utilizador pudesse seleccionar o numero de dias pretendido, ou simplesmente activar um botio para indicat que pretendia seleccionar os movimentos relativos aos tiltimos 30 dias. A figura 5.4 ilustra esta situagio através da utilizagio da relagio de extensio, repre- sentada por uma relagio de dependéncia (seta a tracejado) com o esteredtipo «extend», Pelo facto do caso de utilizacio destino poder ter varios pontos de extensio, especifica-se, na relacio de extensio, qual o ponto de extensio a que diz respeito (neste caso “(N.° de dias)”). O Exemplo 533 ilustra a forma de representacio textual dos pontos de extensio nos casos de utilizacio, bem como a especificagio textual de um caso de utilizagio que permite estender outro num determinado ponto de extensao.CariTuLo 5 - UML — Casos DE UTILIZAGAO 141 Exemplo 5.3: Especificagaéo textual do caso de utilizagéo “Obter Extracto de Conta” revisto. Nome: Obter Extracto de Conta Pontos de Extensa N.* de dias Cenrio Principal Incluir caso de utilizagio “Validar Utilizador”. Obter e verificar 0 mimero da conta, Seleccionar o n.° de dias com base no qual se produz o extracto. (N.° de dias). Por omissio sio seleccionados 0s iiltimos 30 dias. Produzir uma lista resumo com esses movimentos, apresentando a data, o tipo de movimento (débito ou cré- dito), uma breve descri¢ao ¢ 0 valor do movimento. Produzit 0 saldo corrente da conta. Emitir um documento com essa informagao produzida ejectando no termi- nal de Multibanco o referido documento. Apresentar mensagem no visor do ter- minal para cliente retirar 0 extracto. Registar na conta do cliente que esta opera- io foi realizada com sucesso. Cenario Alternativo 1 Exemplo 5.4: Especificagao textual do caso de utilizagéo “Selec- ciona N.° de Dias”. Nome: Selecciona N° de Dias Tipo: Abstracto Cenario Principal E apresentado um ecri em que o utilizador especifica o n.° de dias desejado, atra- vés da marcago em varios botées numéricos (de ‘0’ a ‘9). Quando o utilizador selecciona o botio “Confirmar” o valor construido é retornado ao caso destino no seu respectivo ponto de extensio. Cenario Alternativo 1 Idéntico ao cenario principal. Em qualquer momento 0 utilizador pode marcar sobre o botio “Apagar” de modo a apagar o algarismo introduzido mais recente- mente.Conceito 142 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. 1 Cenario Alternativo 2 Ydéntico ao cenario principal. Quando o utilizador marca “Confirmat” ¢ 0 valor introduzido for superior a 59 dias € apresentada uma mensagem de aviso que 0 mimero maximo € 59, e 0 caso é reiniciado. Cendrio Alternativo 3 [déntico ao cenario principal, Fim qualquer momento o utilizador pode seleccionar o botao “Cancelar”- O caso termina ¢ é retornado o valor 1 (dia) por omissio. Bm situagGes reais este tipo de selagdes pode-se complicar significativamente. Imagine-se, por exemplo, que um outro ponto de extensfio é a lingua escolhida que teti como consequéncia que todas as interfaces com 0 utilizador sejam compativels com a lingua respectiva. 5.3 Diagramas de Casos de Utilizagao Um diagrama de casos de utilizagio ilustra um conjunto de casos de utilizagio, de actores e suas relagdes (ver Figura 5.5). As suas aplicagdes comuns séo: » Para modelat o contexto de um sistema. Neste caso, a énfase encontra-se na identificacio da fronteira do sistema, dos seus actores e no significado das suas fungdes. = Para modelar os requisitos de um sistema, Consiste na identificagio do que 0 sistema deve fazer, independentemente de como o sistema o deve realizar. ‘A ligagio entre um actor ¢ um caso de utilizagio corresponde a uma relacio de comunicagio (de esterestipo «communicate») entre estes dois elementos. E repre- sentada por uma linha a cheio e em geral sem setas, Pols 8 comunicagao entre o actor ¢ 0 caso de utilizagio pode ser em ambos os sentidos, ou pode nem seques ser relevante determinar essa informacao.Conceito Capituto 5 - UML —Casos DE UTILIZAGAO 143 Figura 5.5: Diggrama de casos de utilizagéo 5.3.1 Actores Um actor é 0 conceito que representa, em geral, um papel que um utilizador desempenha relativamente ao sistema em anilise. Todavia, um actor nao é neces- sariamente um papel de um utilizador; pode corresponder a um papel desempe- nhado por um outto sistema informatico, por um equipamento hardware especiali- zado, ou pela simples passagem de tempo. O conjunto total de actores de todos os casos de utilizaco reflecte todos os elementos que interactuam com o sistema. O icone do esterestipo actor representa por omissao a figura de um individuo, mas podem-se definir outros esterestipos (com respectivos cones) para diferentes tipos de actores, Um determinado utilizador pode desempenhar diferentes papéis, podendo, por conseguinte, representar diferentes actores. Por exemplo, na situagio da caixa 0 dliente do banco, que acede ao sistema para realizar variadas operagdes bancérias; e 0 opetador da Multibanco, poder-se-fo identificar pelo menos dois actores: agéncia ou da caixa, que é responsavel pela sua activaco, por carregar dinheiro na maquina, etc, Os actores podem encontrar-se relacionados através de relagdes de generalizacio, conforme ilustrado na Figura 5.6, 0 que significa que 0 actor-filho (na rclagio de generalizagio) herda todas as funcionalidades ¢ todos os papéis do seu actor-pai, podendo adicionalmente apresentar as suas proprias funcionalidades.144 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | Tenporsader sGonesisrcr beat Figura 5.6: Relagio de hierarguia entre actores. 5.3.2 Casos de Utilizagao Abstractos e Concretos Por definicio, um caso de utilizagdo abstract é um caso que nfo apresente uma relacio de comunicagio com qualquer actor. Por outro lado, um caso de utilizagio concreto é um caso que nao é abstracto. O nome dos casos abstractos deve ser representado a itilico de forma a distingui-los dos casos concretos (ver Figuras 5.8 ¢ 5.9). Conceito Estes casos de utilizacio encontram-se tipicamente envolvidos em relagdes de generalizacio (€.g,, 0 caso pai), incluso (0 caso destino) ou de extensio (0 caso base) com outros casos de utilizacao. O objectivo destes casos abstractos € dar a0 modelo um nivel clevado de reutilizagio e de flexibilidade, como se viu na Seccio 52. 5.4 Proposta de Metodologia Apesar da estrutura de conceitos associada aos diagramas de casos de utilizacao sex relativamente simples, como se viu nas secgGes anteriores, a pritica vem mostrar que a sua aplicagao nao é trivial, havendo intimeras situagdes de utilizagio incor- recta, Propomos nesta seco uma metodologia para desenho de diagramas de casos de utilizacio de forma a ajudar o leitor nesta actividade “aparentemente” facil de realizar. Para facilitar a discussio, considere-se 0 exemplo de um sistema “Maquina de Bebidas”. Uma maquina de bebidas é um sistema colocado normalmente em locaisCapiTuLo 5 - UML — Casos DE UTILIZACAO 145 estratégicos, por onde passa muita gente, como sejam paragens de metro, recintos desportivos, escolas, etc. A metodologia proposta consiste na aplicagio sucessiva dos seguintes passos: 1) Identificar os actores do sistema, ou seja, o perfil de individuos e de outros sistemas que interactuam com o sistema original. 2) Identificar, para cada actor, os seus casos de utilizacio principais. Note-se que podem existir casos que envolvam a patticipacio de mais que um actor. 3) Com base nos casos de utilizagio originais, identificar, factorizar e colocar em evidéncia casos de utilizagio que sejam recorrentes em mais que um dos casos originais. Nessa situagio, ctia-se 0 novo caso de utilizagio (em geral é um caso abstracto) ¢ os casos originais envolvidos estabelecem uma telacio de incluso com 0 dito caso. Repetit 0 proceso até nao se conseguir identificar qualquer outro caso a reutilizar. 4) Para tratar casos de utilizacio que pretendam ser flexiveis ¢ versiteis, definir pontos de extensio (ou de variabilidade) e conjuntamente definir um ou mais casos de utilizacio (abstractos) que os permitam estender nesses pontos. Nesta situacio, cria- dido. se uma relagio de extensio do caso abstracto para o caso esten- 5) Especificar textualmente cada caso de utilizagio segundo um determinado for- mato previamente definido. Nao esquecer nesta especificagio textual a expli- citagio dos pontos de extensio e de incluso anteriormente identificados. Tendo em conta a metodologia proposta, 0 passo 1 comeca com a identificagio dos actores do sistema bem como das suas principais actividades. [dentificamos trés actor (1) 0 cliente, que compra a bebida; (2) o agente do fornecedor, que ¢ responsivel por catregar as bebidas na maquina; ¢ (3) o dono da méquina, que é responsivel por retirar o dinheiro da maquina. No passo 2 foram identificados os principais casos. A Figura 5.7 ilustra a versio preliminar do respectivo diagrama de casos de utilizagio. Neste passo é crucial a escolha do nivel de granularidade adequado para “captar” os casos envolvidos. Recorde-se a definigao de caso de utilizagio para se realizar essa escolha. Note-se que um caso nao é simplesmente “uma accio”, ou mesmo “uma sequéncia de accées”, mas sim “uma sequéncia de acces que um ou mais actores tealizam num sistema de modo a obterem um resultado particular”. Note-se que 0 caso “Repor Bebidas” é realizado conjuntamente pelo agente do fornecedor de bebidas ¢ pelo dono da maquina, este altimo responsavel por abrir a miquina e supervisionar 0 proceso envolvido.146 CENTRO ATLANTICO — UML, MeTODOLOGIAS E FERRAMENTAS CASE ~ VoL. | Maquina Bebidas Comprar Bebida 7 b — Repor Bebidas ‘Agente Fornecedor Figura 5.7: Diagrama de casos de utilizagao da “Méquina de Bebidas” — preliminar Passando para o passo 3 da metodologia acima enunciada, deve-se identificar comportamentos comuns sealizados pot mais que um dos casos do sistema. Neste exemplo, constata-se que os casos “Repor Bebidas” ¢ “Retirar Dinheiro” envol- vem dois tipos de acgées comuns “Abrir Maquina” ¢ “Fechar Maquina”. Este facto pode ser factorizado através de dois ca de utilizagio correspondentes € podem set estabelecidas as tespectivas selagdes de inclusio (ver Figura 5.8). © passo 4 da metodologia pressupde que a anilise dos casos de utilizagio existen- tes avalie a necessidade da ctiagio de pontos de extensio para um ou mais casos. No exemplo, vamos considerar que o caso “Repor Bebidas” tem um ponto de extensio designado pot “encher prateleira”, que permite associat ao caso de utili- vacio um ou mais casos abstracts que providenciem diferentes algoritmos para a reposigdo de bebidas nas prateleiras. A Figura 5.9 ilustra essa sitmagiio com 0 caso “Repor Bebidas de Acordo com as Vendas”. A reposi¢io de bebidas na miquina tem em conta 0 nimero de bebidas vendidas, implicando que se colocam mais latas das bebidas mais vendidas, Note- se que poder-se-iam definir outros casos de extensio abstractos, que implementa- vam diferentes algoritmos ou estratégias de reposicio de bebidas; por exemplo: repor bebidas de forma uniforme (0 mesmo niimero de latas, por tipo de bebida)s ou repor bebidas de acordo com a marca.CapiTuLo 5 - UML ~ Casos DE UTILIZAGAO 147 Glierte ial Comprar Bebica }, Maquina Bebidas Figura 5.8: Diqgrama de casos de utilizagio da “Maquina de Bebidas” — com inclusda. Repor Bebidas de Acorda com Verda slncuides = Fechar Mquina ) Figura 5.9: Diagrama de casos de utilizagao da “Meiquina de Bebidas” — com extensio 5.5 Exemplos e Recomendagées Apresentam-se de seguida dois exemplos simples, com base nos quais se discutem alguns aspectos da modelacio de casos de utilizacao e se apresentam recomenda- Ges relevantes148 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — Vol. | Exemplo 5.4: Casos de utilizagao do GPG. A Figura 5.10 ilustra © diagrama de casos de utilizagio do sistema GPG, em parti- cular para 0 processo da realizagio da componente de investigasiio em cursos de mestrado ou de doutoramento. Uaamiristrative nero ur rages Resuitado ‘ina nig de Te (oneti emporzader si RNacionalOT Figura 5.10: Diagrama de casos de utilizagio do Caso GPG (visio incompleta) Este exemplo sugete algumas observagies € recomendagdes que sfio referidas de seguida,CapituLo 5 - UML —Casos DE UTILIZAGAO 149 Recomendagio 1: Actores ndo correspondem apenas a utilizadores do sis- tema! Estio identificados os actores que interactuam directamente com o GPG, em particular actores do tipo “papéis ou perfis de utilizagio” (e.g, UAluno, UCoordenador, UOrientador); do tipo “sistemas de informagio externos” que se relacionam com o GPG (neste caso, 0 actor SI-RNacionalDT); e por fim, 0 actor que representa a passagem de tempo (neste caso, o actor Temporizador, que é responsavel por desencadear periodicamente 0 caso de utilizagao “Envio de Teses Coneluidas”, que tem como destinatario o actor $I-RNacionalDT). Atente-se que nem todos os actores tém de corresponder necessariamente a utilizadores regista- dos no SI; por exemplo, o actor UMembroJuiti (eg. os docentes externos 4 Escola) participa no sistema — pelo facto de ser notificado clectronicamente (e-g., via e-mail ou SMS) da confirmacao da data e local das provas —, mas nao cor- tesponde a um utilizador registado no GPG . Recomendagio 2: Podem-se usar setas (i., telagSes de comunicagao com direcgiio) pata aumentar a compreensio dos casos! Explicitou-se, de forma deliberada, neste exemplo, o sentido das relagdes de comunicagao entre actores ¢ casos de utilizacio. Desta forma torna-se mais evidente e compreensiva a realiza- cao dos casos de utilizagio, pela identificagio dos actores responsaveis pelo inicio de cada caso, € os outros actores que apenas sio notificados pelo respectivo caso. Como exemplo, 0 caso “Propde Constituigio de Jiri” é realizado pelo UOtientador, sendo o UCoordenador de alguma forma (eg., e-mail, e-mail interno, SMS) notificado dessa acgao. Recomendagio 3: Casos de utilizagio nao devem explicitar fluxo de con- trolo! Nio se deve introduzir neste tipo de diagramas fluxo de controlo ou de informagio entre casos de utilizagio. Esse € um dos erros mais habituais que se verificam infelizmente. Por exemplo, na Figura 5.10 nao é ilustrada qual a sequéncia de execugao destes casos de utilizacao; i., nao se ilustra que o caso de utilizagio “Aprova constituicio de Juri” devera ocorrer apés a conclusio dos casos “Submete versio electronica de Tese” e de “Propde Constituigao de Jari”. Essa informagio deverd ser capturada através de diagramas de actividade (ver Capitulo 7).150 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | Exemplo 5.5: Casos de utilizagao do GTTI. Considere, relativamente ao sistema GTTI, os casos de utilizacao relativamente ao actor UMembro. A questio que merece reflexio ¢ discussio é analisar-se que versio do diagrama (versio 1 ou versio 2, respectivamente Figura 5.11 ¢ 5.12) se deve considerar mais adequada. Versao 1; Sem o Caso "Valida Acesso" Consulta Termos ‘Configura Opgtes Pessosis =f gotanan | extend» ‘Submete Opiniso sobre Proposta Recebe Periodicamente Noves Termos Temporizador Figura 5.11: Diqgrama de casos de wtilizagao do actor UMembro, versio 1.CapiTuLo 5 - UML — Casos DE UTILIZAGAO 151 ers 2. Com 0 Caso “Valida Acesso" Temporizader Figura 5.12: Diagrama de casos de utilizaciio do actor UMembro, versdo 2. Recomendagio 4: Simplicidade! A escolha entre estas duas verses no é con- sensual! Para nds, a escolha correcta é a versio 1 (ie., a versio em que mio se ilustra 0 pseudo-caso “Valida Acesso”) porque é a mais simples. Facto real: Na anillise e avaliacio de varios projectos de alunos de licenciatura ou pos-graduacio, constatémos infelizmente que os alunos escolhiam a versio 2... Imagine-se que em sistemas com algumas dezenas de casos de utilizacio (eg, entre 10 a 50), cerca de 80% destes casos apresentavam uma relagio de incluso para um pseudo-caso do tipo de “valida acesso”... . dbvio que essa solugao é de facto inadequada, pois nao promove a simplicidade do diagrama ou o enfoque sobre os aspectos importantes do sistema.152 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE ~ VoL. | 5.6 Exercicios Ex.39, Indique duas vantagens da visualizacio de um caso de utilizacao. Ex.40. Com base no exemplo da “Maquina de Bebidas” descrito na Seccio 5.4 complete a descri¢io dos requisitos do sistema ao especificar textualmente os casos de utilizacio definidos (passo 5 da metodologia proposta) Ex.41. Esboce um diagrama de casos de utilizagio para um controlo remoto de TV. Garanta que inclui todas as fungdes do controlo remoto como casos de utilizagio do seu modelo. Descreva textualmente os casos de utilizacio “Ligar TV” ¢ “Seleccionar Canal”. Sugestio: Considere que a TV tem um sistema de password, configurado opcionalmente, para que os pais tenham a garantia que os filhos nao passem muitas horas em frente ao televisor! Ex.42. Considere o sistema de uma equipa de futebol constituido pelos seguintes actores: jogador, treinador, atacante, guarda-redes, médio, defesa, presidente. Desenhe o respective diagrama de casos de utilizacao. Sugestio: considere por exemplo os seguintes casos: jogar, treinar, defender a baliza, pagar a0 jogador, pagar ao treinador, vender jogador, contratar jogador, contratar trei- nador, despedir treinador. Bix.43. Faca um diagrama de casos de utilizacio a partir do manual de utilizador de uma determinada aplicacio. Considere, por exemplo, 0 Word da Micro- soft ou outra qualquer aplicagio do seu conhecimento. Ex.44, Esboce o diagrama de casos de utilizagao para o sistema de uma miquina de venda de bilhetes e de passes de Metro: «Considere que é possivel a aqui- sicio dos seguintes tipos de bilhetes: simples, carteira de 10 unidades, bilhete didrio. Considere que usualmente © pagamento é feito em dinheiro. Pode-se, no entanto e de forma opcional, pagar através de PMB. Considere que a maquina pode ou nao ter troco. No final pode ser emitido o recibo, caso cliente assim o pretender. Considere, por fim, a reposi¢io de bilhe- tes/passes para venda, realizada pelo funcionario com essa responsabilidade; © a remogiio do dinheiro e reposicaio de trocos na maquina, por parte de um funcionario (com responsabilidades de indole financeira)». Descreva textual- mente 0 cenitio de aquisi¢io de bilhete simples ¢ pagamento, em dinheiro, com troco e emissio do respectivo recibo. Ex.45. Relativamente ao sistema GTTT, considere que o sistema devera suportar trés tipos diferentes de utilizadores: 0 utilizador anonimo, o utilizador mem-CapituLo 5 - UML—Casos DE UTILIZAGAO 153 bro (Le., utilizador registado no sistema), € © utilizador gestor, responsavel pela gestio de utilizadores e paramettizagio geral do sistema. Considere que 0 membro pode tealizar as mesmas consultas que 0 utilizador anénimo ¢ que 6 gestor também pode ser considerado um membro. () Produza o diagrama de casos de utilizagio ilustrando apenas as relacdes entre actores. (i) Produza o diagrama de casos de utilizacao relativamente 4s funcionalidades do utiliza- dor anénimo que sio as seguintes: consultar a lista de membros registados; consultar a lista de termos oficiais, consultar a lista de referéncias (¢.g., links e referéncias bibliograficas) disponiveis. Adicionalmente, 0 utilizador and- nimo podera solicitat o preenchimento de um formulirio Web para subsere- ver o registo de membro (todavia, a aceitagao desse registo tera de ser reali- zada explicitamente pelo gestor). Ex.46. Analise os ptocessos RUP e ICONIX e discuta as suas respectivas inter- pretagées relativamente aos conccitos “requisitos” e “casos de utilizagao”. Fx.47. Discuta as vantagens/desvantagens da aplicagio de diagramas de casos de utilizagiio na produgao de cadernos de encargo ¢/ou propostas de sistemas de informagio. Ex48. Discuta as vantagens/desvantagens da adopgio de um estilo de esctita dos casos de utilizacdo na éptica dos seus utilizadores. Sugestdo: considere a possibilidade de geracio de documentacio.