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.

CIP CATALOGAO NA PUBLICAO

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.

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

A minha me, com todo amor e carinho

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.

Sumrio
Lista de Abreviaturas.................................................................................. 7
Lista de Figuras ........................................................................................... 8
Lista de Tabelas........................................................................................... 9
Resumo ....................................................................................................... 10
Abstract ...................................................................................................... 11
1

Introduo ....................................................................................... 12

Cenrios e Casos de uso: Fundamentos e Conceitos ................... 16

2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3

Cenrios: Viso de IHC ................................................................................... 16

Aplicao ........................................................................................................ 16
Notao........................................................................................................... 16
Estrutura ......................................................................................................... 17
Uso.................................................................................................................. 17
Casos de Uso: Viso de ES ............................................................................... 18
Aplicao ........................................................................................................ 20
Notao........................................................................................................... 21
Estrutura ......................................................................................................... 23
Relacionamentos............................................................................................. 23
Discusso sobre Cenrios e Casos de Uso....................................................... 24

Abordagens Baseadas em Objetivos: Viso Panormica............ 29

3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4

Introduo ......................................................................................................... 29
Algumas Propostas ........................................................................................... 30
Abordagem de Potts ....................................................................................... 31
Abordagem de Cockburn................................................................................ 32
Abordagem de Rolland................................................................................... 33
Anlise Crtica das Abordagens ..................................................................... 34

Abordagem Proposta ...................................................................... 36

4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.5

Introduo ......................................................................................................... 36
Atividades Preliminares ................................................................................... 37
Modelo de Casos de Uso................................................................................... 39
Casos de Uso Essenciais................................................................................. 41
Casos de Uso Singulares ................................................................................ 46
Casos de Uso Operacionais ............................................................................ 50
Casos de Uso Concretos (Cenrios) ............................................................... 53
Construo de Casos de Uso ............................................................................ 54
Viso Macro do Processo de Construo de Casos de Uso ........................... 56

Aplicao Passo a Passo ao Caixa Eletrnico............................... 58

5.1
5.2
5.2.1

Descrio do Exemplo ...................................................................................... 58

Construo de Casos de Uso ............................................................................ 58
Atividades Preliminares.................................................................................. 59

6
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8

Construo de Casos de Uso Essenciais......................................................... 62

Construo de Casos de Uso Singulares......................................................... 67
Construo de Casos de Uso Operacionais .................................................... 73
Construo de Casos de Uso Concretos (Cenrios) ....................................... 76
Experimentao de Cenrios .......................................................................... 77
Modificao de Casos de Uso ........................................................................ 78
Integrao de Casos de Uso............................................................................ 78

Concluso......................................................................................... 80

6.1
6.1.1
6.1.2
6.2
6.3
6.4

Contribuies .................................................................................................... 80
Compatibilidade com a UML e Resoluo de Aspectos Problemticos ........ 80
Resumo de Resultados.................................................................................... 82
Comparao com Outras Abordagens Baseadas em Objetivos ................... 83
Limitaes ......................................................................................................... 84
Perspectivas de Trabalhos Futuros................................................................. 84

Bibliografia................................................................................................. 85

Lista de Abreviaturas
ATM
CREWS
CTT
ER
ES
GBRAM
GOMS
GRASP
HTA
IHC
IU
LEL
MAD
OMT
OO
OOSE
RC
RNF
TAREFA
UAN
UML
XML

Automatic Teller Machine

Cooperative Requirements Engineering With Scenarios
ConcurTaskTree
Engenharia de Requisitos
Engenharia de Software
Goal-Based Requirements Analysis Method
Goal Operators Methods Selection
General Responsibility Assignment Software Patterns
Hierarquical Task Analysis
Interao Humano-Computador
Interface do Usurio
Language Extended Lexicon
Mthode Analytique de Description
Objecto Modeling Technique
Orientado a Objeto
Object-Oriented Software Engineering
Requirements Chunks
Requisito no Funcional
Task Analysis based Requirements Engineering FrAmework
User Action Notation
Unified Modeling Language
Extensible Markup Language

Lista de Figuras
FIGURA 2.1
FIGURA 2.2
FIGURA 2.3
FIGURA 2.4
FIGURA 2.5
FIGURA 2.6
FIGURA 2.7
FIGURA 2.8
FIGURA 2.9
FIGURA 2.10
FIGURA 3.1
FIGURA 3.2
FIGURA 3.3
FIGURA 4.1
FIGURA 4.2
FIGURA 4.3
FIGURA 4.4
FIGURA 4.5
FIGURA 4.6
FIGURA 4.7
FIGURA 4.8
FIGURA 4.9
FIGURA 4.10
FIGURA 5.1
FIGURA 5.2
FIGURA 5.3
FIGURA 5.4
FIGURA 5.5
FIGURA 5.6
FIGURA 5.7
FIGURA 5.8
FIGURA 5.9
FIGURA 5.10
FIGURA 5.11
FIGURA 5.12
FIGURA 5.13

Exemplo de cenrio............................................................................. 16
Ciclo tarefa-artefato ............................................................................ 18
Exemplo de caso de uso na notao de seqncia numerada.............. 21
Exemplo de caso de uso na notao de narrativa com partio .......... 22
Exemplo de diagrama de casos de uso ................................................ 23
Exemplo de relacionamento de incluso............................................. 24
Exemplo de relacionamento de extenso ............................................ 24
Caso de uso com a perspectiva do sistema.......................................... 26
Caso de uso com a perspectiva do usurio.......................................... 26
Modelo de requisitos eixo e raios .................................................... 27
Esquema de casos de uso .................................................................... 31
Metfora do veleiro (sailing ship) ................................................... 33
Metfora da cala-listrada (striped trousers)................................... 33
Viso geral da abordagem teleolgica e dos quatro nveis de abstrao
de casos de uso .................................................................................... 37
Caso de uso essencial estruturado ....................................................... 43
Exemplo de caso de uso essencial....................................................... 44
Sinais de relaes temporais e de ordenao ...................................... 45
Exemplo de singularidade para o caso de uso singular Consultar
extrato ................................................................................................. 46
Esquema gramatical para casos de uso singulares .............................. 48
Exemplo de caso de uso singular ........................................................ 49
Exemplo de diagrama de seqncia .................................................... 52
Exemplo de caso de uso concreto ....................................................... 54
Diretrizes para a descrio textual de casos de uso............................. 55
Modelo de tarefa minimal Sacar Dinheiro, antes da re-engenharia de
tarefas .................................................................................................. 59
Modelo de tarefa minimal Sacar Dinheiro ......................................... 59
Modelo de tarefa minimal Consultar Saldo ........................................ 60
Modelo de tarefa minimal Consultar Extrato ..................................... 60
Exemplos de entradas na notao LEL para o caixa eletrnico.......... 62
Caso de uso essencial Sacar dinheiro ................................................. 63
Caso de uso essencial Consultar Saldo............................................... 65
Caso de uso essencial Sacar Dinheiro, com relao temporal e eventos
assncronos .......................................................................................... 66
Caso de uso singular Sacar Dinheiro.................................................. 68
Caso de uso singular Sacar dinheiro; Pega o dinheiro e o recibo;
Dinheiro no liberado......................................................................... 72
Episdio Pega o dinheiro e o recibo................................................... 73
Objetos identificados no episdio Fornece identificao ao sistema . 75
Diagrama de seqncia para o episdio Fornece identificao ao
sistema................................................................................................. 75

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 HumanoComputador (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 tarefaartefato.

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
Conceitos

Notao na fase de
anlise de requisitos

Funo no processo de
desenvolvimento
Metodologia para
criao de casos de uso

OOSE
Casos de uso, ator,
exceo, extenso
(extends), incluso
(uses).
Linguagem natural para
descrever casos de uso.
Diagramas para
descrever relaes entre
casos de uso.
Guia todo processo,
usado para identificar
objetos e para criar
projetos robustos.
Algumas heursticas.
Questes para responder
a cada ator ajudam a
identificar casos de uso.

OMT
Booch
Caso de uso, ator,
Caso de uso, cenrio,
cenrio, pr e psiniciador, pr e pscondio, exceo, adds. condies.
Linguagem natural com
algumas recomendaes
para estruturao.

Linguagem natural.

usado para reforar a

anlise de requisitos e
para identificar objetos.

usado para identificar

objetos, para concepo
e para planejamento de
verso.
Prescreve o
planejamento de
cenrios como uma
atividade e prov
algumas poucas
recomendaes.

Lista de aes passo a

passo. Cenrios so
combinados ou
generalizados em casos
de uso.

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

2.2.2

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.
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
insere o carto no caixa automtico
entra com a senha
seleciona a opo
seleciona a conta
entra com a quantia
confirma a quantia
pega o carto

resposta do sistema
l o carto
solicita a senha
valida a senha
mostra o menu de opes
mostra o menu de conta
solicita a quantia
mostra a quantia
retorna 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
Aplicao

Nvel de abstrao

Cenrio
Comumente utilizado em IHC para
inspecionar atividades humanas ao
usar um, presente ou futuro, artefato.
Concentra-se em aspectos de
usabilidade.
Uma seqncia especfica de aes,
um nico caminho.
Concreto.

Notao

Descrito em linguagem natural.

Estrutura

No h estrutura para representar

um conjunto de cenrios.

Abordagem

Prov uma abordagem bottom-up.

Cenrios so generalizados e
sintetizados em casos de uso.

Pluralidade

Caso de Uso
Comumente utilizado em ES para
modelar requisitos funcionais e
manipular modelos de objetos.
Concentra-se em aspectos funcionais.
Conjunto de seqncias de aes,
vrios caminhos.
Diferentes nveis de abstrao, mas
tipicamente mais abstratos que
cenrios.
Descrito em linguagem natural,
semiformal ou formal.
Uma coleo de casos de uso possui
uma estrutura. Na UML, so os
diagramas de 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 preocupase 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 CREWSLEcritoire 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
Investigao das
singularidades
Delimitao do
conjunto de casos de
uso
Uso complementar dos
conceitos de cenrios e
casos de uso

Avaliao da
usabilidade com os
usurios
Diferentes nveis de
abstrao
Nvel de abstrao que
estabelece ligao com
abordagens OO
Notaes definidas
Guias para a descrio
textual dos casos de uso
Relaes temporais nos
casos de uso
Fluxo dos eventos
Considerao de
eventos assncronos
Representao de
Objetivos
Representao da
ontologia

Potts

Cockburn

Rolland

Um questionamento
sistemtico e a criao
de aes defensivas e
corretivas
Algumas heursticas
para determinar a
salincia dos casos de
uso. Uso do conceito de
episdios
Apenas sugerido, sem
especificar, que
cenrios podem ser
instanciados para serem
avaliados pelos usurios

Um questionamento
sistemtico e algumas
guias.

Algumas guias

Uso de tcnicas de
subordinao, extenso
e variao

Sugere que os objetivos

delimitam o nmero de
casos de uso. Uso do
conceito de episdios

Cenrios no so
usados para
experimentao com os
usurios

No

No

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
No

No
No

Sumrio, objetivos do
usurio e subfunes
No

Contextual, funcional e
fsico
No

Sim
No

Sim
Sim

Sim
Sim

No

No

No

Seqencial
No

Seqencial
Sugere trat-los em
uma seo separada,
usando asterisco (*)
para identific-los
Metfora do veleiro

Seqencial
No

No

No

Apenas sugerida uma

hierarquia de objetivos
similar a modelos de
tarefas
No

Requirements Chunks
organizados
hierarquicamente

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 determinaremse os objetivos dos usurios; mas , gradualmente, estendido e revisado, conforme os
casos de uso so identificados e inspecionados.

4.3 Modelo de Casos de Uso

Considerando o j exposto at o momento, fcil compreender que o conceito de
casos de uso, apresentado nesta abordagem, est ancorado no paradigma teleolgico. O
entendimento de cenrios e casos de uso leva em conta uma combinao de vrias
abordagens da literatura [BOO 99, CAR 95, COC 2000, CON 2000a, PIM 97, POT 95].
Caso de uso um modelo narrativo de um conjunto de seqncias de interaes
entre atores e um sistema, agrupadas por um objetivo, comum do ator iniciador,
incluindo suas variantes e representando potenciais ou reais situaes de uso do sistema,
ao ser o objetivo alcanado ou no. Um cenrio, por sua vez, uma instncia especfica
e representativa de uma seqncia de interaes de um caso de uso, tendo um resultado
particular com respeito ao objetivo do ator iniciador. Corresponde descrio de um
comportamento do ambiente e do sistema que aparece em uma situao concreta e
restrita de uso.

40
Um ator representa um papel desempenhado por agentes externos ao sistema:
usurios, dispositivos de hardware, outros sistemas. uma categoria de usurios com
comportamentos e objetivos comuns, identificando um papel genrico e no uma
ocorrncia especfica. O ator que tem o objetivo e inicia a interao chamado de ator
iniciador, os demais que assistem o sistema, para satisfazer o objetivo, so chamados de
atores participantes.
As seqncias de interaes, muitas vezes, tambm so referidas como cursos de
interaes. Alguns cursos terminam atingindo o objetivo, outros no. Um caso de uso
agrupa todos os cursos de sucesso e falha. Casos de uso no ocorrem em qualquer
situao, necessrio considerar o contexto, que demarca seu escopo, caracteriza seus
elementos e define suas condies. As condies so predicados do estado do sistema e
do ambiente que devem ser considerados antes - pr-condices - ou depois - pscondies - das seqncias de interaes.
Tem-se ento, que na abordagem, casos de uso devem ser vistos como planos de
execuo de objetivos, ao invs de meras seqncias cronolgicas de eventos.
Conforme j observado em [COC 97a, COC 97b], uma das dificuldades desta
perspectiva o fato de objetivos existirem em vrios nveis (objetivos, subobjetivos,
aes individuais) e a operacionalizao deles requerer uma freqente mudana entre os
nveis.
Outra caracterstica relevante observada por [KAI 95, PIM 97] que um caso de
uso , ao mesmo tempo, uma especificao da estrutura, da funcionalidade e do
comportamento de uma situao de uso. Como toda a especificao, tem dois aspectos:
o tcnico, pois age como ponto de origem para a concepo e a implementao do
sistema; e o social, por servir para comunicao entre os stakeholders, em particular, o
analista e o usurio.
Para lidar com esses aspectos, utiliza-se o conceito de nveis de abstrao.
Abstrao definida como um mecanismo para esconder detalhes, a fim de focar
aspectos essenciais; e o refinamento utilizado para descrever gradualmente os casos de
uso em diferentes nveis de abstrao.
Conforme j mencionado anteriormente, adotam-se nesta abordagem quatro nveis
de abstrao para descrever os casos de uso; cada um adaptado a um determinado
objetivo e relativo a um tipo especfico de conhecimento e de representao. So eles:
Essencial: Casos de uso ao nvel mais abstrato. So construdos, a partir dos
objetivos de tarefas, presentes nos modelos de tarefas minimais. Devem ser
realizados para a satisfao dos objetivos das atividades do usurio, sempre
consideradas num contexto organizacional;
Singular: Casos de uso essenciais, refinados atravs da determinao de
singularidades - desvios do curso normal que incluem problemas,
anormalidades, excees, interrupes e obstculos -. Para cada singularidade,
pode haver a identificao de possveis aes defensivas e corretivas que o
sistema poderia realizar para, respectivamente, evitar ou corrigir um problema.
Portanto, um caso de uso essencial pode dar origem a diversos casos de uso
singulares; um para cada ocorrncia de uma singularidade;
Operacional: Um caso de uso operacional descreve o comportamento de um
caso de uso singular, em termos de objetos e operaes, a um nvel similar ao

41

do Projeto OO. Estes casos de uso esto a um nvel de abstrao abaixo dos
casos de uso singulares e so voltados, especificamente, gerao preliminar
de arquiteturas de sistemas OO;
Concreto: Casos de uso, no menor nvel de abstrao. Um caso de uso
concreto uma ocorrncia de uma execuo particular de um caso de uso
singular do ponto de visto do usurio. Ele corresponde a uma descrio das
caractersticas de uma situao concreta de uso - prottipos das IUs,
comportamento detalhado do usurio e do sistema, condies de uso,
singularidades ocorridas -, sem levar em considerao os detalhes tcnicos e
arquitetnicos do sistema ao nvel operacional. Por definio, corresponde ao
conceito de cenrio utilizado em IHC.

No necessrio fazer a descrio completa de um caso de uso de acordo com os

quatro nveis. Por exemplo, no h necessidade de se fazer um refinamento, passo a
passo, de um caso de uso essencial at o concreto: o caso de uso operacional opcional
e seu uso s interessante para a concepo orientada a objeto.
Existe uma grande variedade de estilos de representao, utilizados para descrever
o contedo narrativo de um caso de uso (maiores detalhes em [ANT 98a, CON 2000a]).
Mas a notao, na qual os casos de uso so escritos, tem um profundo efeito em suas
utilidades e na qualidade dos artefatos que resultam [CON 2000a]. Para cada um dos
nveis de abstrao, adota-se uma notao especfica de acordo com o propsito do
nvel.
4.3.1

Casos de Uso Essenciais

O conceito de caso de uso essencial similar ao de caso de uso essencial de

Constantine [CON 2000a], diferindo basicamente no fato de que os casos de uso
essenciais de Constantine [CON 2000a] so expandidos, pois descrevem alm do curso
normal, as alternativas importantes ou excees que podem surgir em relao ao
curso normal; enquanto que os casos de uso essenciais, aqui apresentados, so bsicos
e de alto nvel, descrevendo apenas o curso normal das atividades, onde o objetivo
alcanado, sem nenhuma obstruo. Considera-se benfico o uso de casos de uso
essenciais como casos de alto nvel; pois, desta maneira, tornam-se teis para
compreender rapidamente o grau de complexidade e a funcionalidade do sistema
proposto. Concentra-se primeiro em como o sistema deve funcionar normalmente, antes
de serem investigadas as possveis alternativas e falhas. Desta forma, evita-se uma
sobrecarga de complexidade e pode-se aumentar o paralelismo e a produtividade do
desenvolvimento.
Os casos de uso essenciais so expressos numa forma ideal, relativamente livre de
tecnologia e de detalhes de implementao; ou seja, as decises de projeto so
postergadas e abstradas, principalmente aquelas relacionadas com a IU [LAR 2000].
Eles so abstratos e modelam as intenes e no as aes dos usurios; as
responsabilidades e no as respostas do sistema [CON 2000a]. Casos de uso no devem
ser entendidos como logs de atividades humanas, ao contrrio, devem ser abstratos e
orientados a objetivos, significativos e discutveis pelos stakeholders.
Um caso de uso essencial no especifica uma seqncia de interaes concretas,
mas uma seqncia de passos abstratos, permitindo um varivel nmero de

42
implementaes [BID 2001] e encorajando a inovao criativa [CON 2000a]. um
mecanismo esquemtico para ajudar a pensar na maneira cujo software ser utilizado
pelos usurios. Neste sentido, um caso de uso essencial uma projeo do futuro uso do
sistema pelos usurios. Alm disso, como so adaptados ao nvel de abstrao do
usurio, eles podem servir como um eficiente meio de comunicao entre o usurio e
analista.
Existe uma sutil diferena entre objetivos e intenes. Objetivo um estado final
desejado de um sistema, sendo corretamente descrito em termos estticos como estado e
caractersticas de objetos. J uma inteno, em contraste, dinmica e representa o
sentido ou o progresso, ao invs de um estado final. Objetivos so destinos, enquanto
que as intenes representam a jornada do usurio [CON 2000a]. Ainda sobre este
aspecto, Kavakli [KAV 96] destaca que necessidades so difceis de serem
averiguadas e que mais apropriado considerar requisitos como tendncias aquilo
que pessoas tentam fazer quando tem oportunidade [KAV 96] . No trabalho,
tendncia cognominada como inteno. Uma inteno deve ser entendida como
uma verso operacional de um objetivo, portanto ela pode ser identificada e testada,
observando-se o comportamento das pessoas [KAV 96]. Neste sentido, casos de uso
essenciais podem definir estratgias sistemticas para se encontrar os requisitos
dinmicos do sistema.
Nos casos de uso essenciais, a motivao para o usurio a inteno de atingir um
objetivo e a motivao para o sistema a responsabilidade de cumprir as obrigaes.
Responsabilidade , ento, uma expresso de o que precisa ser feito, sem
necessariamente detalhar como ser feito. Para este mais alto-nvel de descrio de
um caso de uso, uma responsabilidade uma abstrao das aes, a serem executadas
pelo sistema para transformar o estado atual no estado final desejado, onde o objetivo da
tarefa interativa, representada pelo caso de uso, alcanado. As responsabilidades
(funes) do sistema sustentaro as tarefas interativas para atingir os objetivos e podem
ser classificadas em dois tipos: responsabilidade receptiva do sistema, onde o evento do
sistema uma recepo de uma inteno ou uma preparao para ao do usurio; e a
responsabilidade expressiva do sistema, onde o evento uma resposta do sistema a uma
inteno [PIM 97].
Este tipo de construo permite que os projetos de IUs e do software sejam feitos
em paralelo, ambos a partir dos casos de uso essenciais. Casos de uso essenciais foram
originalmente criados para apoiar o projeto de IUs, uma vez que se levado a deduzir,
de forma correta, a concepo da interface, a partir da lgica de utilizao do sistema
como suporte realizao de tarefas, e no, a partir da lgica de funcionamento das
funes da aplicao, como usualmente realizado. Eles tambm tendem a
permanecerem corretos por um longo perodo de tempo, uma vez que excluem decises
de projeto e descrevem, apenas, a essncia dos casos de uso, isto permite a identificao
de padres de casos de uso, sendo teis no desenvolvimento de novos projetos [BID
2001].
Notao
Encontram-se na literatura diferentes formas para representar casos de uso:
textual, animada, prottipos etc. A UML prope notaes grficas, como os diagramas
de casos de uso e os diagramas de seqncia para descreverem os eventos de um caso de

43
uso, entretanto estas notaes no permitem a expresso necessria aos casos de uso
para efetiva aquisio e validao de requisitos [ANT 98a]. Alm disto, os diagramas de
seqncia levam o desenvolvedor a considerar mensagens passadas entre objetos do
software, ao invs de manter uma perspectiva externa do usurio e um foco na natureza
das tarefas.
Diversos autores recomendam a representao textual em linguagem natural.
Existem claras vantagens da narrativa textual. A principal razo o fato de que
narrativa textual prov a maneira de expressar o problema em uma representao
facilmente compreensvel, permitindo uma comunicao mais efetiva entre os
stakeholders, no desenvolvimento da aplicao. Clientes e usurios geralmente no
possuem um vasto conhecimento de notaes de ES: a narrativa textual, em linguagem
natural, no exige treinamento formal ou o uso de ferramentas sofisticadas, stakeholders
tem familiaridade com esta notao [COC 97a, COC 97b, ROL 98a]. Desta forma,
possvel que pessoas de outras disciplinas entendam mais claramente os requisitos do
sistema.
Os casos de uso essenciais foram estruturados em seis sees: informao
descritiva, contexto, narrativa, relao temporal, anexos e histrico, sendo as duas
ltimas opcionais. A figura 4.2 ilustra a estrutura do caso de uso essencial.
Informao Descritiva
ID:
Contexto
Escopo:
Ator Iniciador:
Atores Participantes:
Prioridade:
Freqncia:
Recursos:
Pr-condies:
Ps-condies:
Narrativa
Intenes do usurio

Nome:

Responsabilidades do sistema

(eventos)
Relao Temporal
(expresso)
Anexos
ncoras:
Histrico
Autor:

(eventos)

Data:

Verso:

FIGURA 4.2 Caso de uso essencial estruturado

A primeira seo, informao descritiva, contm dados que identificam e

explicam o propsito do caso de uso; ou seja, relaciona o caso de uso com o objetivo.
composta pelos elementos:
ID: meramente um identificador nico do caso de uso; til no processo de
desenvolvimento para rastreamento (tracking) e para uso em ferramentas;
Nome: declarao de seu objetivo. O nome do caso de uso uma frase que
expressa o propsito do caso de uso. A primeira palavra deve ser um verbo no
tempo presente na voz ativa, como sugerido em [COC 2000, ROL 98b];

44
A seguir, representado na figura 4.3, tem-se um exemplo de um caso de uso
essencial, para o objetivo Consultar extrato, descrito de acordo com esta estrutura que
foi definida.
Informao Descritiva
ID: UC3
Nome: Consultar extrato
Contexto
Escopo: caixa eletrnico
Ator Iniciador: cliente
Atores Participantes: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: identificao, conta, extrato, recibo
Pr-condies: caixa eletrnico pronto para ser usado
Ps-condies: caixa eletrnico pronto para ser usado; cliente com o recibo do extrato
Narrativa
Intenes do usurio
Responsabilidades do sistema
1. Fornece identificao ao sistema
2. Aceita a identificao do cliente
3. Valida a identificao do cliente
4. Oferece transaes ao cliente
5. Pede a transao extrato
6. Aceita a transao extrato
7. Pede o perodo do extrato ao cliente
8. Escolhe o perodo do extrato
9. Aceita o perodo do extrato
10. Valida o perodo do extrato
11. Emite o recibo do extrato
12. Pega o extrato
13. Registra transao
14. Oferece transaes ao cliente
15. Escolhe Sair
Relao Temporal
1 ||| ( 5 8 ) 12 15

FIGURA 4.3 Exemplo de caso de uso essencial

A seo de contexto contm dados que contextualizam o caso de uso. Seus

elementos so melhores explicados a seguir:
Escopo: termo utilizado para delimitar qual o sistema em discusso.
Tipicamente, o escopo considerado to bvio pelos autores dos casos de uso
que eles sequer o mencionam. Todavia, em um grupo de vrios autores e
leitores o escopo do caso de uso pode no ser to bvio [COC 2000];
Ator Iniciador: nome do papel que tem o objetivo e inicia a interao;
Atores Participantes: demais atores que participam do caso de uso;
Prioridade: prioridade de desenvolvimento do caso de uso;
Freqncia: freqncia de utilizao do caso de uso por unidade de tempo;
Recursos: recursos necessrios ao caso de uso. Podem ser concretos, por
exemplo, o carto bancrio; ou abstratos, a conta corrente;
Pr-condies: predicados do estado do sistema e do ambiente que devem ser
considerados, antes das seqncias de interaes. No podem depender de
informaes obtidas, dentro do prprio caso de uso. So documentadas
separadamente, pois no precisam ser verificadas, novamente, ao longo do
caso de uso;

45

Ps-condies: predicados do estado do sistema e do ambiente que devem ser

encontrados aps a execuo do caso de uso.

A terceira seo, a narrativa, o corpo narrativo do caso de uso e descreve os

aspectos dinmicos, a interao. Esta seo estruturada atravs do estilo de narrao
numerada particionada; ou seja, a narrativa segmentada em etapas individuais
numeradas, dispostas em duas colunas: inteno do usurio e responsabilidade do
sistema. Esta notao torna explcito o limite das perspectivas internas e externas e tm
maior legibilidade e uma menor loquacidade do que outros estilos de narrao (maiores
detalhes em [CON 2000a]). ento, razoavelmente adequada para descrio dos
principais aspectos dos casos de uso, por permitir uma comunicao mais fcil entre os
envolvidos no desenvolvimento do software.
Surge aqui uma pergunta pertinente: Como representar as etapas dos demais
atores participantes? Haver colunas adicionais? Neste caso, onde outros atores, alm
do ator iniciador, participam da interao, sugere-se ser utilizado o estilo de seqncia
numerada na seo narrativa. Mas certifique-se que esteja explicitando o ator, em cada
etapa, e descrevendo intenes e responsabilidades.
Deve-se tambm, atentar para o fato de que, nem sempre, uma interao
estritamente seqencial. Cada inteno pode ter relaes temporais diferentes com as
outras intenes do mesmo caso de uso. Por exemplo, no caso de uso essencial
Consultar extrato, a inteno Fornece a identificao ao sistema pode ser executada de
maneira integrada com as intenes Pede a transao extrato e Escolhe o perodo do
extrato. Este aspecto de ordenao opcional ou flexvel uma situao muito comum
em modelagem de tarefas; mas, raramente, modelado explicitamente no corpo
narrativo de casos de uso [CON 2000a]. Em TAREFA [PIM 97], definido um
conjunto de sinais (figura 4.4) para tratar deste aspecto, inspirado na notao UAN
(User Action Notation). A maioria destas relaes adotada por modelos de tarefas e
modelos de dilogo.
Relaes temporais
1.Grupo
2.Opo (Alternativa)
3.Paralelo
4.Repetio
5.Interrupo
6.Entrelaamento
7.Simultaneidade
8 Ordem independente
9.Esperar por tempo n

Sinais da Notao
(A)
A|B
A||B
A+, A n, A*
BA
A ||| B
A, B
A&B
A (t > n seconds) B

FIGURA 4.4 Sinais de relaes temporais e de ordenao [PIM 97]

Deste modo, tem-se, aps a seo narrativa do caso de uso, a seo de relao
temporal, a qual contm uma expresso, que faz uso deste conjunto de sinais e dos
identificadores dos eventos, para lidar com as relaes temporais como partes
intrnsecas dos casos de uso.
A quinta seo, anexos, contm ncoras a quaisquer informaes que precisam ser
especificadas ao caso de uso, como, por exemplo, o identificador de um requisito
organizacional; e, finalmente, a sexta seo contm dados histricos e de autoria.

46
4.3.2

Casos de Uso Singulares

Casos de uso singulares so casos de uso expandidos que modelam, alm do curso
normal de um caso de uso essencial, os potenciais desvios que podem mudar a
interao do curso normal. Estes desvios - englobando as anormalidades, as excees,
os problemas, os enganos, as interrupes e os obstculos [POT 95] - so chamados de
singularidades, donde vem a expresso caso de uso singular. Por definio, uma
singularidade a causa de um problema [PIM 97]. Para o nvel dos requisitos, um
problema uma diferena semntica entre a situao atual e uma situao desejada
[PIM 97]. Ento, necessrio sempre ligar uma singularidade a um problema, e um
problema a um objetivo.
Os casos de uso essenciais so refinados atravs da determinao de potenciais
singularidades, a cada situao especfica e singular obtm-se um caso de uso singular.
Portanto, um caso de uso essencial pode dar origem a diversos casos de uso singulares.
Esta concentrao em pontos especficos ajuda a refinar a compreenso dos requisitos
de um sistema proposto.
A considerao de singularidades uma questo muito importante e pode ser
crucial para usabilidade de um sistema. Deve-se pensar em alternativas, para serem
alcanados os objetivos, quando ocorrer alguma singularidade. Todo objetivo pode ser
bloqueado de certa maneira por condies ou eventos, no sistema ou no ambiente. Levar
em conta as possveis singularidades fora o desenvolvedor e, tambm, o usurio, a
pensarem em solues flexveis e robustas para estas situaes reais, onde o uso
acontece em modos no antecipados pelo desenvolvedor, e no para situaes
idealizadas [POT 95]. Devem-se capturar as singularidades antes de se preocupar em
como lidar com elas. Um exemplo de singularidade para o caso de uso singular
(Consultar Extrato, ilustrado na figura 4.7) apresentado na figura a seguir.
ID da
ID do episdio
singula- onde a
laridade singularidade
acontece
S06
EP1

ID da ao do
episdio onde a
singularidade
acontece
7

Problema

Singularidade
(Causa do problema)

Aes (D)efensivas ou
(C)orretivas

Senha no aceita

Senha incorreta, provida

pelo cliente

(C) Permitir o cliente

fornecer a senha, at 4
vezes consecutivas
(D) Aps 4 tentativas, o
carto bloqueado

FIGURA 4.5 Exemplo de singularidade para o caso de uso singular Consultar extrato

Para cada singularidade identificada so propostas possveis aes defensivas e

corretivas que o sistema poderia realizar para, respectivamente, evitar ou corrigir seus
efeitos. Os casos de uso singulares permitem avaliar a conseqncia de singularidades e
possveis mecanismos defensivos e corretivos; e, tambm, possibilitam estabelecer
proposies de novas aes para alcanar um determinado objetivo e descobrir novos
objetivos para uma nova situao futura.
Naturalmente, um problema o potencial nmero ilimitado de casos de uso,
necessrios a representar todas as diferentes possibilidades de progresso de uma
interao. A soluo, como proposto em [POT 95], definir um subconjunto de casos
de uso em termos de singularidades e combinaes de singularidades consideradas,
relevantes, salientes [POT 95] por eles terem caractersticas que ajudam

47
exemplificar aspectos cruciais do comportamento do sistema proposto e no so
redundantes. Em TAREFA [PIM 97], as singularidades relevantes so divididas em
duas categorias no-ortogonais: singularidades crticas, obstrues ao curso normal do
caso de uso essencial; e singularidades representativas, obstrues que aparecem mais
freqentemente. Alm disso, uma combinao de singularidades tambm considerada
singularidade. A relevncia das singularidades individuais, por conseguinte,
determinada independente do domnio da aplicao, e a relevncia da combinao
dependente [POT 95].
Provavelmente, no sejam conhecidas todas as condies de um caso de uso,
desde o principio; a anlise de singularidades ajuda a identificar as pr e ps-condies,
que levaro o usurio a seguir um determinado curso de interao. Devemos distinguir
as condies que separam o curso normal dos outros possveis cursos.
Notao
Para serem representados, adequadamente, os casos de uso neste nvel de
abstrao, definiu-se como pr-requisito que a estrutura adotada permitisse a associao
de conceitos teleolgicos: atores, objetivos, singularidades etc.
Um conceito adicional fundamental descrio dos casos de uso essenciais, o
conceito de episdios (ver seo 3.2.1). Como toda narrativa, casos de uso podem ser
descritos de maneira episdica. Assim, a seo narrativa de um caso de uso singular
consiste em uma seqncia de episdios, cada um correspondente a alguma inteno ou
singularidade que bloqueia a realizao dessa inteno.
O conceito de episdio recursivo. Cada episdio pode ser considerado como um
pequeno caso de uso [LEI 97]; mas, no papel de caso de uso, informaes adicionais so
necessrias. Este conceito auxilia a lidar com grandes conjuntos de casos de uso, por
permitir o reuso de partes dos casos de uso. Um mesmo episdio pode aparecer em
vrios casos de uso, evitando assim a duplicao do trabalho de especificao de casos
de uso e oferecendo um modelo de casos de uso mais compacto. Diversos autores j
utilizam o conceito de episdios para estruturar casos de uso [REG 96, POT 95, LEI 97,
ROL 98a].
O elemento bsico do modelo de caso de uso a ao, podendo ser atmica ou
composta. As aes atmicas so divididas em duas categorias: aes de comunicao
(o cliente insere seu carto no caixa eletrnico); e aes internas (o caixa eletrnico
verifica que o carto valido) [ROL 98a]. Uma ao composta formada por uma
organizao, temporal ou de dependncia lgica, de aes atmicas. As aes so
descritas pelo par de termos o agente, seguido pela ao. O agente pode ser tanto o
sistema quanto um ator. Recomenda-se numerar as aes, do mesmo modo que se
numeram os eventos nos casos de uso essenciais.
Adota-se para a representao dos casos de uso singulares uma notao que segue
um esquema gramatical. Segundo Potts [POT 95], casos de uso so um tipo de
histria, ento possvel utilizar um esquema de caso de uso que semelhante a um
esquema de histria. Um esquema gramatical no uma gramtica geradora, no senso
conhecido da Teoria das Linguagens, porque permite deixar indeterminada a estrutura
de certos elementos - tipicamente por uma descrio informal [PIM 97]. Esta

48
representao perfeitamente adaptada para abordagens baseadas em objetivos, como
evidenciado pela explcita associao de uma inteno a cada episdio no caso de uso
[ANT 98a]. Representaes de casos de uso que permitem os analistas e stakeholders
considerarem singularidades so fontes especialmente ricas para identificarem novos
requisitos. Casos de uso esquemticos orientados a objetivos parecem apoiar a
identificao e refinamento de requisitos mais que outras representaes [ANT 98a].
O esquema gramatical, notao dos casos de uso singulares, apresentado na
figura 4.6. O modelo episdico de casos de uso prov uma estrutura para a especificao
dos casos de uso. A especificao em si escrita em linguagem natural estruturada.
<Caso de uso>:= <Informao Descritiva>
<Contexto>
<Narrativa>
<Anexos>
<Histrico>
<Informao Descritiva>:= <ID>
<Nome>
<Nome >:= <Objetivo> |
(<Objetivo> <Nome do episdio>)
<Contexto>:= <Escopo>
<Atores>
<Prioridade>
<Freqncia>
<Recursos>
<Predicados>
<Atores>:= <Ator Iniciador>
<Ator Participante>*
<Recursos>:= <Recurso>*
<Predicados>:= <Pr-condio>+
<Ps-condio>+
<Narrativa>:= <Episdio>+
<Episdio>:= <ID>
<Nome do episdio>
<Predicados>
<Plano>
<Nome do episdio>:= <Inteno> |
(<Inteno > <Singularidade>)
<Plano>:= <Ao>*
<Ao>:= <ID>
<Agente>
<Nome da ao>
<Agente>:= <Sistema> |
<Ator>
<Anexos>:= <Ancora>*
<Histrico>:= <Data>
<Autor>
<Verso>
Legenda: A* = A aparece 0 ou mais vezes; A+ = A aparece 1 ou mais vezes; A | B = A ou B
FIGURA 4.6 Esquema gramatical para casos de uso singulares

A figura 4.7 ilustra um exemplo de caso de uso singular descrito de acordo com o
esquema gramatical. Este caso de uso singular o refinamento do caso de uso essencial
Consultar Extrato representado na figura 4.3.

49
Informao Descritiva
ID: UC3
Nome: Consultar extrato
Contexto
Escopo: caixa eletrnico
Ator Iniciador: Cliente
Ator Participante: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: carto, senha, conta, extrato, perodo do extrato, recibo
Pr-condio: caixa eletrnico pronto para usar; cliente com carto;
Ps-condio: caixa eletrnico pronto para usar; cliente com o carto; cliente com o recibo do extrato
Narrativa
Episdio
ID: EP1
Nome: Fornece identificao ao sistema
Pr-condio: caixa eletrnico pronto para usar; cliente com o carto
Ps-condio: caixa eletrnico pronto para usar ou em uso; cliente com o carto; carto e senha do
cliente vlidos
Plano:
N
Agente
Ao
1
Cliente
Passa seu carto no leitor do caixa eletrnico
2
Sistema
Aceita o carto do cliente
3
Sistema
Valida o carto do cliente
4
Sistema
Pergunta a senha do cliente
5
Cliente
Fornece sua senha ao sistema
6
Sistema
Aceita a senha do cliente
7
Sistema
Valida a senha do cliente
Episdio
ID: EP2
Nome: Pede extrato
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar; pedido de transao extrato aceito
Plano:
N
Agente
Ao
1
Sistema
Oferece transaes ao cliente
2
Cliente
Pede a transao extrato
3
Sistema
Aceita a transao extrato
Episdio
ID: EP3
Nome: Escolhe o perodo do extrato
Pr-condio: caixa eletrnico pronto para usar; pedido de transao extrato aceito
Ps-condio: caixa eletrnico pronto para usar; pedido de transao extrato aceito; perodo do extrato
vlido
Plano:
N
Agente
Ao
1
Sistema
Pede o perodo do extrato ao cliente
2
Cliente
Escolhe o perodo do extrato
3
Sistema
Aceita perodo do extrato
4
Sistema
Valida o perodo do extrato
Episdio
ID: EP4
Nome: Pega o recibo
Pr-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; perodo do extrato
vlido
Ps-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; perodo do extrato
vlido; cliente com o recibo
Plano:
N
Agente
Ao
1
Sistema
Emite o recibo da transao extrato para o cliente
2
Cliente
Pega o recibo
3
Sistema
Registra a transao extrato
Episdio
ID: EP5
Nome: Sair
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar
Plano:
N
Agente
Ao
1
Sistema
Oferece transaes ao cliente
2
Cliente
Pede a transao sair
3
Sistema
Aceita a transao sair
4
Sistema
Registra a transao sair

FIGURA 4.7 Exemplo de caso de uso singular

50
4.3.3

Casos de Uso Operacionais

A um nvel de abstrao abaixo dos casos de uso singulares, os casos de uso

operacionais esto descritos ao nvel mais tcnico e so voltados, especificamente, para
a gerao preliminar de Arquiteturas de sistemas OO. Logicamente, que outras classes
de objetos podem surgir durante o projeto e a implementao do software. Este nvel
baseia-se principalmente na distribuio dos comportamentos descritos nos casos de uso
singulares em objetos que participam dos casos de uso. O foco que, anteriormente, era
usurio e sistema alterado para objetos do sistema que realizam os objetivos. Os casos
de uso operacionais podem ser omitidos, quando no for desejada uma concepo OO.
Neste nvel, procura-se compreender como os componentes do software, em
especial os objetos, interagem uns com os outros e com o ambiente externo. O sistema
considerado como um conjunto de objetos que participam dos casos de uso. Deseja-se
identificar objetos e suas responsabilidades para cobrir o comportamento do sistema a
um nvel particular de abstrao.
A identificao de classes e objetos um ponto de muita importncia em
abordagens OO. reconhecido o fato de que a modelagem conceitual, que identifica
conceitos do domnio do problema, pertinente tanto para abordagens de
desenvolvimento OO quanto para o desenvolvimento de interfaces. Porm modelos
conceituais s modelam componentes estticos, representam conceitos do mundo real
no componentes de software. A identificao dos objetos no deve se limitar a objetos
tangveis do mundo real; precisa-se identificar um conjunto preliminar de objetos que
permitam a realizao do comportamento dos casos de uso. Autores j enfatizam que se
devem modelar os aspectos comportamentais [RUB 92, WIR 2001]. A vantagem da
equivalncia com o mundo real continua sendo aplicada; mas no se limita aos objetos
tangveis.
No o mrito deste trabalho discutir qual a melhor prtica de determinao de
objetos e de atribuio de responsabilidades. Pode-se, por exemplo, construir um
modelo conceitual, usando estratgias de encontrar conceitos baseando-se em listas de
categorias de conceitos e estratgias de encontrar conceitos com a identificao de
substantivos; e, posteriormente, aplicar os padres GRASP (General Responsibility
Assignment Software Patterns) para a atribuio de responsabilidades [LAR 2000]. O
que de fato se destaca que os aspectos comportamentais tm uma grande importncia.
Alguns autores alegam que casos de uso tm uma abordagem de decomposio
funcional e que, por isto, no so uma boa fonte para serem identificados objetos e
classes. Discorda-se desta viso. De fato, casos de uso no so realmente orientados a
objetos; todavia j se encontra destacado em [JAC 94c] que a semntica do modelo de
caso de uso (viso externa) interfere fortemente na semntica do modelo de objetos
(viso interna) e que estes modelos esto intimamente ligados: H um claro
mapeamento de um modelo de casos de uso em um modelo de objetos. Neste
mapeamento, cada caso de uso executado por um nmero de objetos participantes
onde cada objeto tem um papel especfico no caso de uso. Isto significa que todo o
comportamento definido para um caso de uso distribudo para estes diferentes
objetos, os quais cooperam para fazer o caso de uso acontecer. [JAC 94c]. Atravs de
casos de uso pode-se obter uma perspectiva mais dinmica dos objetos, identificam-se
os objetos no contexto de uso.

51
Porm, para ser modelada esta colaborao entre os objetos, precisa-se saber que
objetos esto envolvidos; que operaes esto envolvidas e em quais objetos; e qual a
seqncia de operaes. Na prtica, existe uma lacuna entre as descries narrativas dos
casos de uso e os modelos de objetos.
Focando responsabilidades, tanto nos modelos de casos de uso quanto nos
modelos de objetos, pode-se estabelecer um elo de ligao entre ambos. Em pontos
significantes do processo de desenvolvimento, a habilidade de verificar as
responsabilidades dos objetos com as expressas nos casos de uso representa uma forma
valiosa de verificar se o projeto continua correspondendo aos requisitos [BID 2001]. O
uso do conceito de responsabilidade na ER e no projeto representa um importante fator
na possibilidade de rastreamento (traceability).
A noo de responsabilidades, nos casos de uso, compatvel com a noo de
responsabilidade de objetos; ambos descrevem comportamento, sem descrever
implementao [BID 2001]. Ao atribuir responsabilidades iniciais aos objetos, devemse considerar as responsabilidades requeridas, nos casos de uso. Estas responsabilidades
so atribudas baseadas no conhecimento do domnio e em heursticas.
Para a identificao de objetos e atribuio de responsabilidades, segue-se a
abordagem OOSE [JAC 92], onde uma das fases da anlise construir o modelo de
anlise, onde a arquitetura baseada em trs tipos de objetos: objetos entidade, objetos
de interface e objetos de controle. Esse modelo especifica a composio de objetos e a
associao entre eles. Objetos entidade representam a informao persistente, mantida
pelo sistema; objetos de interface representam as interaes entre atores e o sistema;
objetos de controle representam as tarefas executas pelos usurios e suportadas pelo
sistema.
Modelar um sistema com estes trs tipos de objetos tem vrias vantagens.
Primeiro, proporciona ao desenvolvedor heursticas simples para distinguir conceitos
semelhantes; mas diferentes. Segundo, a abordagem dos trs tipos de objeto resulta em
objetos menores e mais especializados. Terceiro, a abordagem dos trs tipos de objeto
conduz a modelos mais aptos a mudanas [BRU 2000]. A diferenciao dos objetos de
interface permite isolar funcionalidade, representada por objetos entidade e de controle,
da interao humano-computador, representada pelos objetos de interface, garantindo a
possibilidade de serem realizadas modificaes mais facilmente, sem efeitos em cascata.
Para distinguir entre diferentes tipos de objetos, a UML prov o mecanismo de
esteretipos.
Notao
Uma vez definida a arquitetura, devem ser modeladas as interaes entre os
objetos. Para representar os casos uso, neste nvel de abstrao, adotam-se os diagramas
de seqncia, propostos na UML [BOO 99].
Um importante papel, que casos de uso executam em desenvolvimentos
orientados a objeto, a elucidao das responsabilidades de interao. Para este
propsito, os diagramas de seqncia so uma clara representao. Um diagrama de
seqncia um modo formal de assegurar que so identificados todos objetos e
operaes, inseridos num determinado caso de uso e mostra como objetos participantes

52
interagem para cumprir o caso de uso [JAC 94c]. Na anlise de requisitos, os diagramas
de seqncia so usados para ajudarem identificar novos objetos participantes e
comportamento ausente.
Construindo diagramas de seqncia, no s se modela a ordem da interao entre
os objetos; mas, tambm, distribui-se o comportamento do caso de uso. Em outras
palavras, designa-se a cada objeto responsabilidades na forma de um conjunto de
operaes. Estas podem ser compartilhadas por qualquer caso de uso no qual um
determinado objeto participa. Se um objeto participar em mais de um caso de uso sua
definio dever ser idntica; ou seja, o comportamento de uma operao dever ser o
mesmo nos diferentes diagramas de seqncia em que ela aparecer [BRU 2000].
O diagrama de seqncia de fato um elemento piv transio de anlise em
projeto OO. Ele foca comportamento de alto-nvel; assim, aspectos de implementao
no devero ser tratados neste momento.
Nos diagramas de seqncia, cada coluna representa um objeto que participa da
interao. A ordem das colunas no significante; entretanto devem ser posicionadas de
modo a oferecer maior clareza. Pode-se, tambm, ter colunas que representam os atores.
O eixo vertical representa o tempo, de cima para baixo. Objetos interagem entre si,
enviando mensagens, representadas por setas. A recepo de uma mensagem por um
objeto aciona a execuo de uma operao que pode enviar mensagens a outros objetos.
As mensagens podem ter argumentos (parmetros). Rtulos nas setas representam
nomes e argumentos das mensagens. A figura 4.8 ilustra um exemplo de um diagrama
de seqncia.

: Cliente

: Painel do
Cliente

: Extrato

oferecetransaes( )

pedetransao(transao)
cria( )
aceitatransao( )

FIGURA 4.8 Exemplo de diagrama de seqncia

53
4.3.4

Casos de Uso Concretos (Cenrios)

Casos de uso concretos so casos de uso ao menor nvel de abstrao. Um caso de

uso concreto uma instncia especfica e representativa de um caso de uso singular,
tendo um resultado particular com respeito ao objetivo do ator iniciador. Ele descreve
um comportamento do ambiente e do sistema que aparece em uma situao concreta e
restrita de uso, presente ou futura, sob o ponto de vista de um usurio. Por definio,
corresponde ao conceito de cenrio utilizado em IHC (ver seo 2.1).
Os cenrios no expem somente a funcionalidade do sistema; mas declaraes
especficas sobre como o usurio ir acessar a funcionalidade e o que ele experimentar,
fazendo isto [CAR 2000]. Eles expressam uma viso parcial do desenvolvimento e,
dessa forma, expe o desenvolvimento crtica.
Durante estgios de pr-implementao, analistas e stakeholders podem no
compreender muitas de suas decises propostas; as decises e comportamentos podem
ser clarificados atravs de exemplos concretos. Atravs de cenrios, cada deciso pode
ser avaliada e documentada em termos de suas conseqncias especficas.
Cenrios facilitam o melhor entendimento do futuro sistema, forando os
envolvidos no desenvolvimento a prestarem ateno em particularidades do uso real
[ANT 98a]. Podem elucidar como o sistema proposto ir suportar prticas concretas de
trabalho. Ajudando assim a decidir se as atuais solues operacionais dos objetivos
satisfazem as reais necessidades dos usurios.
Sendo concretos, tambm foram que os princpios mais abstratos, suposies,
teorias e mtodos de cada disciplina ou abordagem sejam concretizados [ABO 94].
Funcionam como uma base comum para comunicao entre grupos multidisciplinares.
Cenrios podem enderear conflitos entre reflexo e ao, entre situaes tpicas e
crticas e entre situaes desejveis e indesejveis [BD 2000], e relacionam a maneira
prtica e terica de pensar [ABO 94]. um meio de incorporar o conhecimento e a
experincia dos usurios no processo de desenvolvimento.
Notao
Cenrios ajudam desenvolvedores e usurios a administrarem a complexidade
conceitual de desenvolvimento de software, clarificando as conseqncias
comportamentais concretas dos requisitos ou propostas de desenvolvimento. Outra
estratgia de desenvolvimento relacionada, que faz isto, a prototipagem. Porm
prototipagem usualmente direcionada a testar sistemas resultantes do desenvolvimento
e no a pensar no desenvolvimento, conforme conduzido [CAR 2000]. Cenrios
podem ser usados independentemente da prototipagem, e prottipos podem ser usados
na ausncia de cenrios, contudo o uso conjunto tem se mostrado benfico [ANT 98a,
CAR 2000].
Ento, para o nvel concreto adotada a combinao de uma descrio textual em
linguagem natural e um prottipo de baixo nvel, adequado para exemplificar os
aspectos concretos dos casos de uso para o usurio. Este nvel no se preocupa com
detalhes de plataforma tecnolgica, nem com detalhes de interface; mas, unicamente,

54
com que ela faz. A forma de narrativa textual, contendo informao sobre situaes e
usurios ilustrativos, parece ser mais memorvel e inteligvel maioria dos leitores que
a forma estruturada [POT 95]. A seguir, a figura 4.9 ilustra um exemplo de um caso de
uso concreto.
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 de seu carto magntico; e, por fim, mostra
novamente o menu de opes de transaes.

Caixa Automtico

BANCO X
Escolha a transao desejada

Consultar Saldo

Depositar Valores

Consultar Extrato

Transferir Valores

Sacar Dinheiro

Sair

FIGURA 4.9 Exemplo de caso de uso concreto

4.4 Construo de Casos de Uso

Acredita-se que as abordagens top-down e bottom-up de criao de casos de uso e
cenrios devam ser complementares e que possam ser incorporadas como atividades
iterativas, num mesmo mtodo. Nesta abordagem, o processo de construo de casos de
uso interativo e iterativo; entretanto, a princpio, segue a abordagem top-down, onde
casos de uso so construdos e refinados, sucessivamente, pelo analista, respeitando suas
propriedades estruturais. O uso de notaes definidas para cada um dos nveis de
abstrao, juntamente com a utilizao de heursticas e diretrizes, conduz a construo
dos casos de uso. Este processo incremental resume-se em
construir os casos de usos essenciais, a partir da hierarquia de objetivos
representada pelos modelos de tarefas minimais e da definio das
responsabilidades essenciais do sistema. Cada caso de uso construdo,
associando atores, objetivos, intenes e responsabilidades;
construir os casos de uso singulares, refinando os casos de uso essenciais e
definindo as singularidades, associadas s intenes e responsabilidades;
construir os casos de uso operacionais definindo os objetos e as operaes,
descritos nos casos de uso singulares, caso a concepo seja orientada a
objeto;
construir (instanciar), a partir dos casos de uso singulares, os casos de uso
concretos que sero experimentados, recursivamente, com os usurios.
Deve-se estar atento ao fato de a construo de casos de uso implicar em escrever,
refinar, experimentar, modificar e integrar casos de uso.

55
A seguir, apresentam-se algumas guias para conduzirem o processo de construo
de casos de uso:
Procure definir os atores e seus objetivos, antes de escrever os casos de uso;
Explicite o contexto do caso de uso, especialmente as pr e ps-condies;
Descreva os casos de uso como planos de execuo de objetivos, no como
meras seqncias cronolgicas de eventos;
Descreva as intenes dos usurios e as responsabilidades do sistema, no os
detalhes de IU;
Para cada caso de uso, escreva e revise o curso normal onde o objetivo
alcanado, antes de escrever os cursos alternativos ou de exceo;
Liste as singularidades e avalie suas relevncias, antes de escrever os cursos de
como o sistema deve trat-las;
Utilize as questes por qu? para encontrar o nvel de abstrao acima e
como? para encontrar o nvel de abstrao abaixo;
Revise a ontologia, constantemente, ao gerar ou alterar os casos de uso.
Apoiado nas abordagens de [COC 2000, ROL 98, ACH 98] definem-se algumas
diretrizes que tm a funo de prover recomendaes sobre o estilo esperado das
narrativas dos casos de uso aos nveis essencial e singular. As diretrizes esto
representadas na figura a seguir.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

14.

Use o mesmo nvel de abstrao, ao longo do caso de uso;

A narrativa deve representar um nico curso de aes. Cursos alternativos, variaes e
excees devem ser descritos, separadamente;
Descreva o curso das aes esperadas, no as aes inesperadas, impossveis ou irrelevantes.
Evite o uso de negaes, advrbios, e verbos modais na descrio de uma ao;
Mantenha a IU fora do caso de uso; tenha certeza de estar descrevendo as motivaes
(intenes e responsabilidades) e no os movimentos de manipulao de interface;
Escreva o caso de uso como uma lista de aes discretas. Cada ao deve iniciar em uma
nova linha;
Escreva cada ao como uma frase onde um objetivo alcanado, usando a seguinte
estrutura: sujeito + verbo + objeto direto + frase preposicional. Exemplo: O sistema deduz a
quantia da conta corrente;
Use verbos na voz ativa e no tempo presente, ao descrever as aes, a fim de evitar a
omisso ou esquecimento de algum ator;
Tenha certeza de que o ator que executa a ao e o objeto da ao est visvel em cada
passo;
Caso utilize a notao de duas colunas ao nvel essencial, pode-se omitir o nome do ator
iniciador e sistema, uma vez que a prpria notao j os torna explcitos;
Caso participem dois atores do mesmo tipo, num caso de uso, discrimine-os. Por exemplo,
use os nomes cliente C1 e cliente C2;
Evite utilizar referncias anafricas: ele, ela, dele, sua. Use os nomes do modelo ontolgico;
Evite o uso de sinnimos e homnimos. Use termos consistentes com a terminologia
unificada;
No utilize verifica se substitua por valida ou verifica que. No utilize checagem de
uma condio, elas no do uma seqncia na narrativa, substitua por validao. Por
exemplo, O sistema verifica se a senha est correta, substitua por O sistema verifica que
a senha est correta;
No utilize se... condio... ento. Sempre que encontrar esta construo olhe para a
sentena anterior, provavelmente encontrar uma checagem. Corrija ambas as sentenas. Por
exemplo, O sistema verifica se a senha est correta, Se a senha est correta, o sistema
apresenta opes ao usurio, substitua por O sistema verifica que a senha est correta, O
sistema apresenta opes ao usurio.
FIGURA 4.10 Diretrizes para a descrio textual de casos de uso

56
Estas diretrizes devem estar disponveis ao autor do caso de uso (analista), no
momento da descrio. Acredita-se que a qualidade dos casos de uso, produzidos, possa
aumentar, quando as diretrizes so aplicadas corretamente.

4.5 Viso Macro do Processo de Construo de Casos de Uso

Uma representao tabular concisa das atividades e dos resultados esperados de
cada uma delas, no processo de construo de cenrios e casos de uso proposto,
apresentada na tabela 4.1.
TABELA 4.1 Viso macro do processo de construo de casos de uso
Atividades
1. Encontre todos os atores que interagem com o sistema.
2. Encontre e refine os objetivos dos atores para com o sistema (ver
anlise hierrquica de tarefas, seo 4.2).

Resultados
Lista de atores
Modelos de tarefas minimais
Modelo ontolgico

3. Encontre os requisitos iniciais do sistema:

3.1 Re-engenharia de tarefas;
3.2 Alocao de Funes.

Modelos de tarefas minimais

refinados
Lista de requisitos iniciais do
sistema
Lista ator-objetivo
Diagramas de casos de uso
(opcionalmente)
Casos de uso essenciais

4. Construa os casos de uso essenciais:

4.1 Selecione um objetivo de alto nvel;
4.2 Contextualize o caso de uso;
4.2 Utilize as intenes do modelo de tarefa minimal num caso de
uso;
4.3 Defina as responsabilidades iniciais do sistema;
4.4 Verifique e expresse as relaes temporais entre as intenes;
4.5 Associe os requisitos no funcionais que tem influncia sobre
este caso de uso.
5. Construa os casos de uso singulares:
5.1 Selecione um caso de uso essencial para refinar;
5.2 Capture as pr e ps-condies e escreva o caso de uso
singular para o curso normal;
5.3 Investigue e avalie as singularidades e as aes defensivas e
corretivas;
5.4 Construa os casos de uso singulares s singularidades
consideradas relevantes.
6. Construa os cenrios:
6.1 Selecione um caso de uso singular para instanciar;
6.2 Crie um prottipo de interface para apoiar o teste.
7. Teste os cenrios com os atores.
8. Modifique os casos de uso:
8.1 Propague a modificao at o menor nvel de abstrao;
8.2 Retorne ao passo 7, at que se chegue a um consenso.
9. Integre os casos de uso.
10. Construa os casos de uso operacionais:
10.1 Defina os objetos e atribua as responsabilidades.

Lista de singularidades / aes

defensivas e corretivas
Tabela de sucesso e falha de
episdios
Casos de uso singulares

Cenrios
Prottipos
Lista de modificaes
Casos de uso modificados
Casos de uso validados e
integrados
Casos de uso operacionais

Observa-se que essas atividades no so necessariamente seqenciais; na prtica,

algumas delas podem ser realizadas em paralelo ou entrelaadas. So apresentados de

57
modo linear, por questo de clareza. Alm disto, o processo de construo de casos de
uso no segue um modelo em cascata e, sim, um modelo iterativo.

58

5 Aplicao Passo a Passo ao Caixa Eletrnico

Para ilustrar a aplicao de nossa proposta, nas prximas sees, so utilizados
trechos de um exemplo: o caixa eletrnico, o qual o acrnimo, comumente utilizado,
ATM, do ingls Automatic Teller Machine.

5.1 Descrio do Exemplo

Atualmente, os caixas eletrnicos oferecem uma vasta gama de servios.
Entretanto, no exemplo apresentado no so tratados todos os possveis servios de um
caixa eletrnico. Salienta-se que o exemplo de um sistema hipottico, por o objetivo
aqui ser apresentar a proposta e no conceber completamente uma mquina de caixa
eletrnico. Portanto, selecionam-se algumas das funes mais comuns dos caixas
eletrnicos, considerando suficientes para ilustrarem a aplicao da abordagem.
Tem-se, assim, como definio do problema: Definir o software interativo de um
para permitir que o auto-atendimento nos servios bancrios mais freqentes como
saque, consulta de saldo, consulta de extrato, transferncia e depsito, seja realizado
pelos clientes do banco, em questo.
Tm-se vrias razes para a escolha do caixa eletrnico, como exemplo:
Este tipo de exemplo onipresente na literatura, adotado como benchmark de
vrios mtodos [KAI 95, JAC 94a, ROL 98a, COC 2000]. Assim, seu uso
facilita a comparao de nossa abordagem com outros trabalhos;
No requer um conhecimento especializado do domnio para compreend-lo.
De fato, assume-se que os leitores tenham alguma experincia no uso dirio
dos caixas eletrnicos. Infelizmente, por isto difcil imaginar que se esteja
trabalhando no domnio de caixas eletrnicos, como se tais mquinas no
existissem. Pela mesma razo, porm, este exemplo til para o propsito
deste trabalho, por esta familiaridade ajudar a explicar as noes e conceitos
discutidos;
A especificao dos requisitos do caixa eletrnico ilustra problemas tpicos de
requisitos de sistemas. Ele tem algumas caractersticas muito dependentes da
organizao, s vezes escondidas por suposies implcitas e consideradas
evidentes; h uma ampla oportunidade para diferentes interpretaes e
diferentes pontos de vista sobre os requisitos e vrios aspectos,
freqentemente, no considerados adequadamente pelos caixas eletrnicos
existentes;

5.2 Construo de Casos de Uso

Ser seguido para este exemplo o conjunto de passos descrito na tabela 4.1 (ver
viso macro do processo de construo de casos de uso, seo 4.5). As sees
subseqentes detalham a realizao das atividades presentes nesta tabela.

59
5.2.1

Atividades Preliminares

Sabe-se que, para levar a cabo a construo dos casos de uso e cenrios, algumas
atividades devem ser previamente realizadas. O passo inicial encontrar os atores que
interagem com o sistema. O levantamento dos atores iniciadores foca a ateno do
desenvolvedor nas pessoas que iro utilizar os sistema e auxilia na elicitao de um
maior nmero de objetivos no comeo do desenvolvimento.
Aps terem sido identificados os atores que interagem com o sistema de caixa
eletrnico; determinados seus objetivos; e coletadas as informaes contextuais, aplicase uma re-engenharia de tarefas para as tarefas que se deseja corrigir. s vezes, o
solucionar um problema resultado de uma modificao organizacional ou de atitude
frente a uma tarefa, ao invs de uma inovao tecnolgica. Por exemplo, nas
informaes contextuais coletadas no se tinha nenhuma restrio que impunha a
seqncia mostrada na figura 5.1, que provavelmente a conseqncia do uso freqente
desta seqncia.
Sacar Dinheiro
SEQ
Fornecer Identificao

Pedir Saque

Escolher Valor

Pegar Dinheiro

Sair

FIGURA 5.1 Modelo de tarefa minimal Sacar Dinheiro, antes da re-engenharia de tarefas

Sabe-se que o cliente deve Fornecer Identificao, antes de Pegar Dinheiro; mas
no, necessariamente, antes de realizar a seqncia que agrupa Pedir Saque e Escolher
Valor. Raciocnio similar aplicado aos modelos de tarefas minimais Consultar Saldo e
Consultar Extrato. Os modelos de tarefas minimais para os objetivos Sacar Dinheiro,
Consultar Saldo e Consultar Extrato, aps a re-engenharia de tarefas, esto ilustrados
respectivamente nas figuras 5.2, 5.3 e 5.4. PAR indica que as subtarefas podem ser
executadas em paralelo, e SEQ indica que o ordenamento deve ser seqencial. Utilize o
modelo de tarefas de sua preferncia, como por exemplo, ConcurTaskTree [PAT 2001],
contanto que a representao utilizada ilustre a decomposio de tarefas em subtarefas,
hierarquicamente, como estruturas de rvores e, tambm, represente o ordenamento
temporal da tarefa.
Sacar Dinheiro
SEQ
TPAR

Pegar Dinheiro

PAR
Fornecer Identificao

TSEQ
SEQ
Pedir Saque

Ecolher Valor

FIGURA 5.2 Modelo de tarefa minimal Sacar Dinheiro

Sair

60
Consultar Saldo
SEQ
TPAR

Pegar Saldo

Sair

PAR
Fornecer Identificao

Pedir Saldo

FIGURA 5.3 Modelo de tarefa minimal Consultar Saldo

Consultar Extrato
SEQ
TPAR

Pegar Extrato

Sair

PAR
Fornecer Identificao

TSEQ
SEQ

Pedir Extrato

Ecolher Perodo

FIGURA 5.4 Modelo de tarefa minimal Consultar Extrato

Aps a re-engenharia das tarefas, realiza-se a alocao de funes. Ela determina

quais atividades so afetadas pela introduo do sistema e qual ser o papel do sistema,
como suporte a cada atividade. Tambm importante para ajudar a avaliar custos e
benefcios das alternativas do sistema para os usurios e a organizao. Nela, o
desenvolvedor enumera as diferentes alternativas de apoio do computador para cada
atividade e os stakeholders podem avaliar qual a mais adequada para sua tarefa e a
mais praticvel com os recursos colocados disposio. Na tabela 5.1 pode-se observar
um exemplo de alocao de funo para a emisso de recibos das transaes com o
caixa eletrnico, de acordo com a perspectiva do banco.
TABELA 5.1 Exemplo de alocao de funo para emisso de recibos das transaes com o caixa
eletrnico
Alternativa
1. Emisso do
recibo para todas
transaes, sem
interferncia do
usurio
2. Emisso do
recibo de acordo
com escolha do
usurio

Funo de usurio Funo do

Custo
Sistema
Nenhuma
Imprimir os recibos Preo de papel
interveno do
para todas
usurio
transaes

Decidir se quer ou
no o recibo e
responder a
pergunta dada

Perguntar para o
usurio se quer ou
no o recibo de
suas transaes;
Imprimir os recibos
desejados, de
acordo com a
resposta

Benefcio

O tempo de uso
minimizado,
favorecendo o
nmero de
transaes na
mesma unidade de
tempo
O uso prolongado Uso reduzido de
por causa do
papel
dilogo mais
sofisticado

61
Tendo optado pela primeira alternativa, tem-se ento que, ao final de qualquer
transao bancria, no caixa eletrnico, o cliente dever receber automaticamente um
recibo com informaes sobre a transao e o saldo de sua conta.
Posteriormente, a estas duas atividades, definem-se os requisitos iniciais do
sistema; obtm-se uma lista informal de requisitos iniciais do sistema (tabela 5.2),
derivada diretamente dos requisitos dos usurios.
TABELA 5.2 Lista informal dos requisitos iniciais do sistema para o caixa eletrnico
Identificador
do Requisito
RS1
RS2
RS3
RS4
RS5
RS6
RS7
RS8
...

Requisitos Iniciais do Sistema

O sistema deve exigir o uso do carto bancrio, em todas transaes
Cada carto bancrio est vinculado a uma conta de um cliente
Todo carto bancrio tem uma senha
O nmero de toques e o caminho de interao devem ser minimizados
O sistema deve registrar as transaes realizadas
O sistema deve solicitar a confirmao das transaes
O sistema deve permitir a definio de perodo flexvel na consulta do extrato
O sistema deve emitir um recibo para cada transao
...

Em seguida, cria-se a lista ator-objetivo para o caixa eletrnico, para apoiar a

construo dos casos de uso essenciais, representada na tabela 5.3. estabelecida uma
escala de prioridade que varia de 1 a 5. Caso for conveniente, classifique-os como
primrios, secundrios ou opcionais [LAR 2000].
TABELA 5.3 Lista ator-objetivo para o caixa eletrnico
Ator
iniciador
Cliente
Cliente
Cliente
Operador
...

Objetivo
Sacar dinheiro
Consultar saldo
Consultar extrato
Reabastecer o dinheiro
...

Prioridade
organizacional
Alta
Alta
Alta
Mdia

Complexidade Prioridade
tcnica
Complexo
5
Simples
5
Mdio
4
Simples
5
...

ID do
caso de uso
UC1
UC2
UC3
UC4
...

Algumas pessoas podem preferir utilizar a lista de ator-objetivo para ter uma
viso global dos casos de uso que esto sendo desenvolvidos; enquanto outras podem
optar pelos diagramas de casos de uso. Um diagrama de casos de uso, representando os
atores iniciadores e os casos de uso, pode servir para o mesmo propsito; porm
necessita-se de notas adicionais para explicitar as prioridades.
Lembra-se tambm, que o modelo ontolgico inicialmente criado, conforme se
realiza a anlise de tarefas. Alguns exemplos na notao LEL so representados na
figura 5.5. A LEL baseada na simples idia: entender a linguagem do problema sem
se preocupar em entender o problema [LEI 97]. Nela, cada termo um smbolo, e
cada smbolo uma entrada expressa em termos de noo e resposta comportamental. A
noo deve tentar esclarecer o significado do smbolo e seus relacionamentos
fundamentais com os outros smbolos. A resposta comportamental deve especificar a
conotao do smbolo no macrosistema. Cada smbolo pertence a uma categoria e deve
ser representado por um ou mais sinnimos [CYS 2001].

62

Smbolo: Cliente/Correntista
Noo:
- Algum que possua uma conta em uma agncia do banco.
- Tem um carto e conhece sua senha.
Resposta Comportamental
- Cliente faz um saque.
- Cliente faz um depsito.
- Cliente faz uma transferncia.
- Cliente consulta o saldo.
- Cliente consulta o extrato.
Smbolo: Consulta o Saldo/ Consultar Saldo
Noo:
- Ao requisitada pelo cliente.
- Consiste em verificar a quantia disponvel na conta.
Resposta Comportamental
- O sistema imprime o recibo do saldo da conta.
FIGURA 5.5 Exemplos de entradas na notao LEL para o caixa eletrnico

Ento, chegado o momento de construir os casos de uso, iniciando pelo nvel

mais abstrato: os casos de uso essenciais.
5.2.2

Construo de Casos de Uso Essenciais

Um usurio tem o objetivo de causar um certo efeito (F) no ambiente, sob certas
condies, tem-se assim F como parte dos requisitos. Se um artefato ou dispositivo pode
criar o efeito desejado, ento possvel atribuir o efeito como uma funo
(responsabilidade) do artefato. Cabe ao desenvolvedor criar um sistema que possua esta
responsabilidade, a fim de auxiliar um usurio a alcanar seu objetivo [CHA 96]. Em
sistemas interativos, os objetivos so alcanados por certas interaes entre o usurio e
o sistema, isto , por relacionamentos entre intenes do usurio e responsabilidades do
sistema, modelados atravs de casos de uso.
Construir os casos de uso essenciais implica em definir os dois componentes da
interao usurio-sistema: as intenes do usurio, derivadas diretamente da estrutura
hierrquica de objetivos do modelo de tarefa minimal e as responsabilidades
correspondentes do sistema.
A determinao das responsabilidades do sistema uma atividade criativa de
domnio especfico. Podem ser concebidos vrios sistemas que cumprem os objetivos
dos usurios, eles diferiro no modo com que os objetivos so operacionalizados.
Devem ser realizadas propostas alternativas do sistema [POT 95]. Casos de uso
permitem definir com maior preciso como o usurio deseja usar as tarefas interativas
[PIM 97]; casos de uso ajudam a avaliar, refinar e escolher a proposta [POT 95]. Na
realidade, as responsabilidades do sistema devem ser refinadas, durante todo o processo
de desenvolvimento at a definio detalhada do comportamento do sistema [PIM 97].
A organizao dos eventos, no caso de uso essencial, segue a organizao lgica e
temporal do modelo de tarefa minimal. O uso de seqncia de eventos, como narrao,
encorajado baseado na abordagem de Pimenta [PIM 97]: Mesmo entrelaando
tarefas, para uma dada instncia, o usurio s manipula uma tarefa interativa por vez,
independente da possibilidade de paralelismo do computador. Um caso de uso

63
resultado da escolha de uma seqncia. Em [PIM 97], so propostas as heursticas para
escolha das seqncias: seqncia habitual do usurio; seqncia prvia (formal) da
organizao; e novas seqncias propostas para teste do usurio.
A figura 5.6 ilustra o caso de uso essencial que modela a seqncia habitual do
usurio para realizar o objetivo Sacar dinheiro. O nome do caso de uso objetivo
principal do modelo de tarefa minimal (Sacar dinheiro) que, junto com a identificao
(UC1) e nome o ator iniciador (Cliente), provem da explicita associao entre atores e
objetivos, representados aqui, atravs da lista ator-objetivo.
Informao Descritiva
ID: UC1
Nome: Sacar dinheiro
Contexto
Escopo: caixa eletrnico
Ator Iniciador: cliente
Atores Participantes: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: identificao, conta, valor do saque, dinheiro, recibo
Pr-condies: caixa eletrnico, pronto para ser usado
Ps-condies: caixa eletrnico pronto para ser usado; cliente com o valor do saque em dinheiro;
cliente com o recibo do saque
Narrativa
Intenes do usurio
Responsabilidades do sistema
1. Fornece a identificao ao sistema
2. Aceita a identificao do cliente
3. Valida a identificao do cliente
4. Oferece transaes ao cliente
5. Pede a transao saque
6. Aceita a transao saque
7. Pede o valor do saque ao cliente
8. Escolhe o valor do saque
9. Aceita o valor do saque
10. Valida o valor do saque
11. Altera o saldo da conta do cliente
12. Emite o recibo da transao saque para o cliente
13. Libera o valor do saque em dinheiro para o cliente
14. Pega o dinheiro e o recibo
15. Registra a transao
16. Oferece transaes ao cliente
17. Escolhe Sair
FIGURA 5.6 Caso de uso essencial Sacar dinheiro

Antes de escrever a narrativa do caso de uso, procura-se contextualiz-lo. Alm

do ator iniciador, deve-se definir os outros elementos contextuais que delimitam o caso
de uso, propostos na estrutura dos casos de uso essenciais (figura 4.2). O escopo deste
caso de uso o caixa eletrnico, uma vez que se est discutindo apenas o sistema caixa
eletrnico; a rede de computadores e os outros sistemas esto fora do escopo do
desenvolvimento. Explicitando o escopo, permite-se que os leitores dos casos de uso
vejam rapidamente o que est dentro dos limites do sistema, o que, muitas vezes, no
to claro apenas pelo nome do caso de uso ou do ator iniciador.
No caso de uso, em questo, no participam outros atores; desta forma, o
elemento atores participantes permanece vazio. A prioridade de desenvolvimento do

64
caso de uso oriunda de uma anterior discusso com os stakeholders ao criar-se a lista
ator-objetivo. O motivo pelo qual foi construdo primeiramente este caso de uso que
sua prioridade a mais alta, dentro da escala que se definiu, prioridade 5.
A freqncia de utilizao do caso de uso especialmente til para definir a IU do
sistema. Se um caso de uso possuir uma alta taxa de utilizao, dever-se- tornar o seu
acesso e sua interao a mais direta possvel.
Os recursos restringem o caso de uso e sinalizam importantes aspectos dos
requisitos no funcionais. No exemplo em questo, est-se definindo o caso de uso
Sacar dinheiro onde necessrio ter uma identificao, uma conta, um valor, um recibo
e dinheiro.
Atravs dos recursos, tambm se pode elicitar objetivos complementares,
necessrios para obter uma descrio da total funcionalidade do sistema, aplicando o
princpio consumo/produo [ROL 98b]. De acordo com este princpio, qualquer
recurso, produzido em um caso de uso deve ser consumido no mesmo ou em outro caso
de uso e vice-versa. Por exemplo, argumentando sobre a produo e o consumo do
recurso dinheiro, identifica-se um evento onde ele consumido: a inteno pegar
dinheiro. Mas onde ele produzido? Por quem? No se identifica no caso de uso um
evento responsvel pela produo deste recurso, isto indica que se deve ter outro caso
de uso que descreva o objetivo abastecer o caixa eletrnico com dinheiro.
Outra utilidade dos recursos auxiliar a identificao de objetos e atributos ao
nvel operacional.
Deve-se, tambm, especificar s pr e ps-condies dos casos de uso. Descrevese um caso de uso, de modo que ele transforme o estado atual no estado final desejado.
O caso de uso no pode iniciar se os estados das pr-condies no so verdadeiros. As
ps-condies descrevem os estados resultantes da execuo do caso de uso. Para o caso
de uso Sacar dinheiro, define-se a pr-condio caixa eletrnico pronto para ser usado,
o caso de uso s iniciar se esta condio vlida e, sendo uma pr-condio, ela no
averiguada ao longo do caso de uso. A ps-condio mais direta que se determina o
estado final que o ator iniciador deseja, ao executar o caso de uso e atingir seu objetivo;
ou seja, cliente com o valor do saque em dinheiro. Para serem determinadas as demais
ps-condies, tambm se baseia na propriedade de que as pr-condies devam estar
inclusas nas ps-condies para garantirem um funcionamento autocontido [ROL 98b].
Neste caso, a pr-condio caixa eletrnico pronto para ser usado deve fazer parte das
ps-condies. Quando no se consegue incluir uma pr-condio nas ps-condies de
um caso de uso, significa que devamos ter um caso de uso singular para tratar dessa
exceo.
O uso de pr e ps-condies apia significativamente um desenvolvimento
centrado no uso, e essa prtica expressa a ordem de determinadas tarefas relacionadas.
De fato, casos de uso com pr e ps-condies fornecem meios lgicos e diretos de
modelar o workflow, aspecto da estrutura da tarefa freqentemente negligenciado na
modelagem de casos do uso [CON 2000a].
Ao se escrever a seo narrativa do caso de uso, cada subobjetivo do modelo de
tarefas minimal considerado como uma inteno do usurio. A cada inteno, as

65
responsabilidades receptivas e expressivas so definidas. Por exemplo, para a inteno
Fornece identificao ao sistema (1) definimos a responsabilidade receptiva Aceita a
identificao do cliente (2) e a responsabilidade expressiva Valida a identificao do
cliente (3).
Deve-se lembrar que um dos requisitos iniciais do sistema a emisso de recibo
para cada transao do caixa eletrnico. Como o objetivo do usurio sacar dinheiro,
acredita-se que a emisso do recibo deva preceder a liberao do dinheiro, pois o ator,
atingindo seu objetivo final, tenderia a esquecer de pegar o recibo, com maior
freqncia. Casos de uso facilitam argumentaes desta natureza.
De forma anloga se obtm os outros casos de uso essenciais, como, por exemplo,
os casos de uso essenciais Consultar Saldo (figura 5.7) e Consultar Extrato
(apresentado na seo 4.3.1, figura 4.3).
Informao Descritiva
ID: UC2
Nome: Consultar saldo
Contexto
Escopo: caixa eletrnico
Ator Iniciador: cliente
Atores Participantes: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: identificao, conta, saldo, recibo
Pr-condies: caixa eletrnico pronto para ser usado
Ps-condies: caixa eletrnico pronto para ser usado; cliente com o recibo do saldo
Narrativa
Intenes do usurio
Responsabilidades do sistema
1. Fornece a identificao ao sistema
2. Aceita a identificao do cliente
3. Valida a identificao do cliente
4. Oferece transaes ao cliente
5. Pede a transao saldo
6. Aceita a transao saldo
7. Emite o recibo do saldo para o cliente
8. Pega o saldo
9. Registra a transao
9. Oferece transaes ao cliente
10. Escolhe Sair
FIGURA 5.7 Caso de uso essencial Consultar Saldo

Como se est especificando um novo caixa eletrnico, note que a inteno

Fornece a identificao ao sistema no est presa a nenhuma tecnologia especfica, no
se especifica que o cliente insere seu carto e fornece sua senha, embora um dos
requisitos organizacionais seja que o uso do carto do cliente indispensvel, para que
ele realize as transaes com o caixa eletrnico. Pode-se aqui discutir com os
stakeholders a possibilidade da adoo de novas tecnologias para a identificao dos
clientes, como, por exemplo, leitura de impresso digital. O caso de uso essencial
independente de tecnologia e permite um varivel nmero de implementaes.
Sabe-se que uma interao nem sempre estritamente seqencial. Ento, faz-se
uso dos identificadores dos eventos e do conjunto de sinais temporais definido no
captulo 4 (ver figura 4.4 na seo 4.3.1) para expressar as relaes temporais entre as

66
intenes nos prprios casos de uso. Por exemplo, no caso de uso essencial Sacar
dinheiro ter-se-ia a expresso 1 ||| ( 5 8 ) 14 17, isto , conforme a organizao lgica e
temporal do modelo de tarefa minimal Sacar Dinheiro (figura 5.2) sabe-se que a
inteno Fornece a identificao ao sistema (1) deve ser executada antes da inteno
Pega o dinheiro e o recibo (14); mas pode ser executada de maneira integrada com as
intenes Pede a transao saque (5) e Escolhe o valor do saque (8).
Esta prtica tem um efeito positivo sobre a usabilidade, por encorajar o desenhista
de IU a modelar, como seqncias completamente ordenadas, somente as interaes
onde a ordem realmente fixa ou determinada. Desta forma, o termo seqncia,
utilizado na definio do conceito de caso de uso, torna-se impreciso, pois no indica
uma sucesso estritamente ordenada. As expresses temporais tambm auxiliam na
identificao e avaliao de pr e ps-condies dos episdios ao nvel singular.
Existe ainda outro tipo de eventos no tratado aqui at este momento, os eventos
assncronos. Como eles no se aplicam a um nico ponto especfico da narrativa de um
caso de uso, so descritos, separadamente. Sugere-se utilizar um tipo de identificao
diferente da dos outros eventos para evitar confuses. Como, por exemplo, use letras, ao
invs de nmeros. Exemplificando, caso existisse o requisito de que o cliente pudesse
cancelar a realizao da tarefa Sacar dinheiro a qualquer momento que lhe fosse
requisitada alguma informao, ter-se-ia o caso de uso ilustrado na figura 5.8.
Informao Descritiva
ID: UC1
Nome: Sacar dinheiro
Contexto
Escopo: caixa eletrnico
Ator Iniciador: cliente
Atores Participantes: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: identificao, conta, valor do saque, dinheiro, recibo
Pr-condies: caixa eletrnico pronto para ser usado
Ps-condies: caixa eletrnico pronto para ser usado; cliente com o valor do saque em dinheiro; cliente com o
recibo do saque
Narrativa
Intenes do usurio
Responsabilidades do sistema
1. Fornece a identificao ao sistema
2. Aceita a identificao do cliente
3. Valida a identificao do cliente
4. Oferece transaes ao cliente
5. Pede a transao saque
6. Aceita a transao saque
7. Pede o valor do saque ao cliente
8. Escolhe o valor do saque
9. Aceita o valor do saque
10. Valida o valor do saque
11. Altera o saldo da conta do cliente
12. Emite o recibo da transao saque para o cliente
13. Libera o valor do saque em dinheiro para o cliente
14. Pega o dinheiro e o recibo
15. Registra a transao
16. Oferece transaes ao cliente
17. Escolhe Sair
a. Cancela a transao saque
b. Aceita o cancelamento da transao saque
c. Desfaz a transao saque
Relao temporal
a (1 ||| ( 5 8 )) 14 17

FIGURA 5.8 Caso de uso essencial Sacar Dinheiro, com relao temporal e eventos assncronos

67
A expresso de relao temporal tambm atualizada para considerar este evento.
Dessa forma, tem-se que, enquanto o cliente no Pega o dinheiro e o recibo (14), ele
pode Cancelar a transao saque (a).
5.2.3

Construo de Casos de Uso Singulares

A construo dos casos de uso singulares consiste em algumas atividades:
Refinamento dos casos de uso essenciais, em casos de uso singulares;
Identificao de singularidades;
Elaborao de subobjetivos ou aes para evitar a ocorrncia de
singularidades ou corrigir seus efeitos;
Finalmente, a construo de um caso de uso singular para cada singularidade
considerada relevante.

A atividade de refinamento do caso de uso essencial, em caso de uso singular,

alcanada por Decomposio das intenes dos atores presentes, nos casos de uso
essenciais, aqui consideradas como episdios, em aes mais elementares. O uso da
questo como? auxilia nesta decomposio; Decomposio da informao
manipulada nos passos dos casos de uso essenciais; e Refinamento de pr e pscondies para o caso de uso e seus episdios.
Selecionou-se o caso de uso essencial Sacar Dinheiro para refinar. A figura 5.9
ilustra o caso de uso singular Sacar Dinheiro escrito atravs do esquema gramatical. Os
elementos chave do esquema gramatical esto em negrito.
A inteno Fornece a identificao ao sistema deu origem ao episdio EP1 de
mesmo nome. Decomps-se o recurso identificao, manipulado nesta inteno, em
carto e senha, conforme os requisitos iniciais do sistema. Em seguida, refinaram-se
aes para lidar com esses novos recursos. Observa-se, tambm, que, aps a ultima
requisio de informao do cliente (episdio EP3; conjunto de aes 1,2,3,4 e 5),
adicionaram-se aes (aes 6,7 e 8) para solicitar a confirmao da transao,
conforme o requisito inicial do sistema RS6. Analogamente, escreveram-se os demais
episdios.
Baseados na expresso temporal do caso de uso ao nvel essencial, foram
refinadas as pr e ps-condies. Observa-se que a pr-condio do episdio Pede a
transao saque (EP2) est inserida no conjunto de pr-condies do episdio Fornece
a identificao ao sistema (EP1), isto implica que, sendo as pr-condies do episdio
EP1 verdadeiras, qualquer um dos dois episdios pode ser executado.
Uma vez refinado o caso de uso singular que modela o curso normal, iniciou-se
a investigao das singularidades para o caso de uso. Devem-se capturar as
singularidades, antes de se preocupar em como lidar com elas.
Em geral, um modo intuitivo de serem identificadas as singularidades analisar o
caso de uso normal e realizar um questionamento sistemtico [ANT 96]. Utilizaramse questes do tipo:
What if? [COC 2000];
What can go wrong with this action? [POT 94].

68
Informao Descritiva
ID: UC1
Nome: Sacar dinheiro
Contexto
Escopo: caixa eletrnico
Ator Iniciador: Cliente
Ator Participante: Prioridade: 5
Freqncia: diversas vezes ao dia
Recursos: carto, senha, conta, valor do saque, dinheiro, recibo
Pr-condio: caixa eletrnico pronto para usar; cliente com carto;
Ps-condio: caixa eletrnico pronto para usar; cliente com o carto; cliente com o dinheiro; cliente com o recibo; valor do saque debitado da
conta.
Narrativa
Episdio
ID: EP1
Nome: Fornece identificao ao sistema
Pr-condio: caixa eletrnico pronto para usar; cliente com o carto
Ps-condio: caixa eletrnico pronto para usar ou em uso; cliente com o carto; carto e senha do cliente vlidos
Plano:
N
Agente
Ao
1
Cliente
Passa seu carto no leitor do caixa eletrnico
2
Sistema
Aceita o carto do cliente
3
Sistema
Valida o carto do cliente
4
Sistema
Pergunta a senha do cliente
5
Cliente
Fornece sua senha ao sistema
6
Sistema
Aceita a senha do cliente
7
Sistema
Valida a senha do cliente
Episdio
ID: EP2
Nome: Pede Saque
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito
Plano:
N
Agente
Ao
1
Sistema
Oferece transaes ao cliente
2
Cliente
Pede a transao saque
3
Sistema
Aceita a transao saque
Episdio
ID: EP3
Nome: Escolhe o valor do saque
Pr-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito
Ps-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito; valor de saque vlido
Plano:
N
Agente
Ao
1
Sistema
Pede o valor do saque ao cliente
2
Cliente
Escolhe o valor do saque
3
Sistema
Aceita valor de saque
4
Sistema
Verifica que tem o valor do saque disponvel no caixa eletrnico
5
Sistema
Valida o valor do saque com o saldo da conta do cliente
6
Sistema
Pede a confirmao da transao saque para o cliente
7
Cliente
Entra com a confirmao da transao saque
8
Sistema
Aceita a confirmao da transao saque
Episdio
ID: EP4
Nome: Pega o dinheiro e o recibo
Pr-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido
Ps-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido; cliente com o dinheiro e o recibo
Plano:
N
Agente
Ao
1
Sistema
Emite o recibo da transao saque para o cliente
2
Sistema
Libera o valor do saque em dinheiro para o cliente
3
Cliente
Pega o recibo
4
Cliente
Pega o dinheiro
5
Sistema
Altera o saldo da conta do cliente
6
Sistema
Registra a transao saque
Episdio
ID: EP5
Nome: Sair
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar
Plano:
N
Agente
Ao
1
Sistema
Oferece transaes ao cliente
2
Cliente
Pede a transao sair
3
Sistema
Aceita a transao sair
4
Sistema
Registra a transao sair
Anexos
Ancora: RS1; RS2; RS3; RS5; RS6; RS8

FIGURA 5.9 Caso de uso singular Sacar Dinheiro

69
A inspeo das pr e ps-condies tambm auxilia na identificao de
singularidades, assim como o uso de algumas guias derivadas da abordagem [COC
2000]:
Considere cursos alternativos para cursos de sucesso;
Comportamentos incorretos do ator iniciador; por exemplo, senha invlida;
Inatividade do ator iniciador; por exemplo, tempo limite de entrada da senha
esgotado;
Resposta inadequada ou falta de resposta de um ator participante ou do
sistema; por exemplo, tempo limite de espera por resposta esgotado;
Cada ocorrncia de um evento do tipo o sistema valida implica que existe a
necessidade de tratar a falha da validao; por exemplo, valor de saque
incorreto.
Falha interna de componentes que fazem parte do sistema; por exemplo,
impressora sem papel;
Desta forma, para cada caso de uso singular normal, obtm-se uma lista de
singularidades e, posteriormente, prope-se aes defensivas e corretivas. Representa-se
os relacionamentos entre objetivos/episdios/problemas/singularidades/aes corretivas
e defensivas, atravs de tabelas. Como j mencionado anteriormente, cada singularidade
deve ser associada a um problema; e um problema deve ser associado a um objetivo.
A tabela 5.4 apresenta um resumo das singularidades encontradas para o caso de
uso singular Sacar Dinheiro (UC1), ilustrado na figura 5.9.
Capturadas as singularidades, inicia-se a delimitao das singularidades
relevantes. Prope-se o uso de algumas heursticas, adaptas de [POT 95], para guiar a
obteno do conjunto de casos de uso singulares relevantes:
Cada objetivo da hierarquia de objetivos deve ser realizado com sucesso por
um episdio em, pelo menos, um caso de uso. Esta heurstica garante que
todos objetivos da hierarquia sero considerados;
O conjunto total dos casos de usos tem de conter, pelo menos, uma instncia
de cada categoria de singularidade - crtica ou representativa -; mas cada
singularidade associada somente a um caso de uso, sem repeties;
Respeitar as dependncias lgicas e temporais da hierarquia dos objetivos.
No h necessidade de considerar os objetivos fora da hierarquia.
Sendo assim, atravs destas heursticas e baseados na tabela de singularidades e
no caso de uso singular que representa o curso normal, definem-se os demais casos de
uso singulares relevantes. Um caso de uso singular definido para cada singularidade, e
para cada combinao de singularidades, consideradas relevantes, descrevendo se o
episdio afetado ou no pela conseqncia da singularidade. H trs tipos de
conseqncias:
O episdio alcanado com sucesso (S - sucesso);
O episdio no realizado, porque a singularidade ocorreu no episdio
anterior (F falha);
O episdio alterado para considerar a singularidade (ID da singularidade).

70
TABELA 5.4 Tabela de singularidades para o caso de uso Sacar dinheiro
ID da
singulalaridade
S01

ID do
episdio
onde a singularidade
acontece
EP1

ID da ao
do episdio
onde a singularidade
acontece
2

Problema

Singularidade
(Causa do problema)

Aes (D)efensivas ou
(C)orretivas

Caixa eletrnico desligado

Caixa eletrnico no est

pronto para ser usado
Carto no aceito

S02

EP1

EP1

Carto invlido

S04
S05

EP1
EP1

3
6

Carto invlido
Senha no aceita

Leitor quebrado ou carto

inelegvel
Carto invlido, provido
pelo cliente
Carto bloqueado
Cliente no entra com a
senha a tempo (timeout)

S03

S06

EP1

Senha no valida

S07

EP2

Pedido de transao
incorreto

S08

EP2

Pedido de transao, no
realizado

S09

EP3

Valor de saque incorreto

S10

EP3

Valor de saque no
escolhido

S11

EP3

Dinheiro insuficiente

S12

EP3

Saldo Insuficiente

S13

EP3

Transao no confirmada

S14

EP4

Recibo no emitido

S15

EP4

Recibo no pegado

S16

EP4

Dispensador com defeito

S17

EP4

Dinheiro no pegado

(C) Notificar o cliente

(C) Notificar o cliente

(C) Notificar o cliente e
retornar ao estado inicial,
pr-condio do episdio
Senha provida pelo cliente,
(C) Permitir o cliente
incorreta
fornecer a senha, at 4
vezes, consecutivas
(D) Aps 4 tentativas, o
carto fica bloqueado
Pedir a transao
(D) Fazer o cliente
incorretamente ou transao escolher a transao de
invlida
uma lista de transaes
(C) Permitir escolher a
transao novamente
Cliente no pede a transao (C) Notificar o cliente e
a tempo (timeout)
retornar ao estado inicial,
pr-condio do episdio
Cliente entrou com valores
(C) Notificar o cliente e
incorretos
permitir escolher o valor,
novamente
Cliente no entra com o
(C) Notificar o cliente e
valor de saque a tempo
retornar ao estado inicial,
(timeout)
pr-condio do episdio
O valor do saque escolhido
(C) Informar o cliente da
excede a quantia disponvel quantia disponvel e
no caixa eletrnico
permitir que escolha esta
quantia
O valor do saque escolhido
(D) Exibir o saldo da
excede o saldo da conta do
conta do cliente
cliente
(C) Notificar o cliente e
permitir escolher o valor
,novamente
Cliente no confirma a
(C) Notificar o cliente e
transao a tempo (timeout) retornar ao estado inicial,
pr-condio do episdio
Papel de recibo esgotado ou (C) Apenas notificar o
atolado
cliente, pois o recibo no
indispensvel
Cliente no pega o recibo
(D) Emitir o recibo antes
de dispensar o dinheiro, a
fim de minimizar a
ocorrncia desta
singularidade
Dinheiro enrosca durante a
(C) Notificar o cliente,
liberao
quando isto ocorrer
(D) Tornar indisponvel a
transao de saque
Cliente no pega o dinheiro (C) Recolher o dinheiro e
do dispensador, a tempo
cancelar a transao
(Timeout)

Faz-se uso de uma tabela de sucesso e falha de episdios para a definio dos
casos de uso singulares. Esta tabela tem como cabealho o objetivo que aglutina os
possveis casos de uso singulares que tratam de sua realizao. A cada caso de uso
singular identificado, so atribudos um identificador e um nome. O nome deve ser
sugestivo do comportamento do caso de uso. Para os casos de uso singulares que
modelam casos diferentes do normal, adota-se o nome do caso de uso, como uma

71
combinao do objetivo do caso de uso, o nome do episdio onde a singularidade
aparece e nome da singularidade. Um exemplo de definio de casos de uso singulares,
para as singularidades, anteriormente encontradas, mostrado na tabela 5.5.
TABELA 5.5 Tabela de sucesso e falha de episdios para definio dos casos de uso singulares do
objetivo Sacar Dinheiro
Objetivo: Sacar dinheiro
Id do
Nome do caso de uso
caso de
uso
UC1
Sacar dinheiro
UC4
Sacar dinheiro; Fornece identificao ao sistema; Caixa
eletrnico desligado
UC5
Sacar dinheiro; Fornece identificao ao sistema; Leitor
quebrado ou carto inelegvel
UC6
Sacar dinheiro; Fornece identificao ao sistema; Carto
invlido
UC7
Sacar dinheiro; Fornece identificao ao sistema; Carto
bloqueado
UC8
Sacar dinheiro; Fornece identificao ao sistema;
Timeout da senha
UC9
Sacar dinheiro; Fornece identificao ao sistema; Senha
incorreta
UC10
Sacar dinheiro; Pede saque; Transao invlida
UC11
Sacar dinheiro; Pede saque; Timeout do pedido da
transao
UC12
Sacar dinheiro; Escolhe o valor do saque; Valor
incorreto do saque fornecido
UC13
Sacar dinheiro; Escolhe o valor do saque; Timeout da
escolha do valor do saque
UC14
Sacar dinheiro; Escolhe o valor do saque; Valor do
saque excede o disponvel, no caixa eletrnico
UC15
Sacar dinheiro; Escolhe o valor do saque; Valor do
saque excede o saldo da conta do cliente
UC16
Sacar dinheiro; Escolhe o valor do saque; Timeout da
confirmao da transao
UC17
Sacar dinheiro; Pega o dinheiro e o recibo; Erro na
emisso do recibo
UC18
Sacar dinheiro; Pega o dinheiro e o recibo; Timeout para
pegar o recibo
UC19
Sacar dinheiro; Pega o dinheiro e o recibo; Dinheiro
enrosca, durante a liberao
UC20
Sacar dinheiro; Pega o dinheiro e o recibo; Timeout para
pegar o dinheiro

EP1

EP2

EP3

EP4

EP5

S
S01

S
F

S
F

S
F

S
F

S02

S03

S04

S05

S06

S
S

S07
S08

F
F

F
F

F
F

S09

S10

S11

S12

S13

S14

S15

S16

S17

Para episdios com ordenamento seqencial, ao ocorrer uma falha num episdio,
pode-se, com pouco esforo, determinar que os episdios posteriores, necessariamente
tambm falharo. Isto se deve ao fato de que as ps-condies de um episdio
precedente fazem parte das pr-condies do episdio posterior.
Aps a definio dos casos de uso singulares, cada um deles descrito de acordo
com a notao gramatical. Um exemplo de caso de uso singular UC19 que trata da
singularidade Dinheiro enrosca durante a liberao (S16) apresentado na figura 5.10.
Por motivos de clareza, apresenta-se um extrato deste caso de uso, detalhando apenas o
episdio (Pega o dinheiro e o recibo), onde a singularidade ocorre, e as aes corretivas

72
e defensivas so propostas. Limita-se a citar os demais episdios, por eles serem
integralmente reaproveitados do caso de uso normal (UC1). Observa-se que o plano
(conjunto de aes) do episdio que trata desta singularidade no corresponde ao plano
do episdio onde no ocorre nenhuma singularidade. Sendo assim, para identificar as
variantes dos episdios normais, adota-se o padro de concatenar o identificador do
episdio normal com o da singularidade. No exemplo, em questo, obteve-se o
identificador EP4.S16.
Informao Descritiva
ID: UC19
Nome: Sacar dinheiro; Pega o dinheiro e o recibo; Dinheiro no liberado
Contexto
Ator Iniciador: Cliente
Ator Participante: Recursos: carto, senha, conta, valor do saque, dinheiro, recibo
Pr-condio: caixa eletrnico pronto para usar; cliente com carto;
Ps-condio: caixa eletrnico pronto para usar; cliente com o carto; cliente sem o dinheiro; cliente sem o
recibo; valor do saque no debitado na conta.
Narrativa
Episdio
ID: EP1
Nome: Fornece identificao ao sistema
Pr-condio: caixa eletrnico pronto para usar; cliente com o carto
Ps-condio: caixa eletrnico pronto para usar ou em uso; cliente com o carto; carto e senha do cliente
vlidos
Episdio
ID: EP2
Nome: Pede Saque
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito
Episdio
ID: EP3
Nome: Escolhe o valor do saque
Pr-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito
Ps-condio: caixa eletrnico pronto para usar; pedido de transao saque aceito; valor de saque vlido
Episdio
ID: EP4.S16
Nome: Pega o dinheiro e o recibo; dinheiro enrosca, durante a liberao
Pr-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido
Ps-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido;
cliente sem o dinheiro e sem o recibo
Plano:
N
Agente
Ao
1
Sistema
Libera o valor do saque em dinheiro para o cliente
2
Sistema
Detecta falha no dispensador de dinheiro
3
Sistema
Notifica o cliente de que a transao saque no pode ser efetuada
4
Sistema
Bloqueia a transao saque
Episdio
ID: EP5
Nome: Sair
Pr-condio: caixa eletrnico pronto para usar
Ps-condio: caixa eletrnico pronto para usar
Anexos
Ancora: RS1; RS2; RS3; RS5; RS6; RS8

FIGURA 5.10 Caso de uso singular Sacar dinheiro; Pega o dinheiro e o recibo; Dinheiro no liberado

Ao ser descrito este caso de uso singular, constatou-se que s se poder emitir o
recibo de realizao da transao saque, depois de ter certeza de que foi realizada, com
sucesso. Dessa forma, a alternativa de emitir o recibo, antes de liberar o dinheiro a fim
de se minimizar o esquecimento do recibo, por parte do cliente, mostrou-se ineficiente,
pois podem ocorrer problemas com o dispensador de dinheiro e a transao no se
efetivar. Deve-se, assim, pensar em outras alternativas para evitar o esquecimento do
recibo, como, por exemplo, a exibio de uma mensagem de realizao do saque com
sucesso e de solicitao, para o cliente pegar o recibo. Deste modo, o episdio Pega o
dinheiro e o recibo (EP4) tornar-se-ia o episdio ilustrado na figura 5.11.

73
Episdio
ID: EP4
Nome: Pega o dinheiro e o recibo
Pr-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido
Ps-condio: caixa eletrnico pronto para usar; carto e senha do cliente vlidos; valor de saque vlido; cliente
com o dinheiro e o recibo
Plano:
N
Agente
Ao
1
Sistema
Libera o valor do saque, em dinheiro, para o cliente
2
Cliente
Pega o dinheiro
3
Sistema
Altera o saldo da conta do cliente
4
Sistema
Informa o cliente do sucesso da transao saque e da emisso do recibo
5
Sistema
Emite o recibo da transao saque para o cliente
6
Cliente
Pega o recibo
7
Sistema
Registra a transao saque

FIGURA 5.11 Episdio Pega o dinheiro e o recibo

Este exemplo permite que se compreenda o valor de considerar as singularidades

e a iteratividade do processo de construo de casos de uso. Conforme se caminha aos
nveis de menor abstrao, podem-se avaliar com maior preciso as conseqncias de
opes de desenvolvimento. Neste exemplo, trata-se de uma suposta falha de um
componente interno do caixa eletrnico: o dispensador de dinheiro. As aes defensivas
e corretivas adotadas podem no ser a melhor soluo possvel, o que se gostaria de
destacar que a considerao de singularidades e a anlise dos casos de uso contribuem
para a flexibilidade e a usabilidade do sistema.
5.2.4

Construo de Casos de Uso Operacionais

A construo dos casos de uso operacionais apoiada em heursticas adaptadas

das abordagens de Jacobson [JAC 92] e Bruegge [BRU 2000], tanto para a
determinao dos tipos de objetos responsveis quanto para descrio dos diagramas de
seqncia.
Para identificarem-se objetos entidade, analisa-se os casos de uso singulares.
Anlise de linguagem natural um conjunto intuitivo de heursticas para identificar
objetos, atributos e associaes de uma especificao de sistema. As heursticas de
Abbott [ABB 83], apresentadas na tabela 5.6, mapeiam tipos de palavras em
componentes de modelo. Em geral, essas heursticas funcionam bem para gerarem uma
lista inicial de objetos candidatos, a partir de pequenas descries, como as narrativas
dos casos de uso [BRU 2000].
TABELA 5.6 Heursticas para mapear tipos de palavras em componentes de modelo [ABB 83]
Tipo de palavra
Substantivo prprio
Substantivo imprprio
Verbo de ao
Verbo de estado
Verbo de posse
Verbo modal
Adjetivo

Componente de modelo
Objeto
Classe
Operao
Herana
Agregao
Restries
Atributo

Exemplos
Joo
Cliente
Cria, submete, seleciona
um tipo de
Tem, consiste de, inclui, possui
Deve ser
Carto Ouro

Em conjunto com as heursticas de Abbott, podem-se usar as seguintes heursticas

para identificarem objetos entidade [BRU 2000]:

74

Termos que desenvolvedores ou usurios precisam clarificar para entenderem

o caso de uso;
Procurar substantivos, nos casos de uso;
Entidades do mundo real que o sistema precisa manter;
Processos e procedimentos do mundo real que o sistema precisa manter;
Fontes de dados.

Desenvolvedores nomeiam e descrevem brevemente os objetos, seus atributos e

suas responsabilidades, conforme so identificados. Descrever objetos, mesmo que
brevemente, permite aos desenvolvedores clarificarem os conceitos que esto usando e
evita enganos [BRU 2000].
Objetos de interface modelam a interface do sistema com os atores, atravs
destes que atores se comunicam com o sistema. Em cada caso de uso, cada ator interage
atravs de, pelo menos, um objeto de interface. O objeto de interface coleta a
informao do ator e a traduz em um evento que pode ser usado pelos objetos entidade
e, tambm, pelos objetos de controle, assim como traduz os eventos gerados pelo
sistema em informao apresentada aos atores. Para identificar objetos de interface so
utilizadas as heursticas:
Cada interao entre um ator e o sistema alcanada pelo intermdio de, pelo
menos, um objeto de interface;
Em geral, perifricos, como impressora, teclado, tela ou outro perifrico
especial, so ligados interao ator-sistema e cada um deles pode ser
manipulado por um objeto de interface particular;
Identificar notificaes e requisies de informao aos atores;
No modelar os aspectos visuais da interface com objetos de interface,
prottipos so mais adequados para tal.
Objetos de controle so responsveis por coordenarem os objetos de interface e os
objetos entidade. Objetos de controle, normalmente, no tm uma contraparte concreta
no mundo real. H freqentemente uma forte relao entre um caso de uso e um objeto
de controle. Um objeto de controle, normalmente, criado no comeo de um caso de
uso e deixa de existir a seu fim. responsvel por coletar informao dos objetos de
interface e despachar para objetos entidade. As heursticas para identificarem objetos de
controle so as seguintes:
Depois de atribuir o comportamento de um caso de uso aos objetos de
interface e objetos entidade, o comportamento restante atribudo a um objeto
de controle;
Identificar um objeto de controle, por um caso de uso ou mais, se o caso de
uso for complexo e puder ser dividido em fluxos mais curtos de eventos
(episdios).
Os atributos dos objetos tambm podem ser identificados, usando as heursticas de
Abbott, em particular, frases de substantivo, seguidas por frases possessivas; ou frases
adjetivas devem ser examinadas. No caso de objetos de entidade, qualquer propriedade
que necessite ser armazenada pelo sistema um atributo candidato.
Depois de identificados os objetos, modela-se as interaes entre eles. Os casos de
uso operacionais so representados por diagramas de seqncia, construdos com base
nas seguintes heursticas:

75

A primeira coluna, comumente, deve corresponder ao ator que iniciou o caso

de uso;
A segunda coluna, geralmente, deve ser um objeto de interface, que o ator usa
para iniciar o caso de uso;
A terceira coluna, comumente, deve ser o objeto de controle que administra o
resto do caso de uso;
Objetos de controle so criados por objetos de interface que iniciam o caso de
uso;
Objetos de interface so criados por objetos de controle;
Objetos entidade so acessados por objetos de controle e de interface;
Objetos entidade nunca acessam objetos de interface ou de controle; isto torna
mais fcil de compartilhar objetos entidade, entre casos de uso.

Um exemplo de objetos identificados e de diagrama de seqncia para o episdio

Fornece identificao ao sistema (EP4) do caso de uso singular Sacar dinheiro (UC1)
mostrado, respectivamente, nas figuras 5.12 e 5.13. De fato, como episdios so
utilizados como mecanismos de modularizao, constri-se um diagrama de seqncia
para cada episdio dos casos de uso singulares. Ressalta-se que os episdios, que tratam
de singularidades, tambm so representados em diagramas de seqncia distintos, para
aumentarem a clareza da especificao.
Tipo de objeto
Entidade
Entidade
Interface
Interface
Controle

Nome
Carto
Senha
Painel do Cliente
Leitor
Identificao

Definio
Objeto do domnio do problema
Objeto do domnio do problema
Objeto que realiza as interaes via tela e teclado.
Objeto que realiza as interaes com o leitor de carto
Objeto que controla a transao que corresponde ao episdio EP4

FIGURA 5.12 Objetos identificados no episdio Fornece identificao ao sistema

: Cliente

: Leitor

passacarto( )

: Identificao

: Painel do
Cliente

: Carto

: Senha

cria( )
aceitacarto( )
validacarto

pedesenha( )

fornecesenha( )
aceitasenha( )
validasenha( )

FIGURA 5.13 Diagrama de seqncia para o episdio Fornece identificao ao sistema

76
5.2.5

Construo de Casos de Uso Concretos (Cenrios)

A construo dos cenrios, casos de uso concretos, feita diretamente, a partir de

casos de uso singulares. Cada ao dos episdios de um caso de uso escolhido
instanciada pela determinao de suas caractersticas concretas que serviro para a
experimentao com um usurio especfico.
Para instanciar os atores, faz-se uso da lista ator-pseudnimos. Esta lista
inicialmente criada no comeo do desenvolvimento, tendo a funo de manter a
correspondncia entre os nomes genricos e especficos dos atores e, tambm, de manter
informao sobre os atores, para auxiliar na definio do tipo de interao e,
conseqentemente, da IU. O objetivo e a descrio dos campos da lista ator-pseudnimo
so apresentados a seguir:
Ator: Nome usado nos casos de uso para descrever o papel;
Definio: Definio informal do papel do ator no sistema;
Nomes especficos: Freqentemente, usados nas entrevistas e descries
textuais. Fazem referncia a indivduos ou elementos particulares;
Tipo de uso: Freqente, ocasional, especialista, genrico;
Volume de uso: Nmero de transaes / Unidade de tempo;
Iniciador dos casos de uso: ID dos casos de uso onde o ator o agente
iniciador;
Participante dos casos de uso: ID dos casos de uso onde o ator participa; mas
no o iniciador.
A tabela 5.7 representa um excerto da lista ator-pseudnimos para o caixa
eletrnico.
TABELA 5.7 Lista ator-pseudnimo para o caixa eletrnico
Ator

Definio

Nomes
especficos

Tipo de uso

Volume de
uso

Iniciador dos
casos de uso

Cliente

Pessoa que usa o

caixa eletrnico.
No esperado ser
experiente no uso de
computadores. Pode
ter dificuldade de
leitura, ser
daltnico, etc.

Proprietrio da
conta, Maria,
correntista

genrico

Diversas
vezes, ao dia

Operador

Pessoa que executa

as operaes de
mantena do caixa
eletrnico.
Experiente no uso
de computadores.
Pode ter uma IU
customizada.
...

Joo

especialista

Poucas vezes,
ao dia

UC1, UC2, UC3,

UC4, UC5, UC6,
UC7, UC8, UC9,
UC10, UC11,
UC12, UC13,
UC14, UC15,
UC16, UC17,
UC18, UC19,
UC20
UC30

...

...

...

...

...

Participante
dos casos de
uso
-

UC31

...

De posse dos casos de uso singulares, os projetistas de interface tambm possuem

os elementos suficientes para, atravs de modelos de interface, especificarem as IUs e,
assim, construrem os prottipos de baixo nvel, propriamente ditos. O ideal que
fossem desenvolvidos os prottipos, baseados em critrios de IHC, como os critrios
ergonmicos [CYB 2000]. Todavia, independente de detalhes da IU, o ponto de crucial

77
importncia que os prottipos so construdos para suportarem as tarefas dos usurios.
O quo difcil ou fcil for a interao com um artefato, estar altamente relacionada
com qual informao est representada e como ela est representada, na IU. Uma IU
deve ser projetada de maneira que as aes e operaes que devem ser realizadas
interagindo com o sistema, correspondam s maneiras naturais de pensar e agir do
usurio. Um exemplo de caso de uso concreto foi ilustrado na figura 4.9 da seo 4.3.4.
5.2.6

Experimentao de Cenrios

Erros de requisitos so freqentes, devido validao imprpria. Embora o uso de

templates, heursticas e diretrizes aumente a qualidade dos casos de uso produzidos, ele
no garante que os casos de uso estejam livres de erros. A coleo de casos de uso
abstratos tambm no suficiente para garantir a usabilidade do sistema proposto. So
necessrios testes com os usurios e anlise de interfaces.
Durante a experimentao de cenrios so feitas avaliaes para determinar como
o sistema proposto atende as reais necessidades dos stakeholders. Revises iterativas de
casos de uso com stakeholders ajudam desenvolvedores a assegurar que os requisitos
esto completos, consistentes e realsticos. So teis para assegurar que os
comportamentos dinmicos, descritos pelo modelo, correspondem ao comportamento
desejado.
A experimentao dos casos de uso concretos consiste em simular a interao,
seguindo a seqncia descrita pelo cenrio, usando conjuntamente os prottipos
desenvolvidos. Esta simulao permite o usurio avaliar a funcionalidade e a
usabilidade do sistema; isto pode implicar mudanas, em casos de uso, nos requisitos ou
em ambos. O uso destes cenrios no apenas possibilita verificar a atual soluo
proposta no real contexto de uso; mas, tambm, descobrir novos requisitos que
emergem somente na prtica. A rpida gerao de idias uma das vantagens do uso
conjunto de prottipos. Como resultado dessa avaliao, as conseqncias da introduo
da nova tecnologia podem ser analisadas e as prticas de trabalho podem ser repensadas
pelos usurios.
Freqentemente, existem condies de falha que fazem referncia a regras
organizacionais que o desenvolvedor desconhece [COC 2000]. Cenrios ajudam a
elicitar estas condies uma vez que so testados com os prprios usurios.
Em TAREFA [PIM 97] encontram-se valiosas recomendaes a serem utilizadas
durante as sesses de experimentao de cenrios com os usurios:
Usar, sempre que possvel, o cenrio no contexto concreto de utilizao;
Usar um cenrio, por vez;
Explicar somente as alternativas possveis;
Deixar o usurio expor suas idias, sem represses.
Idealmente, pelo menos uma experimentao de cada caso de uso singular
instanciado deve ser realizada com um usurio. Caso no seja possvel realizar a
experimentao com os reais usurios do futuro sistema, sugere-se realizar a
experimentao dos cenrios com membros da equipe de desenvolvimento, onde, ento,
dever ser efetuada uma avaliao heurstica; isto , os membros da equipe avaliaro os
cenrios, baseados em seus conhecimentos empricos e em heursticas.

78
O caso de uso que modela o curso normal deve ser experimentado, primeiramente,
por ilustrar como o sistema funcionar freqentemente. Inclusive este teste pode ser
realizado antes de se levantarem as singularidades e as aes defensivas e corretivas.
Pois, sendo cenrio um meio concreto, capaz de conduzir conjuntamente a ao e
reflexo, pode servir para o usurio participar mais ativamente do processo de
desenvolvimento, levantando possveis casos de falha ou exceo, alm de encontrar
possveis erros.
Mesmo alertando o usurio que a experimentao seria realizada com um
prottipo de baixo nvel e o objetivo no era avaliar detalhes de interface; porm a
semntica da interface, o primeiro questionamento do usurio foi Mas vai ser desse
jeito mesmo? Com essa aparncia? O que veio a confirmar uma constatao
encontrada em [COM 2000c] que, para o usurio, o sistema a interface. Neste sentido,
casos de uso essenciais mostram-se de grande valia, por permitirem que designers de
interface tenham elementos suficientes para projet-las: alm do corpo narrativo que
descreve a interao entre atores e sistema, o campo freqncia de uso e possveis
ncoras a RNFs so teis na definio das IUs; as expresses de relao temporal
auxiliam a definir o ordenamento dentro do caso de uso e os campos de pr e pscondies ajudam a estabelecer o ordenamento entre os casos de uso.
5.2.7

Modificao de Casos de Uso

As crticas dos usurios so as principais origens das modificaes dos casos de

uso. Estas podem ser pequenas e gerar apenas variantes dos casos de uso concretos,
mudando exclusivamente suas caractersticas concretas; ou grandes, provocando
algumas alteraes a nvel operacional, singular ou at mesmo essencial do caso de uso,
ou seja, propagando alteraes para os nveis mais abstratos. O analista deve revisar os
casos de uso, visando adequ-los s expectativas dos usurios. Os casos de uso
modificados devem ser novamente instanciados e experimentados, junto ao usurio, at
chegar-se, consensualmente, a um conjunto de requisitos considerado satisfatrio pelos
participantes do desenvolvimento.
Mudanas ao nvel essencial lidam com a escolha de alternativas de
desenvolvimento. Ao nvel singular, descrevem diferentes possveis realizaes de uma
tarefa. Mudanas ao nvel operacional referem-se a diferentes maneiras de distribuir
responsabilidades entre objetos.
Envolver mais efetivamente usurios no desenvolvimento de software, como coautores, muito importante. Porm devem-se balancear as sugestes dos usurios com a
anlise destas sugestes [MCD 94]. Deve-se lembrar que, enquanto um caso de uso
abstrato representa o ponto de vista de um grupo de usurios (ator), um cenrio
representa o ponto de vista de um usurio especfico. Usurios e desenvolvedores
sugerem novas funes e interfaces, todavia necessrio realizar uma anlise para
determinar como melhor adotar cada sugesto.
5.2.8

Integrao de Casos de Uso

At o presente momento, cada caso de uso foi utilizado como um apoio

determinao dos requisitos do sistema, na perspectiva de uma situao especfica de

79
uso, ento dissociada dos outros casos de uso. Deste modo, obtm-se uma coleo solta
de casos de uso separados, modelos parciais com aspectos restritos do sistema.
Necessita-se integrar os casos de uso para alcanar uma viso global de utilizao para
um ator do sistema.
O nmero de possveis relacionamentos entre os casos de uso cresce
exponencialmente com o de casos de uso. Se esses relacionamentos forem formalizados,
podero ser mais facilmente identificados e suportados [ALS 99]. Episdios
representam explicitamente o relacionamento entre casos de uso; os relacionamentos
entre os casos de uso aparecem de forma direta na narrativa, no sendo necessria uma
representao grfica, como os diagramas de casos de uso da UML, para represent-los.
Episdios comuns entre os casos de uso devem ser globalmente renumerados, visando
integrao dos casos de uso.
No exemplo do caixa eletrnico, o episdio Fornecer Identificao e o episdio
Sair so os mesmos para os casos de uso essenciais Sacar Dinheiro, Consultar Saldo e
Consultar Extrato. Sendo assim, atribu-se um identificador nico para cada episdio e
tem-se que o sistema do caixa eletrnico composto pelos episdios apresentados na
tabela 5.8.
TABELA 5.8 Episdios do caixa eletrnico

ID
EP1
EP2
EP3
EP4
EP5
EP6
EP7
EP8
EP9

Nome
Fornece identificao ao sistema
Pede saque
Escolhe valor do saque
Pega o dinheiro e o recibo
Sair
Pede extrato
Escolhe perodo do extrato
Pega o recibo
Pede saque

80

6 Concluso
Esta concluso est articulada em quatro partes: a primeira resume as principais
contribuies desta dissertao; a segunda compara a abordagem proposta com outras
abordagens baseadas em objetivos; a terceira discute as limitaes do trabalho e a quarta
investiga perspectivas futuras de continuidade do trabalho.

6.1 Contribuies
Esta dissertao um esforo para a integrao das reas de Engenharia de
Software (ES) e Interao Humano-Computador (IHC), particularmente com a proposta
de uma abordagem para construo sistemtica e integrada de casos de uso e cenrios.
As contribuies podem ser resumidas pelos seguintes aspectos:
6.1.1

Compatibilidade com a UML e Resoluo de Aspectos Problemticos

A abordagem baseada em objetivos para construo de cenrios e casos de uso

proposta totalmente compatvel com a UML. De fato, a UML apenas uma linguagem
de modelagem e no uma metodologia de desenvolvimento. Sendo assim, ela no
prescreve explicitamente nenhum processo de utilizao de seus modelos.
Prope-se uma definio do conceito de casos de uso diferente da UML; mas no
incompatvel. Da mesma forma que a definio de casos de uso da UML, na
abordagem, casos de uso tm igualmente o propsito de especificar requisitos, com o
contedo, na forma de uma narrativa textual consistente, contendo mltiplos cenrios e
possuindo uma estrutura semiformal. Porm, na abordagem, os objetivos dos usurios
esto vinculados prpria definio do conceito de caso de uso (ver seo 4.1), deste
modo, tem-se uma perspectiva centrada no uso e no no sistema como na UML (ver
seo 2.3).
Ressalta-se que o modelo de casos de uso, adotado na UML, ainda apresenta
problemas que a abordagem procurou resolver ou contornar. Com relao aos
problemas conceituais discutidos na seo 2.3, tem-se o seguinte:
Contedo: Casos de uso so planos de execuo de objetivos, ao invs de
meras seqncias cronolgicas de eventos;
Notao: Adoo de representaes adequadas a cada nvel de abstrao,
contendo elementos importantes para a usabilidade e funcionalidade;
Expresses idiomticas: Terminologia unificada com termos do domnio do
problema;
Granularidade: Flexvel, porm no escolhida, arbitrariamente. Definem-se
quatro nveis onde so considerados apenas os elementos relevantes a cada
nvel. Mas deve ser lembrado que o escopo de um caso de uso definido
como possibilitando no mnimo a cobertura (satisfao ou no) de um
objetivo;
Cobertura: A hierarquia de objetivos ajuda a delimitar a cobertura dos casos
de uso;
Contexto: O contexto onde o caso de uso ocorre explicitado, sobretudo,
atravs das pr e ps-condies;

81

Interseo: O conceito de episdio utilizado para se relacionarem casos de

uso na prpria descrio textual;
Concorrncia: O uso de expresses temporais para ordenamento interno e de
pr e ps-condies para o ordenamento externo.

A UML no define precisamente nenhum formato ou template especfico para

descrever o contedo dos casos de usos. Isto faz com que desenvolvedores,
freqentemente, no saibam como identificar casos de uso, o que incluir neles, qual o
nvel de detalhamento, como represent-los e como estrutur-los. Por outro lado, esta
negligncia com o formalizar a especificao permitiu que fosse tida maior liberdade
para adotar diferentes notaes, adequadas a cada nvel de abstrao, sem que fossem
incompatveis com alguma notao, previamente definida.
Prope-se a utilizao de modelos adicionais para representar os objetivos dos
usurios (modelo hierrquico de tarefas) e listas para auxiliar na construo dos casos
de uso nos diferentes nveis de abstrao (lista ator-objetivo, lista ator-pseudnimo, lista
de singularidades etc.).
Com relao aos diagramas de casos de uso, destaca-se que a informao
representada neles similar a da lista ator-objetivo; mas a apresentao diferente. Os
diagramas de casos de uso so dispositivos mnemnicos de duas dimenses que servem
para um propsito cognitivo: destacar relacionamentos. Deve-se us-los para este
propsito, no para substituir o texto. As elipses e as setas mostram apenas as ligaes e
decomposies e no ilustram o contedo dos casos de uso. Os diagramas, por si s, no
definem os requisitos de interao e os requisitos funcionais do sistema. No se deve
substituir a seo narrativa dos casos de uso por diagramas. Os aspectos dinmicos dos
requisitos so representados no corpo narrativo dos casos de uso, e os diagramas devem
servir como sumrios, auxiliando o leitor a localizar o texto que ele precisa ler.
Sobre os relacionamentos propostos na UML, o uso do conceito de objetivos,
aliado ao conceito de episdios e adoo de nveis de abstrao e de notaes
especficas, tornou claros os relacionamentos entre os casos de uso, na prpria narrativa
textual.
O relacionamento inclui (includes) da UML facilmente representado na
narrativa textual dos casos de uso. um relacionamento normal entre um objetivo de
mais alto nvel com um de mais baixo nvel. O caso de uso includo descreve um
objetivo de mais baixo nvel do que o caso de uso base. A estrutura episdica facilita
tratar este tipo de relacionamento. Cada passo em um caso de uso essencial
potencialmente um episdio (subcaso de uso). Se nunca refinar a inteno que o passo
representa, ento ela ser simplesmente um passo; caso for refinada, dir-se- que o caso
de uso inclui o comportamento do episdio.
O relacionamento estende (extends) da UML representado nesta abordagem,
atravs de casos de uso singulares. O comportamento flui normalmente como no caso de
uso base at o ponto onde a condio ocorre e, assim, a singularidade tratada de
maneira diferenciada. O conceito de episdios e singularidades auxilia tratar este tipo de
relacionamento.

82
Quanto ao uso de notao grfica, para expressar a narrativa dos casos de uso,
tambm h algumas consideraes. Embora os diagramas de seqncia possam
igualmente representar interaes entre atores, o uso desta notao grfica para a seo
narrativa dos casos de uso apresenta dois problemas de usabilidade. O primeiro que
usurios finais e outros stakeholders geralmente no tm familiaridade com a notao; o
segundo que diagramas no permitem demonstrar tudo o que se precisa escrever,
geralmente necessrio colocar notas adicionais, nos diagramas. Estes so alguns dos
motivos pelos quais no foi adotada a representao grfica para a narrativa dos casos
de uso (diagrama de seqncia) na fase de elicitao de requisitos; mas, apenas, ao nvel
operacional, restrito aos analistas e programadores.
6.1.2

Resumo de Resultados
1. Apresentou-se uma proposta onde se explorou o uso integrado de modelos de
tarefas, cenrios e casos de uso para o desenvolvimento de sistemas
interativos teis e usveis. Props-se que casos de uso podem ser
especialmente teis para combinar a perspectiva tcnica de ES com a
perspectiva humana de IHC. Tendo os objetivos das atividades humanas,
como ponto de partida, casos de uso apiam o pensamento sobre as tarefas
interativas; ou seja, sobre as interaes entre usurios e sistema, a fim
alcanarem objetivos, dentro de contextos de uso;
2. Promoveu-se uma construo sistemtica de casos de uso, centrada no uso de
um futuro sistema. Sistematizou-se a construo de cenrios e casos de uso,
atravs de guias, heursticas e notaes;
3. Encontrou-se uma base terica, tanto na perspectiva de IHC (relao tarefaobjetivo [STO 95]), quanto na perspectiva de ES (relao funo-objetivo
[CHA 96]) para a proposio da abordagem baseada em objetivos de
construo de casos de uso e cenrios;
4. Demonstrou-se que conceitos teleolgicos so importantes para organizar e
estruturar casos de uso e permitem solucionar grande parte dos problemas
conceituais de casos de uso;
5. Mostrou-se que o conceito de episdios tem um papel significante no
gerenciamento dos casos de uso. Episdios podem ser usados como
mecanismos de modularizao. A estrutura episdica possibilita representar
os relacionamentos entre os casos de uso, dentro da prpria descrio
narrativa;
6. A construo de casos de uso, delimitados pela estrutura hierrquica de
objetivos, evita que se desenvolvam solues tcnicas para problemas
irrelevantes;
7. O uso dos quatro nveis de abstrao ajudou a lidar com a complexidade da
construo e validao dos casos de uso e permitiu utilizar de maneira
integrada casos de uso e cenrios. medida que a modelagem realizada, o
desenvolvedor consegue perceber mais claramente os efeitos de suas decises
e, assim, obter solues mais adequadas;
8. Construram-se primeiramente os casos de uso essenciais que representam a
essncia das tarefas. Ao nvel singular, inspecionaram-se as singularidades, o
que contribuiu para a usabilidade; ao nvel concreto, cenrios permitiram uma
avaliao da usabilidade de um futuro sistema, antes da fase de projeto; j o
nvel operacional estabeleceu uma ligao com abordagens OO e permitiu a
continuidade do desenvolvimento de sistemas nestas abordagens;

83
9. Atravs da abordagem, a concepo do contedo e a organizao das IUs so
deduzidas, a partir da lgica de uso do sistema, como suporte realizao de
tarefas, e no, a partir da lgica de funcionamento das funes do sistema;
10. Casos de uso criados, a partir da abordagem, so gerados de maneira objetiva,
ao invs de intuitiva. Casos de uso gerados, sistematicamente, permitem
estudar os comportamentos no normativos dos usurios mais a fundo, o que
contribuiu para uma investigao mais dirigida usabilidade de sistemas.

6.2 Comparao com Outras Abordagens Baseadas em Objetivos

Tem-se aqui, representada na tabela 6.1, uma sucinta comparao da abordagem
proposta com algumas outras abordagens baseadas em objetivos que foram apresentadas
na seo 3.2 e comparadas na seo 3.2.4 (ver tabela 3.1).
TABELA 6.1 Comparao com outras abordagens baseadas em objetivos
Abordagem
Critrio
Investigao das
singularidades

Potts

Cockburn

Rolland

Abordagem Proposta

Um questionamento
sistemtico e a
criao de aes
defensivas e
corretivas
Algumas heursticas
para determinar a
salincia dos casos
de uso. Uso do
conceito de
episdios
Apenas sugerido,
sem especificar, que
cenrios podem ser
instanciados para
serem avaliados
pelos usurios

Um questionamento
sistemtico e algumas
guias.

Algumas guias

Uso de tcnicas de
subordinao,
extenso e variao

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

Um questionamento
sistemtico, inspeo de pr
e ps-condies, algumas
guias, e a criao de aes
defensivas e corretivas
Hierarquia de objetivos.
Heursticas para determinar
os casos de uso relevantes.
Uso do conceito de
episdios

Cenrios no so
usados para
experimentao com
usurios

No

No

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
usurios
No

Construo sistemtica e
integrada. Casos de uso e
cenrios so integrados em
estruturas com diferentes
nveis de abstrao.
Cenrio como uma
instncia especfica de um
caso de uso, usado para
experimentao com
usurios
Atravs de cenrios e
prottipos de baixo nvel

No
No

Sumrio, objetivos do
usurio e subfunes
No

Contextual, funcional
e fsico
No

Essencial, singular,
operacional e concreto
Nvel operacional

Sim
No

Sim
Sim

Sim
Sim

Sim
Sim

No

No

No

Seqencial

Seqencial

Seqencial

Considerao de
eventos assncronos

No

No

Representao de
Objetivos

Apenas sugerida
uma hierarquia de
objetivos similar a
modelos de tarefas
No

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

Atravs da expresso de
relao temporal
De acordo com a expresso
de relao temporal
(seqencial ou ordenao
flexvel)
Descritos separadamente e
tratados na expresso de
relao temporal

Delimitao do
conjunto de casos de
uso

Uso complementar
dos conceitos de
cenrios e casos de
uso

Avaliao da
usabilidade com os
usurios
Diferentes nveis de
abstrao
Nvel de abstrao
que estabelece ligao
com abordagens OO
Notaes definidas
Guias para a descrio
textual dos casos de
uso
Relaes temporais
nos casos de uso
Fluxo dos eventos

Representao da
ontologia

No

Requirements Chunks
organizados
hierarquicamente

Modelo de tarefa minimal

No

Sim

84

6.3 Limitaes
A falta de aplicao da abordagem em um estudo de caso real uma limitao
clara do trabalho. Exemplos mais claros da integrao da abordagem com uma
metodologia de desenvolvimento, orientado a objetos, poderiam auxiliar os interessados
em usar esta abordagem.

6.4 Perspectivas de Trabalhos Futuros

Perspectivas de continuidade do trabalho incluem:
Aplicao da abordagem em estudos de casos reais (ver Limitaes acima);
Embora a nfase seja no processo, acredita-se que o desenvolvimento uma
ferramenta com a capacidade de navegao por hyperlinks e, tambm,
capacidade de ordenamento, facilitaria a adoo da proposta, principalmente
devido iteratividade do processo. Uma possvel ferramenta poderia ter
esquemas, em XML (Extensible Markup Language), para a notao aos nveis
essencial e singular, onde se poderia ter proveito de hyperlinks para navegar
ao longo dos nveis de abstrao e do modelo ontolgico; gerao assistida de
cenrios e prottipos; e mecanismos de ordenao e filtro, como nas planilhas
eletrnicas, para trabalhar com as listas auxiliares. Em resumo, a ferramenta
permitiria apoiar a construo dos casos de uso, obter rastreabilidade
(traceability) e obter ainda, uma consistncia da terminologia, mais
facilmente;
Uma possvel extenso da abordagem seria avaliar os benefcios da
categorizao de objetivos sobre as duas dimenses ortogonais: tipo e assunto,
a fim de auxiliar na questo de mltiplos pontos de vista, conforme sugerido
em alguns trabalhos relacionados [ANT 98b, KAV 96].

85

Bibliografia
[ABB 83]

ABBOTT, R. Program Design by Informal English Descriptions.

Communications of the ACM, [S.l.], v. 26, n. 11, 1983.

[ABO 94]

ABOULAFIA, A.; KLAUSEN, T.; JORGENSEN, A. H. Towards a

Theoretical Underpinning fo Scenarios. In: INFORMATION SYSTEMS
RESEARCH SEMINAR, IRIS, 17., 1994, Finland. Proceedings...
[S.l.:s.n.], 1994. p.561-571.

[ACH 98]

ACHOUR, C. Ben. Guiding Scenario Authoring. In: EUROPEANJAPANESE CONFERENCE ON INFORMATION MODELLING AND
KNOWLEDGE BASES, 8., 1998, Finland. Proceedings... [S.l.]: H.
Jaakola, H. Kangassalo, 1998. p.181-200.

[ALS 99]

ALSPAUGH, T. A.; ANTN, A. I.; BARNES, T.; MOTT, B. An

Integrated Scenario Management Strategy. In: IEEE INTERNATIONAL
SYMPOSIUM ON REQUIREMENTS ENGINEERING, RE, 4., 1999,
Limerick, Ireland. Proceedings... [S.l]: IEEE Computer Society, 1999.
p.142-149.

[ANT 96]

ANTN,
A.
I.
Goal-Based
Requirements
Analysis.
In:
INTERNATIONAL
CONFERENCE
ON
REQUIREMENTS
ENGINEERING, ICRE, 1996, Colorado, USA. Proceedings... Colorado
Springs: ICRE, 1996. p.136-144.

[ANT 98a]

ANTN, A. I.; POTTS, C. A Representational Framework for Scenarios

of Systems Use. Requirements Engineering Journal, [S.l.], v.3, n.3-4,
p.219-241, 1998.

[ANT 98b]

ANTN, A. I.; POTTS, C. The Use of Goal to Surface Requirements for

Evolving Systems. In: INTERNATIONAL CONFERENCE ON
SOFTWARE ENGINEERING, ICSE, 20., 1998, Koyto, JP. Forging
New Links: proceedings. [Los Alamitos: IEEE Computer Society], 1998.
p.157-166.

[BEN 93]

BENNER, M. K. et al. Utilizing Scenarios in the Software Development

Process. In: INFORMATION SYSTEM DEVELOPMENT PROCESS,
IFIP, 1993, Como, Italy. IFIP WG8.1 Working Conference on
Information System Development Process: proceedings. [S.l.:s.n.],
1993

[BID 2001]

BIDDLE, R.; NOBEL, J.; TEMPERO, E. Essential Use Cases and

Responsibility in Object-Oriented Development. Australian Computer
Science Communications, [S.l.], v. 24 , n. 1, Jan.-Feb. 2002.

[BD 2000] BDKER, S. Scenarios in User-Centered Design Setting the Stage for
Reflection and Action. Interacting with Computers, [S.l.], v. 13, n. 1,
p.61-75, 2000.

86
[BOO 99]

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling

Language User Guide. Reading, MA: Addison-Wesley, 1999. 482 p.

[BRU 2000] BRUEGGE, Bernd; DUTOIT, Allen H. Object-Oriented Software

Engineering: Conquering Complex and Changing Systems. [S.l.]:
Prentice-Hall, 2000. 553p.
[CAM 92]

CAMPBELL, R. L. Will the real scenario please stand up? SIGCHI

Bulletin, [S.l.], v. 24, n. 2, p.6-8, 1992.

[CAR 95]

CARROLL, J. M. Artifacts and Scenarios: An Engineering Approach. In:

MONK, A.; GILBERT, N. (Ed.). Perspectives on HCI: Diverse
Approaches. London: Academic Press, 1995. chap.6, p.121-144.

[CAR 2000] CARROLL, J. M. Five Reasons for Scenario-Based Design. Interacting

with Computers, [S.l.], v. 13, n. 1, p.61-75, 2000.
[CHA 96]

CHANDRASEAKARAN, B.; KAINDL, H. Representing Functional

Requirements and User-System Interactions. In: NATIONAL
CONFERENCE ON ARTIFICIAL INTELLIGENCE, AAAI, 13., 1996,
Portland, USA. ProceedingsMenlo Park: AAAI, 1996.

[COC 97a]

COCKBURN, A. Structuring Use Cases with Goals (Part 1). Journal of

Object Oriented Programming, [S.l.], v. 9, n. 5, p.35-40, Sept./Oct.
1997.

[COC 97b]

COCKBURN, A. Structuring Use Cases with Goals (Part 2). Journal of

Object Oriented Programming, [S.l.], v. 9, n. 6, p.56-62, Nov./Dec.
1997.

[COC 98]

COCKBURN, A. Basic Use Case Template. Oct. 1998. Disponvel em:

<http://www.members.aol.com/acockburn/papers/uctempla.htm>. Acesso
em: 08 jan. 2002.

[COC 2000] COCKBURN, A. Writing Effective Use Cases. Boston: AddisonWesley, 2000.
[CON 99]

CONSTANTINE, L.; LOCKWOOD, L. Structured Use Case Form.

1999.
Disponvel
em:
<http://www.foruse.com/Files/Forms/
taskcases6.pdf>. Acesso em: 20 fev. 2002.

[CON 2000a] CONSTANTINE, L. et al. Structure and Style in Use Cases for User
Interface Design. 2000. Disponvel em: <http://www.foruse.com/
Presentations/ structurestyle2.pdf>. Acesso em: 20 fev. 2002.
[CON 2000b] CONSTANTINE, L.; LOCKWOOD, L. The Usability Challenge: Can
UML and the Unified Process Meet It? Australia, Nov. 2000. Disponvel
em: <http://www.foruse.com/Presentations/tools.pdf>. Acesso em: 03
mar. 2002.

87
[CON 2000c] CONSTANTINE, L.; LOCKWOOD, L. What Do Users Want?
Engineering Usability into Software. Australia, Nov. 2000. Disponvel
em: <http://www.foruse.com/Presentations/tools.pdf>. Acesso em: 15
jan. 2002.
[CYB 98]
CYBIS, W. A.; PIMENTA, M. S.; SILVEIRA, M. C.; GAMEZ, L. Uma
Abordagem Ergonmica para o Desenvolvimento de Sistemas
Interativos. In: WORKSHOP SOBRE FATORES HUMANOS EM
SISTEMAS COMPUTACIONAIS, IHC, 1., 1998, Maring-PR.
Compreendendo Usurios, Construindo Interfaces: atas. [Rio de
Janeiro: PUC-RJ], 1998.
[CYB 2000] CYBIS, W. A. Abordagem ergonmica para IHC. 2000. Apostila de
curso. Laboratrio de Utilizabilidade INE/UFSC, Florianpolis.
Disponvel em: <http://www.labiutil.inf.ufsc.br/apostila/apostila.htm>.
Acesso em: 18 maio 2002.
[CYS 2001]

CYSNEIROS, L. M.; LEITE, J. C. S. P. Driving Non-Functional

Requirements to Use Cases and Scenarios. In: SIMPSIO BRASILEIRO
DE ENGENHARIA DE SOFTWARE, SBES, 15., 2001, Rio de Janeiro.
Anais... Rio de Janeiro: UFRJ, 2001.

[FER 99]

FERREIRA, Aurlio B. H. Novo Dicionrio Aurlio Sculo XXI.

[S.l.]: Nova Fronteira, 1999.

[FOW 97]

FOWLER, M.; SCOTT, K. UML Distilled: Applying the Standard

Object Modeling Language. Reading: Addison-Wesley, 1997.

[FOW 2000] FOWLER, M.; SCOTT, K. UML Distilled: A Brief Guide to the
Standard Object Modeling Language. 2nd ed. Reading: Addison-Wesley,
2000.
[FUR 98]

FURLAN, J. D. Modelagem de Objetos atravs da UML. So Paulo:

Makron Books, 1998.

[JAC 92]

JACOBSON, I. et al. Object Oriented Software Engineering: A Use

Case Driven Approach. Workingham: Addison-Wesley, 1992.

[JAC 94a]

JACOBSON, I. Basic Use-Case Modeling. Report on Object Analysis

& Design, [S.l.], v. 1, n. 2, Aug. 1994.

[JAC 94b]

JACOBSON, I. Basic Use-Case Modeling (Continued). Report on

Object Analysis & Design, [S.l.], v. 1, n. 3, Oct. 1994.

[JAC 94c]

JACOBSON, I. Use Cases an Objects. Report on Object Analysis &

Design, [S.l.], v. 1, n. 4, Dec. 1994.

[JAR 99]

JARKE, M. Scenarios for Modeling. Communications of the ACM,

New York, v. 42, n. 1, Jan. 1999.

88
[KAI 95]

[KAI 99]

KAINDL, H. An Integration of Scenarios with Their Purposes in Task

Modelling. In: SYMPOSIUM ON DESIGNING INTERATIVE
SYSTEMS, DIS, 1995, Ann Arbor, USA. Processes, Practices,
Methods & Techniques: proceedings. [Ann Arbor: ACM], 1995. p.227235.
KAINDL, H.; CARROLL, J. M. Symbolic Modeling in Practice.
Communications of the ACM, New York, v. 42, n. 1, Jan. 1999.

[KLA 93]

KLAUSEN, T.; BERSEN, N.O. COSITUE: Towards a Methodology for

Constructing Scenarios. In: COGNITIVE SCIENCE APPROACHES TO
PROCESS CONTROL, CSAPC, 1993, Copenhagen. Designing for
Simplicity: proceedings. [S.l.:s.n.], 1993, p.1-16.

[KAV 96]

KAVAKLI, E.; LOCOPOULOS, P.; FILIPPIDOU, D. Using Scenarios

to Systematically Support Goal-Direct Elaboration for Information
System Requirements. In: IEEE SYMPOSIUM AND WORKSHOP ON
ENGINEERING OF COMPUTER-BASED SYSTEM, ECBS, 1996,
Friedrichshafen, Germany. Proceedings [Los Alamitos: IEEE
Computer Society], 1996. p.308-314.

[KYN 92]

KYNG, M. Scenario? Guilty! SIGCHI Bulletin, [S.l.], v. 24, n. 4, p. 8-9,

Oct. 1992.

[LAR 2000] LARMAN, C. Utilizando UML e Padres: uma Introduo Anlise e

ao Projeto Orientados a Objetos. Traduo L. A. M. Salgado. Porto
Alegre: Bookman, 2000.
[LEI 97]

LEITE, J. C. S. P. et al. Enhancing a Requirements Baseline with

Scenarios. Requirements Engineering Journal, [S.l.], v.2, n.4, p.184198, 1997.

[MAR 2000] MARKOPOULOS, P. and MARIJNISSEN, P. UML as a representation

for Interaction Design. In: OZCHI, 2000, Paris. Proceedings... [S.l.:s.n.],
2000. p. 240-249.
[MCD 94]

McDANIEL, S. E.; OLSON, G. M.; OLSON, J. S. Methods in Search of

Methodology-Combining HCI and Object Orientation. In: CHI, 1994,
USA. Proceedings... New York: ACM Press, 1994. p. 145-151.

[MON 2000] MONTEIRO, C. de C. O.; BARBOSA, S.D.J.; de SOUZA, C.S. The

Role of Designer-Generated Scenarios in Developing Web Apllications:
A Case Study. In: WORKSHOP SOBRE FATORES HUMANOS EM
SISTEMAS COMPUTACIONAIS, IHC, 3., Gramado-RS. Muitas Faces
em Interfaces: anais. Porto Alegre: Instituto de Informtica da UFRGS,
2000.
[PAT 99]

PATERN, F.; MANCINI, C. Developing Task Models from Informal

Scenarios. In: ACM CHI, 1999. Late Breaking Results: proceedings.
[Pittsburgh: ACM Press], 1999. p.228-229.

89
[PAT 2001]

PATERN, F. Task Models in Interactive Software Systems. In:

CHANG, S.K. (Ed.). Handbook of Software Engineering &
Knowledge Engineering, [S.l.]: World Scientific Publishing Co., 2001.

[PIM 96]

PIMENTA, M. S.; BARTHET, M. Context Modelling for an Usability

Oriented Approach to Interactive Systems Requirements Engineering. In:
In: IEEE SYMPOSIUM AND WORKSHOP ON ENGINEERING OF
COMPUTER-BASED SYSTEM, ECBS, 1996, Friedrichshafen,
Germany. Proceedings [Los Alamitos: IEEE Computer Society],
1996. p.315-321.

[PIM 97]

PIMENTA, Marcelo S. TAREFA: Une Approche pour IIngnierie des

Besoins des Systmes Interactifs. 1997. 285p. Tese (Doutorado) Universit Toulouse, Toulouse.

[PIM 2000]

PIMENTA, M. S. TAREFA: Uma Abordagem para Engenharia de

Requisitos
de
Sistemas
Interativos.
In:
JORNADAS
IBEROAMERICANAS DE INGENIERA DE REQUISITOS Y
AMBIENTES SOFTWARE, IDEAS, 2000, Cancn. Memorias
Cuernavaca: Centro Nacional de Investigacin y Desarollo Tecnolgico,
2000.

[POT 94]

POTTS, C.; TAKAHASHI, K.; ANTN, A. Inquiry-Based Scenario

Analysis of Systm Requirements. [S.l.]: Georgia Tech College of
Computing, Jan. 1994. Technical Report.

[POT 95]

POTTS, C. Using Schematic Scenarios to Understand User Needs. In:

SYMPOSIUM ON DESIGNING INTERATIVE SYSTEMS, DIS, 1995,
Ann Arbor, USA. Processes, Practices, Methods & Techniques:
proceedings. [Ann Arbor: ACM], 1995. p.247-256.

[REG 95a]

REGNELL, B.; KIMBLER, K.; WESSLN. A. Improving the Use Case

Driven Approach to Requirements Engineering. In: IEEE
INTERNATIONAL
SYMPOSIUM
ON
REQUIREMENTS
ENGINEERING, RE, 2., 1995, York, England. Proceedings... Los
Alamitos: IEEE Computer Society, 1995.

[REG 95b]

REGNELL, B. Usage Oriented Requirements Engineering. In: IEEE

INTERNATIONAL
SYMPOSIUM
ON
REQUIREMENTS
ENGINEERING, RE, 2., 1995, York, England. Consortium... Los
Alamitos: IEEE Computer Society, 1995.

[REG 96]

REGNELL, B.; ANDERSSON, M.; BERGSTRAND, J. A Hierarchical

Use Case Model with Graphical Representation. In: IEEE
INTERNATIONAL
SYMPOSIUM
AND
WORKSHOP
ON
ENGINEERING OF COMPUTER BASED SYSTEMS, Friedrichshafen.
Proceedings... Los Alamitos: IEEE Computer Society, 1996.

90
[ROL 98a]

ROLLAND, C.; ACHOUR, C. Ben. Guiding the Construction of Textual

Use Case Specifications. Data & Knowledge Engineering Journal,
Amsterdam, v. 25, n. 1-2, p.125-160, Mar. 1998.

[ROL 98b]

ROLLAND, C.; SOUVEYET, C.; ACHOUR, C. Ben. Guiding Goal

Modeling Using Scenarios. IEEE Transactions on Software
Engineering, New York, v. 24, n. 12, p.1055-1071, Dec. 1998 .

[ROL 99]

ROLLAND, C. et al. Experience With Goal-Scenario Coupling In

Requirements Engineering. In: IEEE INTERNATIONAL SYMPOSIUM
ON REQUIREMENTS ENGINEERING, RE, 4., 1999, Limerick,
Ireland. Proceedings... [S.l.]: IEEE Computer Society, 1999.

[ROS 95]

ROSSON, M. B.; CARROLL, J. M. Integrating Task and Software

Development for Object-Oriented Applications. In: CONFERENCE ON
HUMAN FACTORS IN COMPUTING SYSTEMS, CHI, 1995, Denver.
Human Factors in Computing Systems. New York: ACM, 1995.
p.377-384.

[RUB 92]

RUBIN, K. S.; COLDBERG, A. Object Behavior Analysis.

Communications of the ACM, New York, v. 35, n. 9, September 1992.

[RYS 2000]

RYSER, J.; GLINZ, M. SCENT: A Method Employing Scenarios to

Systematically Derive Test Cases for System Test. Zrich: Universitt
Zrich, Institut fr Informatik, Berichte des Instituts fr Informatik, 2000.

[STO 95]

STORRS, Graham. The Notion of Task in Human-Computer Interaction.

In: HUMAN COMPUTER INTERACTION, HCI, 1995, Huddersfield.
Preceedings Huddersfield: Cambridge University Press, 1995. p.357365.

[VED 2001] VEDOATO, Roberto. Uma Reviso Bibliogrfica sobre Cenrios e

Casos de Uso: Rumo Integrao de Engenharia de Software e Interao
Humano-Computador no Desenvolvimento de Sistemas Interativos.
2001. Trabalho Individual (Mestrado em Cincia da Computao)
Instituto de Informtica, UFRGS, Porto Alegre. (TI-999).
[VED 2002a] VEDOATO, R.; PIMENTA, M. S. Rumo a uma Abordagem Teleolgica
para Construo de Cenrios e Casos de Uso. In: SYMPOSIUM ON
HUMAN FACTORS IN COMPUTER SYSTEMS, 5., 2002, Fortaleza.
Proceedings... Fortaleza: SBC, 2002. p. 371-375.
[VED 2002b] VEDOATO, R.; PIMENTA, M. S. Uma abordagem teleolgica para
construo de casos de uso e cenrios. In: CONFERENCIA
LATINOAMERICANA DE INFORMTICA, CLEI, 28., 2002,
Montevideo, Uruguai. Program and Abstracts... Montevideo, Uruguai:
CLEI, 2002. 1 CD-ROM.
[VEM 95]

VEMULAPALLI, C. A Use Case FAQ. In: SIGPLAN Notices, New

York, v.30, n.10, Oct. 1995. Trabalho apresentado na 10. Conference on

91
Object-Oriented Programming Systems, Languages na Applications,
OPSLA, 1995.
[WIR 2001]

WIRFS-BROCK, R.; McKEAN, A. A Brief Tour of ResponsibilityDriven Design. OOPSLA 2001. Disponvel em: <http://www.wirfsbrock.com/pages/resources/zip/brief_tour_of_responsibility_driven_desi
gn_tutorial.zip>. Acesso em: 27 set. 2002.

[WOO 96]

WOOD, Larry E.; ZENO, Ron. Transforming User-Centered Analysis

into Concrete Design. SIGCHI Bulletin, New York, v. 28, n.4, Oct.
1996.