UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA

PROGRAMA DE PS-GRADUAO EM COMPUTAO

Abordagem Baseada em Objetivos para Construo de Casos de Uso e Cenrios

por

ROBERTO VEDOATO

Dissertao submetida avaliao, como requisito parcial para a obteno do grau de

Mestre em Cincia da Computao

Prof. Marcelo Soares Pimenta Orientador

Porto Alegre, junho de 2003.

2

CIP CATALOGAO NA PUBLICAO

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitora: Profa. Wrana Maria Panizzi Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann Pr-Reitora Adjunta de Ps-Graduao: Profa. Joclia Grazia Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux Coordenador do PPGC: Prof. Carlos Alberto Heuser Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

Vedoato, Roberto

Abordagem Baseada em Objetivos para Construo de Casos de Uso e Cenrios / por Roberto Vedoato. Porto Alegre: PPGC da UFRGS, 2003.

91 f.:il.

Dissertao (Mestrado) Universidade Federal do Rio Grande do Sul. Programa de Ps-Graduao em Computao, Porto Alegre, BR-RS, 2003. Orientador: Pimenta, Marcelo.

1. Engenharia de Software 2. Interao Humano-Computador 3. Construo de Casos de Uso e Cenrios 4. Abordagem Orientada a Objetivos I. Pimenta, Marcelo Soares II. Ttulo.

3

A minha me, com todo amor e carinho

4

Agradecimentos

Agradeo a Deus e a Nossa Senhora, em primeiro lugar, por guiarem meus passos ao longo da vida;

minha famlia, pais Ademar Vedoato e Oflia Chimento Vedoato e irmos Flvio Anselmo Vedoato e Valria Vedoato, pelo constante amor, apoio e incentivo, dando-me suporte para chegar at aqui. Tenho certeza de meu sucesso ser tambm o deles;

A todos professores do Instituto de Informtica, em especial a meu orientador, Marcelo Soares Pimenta, pessoa que me inspirou e, desde o princpio, no poupou esforos para me orientar. Sem dvida, meus conhecimentos em ES e IHC cresceram profundamente, trabalhando com ele. Ao ilustre mestre, minha sincera gratido;

A meus grandes amigos: Rafael Batistela Parisotto, Fbio Luis Secco, Cssio Duran Savioli, Bertoldo Prellwitz e Ronald Pablo Meneses pelos ideais e companheirismo;

Aos colegas de turma, particularmente a Carlos Gomiero Maluf, Dionsio Pinheiro de Oliveira, Fernando Manchini Serenato, Leonardo Mota Pinheiro e Marcel Watanabe, pelo esforo coletivo que fez com que obtivssemos maior proveito do mestrado;

A todos aqueles que, de forma direta ou indireta, contriburam realizao deste trabalho.

5

Sumrio

Lista de Abreviaturas.................................................................................. 7

Lista de Figuras ........................................................................................... 8

Lista de Tabelas........................................................................................... 9

Resumo .......................................................................................................10

Abstract ......................................................................................................11

1 Introduo .......................................................................................12

2 Cenrios e Casos de uso: Fundamentos e Conceitos ...................16 2.1 Cenrios: Viso de IHC ................................................................................... 16 2.1.1 Aplicao ........................................................................................................ 16 2.1.2 Notao........................................................................................................... 16 2.1.3 Estrutura ......................................................................................................... 17 2.1.4 Uso.................................................................................................................. 17 2.2 Casos de Uso: Viso de ES............................................................................... 18 2.2.1 Aplicao ........................................................................................................ 20 2.2.2 Notao........................................................................................................... 21 2.2.3 Estrutura ......................................................................................................... 23 2.2.4 Relacionamentos............................................................................................. 23 2.3 Discusso sobre Cenrios e Casos de Uso....................................................... 24 3 Abordagens Baseadas em Objetivos: Viso Panormica............29 3.1 Introduo ......................................................................................................... 29 3.2 Algumas Propostas ........................................................................................... 30 3.2.1 Abordagem de Potts ....................................................................................... 31 3.2.2 Abordagem de Cockburn................................................................................ 32 3.2.3 Abordagem de Rolland................................................................................... 33 3.2.4 Anlise Crtica das Abordagens ..................................................................... 34

4 Abordagem Proposta ......................................................................36 4.1 Introduo ......................................................................................................... 36 4.2 Atividades Preliminares ................................................................................... 37 4.3 Modelo de Casos de Uso................................................................................... 39 4.3.1 Casos de Uso Essenciais................................................................................. 41 4.3.2 Casos de Uso Singulares ................................................................................ 46 4.3.3 Casos de Uso Operacionais ............................................................................ 50 4.3.4 Casos de Uso Concretos (Cenrios) ............................................................... 53 4.4 Construo de Casos de Uso............................................................................ 54 4.5 Viso Macro do Processo de Construo de Casos de Uso........................... 56 5 Aplicao Passo a Passo ao Caixa Eletrnico...............................58 5.1 Descrio do Exemplo ...................................................................................... 58 5.2 Construo de Casos de Uso............................................................................ 58 5.2.1 Atividades Preliminares.................................................................................. 59

6

5.2.2 Construo de Casos de Uso Essenciais......................................................... 62 5.2.3 Construo de Casos de Uso Singulares......................................................... 67 5.2.4 Construo de Casos de Uso Operacionais .................................................... 73 5.2.5 Construo de Casos de Uso Concretos (Cenrios) ....................................... 76 5.2.6 Experimentao de Cenrios .......................................................................... 77 5.2.7 Modificao de Casos de Uso ........................................................................ 78 5.2.8 Integrao de Casos de Uso............................................................................ 78 6 Concluso.........................................................................................80 6.1 Contribuies .................................................................................................... 80 6.1.1 Compatibilidade com a UML e Resoluo de Aspectos Problemticos ........ 80 6.1.2 Resumo de Resultados.................................................................................... 82 6.2 Comparao com Outras Abordagens Baseadas em Objetivos ................... 83 6.3 Limitaes ......................................................................................................... 84 6.4 Perspectivas de Trabalhos Futuros................................................................. 84 Bibliografia.................................................................................................85

7

Lista de Abreviaturas

ATM Automatic Teller Machine CREWS Cooperative Requirements Engineering With Scenarios CTT ConcurTaskTree ER Engenharia de Requisitos ES Engenharia de Software GBRAM Goal-Based Requirements Analysis Method GOMS Goal Operators Methods Selection GRASP General Responsibility Assignment Software Patterns HTA Hierarquical Task Analysis IHC Interao Humano-Computador IU Interface do Usurio LEL Language Extended Lexicon MAD Mthode Analytique de Description OMT Objecto Modeling Technique OO Orientado a Objeto OOSE Object-Oriented Software Engineering RC Requirements Chunks RNF Requisito no Funcional TAREFA Task Analysis based Requirements Engineering FrAmework UAN User Action Notation UML Unified Modeling Language XML Extensible Markup Language

8

Lista de Figuras

FIGURA 2.1 Exemplo de cenrio............................................................................. 16 FIGURA 2.2 Ciclo tarefa-artefato ............................................................................ 18 FIGURA 2.3 Exemplo de caso de uso na notao de seqncia numerada.............. 21 FIGURA 2.4 Exemplo de caso de uso na notao de narrativa com partio .......... 22 FIGURA 2.5 Exemplo de diagrama de casos de uso................................................ 23 FIGURA 2.6 Exemplo de relacionamento de incluso............................................. 24 FIGURA 2.7 Exemplo de relacionamento de extenso ............................................ 24 FIGURA 2.8 Caso de uso com a perspectiva do sistema.......................................... 26 FIGURA 2.9 Caso de uso com a perspectiva do usurio.......................................... 26 FIGURA 2.10 Modelo de requisitos eixo e raios .................................................... 27 FIGURA 3.1 Esquema de casos de uso .................................................................... 31 FIGURA 3.2 Metfora do veleiro (sailing ship) ................................................... 33 FIGURA 3.3 Metfora da cala-listrada (striped trousers)................................... 33 FIGURA 4.1 Viso geral da abordagem teleolgica e dos quatro nveis de abstrao

de casos de uso .................................................................................... 37 FIGURA 4.2 Caso de uso essencial estruturado ....................................................... 43 FIGURA 4.3 Exemplo de caso de uso essencial....................................................... 44 FIGURA 4.4 Sinais de relaes temporais e de ordenao ...................................... 45 FIGURA 4.5 Exemplo de singularidade para o caso de uso singular Consultar

extrato ................................................................................................. 46 FIGURA 4.6 Esquema gramatical para casos de uso singulares .............................. 48 FIGURA 4.7 Exemplo de caso de uso singular ........................................................ 49 FIGURA 4.8 Exemplo de diagrama de seqncia .................................................... 52 FIGURA 4.9 Exemplo de caso de uso concreto ....................................................... 54 FIGURA 4.10 Diretrizes para a descrio textual de casos de uso............................. 55 FIGURA 5.1 Modelo de tarefa minimal Sacar Dinheiro, antes da re-engenharia de

tarefas .................................................................................................. 59 FIGURA 5.2 Modelo de tarefa minimal Sacar Dinheiro ......................................... 59 FIGURA 5.3 Modelo de tarefa minimal Consultar Saldo ........................................ 60 FIGURA 5.4 Modelo de tarefa minimal Consultar Extrato ..................................... 60 FIGURA 5.5 Exemplos de entradas na notao LEL para o caixa eletrnico.......... 62 FIGURA 5.6 Caso de uso essencial Sacar dinheiro ................................................. 63 FIGURA 5.7 Caso de uso essencial Consultar Saldo ............................................... 65 FIGURA 5.8 Caso de uso essencial Sacar Dinheiro, com relao temporal e eventos

assncronos .......................................................................................... 66 FIGURA 5.9 Caso de uso singular Sacar Dinheiro.................................................. 68 FIGURA 5.10 Caso de uso singular Sacar dinheiro; Pega o dinheiro e o recibo;

Dinheiro no liberado......................................................................... 72 FIGURA 5.11 Episdio Pega o dinheiro e o recibo................................................... 73 FIGURA 5.12 Objetos identificados no episdio Fornece identificao ao sistema . 75 FIGURA 5.13 Diagrama de seqncia para o episdio Fornece identificao ao

sistema................................................................................................. 75

9

Lista de Tabelas

TABELA 2.1 Viso geral de casos de uso em mtodos OO [REG 96] ...................... 19 TABELA 2.2 Quadro sinttico, destacando diferenas entre cenrios e casos de uso 26 TABELA 3.1 Comparao entre abordagens baseadas em objetivos ......................... 35 TABELA 4.1 Viso macro do processo de construo de casos de uso ..................... 56 TABELA 5.1 Exemplo de alocao de funo para emisso de recibos das transaes

com o caixa eletrnico.......................................................................... 60 TABELA 5.2 Lista informal dos requisitos iniciais do sistema para o caixa eletrnico

.............................................................................................................. 61 TABELA 5.3 Lista ator-objetivo para o caixa eletrnico ........................................... 61 TABELA 5.4 Tabela de singularidades para o caso de uso Sacar dinheiro ............... 70 TABELA 5.5 Tabela de sucesso e falha de episdios para definio dos casos de uso

singulares do objetivo Sacar Dinheiro.................................................. 71 TABELA 5.6 Heursticas para mapear tipos de palavras em componentes de modelo

.............................................................................................................. 73 TABELA 5.7 Lista ator-pseudnimo para o caixa eletrnico ..................................... 76 TABELA 5.8 Episdios do caixa eletrnico ............................................................... 79 TABELA 6.1 Comparao com outras abordagens baseadas em objetivos................ 83

10

Resumo

Para o desenvolvimento de sistemas interativos que respeitem critrios de usabilidade em adio aos critrios de qualidade convencionais, necessrio que, desde suas primeiras etapas, as reas de Engenharia de Software (ES) e de Interao Humano-Computador (IHC) sejam consideradas, simultaneamente e de maneira integrada. Essas duas reas investigam modelos, conceitos, tcnicas e prticas que refletem diferentes perspectivas sobre a atividade de desenvolvimento, uma orientada mais ao sistema (ES) e outra, mais ao usurio (IHC). Para conciliar estas perspectivas, necessrio o estabelecimento de um entendimento mtuo e a utilizao conjunta e integrada de conceitos, tcnicas e prticas de desenvolvimento de ambas as reas. Este trabalho visa mostrar as possibilidades desta integrao, atravs da combinao dos conceitos de Casos de Uso (Use Cases) e Cenrios (Scenarios), importantes tcnicas de modelagem amplamente utilizadas respectivamente nas reas de ES e IHC, em diferentes contextos, com diferentes vises; mas apresentando similaridades valiosas para propiciarem o uso complementar de ambas as tcnicas. Para sistematizar esta integrao, proposta uma abordagem teleolgica baseada em objetivos de construo sistemtica de casos de uso com quatro diferentes nveis de abstrao, desde os mais abstratos casos de uso essenciais at os cenrios, aqui utilizados como instncias concretas de casos de uso. Com esta abordagem, pretende-se construir um modelo de casos de uso que permita especificar requisitos funcionais, conjuntamente com requisitos de interao, de maneira compreensvel e praticvel e que sirva como ponto de partida continuidade do desenvolvimento orientado a objetos de software. Com o intuito de exemplificar a proposta, descrita e discutida a aplicao passo a passo desta abordagem a um exemplo.

Palavras-chave: Engenharia de Software, Interao Humano-Computador, Construo de Casos de Uso e Cenrios, Abordagem Orientada a Objetivos.

11

TITLE: GOAL-BASED APPROACH FOR CONSTRUCTION OF USE CASES AND SCENARIOS

Abstract

For the development of interactive systems that respect usability criteria in addition to the conventional quality criteria, it is necessary to consider simultaneously and jointly from their first stages, the areas of Software Engineering (SE) and of Human Computer Interaction (HCI). Those two areas investigate models, concepts, techniques and practices that reflect different perspectives about the development activity, one more oriented to the system (SE) and other, more to the user (HCI). To conciliate these perspectives, it is necessary the establishment of a mutual understanding and the united and integrated use of concepts, techniques and practices of development of both areas. This work aims to show the possibilities of this integration, through the combination of the concepts of Use Cases and Scenarios, important modelling techniques widely used respectively in the areas of SE and HCI, in different contexts, with different visions; but presenting valuables similarities to propitiate the complemental use of both techniques. To systematize this integration, is proposed a teleological approach - goal-based - of systematic construction of use cases with four different abstraction levels, from the most abstract essentials use cases to the scenarios, here used as concrete instances of use cases. With this approach, it intends to build a use case model to allow to specify functional requirements, jointly with interaction requirements, in a comprehensible and practicable fashion and that serves as starting point to the continuity of the object oriented software development. With the intention of exemplifying the proposal, the application step by step of this approach to an example is described and discussed.

Keywords: Software Engineering, Human Computer Interaction, Use Cases and Scenarios Construction, Goal-Driven Approach.

12

1 Introduo

Freqentemente, sistemas interativos so desenvolvidos com vises isoladas das reas de Engenharia de Software (ES) e de Interao Humano-Computador (IHC). ES, tradicionalmente, prioriza aspectos essencialmente funcionais dos sistemas, como eficincia, manutenibilidade e portabilidade, conferindo ao desenvolvimento uma orientao funcional em detrimento da operacional. J IHC foca principalmente a usabilidade dos sistemas, concentrando ateno aos aspectos de interao e no considerando adequadamente os aspectos enfatizados pela ES [CYB 98]. Essas duas abordagens refletem diferentes perspectivas, uma mais orientada ao sistema (tecnolgica) e outra mais orientada ao usurio (humana), sobre a mesma atividade de desenvolvimento.

Recentes trabalhos de pesquisa convergem para idia central de, para desenvolver sistemas interativos teis e usveis, ser necessrio considerar as perspectivas de ES e IHC, desde as primeiras etapas do desenvolvimento do sistema, exigindo a utilizao conjunta e integrada de conceitos, tcnicas e metodologias de desenvolvimento de ambas as reas. Porm, essa interseo no ainda nem natural nem objetiva: cada rea considera aspectos diferentes e, muitas vezes, disjuntos do sistema, sem nenhuma correspondncia explcita e sistematicamente estabelecida, tendo como conseqncia o fracionamento de requisitos [PIM 2000]. Compor o desenvolvimento de sistemas com grupos multidisciplinares, com diferentes pontos de vista sobre o processo de desenvolvimento, tem como potencial problema promover um entendimento mtuo da mesma tarefa de desenvolvimento e dos objetivos comuns [ABO 94].

Esta dissertao visa mostrar as possibilidades desta integrao, atravs da combinao dos conceitos de Casos de Uso (Use Cases) e Cenrios (Scenarios), importantes tcnicas de modelagem, amplamente utilizadas, respectivamente nas reas de ES e IHC, em diferentes contextos, com diferentes vises; mas apresentando similaridades valiosas para propiciarem o uso complementar de ambas as tcnicas. Ambos so descries narrativas. Cenrios so utilizados em IHC para diversos fins, todavia particularmente teis para inspecionarem atividades humanas ao usar um, presente ou futuro, artefato [CAR 95] e mediarem a comunicao entre grupos multidisciplinares, enquanto que casos de uso so usualmente utilizados, em ES, para modelarem requisitos funcionais e manipularem modelos de objetos [JAC 94a]. Baseando-se em estudo realizado previamente [VED 2001], tem-se a convico de serem conceitos valiosos para combinar as diferentes perspectivas das duas reas citadas, permitindo uma busca integrada da qualidade interna e externa dos sistemas. Fazendo uso do conceito de nveis de abstrao e partindo do enfoque de que cenrios so instncias concretas de casos de uso, podem-se combinar os propsitos e usos complementares de ambas as tcnicas.

Contudo, abordagens apontam que casos de uso apresentam problemas conceituais [REG 95a, REG 95b] e a maneira pela qual so comumente usados na Unified Modeling Language (UML) [BOO 99], no considera adequadamente aspectos de usabilidade [CON 2000b].

Vrias pesquisas tm focado, principalmente, as funes e os usos de cenrios e casos de uso, no processo de desenvolvimento de sistemas, enquanto que o processo de

13

construo destes, muitas vezes, negligenciado. Desenvolvedores, freqentemente, no sabem como identificar casos de uso, o que incluir neles, qual o nvel de detalhamento, como represent-los e como estrutur-los. A abordagem original de casos de uso [JAC 92, JAC 94a, JAC 94b, JAC 94c], posteriormente adotada na UML, no define precisamente nenhum formato especfico para descrever seus contedos, nem um processo sistemtico para constru-los. A falta de guias para a construo de casos de uso certamente uma das desvantagens das abordagens baseadas em casos de uso para Engenharia de Requisitos (ER). Caso no sejam devidamente construdos, ou, ainda, sejam ambguos, incompletos ou inconsistentes, as interaes que os casos de uso representam tambm herdaro essas propriedades [ROL 98a].

Ao se criar um software, no se planeja e se desenvolve apenas um artefato, criam-se novas possibilidades para aes e interaes humanas [CAR 95]. Todo software uma ferramenta. Como boa ferramenta, deve suportar o trabalho de algum, tornar o trabalho mais fcil, mais rpido, mais simples e mais flexvel. Para desenvolverem-se sistemas que suportem adequadamente o uso, trabalhos de pesquisa enfatizam que se precisa entender melhor as tarefas realizadas pelas pessoas e aplicar de maneira mais eficiente a compreenso das tarefas no processo de desenvolvimento de software (ver ciclo tarefa-artefato [CAR 95] na seo 2.1.4).

As atividades de pessoas, no trabalho, podem ser descritas como tarefas. Segundo [STO 95] o termo tarefa definido como: uma tarefa um objetivo junto com conjuntos ordenados de aes que o satisfariam em contextos apropriados. Baseando-se na teoria da ao, sabe-se que, antes de executar uma seqncia de aes, elaboram-se planos, e o ponto inicial de um plano a formulao de um objetivo [CAR 95]. Seguindo esta perspectiva, est claro que, para desenvolver um sistema interativo, necessrio, em primeiro lugar, conhecer os objetivos dos usurios para, ento, propor a especificao dos mecanismos que sustentaro as tarefas necessrias para alcan-los.

Trabalhos de pesquisa j reconhecem a importncia da relao entre objetivos e casos uso. Segundo Kaindl, somente se pode entender as interaes descritas em um caso de uso, quando se conhece seu objetivo [KAI 95]. Quando se est familiarizado com um sistema, os objetivos das interaes parecem bvios; todavia, no processo de elicitao de requisitos e modelagem de tarefas de um novo sistema, ainda desconhecido, saber o objetivo uma informao crucial para a compreenso de cada caso de uso.

Na realidade, outras abordagens tambm consideram serem os objetivos fundamentais para construo de cenrios e/ou casos de uso [KLA 93, POT 95, KAV 96, REG 96, COC 97a, COC 97b, ROL 98b, CON 2000a]; porm poucos oferecem um modo de se utilizarem complementarmente as duas tcnicas para a determinao dos requisitos. Na maioria das abordagens, ou no existe uma notao para objetivos, ou no existe um processo sistemtico de construo e validao de casos de uso, a partir dos objetivos, ou, at mesmo no, existem ambos.

Para sistematizar esta integrao, este trabalho tem como principal objetivo investigar os conceitos de cenrios e casos de uso e propor uma abordagem teleolgica baseada em objetivos de construo sistemtica de casos de uso com quatro

14

diferentes nveis de abstrao, desde os mais abstratos casos de uso essenciais at os cenrios, aqui utilizados, como instncias concretas de casos de uso.

Prope-se uma abordagem que, a partir de um modelo explcito de objetivos dos usurios, refinados e representados, permite definir, refinar e representar os objetivos do sistema que serviro como base para a construo de casos de uso em quatro diferentes nveis de abstrao, essencial, singular, operacional e concreto, cada um relativo a um tipo de conhecimento especfico.

A abordagem um processo interativo e iterativo de construo, refinamento, experimentao, modificao e integrao de casos de uso. Prope-se a construo de casos de uso essenciais, nvel mais abstrato, pelo analista, a partir dos objetivos; ainda pelo analista, o refinamento de casos de uso essenciais, visando definir casos de uso singulares; a instanciao dos casos de uso concretos, cenrios; e, quando desejvel, a definio dos casos de uso operacionais, a partir dos casos de uso singulares; a experimentao e avaliao da funcionalidade e do comportamento dos cenrios pelos usurios, visando investigar suas reais necessidades; a reviso dos casos de uso pelo analista, procurando adequ-los s expectativas dos usurios; e, finalmente, a integrao, pelo analista, dos casos de uso obtidos neste processo recursivo.

Com esta abordagem, pretende-se construir um modelo de casos de uso que permita especificar requisitos funcionais conjuntamente com os de interao, de maneira compreensvel e praticvel e que sirva como ponto de partida para a continuidade do desenvolvimento orientado a objetos de software.

Os objetivos especficos do trabalho so os seguintes: Combinar os conceitos de cenrios e casos de uso, contemplando mutuamente

as perspectivas de ES e IHC; Promover uma abordagem de construo de casos de uso centrada no uso

(usage-centered); Investigar e adotar notaes casos de uso adequadas para cada nvel de

abstrao; Considerar aspectos problemticos de casos de uso, abordados por

pesquisadores da rea, e propor maneiras de resolv-los ou contorn-los; Sistematizar a construo de casos de uso e cenrios, conduzindo e orientando

o autor do caso de uso, atravs de diretrizes, heursticas e templates; Permitir compatibilidade com tcnicas de modelagem conhecidas por grande

parte dos desenvolvedores, como, por exemplo, a UML, de modo a possibilitar a continuidade do desenvolvimento;

Acredita-se que a combinao de casos de uso e cenrios com uma boa compreenso das tarefas e do contexto organizacional em que elas so executadas, juntamente com a explicitao dos objetivos, previnam a possibilidade de que especificaes se tornem desencontradas das reais necessidades dos usurios e devam ser a base para um processo de desenvolvimento de software interativo.

Com o intuito de exemplificar a proposta, descrita e discutida a aplicao passo a passo desta abordagem a um exemplo.

15

O restante do trabalho estruturado como segue: no prximo captulo, conceitos e fundamentos de cenrios e casos de uso, sob a tica, respectivamente, de IHC e ES, so apresentados e discutidos; em seguida, no captulo 3, apresenta-se uma viso panormica sobre abordagens teleolgicas e comparam-se algumas propostas; no captulo 4, apresenta-se a proposta; e, no captulo 5, ilustra-se a aplicao passo a passo da abordagem ao exemplo do caixa eletrnico; por fim, no captulo 6, so apresentadas consideraes finais e perspectivas de trabalhos futuros.

16

2 Cenrios e Casos de uso: Fundamentos e Conceitos

2.1 Cenrios: Viso de IHC

Segundo definio do dicionrio Aurlio [FER 99], o termo cenrio significa: Lugar onde ocorre algum fato, ou onde decorre a ao, ou parte da ao, de uma pea, romance, filme, etc. Em IHC, o comum significado para o termo cenrio, uma instncia representativa de uma interao entre usurio e sistema [CAM 92]. Um cenrio uma descrio narrativa informal e concreta a respeito de um uso de um sistema por uma pessoa.

2.1.1 Aplicao

Na literatura de IHC, h um amplo consenso sobre os benefcios da utilizao de cenrios, no processo de desenvolvimento de software, e, tambm, que cenrios podem ser usados para muitos propsitos diferentes. Em IHC, cenrios so particularmente teis para

ilustrar como um usurio provavelmente efetue tarefas particulares com um, presente ou futuro, sistema;

prover uma representao de projeto, formulada em aes e experincias das pessoas que, efetivamente, usaro a tecnologia;

avaliar a usabilidade de sistemas; guiar o projeto de interfaces dos usurios (IUs); testar teorias de IHC; mediar a comunicao entre grupos multidisciplinares [CAM 92, CAR 2000].

2.1.2 Notao

Cenrios geralmente so representados por narrativas textuais, em linguagem natural, que, freqentemente, so aprimoradas por grficos, diagramas e imagens [RYS 2000]. Podem tambm ser representados atravs de prottipos, storyboards, vdeos, maquetes, ou at mesmo por situaes fsicas planejadas para suportar as atividades de um usurio [CAR 2000]. Um exemplo de cenrio pode ser observado na figura 2.1.

Maria deseja utilizar o caixa eletrnico do banco X para retirar RS 50,00 em dinheiro de sua conta corrente; Ela passa seu carto no leitor do caixa eletrnico pronto para ser usado. O sistema valida o carto e, em seguida, requisita a senha a Maria. Pelo teclado, Maria digita sua senha. O sistema valida a senha digitada e mostra na tela o menu de opes de transaes. Maria escolhe a opo saque, tocando no boto com esta denominao que est na tela; em seguida escolhe R$ 50,00 no menu de possveis quantidades de dinheiro. O caixa automtico verifica a quantia escolhida, a existncia de fundos, aprova a transao e libera a quantia correta e um recibo do saque. Maria pega o dinheiro e o recibo nos locais especificados, o sistema debita a quantia da conta corrente, exibe uma mensagem, pedindo para o cliente certificar-se de que est de posse do seu carto magntico; e, por fim, mostra novamente o menu de opes de transaes.

FIGURA 2.1 Exemplo de cenrio

17

2.1.3 Estrutura

Uma coleo de cenrios no possui uma estrutura definida, representada atravs de um conjunto no estruturado. 2.1.4 Uso

Cenrios so utilizados tanto de maneira formal quanto informal, variando seu uso de partes constituintes do processo de desenvolvimento; por exemplo, no desenvolvimento baseado em cenrios e no desenvolvimento participativo de software; at usos mais espontneos; por exemplo, para propsitos de comunicao [KLA 93].

Em geral, desenvolvedores parecem no considerar cenrios como parte integrante do mtodo de desenvolvimento [ABO 94]. Estudos empricos demonstram que programadores avaliam projetos, simulando cenrios mentalmente [BEN 93]. O uso informal de cenrios pode ser observado, quando desenvolvedores tm algum ponto de discordncia, exploram opes de projeto, procuram esclarecer requisitos do sistema etc. [KLA 93].

Quando utilizados de maneira informal, cenrios so construdos ad hoc, nenhum mtodo especfico utilizado para ger-los ou avali-los [ABO 94]; seus contedos provem de muitas fontes diferentes, desde experincias dos desenvolvedores e conhecimento do domnio a reais observaes dos usurios. No existem compromissos com o que um cenrio deve conter ou o quo representativo deve ser para uma futura situao de uso [KLA 93]. Os usos informais ou implcitos de cenrios so predecessores dos usos mais formais ou explcitos.

Segundo Carroll [CAR 95], o desenvolvimento tecnolgico tem sido dificultado pela incompleta compreenso da prtica. Geralmente, computadores so vistos como artefatos da atividade humana por meio de especificaes funcionais, o que gera uma viso idealizada de uso, no de como um usurio ativaria uma funo e experimentaria seus efeitos. Computadores so mais do que funcionalidade. Eles inevitavelmente reestruturam atividades humanas, criando novas possibilidades, assim como novas dificuldades [CAR 2000]. Cenrios so meios concretos para descreverem situaes existentes e para projetarem futuras situaes de uso, facilitando a comunicao efetiva entre usurios e desenvolvedores sobre os requisitos do sistema e opes de projeto.

Extrair dos usurios aquilo que desejam e de que necessitam no uma tarefa fcil. A cincia cognitiva tem demonstrado que a inteligncia humana est organizada em chunks, que reconhecem e respondem a situaes especficas. A resoluo de problemas, pelos humanos, tende a ser altamente situada; por exemplo, ao invs de realizarem planos detalhados antecipadamente, pessoas respondem aos detalhes de uma situao, conforme eles aparecem [BEN 93]. Representar o uso de um sistema atravs de um conjunto de cenrios torna o uso explcito, isso pode ajudar a programadores e analistas a focarem ateno na compreenso das pessoas e suas tarefas, aspectos, muitas vezes, implcitos nos sistemas [CAR 2000]. O real uso de um sistema pode ser concretamente descrito por um conjunto de cenrios [CAR 95].

Enquanto abordagens tradicionais lidam com a complexidade do processo de desenvolvimento, atravs de abstrao, o desenvolvimento baseado em cenrios utiliza concretizao. Ao invs de desenvolver software, listando requisitos, funes e mdulos

18

de cdigo, o desenvolvedor foca primeiramente as tarefas dos usurios que precisam ser suportadas pelo sistema e, ento, atravs de cenrios, realiza descries dessas para guiar todo o processo de desenvolvimento.

Na abordagem baseada em cenrios, estes so construdos, baseados no ciclo tarefa-artefato: as tarefas que as pessoas esto engajadas e aquelas que elas desejam realizar definem os requisitos da futura tecnologia, incluindo novos artefatos de IHC. Os novos artefatos criam novas possibilidades para as tarefas humanas, novas maneiras de executar coisas familiares e atividades completamente novas para fazer; mas, tambm, criam novas complexidades de aprendizagem e performance, novas interaes entre tarefas e, naturalmente, novas dificuldades e novos erros para as pessoas. Essas novidades, eventualmente, tornam-se requisitos dos prximos desenvolvimentos tecnolgicos, provocando novas transaes [CAR 95]. A figura 2.2 ilustra o ciclo tarefa-artefato.

FIGURA 2.2 Ciclo tarefa-artefato

Para construir representaes de cenrios, no se pode contar somente com observaes. Caso se desejar que cenrios representem um papel pr-ativo, guiando o planejamento e desenvolvimento de um novo sistema, precisa-se ser capaz de criar representaes de cenrios, antes que qualquer verso do sistema tenha sido desenvolvida. Podem-se construir cenrios que representam futuras situaes de uso, atravs do uso coordenado de observaes empricas e de abstraes das teorias da atividade humana [CAR 95].

Portanto, o desenvolvimento baseado em cenrios uma tcnica, orientada a tarefa, para fazer uma projeo do uso de um artefato, antes de constru-lo; nele, cenrios podem ser usados ao longo de todo o ciclo de vida do software, desde a anlise de requisitos e projeto do sistema at a documentao, o treinamento e a avaliao de prottipos.

2.2 Casos de Uso: Viso de ES

Casos de uso foram introduzidos por Jacobson como parte da metodologia de desenvolvimento de software OOSE (Object-Oriented Software Engineering) [JAC 92]. Sua definio original Um caso de uso uma maneira especfica de usar um sistema usando alguma parte da funcionalidade. Constitui um curso completo de interao que acontece entre um ator e o sistema.

19

Por definio, o termo caso de uso, introduzido nesta metodologia, no sinnimo do termo cenrio. Um cenrio deve ser entendido como uma instncia especfica de um caso de uso [JAC 94a], ao passo que o caso de uso uma coleo de cenrios, representando mltiplos caminhos.

A idia geral de um caso de uso representar seqncias de interaes entre um sistema, mesmo que ainda no implementado, e o mundo externo ao sistema; ou seja, descreve maneiras de usar um sistema.

Muitas metodologias de desenvolvimento de software possuem alguma noo de casos de uso. Em [REG 96] pode-se encontrar uma viso geral, na forma de uma tabela comparativa, sobre como casos de uso so aplicados s metodologias Orientadas a Objeto (OO): OOSE, Object Modeling Technique (OMT) e Booch. A tabela 2.1 uma transcrio parcial desta viso geral.

TABELA 2.1 Viso geral de casos de uso em mtodos OO [REG 96] Metodologia OOSE OMT Booch Conceitos Casos de uso, ator,

exceo, extenso (extends), incluso (uses).

Caso de uso, ator, cenrio, pr e ps-condio, exceo, adds.

Caso de uso, cenrio, iniciador, pr e ps-condies.

Notao na fase de anlise de requisitos

Linguagem natural para descrever casos de uso. Diagramas para descrever relaes entre casos de uso.

Linguagem natural com algumas recomendaes para estruturao.

Linguagem natural.

Funo no processo de desenvolvimento

Guia todo processo, usado para identificar objetos e para criar projetos robustos.

usado para reforar a anlise de requisitos e para identificar objetos.

usado para identificar objetos, para concepo e para planejamento de verso.

Metodologia para criao de casos de uso

Algumas heursticas. Questes para responder a cada ator ajudam a identificar casos de uso.

Lista de aes passo a passo. Cenrios so combinados ou generalizados em casos de uso.

Prescreve o planejamento de cenrios como uma atividade e prov algumas poucas recomendaes.

As semnticas dos conceitos, relacionados a casos de uso nos diferentes mtodos, no so correspondentes e existe uma significante inconsistncia entre os mtodos com relao a como os conceitos so interpretados [REG 96].

Posteriormente, os autores das trs metodologias, Jacobson (OOSE), Booch (Booch) e Rumbaugh (OMT), uniram e estenderam suas abordagens atravs de uma linguagem de modelagem unificada a Unified Modeling Language (UML), que emergiu como um padro entre desenvolvedores de software OO. Conseqentemente, neste trabalho, dar-se- enfoque UML.

A UML uma linguagem padro para elaborao da estrutura de projetos de software, empregada para a visualizao, especificao, construo e documentao de artefatos que faam uso de sistemas complexos de software [BOO 99]. Ela integra tcnicas de modelagem de diversas metodologias de desenvolvimento. Muitos dos conceitos sobre casos de uso, originalmente associados metodologia OOSE, foram integrados especificao da UML.

20

UML linguagem de modelagem, no metodologia, portanto somente parte do mtodo de desenvolvimento de software. A UML no prescreve explicitamente um processo de utilizao; porm, para obter maior proveito da UML preciso que o processo tenha a caracterstica de ser baseado em casos de uso. Isto significa que casos de uso so utilizados como principal artefato para estabelecer o comportamento desejado do sistema, para verificao e validao da arquitetura do sistema, para a realizao de testes e para comunicao entre os envolvidos no desenvolvimento do sistema [BOO 99].

A definio formal de caso de uso, segundo a UML [BOO 99], Caso de uso uma descrio de um conjunto de seqncias de aes, inclusive variantes, que um sistema realiza para produzir um resultado de valor observvel a um ator.

Um ator representa um agente externo ao sistema que de alguma forma participa de um caso de uso. chamado de ator um papel que uma pessoa, um dispositivo de hardware, ou, at mesmo, outro sistema desempenha com o software [BOO 99]. Atores ajudam a delimitar o sistema em desenvolvimento, por representarem agentes externos que interagem com o mesmo.

Existe distino entre os conceitos de ator e usurio. Usurio um conceito no formal. Ator representa um papel especfico que um usurio pode atuar, enquanto que o usurio algum que utiliza o sistema [JAC 94a].

Um caso de uso uma descrio narrativa de um processo do domnio da aplicao. Ele representa um requisito funcional do sistema [BOO 99] e captura o comportamento pretendido do sistema; sem, no entanto, especificar como este comportamento implementado, descreve o que o sistema faz e no como feito. Casos de uso proporcionam uma viso externa do sistema; atravs deles, o sistema visto como uma caixa-preta (black box).

2.2.1 Aplicao

Caso de uso uma tcnica de modelagem que pode ser aplicada a qualquer metodologia de desenvolvimento de software, estruturada, ou OO. A semntica de um modelo de casos de uso relaciona-se fortemente com a de um modelo de objetos [JAC 94c]; porm, um modelo de casos de uso no substitui um de objetos. O modelo de casos de uso uma viso externa de um sistema; o modelo de objetos uma viso interna do mesmo sistema [JAC 94a].

Nos ltimos anos, casos de uso tm recebido muita ateno na rea de ES, como meio para elicitar, documentar e validar requisitos, no entanto, isto no significa que esto limitados a ER [REG 96, RYS 2000]; eles podem ser usados ao longo de todo o ciclo de vida do desenvolvimento do software.

Casos de uso so utilizados para diversas finalidades, entre as quais: Estruturar complexos modelos de objetos, em vises manejveis; Capturar, documentar e validar requisitos funcionais de sistemas; Gerenciar a complexidade de desenvolvimento, focando um aspecto distinto

por vez; Compreender e estabelecer o comportamento desejado do sistema;

21

Ganhar percepo sobre modelos alternativos de software; Fornecer uma descrio consistente e clara sobre as responsabilidades a serem

cumpridas pelo sistema, funcionando como uma espcie de contrato; Facilitar a comunicao entre os envolvidos no desenvolvimento do sistema; Envolver usurios no desenvolvimento de software; Verificar e validar a arquitetura de sistemas; Realizar testes de sistemas; Servir como fonte para construo de manuais; Derivar modelos conceituais; Reengenharia de software.

2.2.2 Notao

Existe uma grande variedade de estilos para descrever o contedo narrativo de um caso de uso. A abordagem original de casos de uso, proposta por Jacobson e, posteriormente, adotada na UML, no define precisamente nenhum formato ou template especfico para descrever o contedo de um caso de uso. Originalmente, casos de uso no possuem notao formal; eles so representados na forma de narrativa textual contnua.

Os problemas deste estilo de narrativa so numerosos. No h nenhuma separao clara entre o lado do usurio e o do sistema. A narrativa mistura exigncias internas e externas e salta irregularmente entre perspectivas internas e externas. Os elementos essenciais natureza do problema so misturados com decises de projeto, e a falta de estrutura fora o leitor a seguir o texto inteiro apenas para obter uma idia geral do caso de uso [CON 2000b].

Um outro estilo comum para representar casos de uso a seqncia numerada; nele, a narrativa escrita como uma srie de etapas numeradas. A figura 2.3 ilustra um exemplo extrado de [CON 2000b].

1. O caso de uso inicia, quando o cliente introduz um carto no caixa automtico. O sistema l e valida a informao do carto. 2. O sistema aguarda pela senha. O cliente entra com a senha. O sistema valida a senha. 3. O sistema pergunta que operao o cliente deseja executar. O cliente seleciona saque de dinheiro. 4. O sistema pede a quantia. O cliente entra com a quantia. 5. O sistema pede o tipo. O cliente seleciona o tipo de conta (poupana, conta corrente). 6. O sistema comunica-se com a rede do caixa automtico para validar o nmero da conta, o carto, a senha e a disponibilidade da quantia pedida. 7. O sistema pergunta ao cliente se ele deseja um recibo. Esta etapa executada somente se houver papel para a impresso do recibo. 8. O sistema pede que o cliente retire o carto. O cliente retira o carto. (Esta uma medida de segurana para assegurar que os clientes no deixem seus cartes na mquina.). 9. O sistema libera a quantia pedida. 10. O sistema imprime o recibo. 11. O caso de uso termina.

FIGURA 2.3 Exemplo de caso de uso na notao de seqncia numerada [CON 2000b]

22

Uma vantagem deste estilo evidente: a separao em etapas distintas facilita a leitura do caso de uso para a obteno de uma viso geral. Todavia, sofre muito dos mesmos problemas do estilo narrativo contnuo. Apesar da segmentao em etapas discretas, as etapas individuais mesclam aes do sistema e do usurio.

Ambos os estilos de narrativa, textual contnua e seqncia numerada, apresentam abundncia de palavras. Devido ao fato de no possurem quase nenhuma estrutura, esses estilos de narrativa requerem, para clareza, que a perspectiva seja repetidamente declarada - o sistema faz isto, o usurio escolhe isso, o sistema termina algo mais -, o que contribui para suas loquacidades. Mesmo assim, o limite entre o que est dentro do sistema e o que est fora no est explicito e, somente, poder ser discernido atravs de uma leitura cuidadosa da narrativa inteira [CON 2000b].

A soluo simples para isto, separar completamente da interao o lado do usurio e o do sistema. Para casos de uso, esta separao foi originalmente sugerida por Wirfs-Brock, sendo criado o estilo de narrativa com partio [CON 2000b]. Neste estilo, a narrativa de casos de uso dividida em duas colunas: ao do usurio e resposta do sistema. Assim, o limite das perspectivas internas e externas torna-se bvio e explcito, sem repetio desnecessria. Por exemplo, a figura 2.4 uma narrativa com partio do caso de uso, sacar dinheiro, representado na figura 2.3, como narrativa com seqncia numerada:

ao do usurio resposta do sistema insere o carto no caixa automtico

l o carto solicita a senha

entra com a senha valida a senha mostra o menu de opes

seleciona a opo mostra o menu de conta

seleciona a conta solicita a quantia

entra com a quantia mostra a quantia

confirma a quantia retorna o carto

pega o carto libera o dinheiro se disponvel

FIGURA 2.4 Exemplo de caso de uso na notao de narrativa com partio [CON 2000b]

Este estilo de narrativa bem mais legvel e apresenta uma menor verbosidade do que os outros estilos apresentados, anteriormente. Naturalmente, nada impede que se numerem as aes e as respostas, tornando-o ainda mais til.

Casos de uso podem ainda ser representados por pseudocdigos. Embora tais expresses paream oferecer preciso e possam ser confortveis e familiares aos engenheiros de software, elas, raramente, so compreensveis aos usurios comuns [CON 2000b].

23

2.2.3 Estrutura

Em adio aos de casos de uso, Jacobson tambm introduziu um modo de represent-los graficamente: o diagrama de casos de uso, o qual tambm parte integrante da UML.

Um diagrama de caso de uso exibe uma coleo de casos de uso, atores e seus relacionamentos. Essa notao permite visualizar um caso de uso em separado de sua realizao e no contexto com outros casos de uso [BOO 99].

Graficamente, um caso de uso representado por uma elipse com linhas contnuas, incluindo um nome que o diferencia dos demais; um ator representado por uma figura esquematizada, um boneco de palitos; e as associaes entre atores e casos de uso so representadas por linhas. O escopo do sistema explicitado por uma caixa que envolve os casos de uso. A figura 2.5 mostra um exemplo de diagrama de caso de uso.

FIGURA 2.5 Exemplo de diagrama de casos de uso

Diagramas de caso de uso fornecem um modo de descrever a viso externa do sistema e suas interaes com o mundo exterior, representando uma viso de alto nvel de funcionalidade intencional, mediante o recebimento de um tipo de requisio de usurio [FUR 98]. Esses diagramas definem a total funcionalidade do sistema e so importantes principalmente, para organizao e modelagem de comportamento do sistema [JAC 94a, BOO 99].

2.2.4 Relacionamentos

Na UML, a conexo entre um ator e um caso de uso denominada de associao. Ela indica que o ator e o caso de uso comunicam entre si, cada um com a possibilidade de enviar e receber mensagens.

Podem existir relacionamentos entre casos de uso, aplicados com a finalidade de fatorar comportamentos comuns e variantes, evitando redundncias e aumentado o reuso. Os relacionamentos existentes na UML so generalizao, incluso e extenso [BOO 99].

24

Um relacionamento de generalizao entre casos de uso indica que um caso de uso pode compartilhar o comportamento definido em um ou mais casos de uso. um mecanismo usado para identificar comportamentos reutilizveis.

O relacionamento de incluso entre casos de uso, identificado pelo estereotipo inclui (do ingls include), significa que um caso de uso incorpora explicitamente o comportamento de outro caso de uso. O caso de uso, includo, nunca permanece isolado, apenas instanciado como parte de alguma base maior que o inclui. Este tipo de relacionamento utilizado para evitar descrever o mesmo fluxo de eventos vrias vezes, fatorando o comportamento comum em um caso de uso prprio. O relacionamento de incluso essencialmente um exemplo de delegao [BOO 99]. A figura 2.6 ilustra um exemplo de relacionamento de incluso.

! !

FIGURA 2.6 Exemplo de relacionamento de incluso

J o relacionamento de extenso entre casos de uso, identificado pelo estereotipo estende (do ingls extend), significa que um caso de uso incorpora implicitamente o comportamento de um outro caso de uso, em um local especificado indiretamente pelo caso de uso estendido. Este relacionamento usado para modelar um comportamento que ocorre em situaes especficas, de modo a separar os comportamentos opcionais do comportamento obrigatrio de um caso de uso. A figura 2.7 um exemplo deste tipo de relacionamento.

! !

FIGURA 2.7 Exemplo de relacionamento de extenso

Organizar os casos de uso, extraindo o comportamento comum, por meio de relacionamentos de incluso, e diferenciando as variantes, atravs de relacionamentos estendidos, uma parte importante para a criao de um conjunto de casos de uso simples, equilibrado e compreensvel, para o sistema [BOO 99].

2.3 Discusso sobre Cenrios e Casos de Uso

Existem ainda vrias discusses ao redor de cenrios e casos de uso. Os termos cenrio e caso de uso significam diferentes coisas para diferentes pessoas: suas

25

definies, muitas vezes, no so claras, ora sendo utilizados como sinnimos, ora como conceitos distintos.

Em [COC 97a, COC 97b], encontra-se um estudo onde apontado que as diversas definies de casos de uso diferem sobre quatro dimenses:

Propsito: casos de uso podem ter o propsito de descrever histrias dos usurios ou especificar requisitos;

Contedo: o contedo de um caso de uso pode ser contraditrio ou consistente; quando consistente, pode estar na forma de narrativa textual ou notao formal;

Pluralidade: casos de uso podem ser apenas um cenrio ou conter mltiplos cenrios;

Estrutura: uma coleo de casos de uso pode ser representada atravs de uma estrutura formal, uma estrutura informal, ou, simplesmente, atravs de um conjunto no estruturado.

A definio original de casos de uso proposta por Jacobson [JAC 92] e, posteriormente, adotada na UML, tem o propsito de especificar requisitos, com o contedo na forma de uma narrativa textual consistente, contendo mltiplos cenrios e possuindo uma estrutura semiformal.

Entretanto, o conceito de casos de uso ainda vago e confuso, e existem vrios aspectos problemticos que precisam ser tratados. Abordagens apontam que casos de uso apresentam problemas conceituais, alguns deles so destacados em [REG 95a, REG 95b, CON 2000b] e mostrados a seguir:

Notao e contedo: O que exatamente casos de uso contm? Como so organizados os contedos? O que significam os contedos?

Expresses idiomticas: Qual linguagem usada para expressar os contedos que definem um caso de uso?

Granularidade: O tamanho e o nvel de detalhamento de cada caso de uso escolhido arbitrariamente?

Cobertura: Casos de uso podem garantir apenas uma cobertura parcial de todos possveis usos do sistema?

Contexto: Casos de uso ocorrem sobre quaisquer situaes ou sobre condies especficas?

Interseo: Casos de uso so independentes ou podem sobrepor-se total ou parcialmente? Como modelar os relacionamentos?

Concorrncia: Como modelar as concorrncias internas e entre casos de uso?

Outro problema pertinente que, na UML, casos de uso geralmente so referentes interao sob a tica do sistema, no considerando adequadamente aspectos de usabilidade. Conforme j destacado em [CON 2000a], observa-se que, na UML, a corrente definio de casos de uso, desviou-se da nfase original de Jacobson, no uso: Um caso de uso uma maneira especfica de usar um sistema...; para um ponto de vista mais centrado no sistema: Caso de uso uma descrio de um conjunto de seqncias de aes... que um sistema realiza.... O foco est no que o sistema executa, no no que o usurio faz ou deseja.

Casos de uso tm sido usados na ES para ganhar percepo em possveis modelos de software, no focando as tarefas dos usurios, enquanto que cenrios, em IHC,

26

capturam primeiramente o comportamento dos usurios. Deve-se atentar para no se modelar apenas a perspectiva do sistema (figura 2.8) ou a perspectiva do usurio (figura 2.9). necessrio estar centrado nas tarefas dos usurios e nas responsabilidades do sistema para suport-las, ou seja, no uso do sistema.

Consultar Extrato 1. O caixa eletrnico captura a identificao. 2. O caixa eletrnico valida a identificao. 3. O caixa eletrnico coleta a transao extrato. 4. O caixa eletrnico coleta o perodo. 5. O caixa eletrnico valida o perodo 6. O caixa eletrnico emite o recibo do extrato. 7. O caixa eletrnico fica pronto para nova transao.

FIGURA 2.8 Caso de uso com a perspectiva do sistema

Consultar Extrato 1. O cliente fornece sua identificao. 2. O cliente pede o extrato. 3. O cliente escolhe o perodo 4. O cliente pega o recibo do extrato. 5. O cliente sai.

FIGURA 2.9 Caso de uso com a perspectiva do usurio

Como visto anteriormente, casos de uso e cenrios so importantes tcnicas de modelagem, amplamente utilizadas respectivamente em IHC e ES, em diferentes contextos, com diferentes vises; mas apresentando muitas similaridades. Embora ambos sejam descries narrativas sobre interaes, existem diferenas entre estes conceitos. A tabela a seguir destaca resumidamente algumas delas:

TABELA 2.2 Quadro sinttico, destacando diferenas entre cenrios e casos de uso [VED 2001] Conceito Cenrio Caso de Uso Aplicao

Comumente utilizado em IHC para inspecionar atividades humanas ao usar um, presente ou futuro, artefato. Concentra-se em aspectos de usabilidade.

Comumente utilizado em ES para modelar requisitos funcionais e manipular modelos de objetos. Concentra-se em aspectos funcionais.

Pluralidade

Uma seqncia especfica de aes, um nico caminho.

Conjunto de seqncias de aes, vrios caminhos.

Nvel de abstrao Concreto. Diferentes nveis de abstrao, mas tipicamente mais abstratos que cenrios.

Notao

Descrito em linguagem natural. Descrito em linguagem natural, semiformal ou formal.

Estrutura

No h estrutura para representar um conjunto de cenrios.

Uma coleo de casos de uso possui uma estrutura. Na UML, so os diagramas de casos de uso.

Abordagem

Prov uma abordagem bottom-up. Cenrios so generalizados e sintetizados em casos de uso.

Prov uma abordagem top-down. Casos de uso so refinados respeitando suas propriedades estruturais.

27

Contudo, tem-se a convico de serem conceitos valiosos para se combinarem as diferentes perspectivas das reas de IHC e ES.

Fazendo uso do conceito de nveis de abstrao e partindo do enfoque de cenrios serem instncias concretas de casos de uso, podem-se combinar os propsitos e usos complementares de ambas as tcnicas. De fato, cenrios tm sido utilizados com uma base comum entre diferentes tipos de modelagem. Um mtodo de construo que integrasse as duas tcnicas seria til; pois permitiria uma busca integrada da qualidade interna e externa dos sistemas e, conseqentemente, o desenvolvimento de sistemas interativos teis e usveis.

A integrao destes conceitos s metodologias de desenvolvimento de software tambm um importante aspecto a ser considerado. Em alguns casos, os conceitos so usados informalmente; em outros, fazem parte do processo de desenvolvimento; e, num ponto de destaque, quando suas potencialidades so exploradas mais efetivamente, so eles utilizados ao longo de todo o ciclo de vida do software, guiando o processo de desenvolvimento.

Todavia, no se podem representar atravs de casos de uso todos os requisitos de um sistema. Casos de uso so mais adequados para representar os requisitos comportamentais e os requisitos funcionais. Demais requisitos no funcionais (RNFs), como formato de dados, requisitos de performance, regras de negcio e frmulas complexas, devem ser representados em outros formatos. Porm, casos de uso funcionam como uma estrutura central capaz de conectar vrios tipos de requisitos, podendo ser ligadas a casos de uso informaes associativas. Utilizando a metfora da roda (figura 2.10), considera-se casos de uso como o eixo de uma roda que conecta outras informaes, associadas aos raios, levando a diferentes direes [COC 2000]. Esta uma das razes pelas quais muitos consideram casos de uso como o elemento central na ER e no processo de desenvolvimento, como um todo.

"

#

" $

"%

"

#

&

"'%& (

( )

FIGURA 2.10 Modelo de requisitos eixo e raios [COC 2000]

Segundo [CYS 2001] os RNFs, devem ser tratados desde as primeiras fases do desenvolvimento de software, trazendo para os casos de uso as informaes e aes necessrias para satisfazerem o conjunto de RNFs elicitados. Os ciclos de requisitos

28

funcionais (viso funcional) e de RNFs (viso no funcional) devem ser integrados atravs do uso de pontos convergentes [CYS 2001]. De fato, os RNFs so modelados atravs de outra notao, como, por exemplo, RNFs Framework [CYS 2001]), no atravs de casos de uso; embora estes permitam ligar as duas vises. Casos de uso ajudam na clarificao do inter-relacionamento entre requisitos funcionais e RNFs.

Vrias pesquisas tm focado principalmente as funes e os usos de cenrios e casos de uso, no processo de desenvolvimento de sistemas, enquanto que o processo de construo destes, muitas vezes, negligenciado. Desenvolvedores, freqentemente, no sabem como identificar casos de uso, o que incluir neles, qual o nvel de detalhamento, como represent-los e como estrutur-los. A abordagem original de casos de uso [JAC 92, JAC 94a, JAC 94b, JAC 94c], posteriormente adotada na UML [BOO 99], no define precisamente nenhum formato especfico para descrever seus contedos, nem um processo sistemtico para constru-los. A falta de guias para a construo de casos de uso certamente uma das desvantagens das abordagens baseadas em casos de uso para ER. Caso no sejam devidamente construdos, ou, ainda, sejam ambguos, incompletos ou inconsistentes, as interaes que os casos de uso representam tambm herdaro essas propriedades [ROL 98a].

29

3 Abordagens Baseadas em Objetivos: Viso Panormica

3.1 Introduo

Ao se criar um software, no se planeja e no se desenvolve apenas um artefato, criam-se novas possibilidades para aes e interaes humanas [CAR 95]. Todo software uma ferramenta. Como boa ferramenta, deve suportar o trabalho de algum, tornar o trabalho mais fcil, mais rpido, mais simples e mais flexvel. Para desenvolverem-se sistemas que suportam adequadamente o uso, trabalhos de pesquisa enfatizam que se precisa entender melhor as tarefas realizadas pelas pessoas e aplicar de maneira mais eficiente a compreenso das tarefas no processo de desenvolvimento de software (ver ciclo tarefa-artefato [CAR 95] na seo 2.1.4).

As atividades de pessoas, no trabalho, podem ser descritas como tarefas. Segundo [STO 95] o termo tarefa definido como: uma tarefa um objetivo junto com conjuntos ordenados de aes que o satisfariam em contextos apropriados. Baseando-se na teoria da ao, sabe-se que, antes de executar uma seqncia de aes, elaboram-se planos, e o ponto inicial de um plano a formulao de um objetivo [CAR 95]. Seguindo esta perspectiva, est claro que, para desenvolver um sistema interativo, necessrio, em primeiro lugar, conhecer os objetivos dos usurios para, ento, propor a especificao dos mecanismos que sustentaro as tarefas necessrias para alcan-los.

Enquanto anlises de sistema tradicionais focam quais caractersticas um sistema ir suportar, abordagens baseadas em objetivos focam por que sistemas so construdos, provendo motivao e argumento para justificar os requisitos de software [ANT 96]. Possibilitam assim uma anlise mais ampla do contexto no qual o sistema ir operar. Focar objetivos, ao invs de requisitos especficos, permite analistas comunicarem com stakeholders - pessoas envolvidas no sistema em desenvolvimento -, usando uma linguagem baseada em conceitos que ambos tm familiaridade [ANT 96]. Todavia, especificar os requisitos de um sistema, a partir dos objetivos dos usurios, no uma tarefa trivial. Objetivos so estados finais desejveis de serem alcanados, no aes a serem realizadas [ANT 96]. O refinamento de objetivos em solues de projeto um processo de mltiplos estgios; vagos objetivos de alto nvel devem ser refinados em concretos objetivos formais [KAV 96]. Isto necessrio, pois somente objetivos primitivos podem ser operacionalizados - traduzidos em aes atmicas do usurio, do hardware ou do sistema para, ento, se tornarem requisitos operacionais na especificao final de requisitos [POT 95].

Um dos fatores positivos de se enfatizarem objetivos, como fontes para o desenvolvimento, que eles so consideravelmente estveis [ANT 96]. Vrios sistemas podem ser propostos para serem realizados os objetivos dos usurios: eles diferiro basicamente em como os objetivos so operacionalizados, ou seja, quais aes sero executadas para que os objetivos sejam alcanados e quem ou o que as realizar. Isto implica que possvel, a partir dos objetivos, especificar as futuras tarefas com o sistema, ou seja, as tarefas interativas [PIM 97].

30

Deve-se considerar que a operacionalizao dos objetivos no deve ser predominantemente top-down, por ser altamente interativa [KAV 96]. Derivao de casos de uso e refinamento de objetivos so atividades do desenvolvimento de software que se apiam mutuamente [POT 95, ROL 98b]. O conhecimento teleolgico preocupa-se com os propsitos especficos para os quais o sistema foi projetado, enquanto a anlise de casos de uso dedicada a preencher a lacuna entre tais propsitos abstratos e a real estrutura e comportamento do sistema [KAV 96].

Casos de uso especificam um modo de operacionalizar um objetivo. Assim, possvel obter um conjunto de casos de uso, analisando objetivos, alocao de objetivos etc. Reciprocamente, possvel retornar e elaborar objetivos, quando se caminha atravs de um caso de uso, j que ele uma forma natural para se descreverem as circunstncias nas quais um objetivo pode falhar ou ser bloqueado, facilitando a descoberta de novos objetivos e a considerao de alternativas para a operacionalizao dos mesmos. A anlise do caso de uso pode fornecer percepes concretas sobre o comportamento do macrosistema - ambiente geral no qual o software desenvolvido e deve operar - e as razes para tal, possibilitando a identificao de solues mais plausveis [POT 95, ANT 98a].

Trabalhos de pesquisa j reconhecem a importncia da relao entre objetivos e casos uso. Segundo Kaindl, somente se podem entender as interaes descritas em um caso de uso, quando se conhece seu objetivo [KAI 95]. Quando se est familiarizado com um sistema, os objetivos das interaes parecem bvios; todavia, no processo de elicitao de requisitos e modelagem de tarefas de um novo sistema, ainda desconhecido, saber o objetivo uma informao crucial para a compreenso de cada caso de uso. De acordo com a abordagem [KAI 95] os propsitos da utilizao de casos de uso so claramente definidos, j os propsitos das interaes descritas nestes, geralmente so ignorados ou deixados implcitos. Faltam representaes adequadas de objetivos em casos de uso.

Na realidade, outras abordagens tambm consideram serem os objetivos fundamentais para construo de cenrios e/ou casos de uso [KLA 93, POT 95, KAV 96, REG 96, COC 97a, COC 97b, ROL 98b, CON 2000a]; porm poucos oferecem um modo de se utilizarem complementarmente as duas tcnicas para a determinao dos requisitos. Na maioria das abordagens, ou no existe uma notao para objetivos, ou no existe um processo sistemtico de construo e validao de casos de uso, a partir dos objetivos, ou, at mesmo no, existem ambos.

3.2 Algumas Propostas

Nesta seo, so apresentadas sucintamente trs abordagens baseadas em objetivos para construo de casos de uso e/ou cenrios. Notifica-se que se utilizar, ao longo deste trabalho, os termos cenrio e casos de uso, de acordo com o entendimento apresentado no captulo 2, embora possam ser utilizadas terminologias diferentes em algumas das abordagens referenciadas.

31

3.2.1 Abordagem de Potts [POT 94, POT 95]

Em [POT 94, POT 95], apresentada a proposta de Colin Potts para a construo de casos de uso. Nesta abordagem, conceitos teleolgicos so utilizados para gerarem casos de uso esquemticos, utilizados para compreender as necessidades dos usurios.

proposto um esquema de caso de uso com estrutura teleolgica (figura 3.1) que, utilizado em conjunto com uma estratgia de refinamento de objetivos, guia a produo de casos de uso. O princpio que a seo narrativa de um caso de uso consiste em uma seqncia de episdios, cada um correspondente a algum objetivo ou obstculo. obstculo definido como comportamento ou, outro objetivo que bloqueia a realizao de um dado objetivo e episdio definido como um conjunto particular de aes (plano), executadas sob condies, que tornam possvel a descrio operacional de um objetivo do domnio do problema [POT 95].

Scenario Setting Narrative Evaluation Setting Background Roles Roles Role* Narrative Episode+ Episode Goal Action Outcome

Legend: Asterisks represent zero or more repetitions, braces represent optional categories, and the vertical bar represents alternatives.

FIGURA 3.1 Esquema de casos de uso [POT 95]

Em [POT 95], apontado que, diferentemente das intuies dos usurios, a hierarquia dos objetivos ajuda a delimitar a cobertura dos casos de uso. Porm, um potencial nmero ilimitado de casos de uso, pode ser derivado, a partir dessa hierarquia. Heursticas so utilizadas para guiarem a obteno do conjunto de casos de uso salientes. Um caso de uso saliente tem um propsito, no redundante e auxilia os usurios e desenvolvedores a levantarem e entenderem algum aspecto do sistema proposto que deve ser resolvido antes de poder ser dito que o sistema atende as necessidades dos usurios.

De acordo com a abordagem, vrias atividades so necessrias antes que os casos de uso esquemticos possam ser produzidos. Os objetivos para o domnio devem ser identificados e decompostos; obstculos devem ser identificados e analisados para decidir quais merecem futura ateno; e, um ou mais sistemas que cumprem os objetivos identificados devem ser propostos. Com respeito decomposio de objetivos, apenas observada a similaridade com a anlise hierrquica de tarefas [POT 95] e, para a identificao de obstculos, sugerida a realizao de um questionamento sistemtico [POT 94]. Os relacionamentos entre os objetivos e atores, assim como os relacionamentos entre objetivos, obstculos e objetivos defensivos ou de suavizao so representados por tabelas.

Segundo Potts [POT 95], casos de uso esquemticos tm a vantagem de poder esclarecer antes da implementao como o sistema proposto, ou propostas alternativas iro afetar os reais objetivos dos usurios em situaes atpicas de uso; mas significantes.

32

3.2.2 Abordagem de Cockburn [COC 97a, COC 97b, COC 98, COC 2000]

Em [COC 97a, COC 97b, COC 98, COC 2000] proposta, por Alistair Cockburn, uma teoria que utiliza objetivos como o elemento chave dos casos de uso. A abordagem considera que os objetivos podem resumir as funes do sistema, em termos compreensveis e verificveis.

O foco principal da abordagem a escrita de casos de uso efetivos, sendo apresentas tcnicas de como pensar, como redigir sentenas e em que seqncia trabalhar. Os modelos e as tcnicas apresentados na abordagem tm sido aplicados e avaliados em projetos reais. Os trabalhos [COC 97a, COC 97b, COC 2000] so descritos como resultados destas experincias.

Na abordagem de Cockburn, proposto um modelo para descrever os casos de uso que utiliza conceitos teleolgicos; mas que, diferentemente, da abordagem apresentada anteriormente, no possui uma estrutura episdica. O modelo pode ser usado tanto na forma textual quanto na tabular; em ambos os casos, a descrio dos casos de uso divida em sees [COC 98]:

Nome do caso de uso: uma pequena frase verbal descrevendo o objetivo; Objetivo no contexto: uma descrio mais detalhada a respeito do objetivo,

caso necessrio; Escopo: qual sistema deve ser considerado uma caixa-preta sobre o ponto de

vista do projeto; Nvel: o caso de uso pode ser de algum dos trs tipos: resumo, tarefa primria

ou subfuno; Pr-condio: as condies esperadas do contexto, antes de iniciar o caso de

uso; Condio de termino bem sucedido: as condies esperadas do contexto, aps

a realizao completa do caso de uso; Condio de termino com falha: as condies esperadas do contexto, aps o

abandono do caso de uso; Ator principal: o nome ou a descrio do ator principal; Gatilho (Trigger): a ao sobre o sistema que inicia o caso de uso; Curso principal: seqncia de passos do curso normal, descrevendo aes, a

partir da ativao do caso de uso; Extenses: lista de condies, cada uma se referindo ao passo do curso

principal; Subvariaes: as subvariaes que, eventualmente, possam causar bifurcao

no caso de uso; Informaes adicionais: outros dados importantes para o caso de uso, como

prioridade, performance, freqncia, atores secundrios e casos de uso relacionados.

A abordagem de Cockburn [COC 97a, COC 97b, COC 2000] faz uso de metforas para representar os objetivos e os casos de uso. Os objetivos em seus diversos nveis so estruturados hierarquicamente, formando um grfico que se assemelha a um veleiro (do ingls sailing ship), ilustrado na figura 3.2. J casos de uso so associados a calas listradas (do ingls striped trousers) com pernas de sucesso e falha (figura 3.3). O cinto da cala o objetivo que aglutina todos os cenrios, cada listra um cenrio, e cada linha, em um cenrio, uma ao primitiva ou um objetivo de

33

um caso de uso subordinado. Essa analogia prov uma viso sintetizada da coleo dos caminhos de um caso de uso.

FIGURA 3.2 Metfora do veleiro (sailing ship) [COC 2000]

FIGURA 3.3 Metfora da cala-listrada (striped trousers) [COC 2000]

Em [COC 97a, COC 97b, COC 2000], a exploso do nmero de casos de uso evitada, utilizando trs tcnicas: casos de uso subordinados, extenses e variaes. Para ligar casos de uso a requisitos de interface, de performance e aos atores, sugerido o uso de tabelas auxiliares.

3.2.3 Abordagem de Rolland [ROL 98a, ROL 98b, ROL 99]

A abordagem CREWS-LEcritoire de Colette Rolland parte integrante do projeto CREWS (Cooperative Requirements Engineering With Scenarios), um longo projeto de pesquisa, iniciado em 1996, pela Comunidade Europia. A abordagem visa elicitar requisitos, explorando o relacionamento bidirecional entre a autoria de cenrios textuais e a descoberta de objetivos. Para cada objetivo descoberto, escrito um cenrio que, posteriormente, analisado para descobrir novos objetivos, o que leva descrio de novos cenrios e assim sucessivamente. Os requisitos elicitados so expressos na forma de uma hierarquia de objetivos e cenrios.

A idia central da abordagem CREWS-LEcritoire o conceito de Requirements Chunks (RC) definido como um par de objetivo e cenrio. Um objetivo de natureza intencional; e um cenrio, de natureza operacional; um RC uma possvel maneira de alcanar um objetivo. Os RCs so inter-relacionados por composio, alternativa e

34

refinamento, constituindo um sistema de conceitos, denominado Requirement Chunck Model (RC Model).

Os RCs so organizados hierarquicamente em 3 nveis de abstrao: contextual, funcional e fsico. O nvel contextual tem o propsito de identificar os servios que um sistema deve prover para uma organizao. O foco do nvel funcional nas interaes, entre o sistema e seus usurios, necessrias para alcanarem os servios atribudos ao sistema ao nvel contextual. O nvel fsico foca quais aes internas o sistema precisa para executar as interaes selecionadas ao nvel funcional.

Uma nfase particular dada na explorao de cenrios textuais, descritos em linguagem natural pelos stakeholders. So propostas guias para autoria de cenrios e elicitao de objetivos.

A elicitao de objetivos baseada em anlise lingstica de declaraes de objetivos. O processo guiado de autoria de cenrios dividido em dois estgios principais: a escrita dos cenrios e a correo dos mesmos. Para guiar a escrita dos cenrios so propostas guias de estilo e contedo referentes a um modelo conceitual e um modelo lingstico de cenrios. Para guiar a correo dos cenrios proposto um conjunto de regras. Cenrios escritos, em prosa informal, so progressivamente transformados em textos estruturados e no ambguos, integrados ao RC Model. Atravs de estratgias de composio e alternativa, diferentes cenrios so integrados em um caso de uso.

3.2.4 Anlise Crtica das Abordagens

A anlise destes trabalhos permitiu a avaliao da importncia de relacionar objetivos com casos de uso. A abordagem de Potts [POT 94, POT 95], em especial, clarifica a importncia da considerao de obstculos. A abordagem de Cockburn [COC 97a, COC 97b, COC 98, COC 2000] um relato prtico de como casos de uso tm sido utilizados em projetos e possui valiosas guias para a construo e descrio de casos de uso, assim como sugere o uso de uma simples, mas eficiente, lista para relacionarmos atores a objetivos. Diferentemente das duas abordagens anteriores, a CREWS-LEcritoire de Rolland [ROL 98a, ROL 98b, ROL 99] utiliza primeiramente cenrios e prope anlises sintticas e semnticas destes para a elicitao de objetivos e obstculos e, tambm, para a integrao dos cenrios em casos de uso. As anlises lingsticas, sintticas e semnticas, so relativamente complexas. Deste modo, precisa-se de ferramentas especializadas para utilizar a abordagem CREWS-LEcritoire, mesmo para pequenos projetos. De fato, em [ROL 98b] j apresentada uma ferramenta para a aplicao da abordagem.

As idias e conceitos presentes nessas trs abordagens foram cruciais para a elaborao da proposta. Cada uma delas apresenta pontos de destaque; porm nenhuma delas atende a todo o conjunto de critrios que so julgados pertinentes para uma construo sistemtica, que considere mutuamente as perspectivas de ES e IHC. A seguir apresentada uma tabela comparativa que sintetiza a anlise das abordagens.

35

TABELA 3.1 Comparao entre abordagens baseadas em objetivos Abordagem

Critrio Potts Cockburn Rolland

Investigao das singularidades

Um questionamento sistemtico e a criao de aes defensivas e corretivas

Um questionamento sistemtico e algumas guias.

Algumas guias

Delimitao do conjunto de casos de uso

Algumas heursticas para determinar a salincia dos casos de uso. Uso do conceito de episdios

Uso de tcnicas de subordinao, extenso e variao

Sugere que os objetivos delimitam o nmero de casos de uso. Uso do conceito de episdios

Uso complementar dos conceitos de cenrios e casos de uso

Apenas sugerido, sem especificar, que cenrios podem ser instanciados para serem avaliados pelos usurios

Cenrios no so usados para experimentao com os usurios

Cenrios so usados apenas num primeiro momento para elicitar objetivos e posteriormente so integrados em casos de uso. No so, porm, usados para experimentao com os usurios

Avaliao da usabilidade com os usurios

No No No

Diferentes nveis de abstrao

No Sumrio, objetivos do usurio e subfunes

Contextual, funcional e fsico

Nvel de abstrao que estabelece ligao com abordagens OO

No No No

Notaes definidas Sim Sim Sim Guias para a descrio textual dos casos de uso

No Sim Sim

Relaes temporais nos casos de uso

No No No

Fluxo dos eventos Seqencial Seqencial Seqencial Considerao de eventos assncronos

No Sugere trat-los em uma seo separada, usando asterisco (*) para identific-los

No

Representao de Objetivos

Apenas sugerida uma hierarquia de objetivos similar a modelos de tarefas

Metfora do veleiro Requirements Chunks organizados hierarquicamente

Representao da ontologia

No No No

36

4 Abordagem Proposta

4.1 Introduo

Este trabalho investiga e prope uma abordagem que faz uso de conceitos teleolgicos para gerar, estruturar e validar casos de uso e cenrios. Tem como principal objetivo investigar os conceitos de cenrios e casos de uso, e integrar e sistematizar a construo destes, conciliando as perspectivas de ES e IHC.

O trabalho tem como base algumas idias da abordagem TAREFA (Task Analysis based Requirements Enginnering Framework) [PIM 97], concebida para sistematizar a engenharia de requisitos de sistemas interativos que j adota casos de uso e cenrios como fios condutores para a integrao das reas de ES e IHC. Esta abordagem uma evoluo da abordagem TAREFA [PIM 97], de forma que os aspectos construtivos de casos de uso so aprimorados, novos aspectos so investigados e a construo de casos de uso e cenrios , afinal, sistematizada. Uma descrio detalhada da abordagem ser apresentada ao longo dos prximos dois captulos.

Prope-se uma abordagem que, a partir de um modelo explcito de objetivos dos usurios, refinados e representados, permite definir, refinar e representar os objetivos do sistema que serviro como base para a construo de casos de uso em quatro diferentes nveis de abstrao, essencial, singular, operacional e concreto, cada um relativo a um tipo de conhecimento especfico.

A abordagem um processo interativo e iterativo de construo, refinamento, experimentao, modificao e integrao de casos de uso. Em resumo, prope-se a construo de casos de uso essenciais, nvel mais abstrato, pelo analista, a partir dos objetivos; ainda pelo analista, o refinamento de casos de uso essenciais, visando definir casos de uso singulares; a instanciao dos casos de uso concretos, cenrios; e, quando desejvel, a definio dos casos de uso operacionais, a partir dos casos de uso singulares; a experimentao e avaliao da funcionalidade e do comportamento dos cenrios pelos usurios, visando investigar suas reais necessidades; a reviso dos casos de uso pelo analista, procurando adequ-los s expectativas dos usurios; e, finalmente, a integrao, pelo analista, dos casos de uso obtidos neste processo recursivo.

O diagrama ilustrado na figura 4.1 representa uma viso geral do processo de construo sistemtica de casos de uso e cenrios. Ao final do processo, deseja-se obter um modelo de casos de uso que permita especificar requisitos funcionais, conjuntamente com requisitos de interao, de maneira compreensvel e praticvel e que sirva como ponto de partida para a continuidade do desenvolvimento de software.

Acredita-se que a combinao de casos de uso e cenrios com uma boa compreenso das tarefas e do contexto organizacional em que elas so executadas, juntamente com a explicitao dos objetivos, previnam a possibilidade de que especificaes se tornem desencontradas das reais necessidades dos usurios e devam ser a base para um processo de desenvolvimento de software interativo.

37

* "

+, "

%

&

' "

,

- .

(

" %

&

,

*

* " "

" %

/ 0 "

" %

' (

FIGURA 4.1 Viso geral da abordagem teleolgica e dos quatro nveis de abstrao de casos de uso

4.2 Atividades Preliminares

A proposta, em epgrafe, est inserida no mbito da ER; mas especificamente na ER de sistemas interativos. Casos de uso tm um papel importante na ER, contudo, de se lembrar que algumas atividades so necessrias, antes que os casos de uso possam ser produzidos. Levando em considerao o que foi apresentado no captulo 3 (seo 3.1), fcil compreender que, para considerarem-se, adequadamente, aspectos de usabilidade, os objetivos dos usurios so fundamentais. Deve-se, ento, ter como ponto de partida no processo de construo de casos de uso um modelo explcito de objetivos dos usurios, refinados e representados.

No cabe aqui, neste trabalho, discutir quais so as melhores tcnicas de coleta e determinao de objetivos dos usurios e de informao contextual. Sinta-se vontade para usar o processo de sua preferncia, como, por exemplo, GBRAM (Goal-Based Requirements Analysis Method) [ANT 96, ANT 98b], mas lembre-se que preciso, sobretudo, identificar todos os atores que interagem com o sistema; identificar seus objetivos; decomp-los; organiz-los; e represent-los.

Sugere-se, assim, o uso do subprocesso de anlise, proposto em TAREFA [PIM 97], que tem o objetivo de compreender o contexto do domnio do problema e de identificar os requisitos dos usurios. A anlise composta por anlise contextual, elicitao dos requisitos dos usurios (explicitamente solicitados) e determinao dos

38

requisitos dos usurios, chegando a um conjunto de requisitos de usurios (explcitos, implcitos e organizacionais) e um conjunto de modelos para representar os conhecimentos obtidos durante a anlise contextual [PIM 2000].

Uma contribuio original de TAREFA [PIM 97] que a hierarquia de objetivos dos usurios obtida e representada atravs de um tipo particular de modelo de tarefa. A anlise de tarefa emergiu da ergonomia, como um importante apoio ao desenvolvimento de sistemas interativos, devido ao fato de ser um mtodo emprico de compreender como as pessoas executam suas tarefas [PIM 96]. Uma anlise de tarefa produz um modelo explcito de tarefas em um domnio, denominado modelo de tarefas, representando dois tipos de informao: objetivos e aes.

Em [PIM 97], proposto um modelo, derivado diretamente de um modelo de tarefas, onde o elemento principal a estrutura dos objetivos e subobjetivos, denominado modelo de tarefa minimal. Alm da organizao hierrquica dos objetivos, h a descrio da organizao e da interdependncia deles. A organizao a organizao temporal na qual o usurio alcana suas tarefas (sucesso, intercalao, paralelismo, etc). A interdependncia uma sucesso imposta pelas relaes entre as entradas e sadas das tarefas. O modelo de tarefa minimal um modelo abstrato, sem consideraes tecnolgicas, representando as intenes do usurio, ao invs de aes, e serve como base para a construo dos casos de uso. utilizada a notao MAD (Mthode Analytique de Description), neste modelo; mas qualquer modelo de tarefas com essas caractersticas pode ser usado, como, por exemplo, GOMS (Goal Operators Methods Selection), HTA (Hierarquical Task Analysis) ou CTT (ConcurTaskTree).

Entretanto, a determinao dos requisitos dos usurios no suficiente para a definio dos requisitos do sistema, pois os requisitos dos usurios tendem a ser muito gerais e no provem indicaes ou detalhes sobre o comportamento (interno ou externo) do sistema. O modelo de tarefas descreve os objetivos dos usurios, sem a preocupao com as funes subjacentes do sistema. Tambm em TAREFA [PIM 97], so propostas duas atividades para a definio dos requisitos iniciais do sistema, chamados iniciais, por representarem o ponto de vista do usurio sobre os requisitos do sistema. A primeira uma Re-engenharia de Tarefas, baseada na informao contextual coletada, que tem o intuito de reorganizar as tarefas que se deseja corrigir para eliminar as redundncias e as ineficincias, antes de propor uma soluo computacional; a segunda uma Alocao de Funes, para determinar que tarefas sero manuais, automticas ou interativas (maiores detalhes em [PIM 97]). Aps a execuo desses dois passos, os requisitos iniciais do sistema so determinados e pode-se pelas atividades de construo, de experimentao, de modificao e integrao dos casos de uso, especificar as caractersticas que um sistema tem de possuir para satisfazer os requisitos dos usurios.

Para apoiar a construo dos casos de uso, tambm interessante relacionar explicitamente os objetivos representados nos modelos de tarefas minimais com seus atores iniciadores. Para tal propsito, utiliza-se a lista ator-objetivo, proposta em [COC 2000]. A lista ator-objetivo tambm ajuda a priorizar e particionar o trabalho de desenvolvimento e atualizada, conforme novos objetivos so descobertos na anlise dos casos de uso. Esta lista ator-objetivo composta pelos seguintes campos:

Prioridade Organizacional: Prioridade do objetivo para a organizao;

39

Ator Iniciador: Nome do ator que inicia o caso de uso, ou seja, que tem o objetivo;

Objetivo: Objetivo extrado do modelo de tarefa minimal; Prioridade: Prioridade na qual o sistema tem de suportar o objetivo; ID do Caso de Uso: Identificador do caso de uso que suporta o objetivo.

Opcionalmente o campo prioridade pode ser dividido em trs: Prioridade Organizacional: Prioridade do objetivo para a organizao; Complexidade Tcnica: Complexidade ou dificuldade estimada pelo grupo de

desenvolvimento para prover esta funo; Prioridade de Desenvolvimento: Prioridade na qual o sistema tem de suportar

o objetivo.

Esta diviso torna possvel separar as necessidades da organizao dos custos de desenvolvimento para derivar a prioridade de desenvolvimento [COC 2000].

Segundo Leite [LEI 97], o desenvolvimento de software baseado em casos de uso, apia-se no conceito de que a utilizao da linguagem do problema benfica na interao entre usurios e desenvolvedores. Produzir casos de uso, com a linguagem do usurio, ao invs da linguagem do desenvolvedor, contribui para o sistema resultante refletir o domnio do usurio [MCD 94]. Defende-se ento, a construo de um modelo ontolgico do vocabulrio do problema usado pelo usurio, para representar e estabelecer uma terminologia unificada (ontologia). Essa unificao terminolgica especialmente importante, porque diferentes casos de uso podem ser descritos e analisados por pessoas ou grupos diferentes, e ela auxilia a melhorar a comunicao e estabelecer um entendimento comum entre os stakeholders. Em adio, a ontologia pode ajudar a encontrar e prevenir redundncias; problema que, geralmente aparece, conforme aumenta o nmero de casos de uso. Pode-se representar o modelo ontolgico atravs da notao LEL (Language Extended Lexicon) [LEI 97], centrada na idia de que uma descrio circular dos termos da linguagem melhora a compreenso do macrosistema. O modelo ontolgico j deve ser previamente gerado, ao determinarem-se os objetivos dos usurios; mas , gradualmente, estendido e revisado, conforme os casos de uso so i