Transformação de Um Modelo de Empresa em Um Modelo de Casos de Uso Seguindo Os Conceitos de Engenharia Dirigida Por Modelos

FBIO LEVY SIQUEIRA
TRANSFORMAO DE UM MODELO DE EMPRESA EM UM

MODELO DE CASOS DE USO SEGUINDO OS CONCEITOS DE
ENGENHARIA DIRIGIDA POR MODELOS
Tese de Doutorado apresentada Escola
Politcnica da Universidade de So Paulo
SO PAULO
2011
FBIO LEVY SIQUEIRA
TRANSFORMAO DE UM MODELO DE EMPRESA EM UM

MODELO DE CASOS DE USO SEGUINDO OS CONCEITOS DE
ENGENHARIA DIRIGIDA POR MODELOS
Tese de Doutorado apresentada Escola
Politcnica da Universidade de So Paulo
rea de concentrao: Sistemas Digitais
Orientador:
Prof. Dr. Paulo Srgio Muniz Silva
SO PAULO
2011
FICHA CATALOGRFICA
Siqueira, Fbio Levy

Transformao de um modelo de empresa em um modelo de
casos de uso seguindo os conceitos de engenharia dirigida por
modelos / F.L. Siqueira. -- So Paulo, 2011.
256 p.
Tese (Doutorado) - Escola Politcnica da Universidade de
So Paulo. Departamento de Engenharia de Computao e Sistemas Digitais.
1. Engenharia de requisitos 2. Engenharia dirigida por modelos 3. Engenharia de software I. Universidade de So Paulo. Escola Politcnica. Departamento de Engenharia de Computao e
Sistemas Digitais II. t.
AGRADECIMENTOS
Ao Prof. Dr. Paulo Srgio Muniz Silva pela amizade e pelos 10 anos de orientao,
desde o trabalho de concluso da graduao a at o doutorado. Mesmo depois de
todo esse tempo, ainda tenho muito a aprender com ele.
banca de qualificao, composta pelo Prof. Dr. Jaelson Castro e pela Profa. Dra.
Selma Shin Shimizu Melnikoff, pelos valiosos comentrios e crticas.
Ao Prof. Dr. Kechi Hirama por permitir a realizao do experimento em sua
disciplina.
Aos meus pais, Anita e Gustavo, e s minhas irms, Mnica e Karina, pelo amor e
apoio incondicional durante todos esses anos.
Aos meus amigos Alex, Andr, Ivan, Sylvio e Tarcsio pelo companheirismo e pelos
momentos de descontrao.
Fundao de Amparo Pesquisa do Estado de So Paulo (FAPESP) por ter
fomentado, parcialmente, este doutorado atravs da bolsa nmero 2007/58489-4.
A todos que contriburam de alguma forma para a realizao deste trabalho.
ii
RESUMO
Uma das principais responsabilidades da rea de Engenharia de Requisitos refinar
requisitos em especificaes. Em sistemas empresariais esse refinamento deve
considerar o contexto empresarial no qual o sistema far parte. Apesar de existirem
algumas abordagens para refinar requisitos algumas delas at mesmo
considerando o contexto empresarial essa tarefa realizada manualmente.
Baseado em conceitos de Engenharia Dirigida por Modelos, este trabalho prope
uma transformao semiautomtica usando um modelo da empresa como modelo
dos requisitos e um modelo de casos de uso como modelo das especificaes. Para
isso, considera-se que ao usar um modelo de empresa como origem dessa
transformao possvel representar tanto os requisitos quanto os conhecimentos
de domnio necessrios para obter especificaes atravs de uma transformao.
Com isso, este trabalho apresenta os metamodelos de origem e de destino, um
conjunto de regras de transformao e uma ferramenta que permite executar a
transformao. Por fim, este trabalho tambm discute um experimento que foi
executado para analisar alguns aspectos desta proposta.
Palavras-chave: engenharia de requisitos, engenharia dirigida por modelos,
requisito, especificao, transformao, modelo empresarial, caso de uso.
iii
ABSTRACT
One of the key responsibilities of Requirements Engineering is to refine requirements
into specifications. For enterprise systems, this refinement must consider the
enterprise context where the system will be deployed. Although there are some
approaches for requirements refinement, some of them even considering the
enterprise context, this task is executed manually. Based on Model-Driven
Engineering concepts, this study proposes a semi-automatic transformation using an
enterprise model as a requirements model and a use case model as a specifications
model. For that, this work considers that using an enterprise model as a source it is
possible to represent both the requirements and the domain knowledge that are
necessary to obtain specifications through a transformation. Therefore, this study
presents the source and target meta-models, a set of transformation rules, and a tool
to support the transformation. Finally, this study also discusses an experiment
executed to analyze some aspects of this proposal.
Keywords: requirements engineering, model-driven engineering, requirement,
specification, transformation, enterprise model, use case.
iv
LISTA DE FIGURAS
Figura 1.1: Mtodo empregado para a realizao da tese. ........................................ 7
Figura 3.1: O modelo WRSPM, evidenciando os cinco artefatos por ele definidos
(GUNTER et al., 2000). ........................................................................................ 19
Figura 3.2: Parte do metamodelo da UML a respeito do caso de uso (OMG, 2011b).
............................................................................................................................. 43
Figura 4.1: Modelo de domnio de uma biblioteca e o metamodelo usado............... 60
Figura 4.2: A relao entre os elementos do metamodelo usado no exemplo da
Figura 4.1 e o seu metametamodelo. .................................................................. 61
Figura 4.3: Representao de um espao tecnolgico com trs nveis de
modelagem, segundo Bzivin (2006). .................................................................. 63
Figura 4.4: Os modelos envolvidos em uma transformao de modelos e a relao
entre eles. ............................................................................................................ 66
Figura 5.1: Relao entre o ambiente, o sistema e a empresa. ............................... 71
Figura 5.2: A relao entre os requisitos e a empresa, considerando o ambiente e o
sistema................................................................................................................. 73
Figura 5.3: A restrio do espao da soluo, considerando alguns momentos
especficos, at se obter o sistema construdo. ................................................... 85
Figura 6.1: Representao dos Espaos Tcnicos e as transformaes entre os
modelos para o caso de trs Espaos Tcnicos. ............................................... 101
Figura 6.2: A relao entre os modelos do MDA e o cdigo................................... 103
Figura 6.3: A transformao proposta. ................................................................... 109
Figura 6.4: A sintaxe abstrata da viso da estrutura organizacional. ..................... 116
Figura 6.5: Restries nas metaclasses da viso estrutura organizacional. .......... 116
v
Figura 6.6: A sintaxe abstrata do metamodelo de empresa referente viso de
ambiente fsico. .................................................................................................. 117
Figura 6.7: Restrio na metaclasse Layout da viso de ambiente fsico. ............. 117
Figura 6.8: A sintaxe abstrata do metamodelo de empresa referente viso de
documento. ........................................................................................................ 118
Figura 6.9: Restries nas metaclasses da viso de documentos. ........................ 118
Figura 6.10: A sintaxe abstrata do metamodelo de empresa referente viso
motivacional, baseado no BMM (OMG, 2008a). ................................................ 119
Figura 6.11: Parte da sintaxe abstrata do metamodelo de empresa referente viso
processual, baseado no BPDM (OMG, 2008b) (OMG, 2008c). ......................... 122
Figura 6.12: Relaes entre os elementos definidos pelas 5 vises do metamodelo
de empresa. ....................................................................................................... 123
Figura 6.13: Restrio entre as vises de processo e organizacional. ................... 123
Figura 6.14: A relao da organizao com os demais elementos do metamodelo de
empresa. ............................................................................................................ 124
Figura 6.15: A sintaxe abstrata do metamodelo de caso de uso. ........................... 137
Figura 6.16: Restries em OCL (OMG, 2006b) da sintaxe abstrata do metamodelo
de caso de uso. .................................................................................................. 138
Figura 6.17: Gabarito como sintaxe concreta do metamodelo de caso de uso. ..... 140
Figura 6.18: Mtodo para obteno das regras de refinamento, descrito em BPMN
(OMG, 2011a). ................................................................................................... 145
Figura 6.19: As transformaes entre os modelos do GMF e do EMF para obter
cdigo fonte Java de um plug-in grfico (baseado no GMF dashboard (THE
ECLIPSE FOUNDATION, 2011a)). .................................................................... 152
Figura 6.20: A parte central do mapeamento. ........................................................ 155
vi
Figura 6.21: Detalhe do mapeamento activity2Action. ........................................... 156
Figura 6.22: Detalhe do mapeamento gateway2Statement. ................................... 157
Figura 6.23: Viso geral da ferramenta EMUCase. ................................................ 158
Figura 6.24: A edio de um diagrama de estrutura organizacional na ferramenta
EMUCase........................................................................................................... 159
Figura 6.25: O primeiro passo do assistente para a transformao dos modelos de
empresa em casos de uso. ................................................................................ 159
Figura 6.26: Validao dos modelos de entrada e sada da transformao. .......... 162
Figura 7.1: O projeto do experimento. .................................................................... 168
Figura 7.2: As atividades realizadas no experimento, descritas usando BPMN (OMG,
2011a). ............................................................................................................... 176
Figura 7.3: Grfico boxplot para as notas do escopo ATM. .................................... 181
Figura 7.4: Grfico boxplot para as notas do escopo Locadora. ............................ 182
Figura 7.5: Respostas dos questionrios finais dos sujeitos que executaram um
tratamento com a tcnica de criao de caso de uso Transformao. .............. 186
vii
LISTA DE TABELAS
Tabela 3.1: Viso geral da relao entre o escopo e o nvel de detalhamento do
caso de uso e as informaes que eles representam. ......................................... 39
Tabela 3.2: Fatores de qualidade propostos por (PHALP; VINCENT; COX, 2007a).
............................................................................................................................. 54
Tabela 6.1: Comparao entre os Espaos Tcnicos do MDA, XML e EMF. ......... 107
Tabela 6.2: Simplificaes feitas no metamodelo do BPDM. .................................. 121
Tabela 6.3: Sintaxe concreta da viso organizacional. ........................................... 126
Tabela 6.4: Sintaxe concreta da viso de ambiente fsico. ..................................... 126
Tabela 6.5: Sintaxe concreta da viso motivacional. .............................................. 127
Tabela 6.6: Sintaxe concreta da viso de documento. ........................................... 128
Tabela 6.7: Resultados do levantamento realizado nas bases de artigos cientficos.
........................................................................................................................... 129
Tabela 6.8: Frequncia dos elementos nos trabalhos analisados, evidenciando os
mais comuns. ..................................................................................................... 132
Tabela 6.9: Frequncia dos subelementos nos trabalhos analisados, evidenciando
os mais comuns. ................................................................................................ 134
Tabela 6.10: O posicionamento dos trabalhos em relao organizao dos passos.
........................................................................................................................... 135
Tabela 6.11: Regras obtidas atravs da anlise dos trabalhos relacionados. ........ 142
Tabela 6.12: As regras de refinamento obtidas ao aplicar o mtodo no exemplo da
biblioteca. ........................................................................................................... 149
Tabela 6.13: As regras sintticas obtidas ao aplicar o mtodo no exemplo da
biblioteca. ........................................................................................................... 149
viii
Tabela 7.1: As variveis independentes e como elas foram tratadas pelo
experimento (abordagem): fator, randomizada ou fixa....................................... 167
Tabela 7.2: Nmero de sujeitos para cada um dos tratamentos. ............................ 179
Tabela 7.3: As notas e os tempos obtidos no experimento. ................................... 180
Tabela 7.4: Valores para o teste da hiptese HE1.................................................. 183
Tabela 7.7: Valores ao analisar os tempos ao empregar a tcnica Modelo da
Empresa e Diretamente. .................................................................................... 185
Tabela 7.8: Regras usadas por sujeito. .................................................................. 188
ix
LISTA DE ABREVIATURAS E SIGLAS

ATL
Atlas Transformation Language
BMM
Business Motivation Model
BPDM
Business Process Definition Metamodel
BPMN
Business Process Modeling Notation
B-SCP
Business Strategy, Context, and Process
CIM
Computation Independent Model
DTD
Document Type Definition
EKD
Enterprise Knowledge Development
EMF
Eclipse Modeling Framework
GMF
Graphical Modeling Framework
GORE
Engenharia
de
Requisitos
orientada
por
metas
(Goal
Oriented
Requirements Engineering)
i*
Intencionalidade Distribuda
KAOS
Knowledge Acquisition in Automated Specification ou Keep All Objectives

Satisfied
Map
Intention/Strategy Map
MDA
Arquitetura Dirigida por Modelos (Model Driven Architecture)
MDE
Engenharia Dirigida por Modelos (Model Driven Engineering)
MOF
Meta Object Facility
O&M
Organizao e Mtodos (ou Organizao, Sistemas e Mtodos)
OCL
Object Constraint Language
PIM
Platform Independent Model
PSM
Platform Specific Model
QVT
Query/View/Transformation
x
TI
Tecnologia da Informao
TOGAF
The Open Group Architecture Framework
TS
Espao Tcnico (ou Espao Tecnolgico) (Technical Space)
UML
Unified Modeling Language
WRSPM
World, Requirement, Specification, Platform e Machine
XMI
XML Metadata Interchange
XML
Linguagem de Marcao Extensvel (Extensible Markup Language)
XSLT
Extensible Stylesheet Language Transformations
xi
SUMRIO
1
INTRODUO .......................................................................................................... 1
1.1 Motivao...................................................................................................... 1
1.2 Objetivo ......................................................................................................... 3
1.3 Justificativa .................................................................................................. 4
1.4 Escopo .......................................................................................................... 5
1.5 Hipteses consideradas .............................................................................. 5
1.6 Mtodo .......................................................................................................... 6
1.7 Organizao do trabalho ............................................................................. 8
REPRESENTAO DE UMA EMPRESA ......................................................................... 9

2.1 Arquitetura empresarial ............................................................................. 12
2.2 Organizao e Mtodos ............................................................................. 15
2.3 Concluso ................................................................................................... 17
REQUISITO, ESPECIFICAO E SUAS REPRESENTAES ........................................... 18

3.1 Definies ................................................................................................... 18
3.2 Engenharia de Requisitos ......................................................................... 25
3.3 Engenharia de Requisitos orientada por metas ...................................... 27
3.3.1 Abordagens orientadas por metas ......................................................... 29
3.3.2 Vantagens e desvantagens de abordagens GORE ............................... 33
3.4 Representao dos requisitos .................................................................. 34
3.5 Caso de uso ................................................................................................ 36
3.5.1 Vantagens e limitaes do caso de uso ................................................ 39
3.5.2 Caso de uso na UML ............................................................................. 41
3.5.3 Representao textual do caso de uso.................................................. 49
3.5.4 Avaliao da qualidade de um caso de uso .......................................... 51
xii
3.6 Concluso ................................................................................................... 54
4
ENGENHARIA DIRIGIDA POR MODELOS (MDE).......................................................... 56

4.1 Modelo......................................................................................................... 56
4.2 Viso geral da MDE .................................................................................... 58
4.3 Transformao de modelos ...................................................................... 63
4.4 Formas de representao de metamodelos ............................................ 66
4.5 Concluso ................................................................................................... 68
MODELO DA EMPRESA E A TRANSFORMAO DE REQUISITOS EM ESPECIFICAES..... 69

5.1 Modelo da empresa, requisitos e especificaes ................................... 69
5.1.1 Relao entre o ambiente, a empresa e o sistema................................ 70
5.1.2 Relao entre a empresa e os requisitos .............................................. 72
5.1.3 Modelo da empresa e os modelos dos requisitos e das especificaes 74
5.1.4 Modelo da empresa e sistemas de automao de processos ............... 78
5.2 Transformao de requisitos em especificaes ................................... 80
5.2.1 Limitaes da transformao ................................................................. 83
5.3 Trabalhos relacionados ............................................................................. 86
5.3.1 Abordagens orientadas por metas ......................................................... 86
5.3.2 Abordagens que empregam casos de uso ............................................ 90
5.3.3 Abordagens de transformao seguindo a MDA ................................... 93
5.3.4 Outras abordagens ................................................................................ 96
5.4 Concluso ................................................................................................... 98
TRANSFORMAO DO MODELO DA EMPRESA EM MODELO DE CASO DE USO ............. 100

6.1 Escolha do Espao Tcnico .................................................................... 101
6.1.1 Arquitetura Dirigida por Modelos (MDA) .............................................. 102
6.1.2 Eclipse Modeling Framework (EMF) .................................................... 104
6.1.3 Linguagem de marcao extensvel (XML) ......................................... 105
xiii
6.1.4 Anlise dos Espaos Tcnicos ............................................................ 106
6.2 Metamodelo de empresa ......................................................................... 109
6.2.1 Anlise ................................................................................................. 112
6.2.2 Sintaxe abstrata ................................................................................... 115
6.2.3 Semntica ............................................................................................ 124
6.2.4 Sintaxe concreta .................................................................................. 126
6.3 Metamodelo de caso de uso ................................................................... 128
6.3.1 Anlise ................................................................................................. 128
6.3.2 Sintaxe abstrata ................................................................................... 136
6.3.3 Semntica ............................................................................................ 138
6.3.4 Sintaxe concreta .................................................................................. 139
6.4 Regras de transformao ........................................................................ 140
6.4.1 Mtodo para obteno de regras de refinamento ................................ 144
6.4.2 Aplicao do mtodo e as regras de refinamento................................ 147
6.4.3 Problemas e limitaes do mtodo ...................................................... 150
6.5 Ferramenta................................................................................................ 151
6.5.1 Roteiro da transformao .................................................................... 153
6.5.2 Projetor para o TS do XML .................................................................. 157
6.5.3 Viso geral da ferramenta EMUCase .................................................. 157
6.6 Problemas e limitaes da transformao ............................................ 160
6.7 Concluso ................................................................................................. 162
7
EXPERIMENTO..................................................................................................... 163
7.1 Declarao do problema.......................................................................... 163
7.2 Planejamento do experimento ................................................................ 164
7.2.1 Ambiente do experimento .................................................................... 165
7.2.2 Variveis e fatores ............................................................................... 166
xiv
7.2.3 Projeto do experimento ........................................................................ 168
7.2.4 Estratgia de anlise dos dados .......................................................... 169
7.2.5 Validade dos resultados ...................................................................... 172
7.3 Operao do experimento ....................................................................... 176
7.4 Anlise e interpretao dos dados ......................................................... 180
7.4.1 Hiptese HE1....................................................................................... 182
7.4.2 Hiptese HE2....................................................................................... 183
7.4.3 Hiptese HE3....................................................................................... 184
7.4.4 Questionrio final ................................................................................. 185
7.4.5 Outras anlises .................................................................................... 187
7.5 Discusso e concluses.......................................................................... 188
8
CONCLUSO ....................................................................................................... 191

8.1 Contribuies ........................................................................................... 192
8.2 Trabalhos futuros ..................................................................................... 192
8.3 Artigos publicados ................................................................................... 194
REFERNCIAS ........................................................................................................... 196

GLOSSRIO ............................................................................................................... 213
APNDICE A ELEMENTOS DE REPRESENTAES DA EMPRESA ................................ 217
APNDICE B SINTAXE CONCRETA EM XML DO METAMODELO DE CASO DE USO ........ 221
APNDICE C MODELO AS-IS E TO-BE DO EXEMPLO DA BIBLIOTECA .......................... 224
C.1. Modelo as-is ............................................................................................. 224
C.2. Modelo to-be ............................................................................................. 228
APNDICE D MODELO DE CASO DE USO IDEAL PARA A BIBLIOTECA ......................... 232
APNDICE E RESULTADO
USANDO AS REGRAS INICIAIS
DA TRANSFORMAO PARA O EXEMPLO DA BIBLIOTECA
...................................................................................... 237
APNDICE F FORMATO DO CASO DE USO CRUD DA REGRA RR8 ............................ 239
xv
APNDICE G CRITRIOS PARA AVALIAO DE CASOS DE USO ................................. 240
APNDICE H QUESTIONRIOS APLICADOS NO EXPERIMENTO .................................. 242
H.1. Questionrio Inicial .................................................................................. 242
H.2. Questionrio final ..................................................................................... 243
APNDICE I ENUNCIADOS DOS EXERCCIOS USADOS NO EXPERIMENTO .................... 245
I.1. Criao do caso de uso para a ATM ....................................................... 245
I.2. Criao do modelo as-is e to-be para a ATM ......................................... 246
I.3. Criao do caso de uso para a locadora................................................ 248
I.4. Criao do modelo as-is e to-be para a locadora .................................. 249
I.5. Legenda .................................................................................................... 250
APNDICE J GABARITOS USADOS NO EXPERIMENTO .............................................. 252
J.1. Alugar filme .............................................................................................. 252
J.2. Sacar dinheiro .......................................................................................... 252
APNDICE K RESULTADOS DOS EXPERIMENTOS .................................................... 254
1 INTRODUO
Atualmente os sistemas computacionais so fundamentais para que as empresas
possam atuar nos mercados cada vez mais competitivos. Eles no somente auxiliam
os funcionrios e outras partes envolvidas a realizar algumas de suas atividades,
como em alguns casos as automatizam completamente sejam elas atividades
simples e repetitivas, ou mesmo to complexas que um grupo de pessoas no
conseguiria execut-las com a mesma qualidade e no mesmo tempo. Dessa
maneira, os sistemas computacionais auxiliam direta ou indiretamente as empresas
a atender s necessidades de seus clientes e, em geral, com um custo menor do
que se as atividades fossem realizadas completamente de forma manual.
Apesar de sua importncia, uma empresa no feita somente de sistemas
computacionais. Existem diversos outros elementos que a constituem, sejam eles
fsicos ou no: os funcionrios, as ferramentas usadas, as atividades executadas, os
artefatos gerados como resultados das atividades, os processos executados, os
objetivos estabelecidos, as misses definidas, a cultura organizacional existente,
entre diversos outros elementos. Cada empresa uma organizao particular devido
a esses diversos elementos que a regem coletivamente.
Como o sistema computacional apenas mais um elemento da empresa, a sua
criao precisa considerar o contexto empresarial em que ele far parte. Se isso no
for feito, o sistema possivelmente no conseguir corresponder s expectativas que
motivaram a sua construo podendo at mesmo no ser usado.
1.1 Motivao
Uma das principais responsabilidades da Engenharia de Requisitos levantar o que

os clientes desejam do sistema, ou seja, elicitar os requisitos. Os requisitos obtidos
atravs desse levantamento devem descrever o ambiente no qual o sistema
computacional dever operar evitando, assim, descrever detalhes internos do
sistema (ZAVE; JACKSON, 1997). No caso de sistemas empresariais, esse
ambiente envolve o contexto empresarial que motivou o desenvolvimento do sistema
e no qual o sistema ir operar.
2
Algumas abordagens de elicitao de requisitos consideram o contexto empresarial
de forma indireta, como, por exemplo, ao realizar entrevistas, workshops de
requisitos, brainstorming e storyboarding. Nessas tcnicas, por mais que os diversos
elementos da empresa relacionados ao sistema no sejam explicitados, as partes
envolvidas naturalmente levam em considerao essas informaes. Em outras
abordagens, so considerados apenas alguns tipos de elementos da empresa e/ou
uma abstrao deles para elicitar os requisitos, como, por exemplo, i* (YU, 1995),
Tropos (BRESCIANI et al., 2004), B-SCP (BLEISTEIN et al., 2006), e KAOS (VAN
LAMSWEERDE, 2009). Por outro lado, algumas abordagens usam especificamente
modelos de empresa para a elicitao de requisitos como, por exemplo, EKD
(BUBENKO JR. et al., 1998) e em (DE LA VARA; SANCHEZ; PASTOR, 2008) e
(MOLINA et al., 2000).
Porm, os requisitos obtidos durante a elicitao ainda no esto expressos de uma
forma adequada para que sejam empregados pelas demais atividades de
desenvolvimento de sistemas (anlise, projeto, implementao e teste). Alguns deles
precisam ser detalhados para que possam ser realizados ou garantidos pelo sistema
(ZAVE; JACKSON, 1997), o que pode envolver a seleo entre alternativas. Por
exemplo, um requisito de que "um funcionrio deve ser avisado sobre o trmino de
uma atividade" ainda impreciso: esse aviso pode ser feito de diversas formas, seja
por e-mail, pelo envio de SMS, por uma mensagem disponvel na Intranet etc. A
escolha de qual dessas alternativas a mais apropriada depende de informaes do
contexto no qual o sistema est inserido, o que envolve o contexto empresarial.
Como exemplo disso, se houver uma poltica empresarial afirmando que o e-mail a
forma padro de divulgao de informaes coorporativas, ela pode ser suficiente
para que seja escolhido o aviso por e-mail.
Apesar da necessidade de detalhamento dos requisitos obtendo o que chamado
neste trabalho de especificaes algumas abordagens de Engenharia de
Requisitos ou de desenvolvimento de sistemas computacionais no discutem como
isso pode ser feito. Em outras, a representao de uma dessas informaes
omitida, sendo considerado apenas os requisitos ou as especificaes. O mais
frequente no existir uma separao clara entre os requisitos e as especificaes.
Entretanto, os requisitos e as especificaes representam diferentes informaes:
um representa o que os clientes desejam do sistema e outro o que deve ser
3
construdo. A obteno das especificaes a partir dos requisitos propensa a
erros, j que podem ser tomadas decises inadequadas. Mas, alm disso, uma
mudana nos requisitos ou no ambiente principalmente ao considerar um contexto
empresarial , pode ter impacto direto nas decises tomadas durante esse
detalhamento. Em alguns casos essa mudana impacta os requisitos, sendo
necessrio revisitar o detalhamento realizado; em outros a mudana no impacta os
requisitos, mas as decises tomadas no detalhamento realizado; e em outros a
mudana impacta apenas as especificaes no sendo necessrio rever o
detalhamento realizado. Dessa maneira, importante representar tanto os requisitos
quanto as especificaes, alm das decises tomadas durante o detalhamento.
Caso os requisitos no sejam representados, o sistema pode ser restrito de forma
inadequada, enquanto que se as especificaes no forem representadas, haver
dificuldades para executar as demais atividades de desenvolvimento (MAIDEN,
2008).
1.2 Objetivo
Dada a importncia da obteno das especificaes a partir dos requisitos, o

objetivo deste trabalho propor a transformao de um modelo dos requisitos,
descrito atravs de um modelo da empresa, em um modelo das especificaes,
descrito atravs de um modelo de caso de uso, seguindo os conceitos de
Engenharia Dirigida por Modelos. Ao propor essa transformao pretende-se
simplificar a execuo de uma das atividades centrais da Engenharia de Requisitos.
Para que essa transformao possa ser executada, este trabalho possui trs
objetivos secundrios:
Definir metamodelos de empresa e de casos de uso;
Propor regras para a transformao; e
Construir uma ferramenta.
Os metamodelos permitem descrever os modelos de entrada e de sada da

transformao, ou seja, os modelos de empresa e de casos de uso,
respectivamente. As regras concretizam a transformao ao definir como obter as
especificaes a partir dos requisitos. Por fim, para executar essa transformao foi
4
construda a ferramenta EMUCase que permite criar o modelo da empresa e
transform-lo em um modelo de caso de uso empregando as regras de
transformao.
1.3 Justificativa
Existem diversos trabalhos que propem abordagens para a obteno das

especificaes a partir dos requisitos, algumas vezes at mesmo empregando
modelos de empresa. As abordagens de Engenharia de Requisitos orientadas por
metas, como i* (YU, 1995), Tropos (BRESCIANI et al., 2004), B-SCP (BLEISTEIN et
al., 2006), e KAOS (VAN LAMSWEERDE, 2009), propem formas para obter
especificaes a partir de uma abstrao do ambiente centrada na representao do
que chamado de meta. A obteno das especificaes feita manualmente
atravs de um processo de refinamento que detalha essas metas e algumas outras
informaes relacionadas.
Outros
trabalhos
propem
transformaes
envolvendo
requisitos
e/ou
especificaes. Trabalhos como (DIETZ, 2003), (DIJKMAN; JOOSTEN, 2002a),

(DIJKMAN;
JOOSTEN,
2002b)
(STOLFA;
RADECK,
2004)
propem
transformaes de uma representao do ambiente atual em um modelo dos

requisitos descritos atravs de casos de uso. Outros trabalhos, como (DIAS et al.,
2006), (ROBINSON; ELOFSON, 2004) e (RODRGUEZ; FERNNDEZ-MEDINA;
PIATTINI, 2007), propem transformaes entre diferentes representaes dos
requisitos sem obter especificaes (ou seja, fazendo apenas uma mudana de
representao). Similarmente, em (DECREUS; SNOECK; POELS, 2009) e
(KOLIADIS et al., 2006) so discutidas transformaes entre vises da empresa,
consideradas por este trabalho como partes do modelo dos requisitos. Por outro
lado, em (SANTANDER; CASTRO, 2002) proposta uma transformao que trata
da mudana de representao de especificaes, no caso obtendo como resultado
um modelo de caso de uso. Outros trabalhos, como (DE LA VARA; SANCHEZ;
PASTOR, 2008) e (MOLINA et al., 2000), abordam a transformaes de requisitos,
representados por diferentes vises da empresa, em especificaes, representadas
por casos de uso.
5
Apesar de esses trabalhos apresentarem diversas similaridades com esta proposta,
poucos consideram explicitamente o contexto empresarial para detalhar os
requisitos em especificaes. Alm disso, nessas abordagens as especificaes so
obtidas manualmente a partir dos requisitos. Em contraposio, uma transformao
semiautomtica de requisitos em especificaes ajudaria a evitar alguns erros
durante o detalhamento dos requisitos. Mais que isso, ela facilitaria a absoro de
mudanas nos requisitos, o que essencial em um ambiente dinmico, como o
caso do ambiente empresarial. Nesse sentido, a existncia de uma ferramenta que
executa a transformao e que permite a alterao de um modelo j criado contribui
tanto para a absoro de mudanas nos requisitos (durante o desenvolvimento ou
mesmo durante a manuteno) como para a realizao semiautomtica da
transformao. Alm disso, do ponto de vista terico, a definio de tal
transformao tambm ajuda a melhorar o entendimento da diferena entre
requisitos e especificaes.
1.4 Escopo
A transformao de requisitos em especificaes proposta considera apenas os

requisitos funcionais, portanto, no tratando de requisitos no funcionais e restries
de projeto. Alm disso, a transformao limitada a sistemas com as seguintes
caractersticas, que sero chamados de sistemas de automao de processos:
Automatizam processos de negcio, com foco no fluxo de trabalho; e
So internos a uma empresa, mas podem possuir algumas interfaces com

outros participantes.
Essas caractersticas permitem simplificar a transformao, seja ao facilitar a criao

das regras de transformao, ou mesmo ao evidenciar a presena dos requisitos em
um modelo da empresa. Alm disso, esse escopo permite evidenciar as vantagens
da transformao, deixando clara a passagem de requisitos em especificaes.
1.5 Hipteses consideradas
A transformao de requisitos em especificaes proposta por este trabalho

centrada em quatro hipteses:
6
H1. Um modelo da empresa do ponto de vista organizacional representa
requisitos funcionais de sistemas de automao de processos.
H2. Em projetos em que no h uma reengenharia completa da empresa, o
modelo as-is da empresa possui parte do conhecimento de domnio
necessrio para se refinar requisitos em especificaes.
H3. Em sistemas de automao de processos possvel automatizar a
transformao de requisitos presentes em um modelo da empresa em
especificaes.
H4. Em sistemas de automao de processo, o modelo da empresa as-is pode
ser usado como referncia para decises de refinamento.
A hiptese H1 considera, no contexto de sistemas de automao de processo, que
um modelo da empresa consegue representar os requisitos funcionais de modo a
ser visto como um modelo dos requisitos. De forma similar, a hiptese H2 considera
que uma parte do modelo da empresa, o modelo do ambiente atual (as-is),
representa parte do conhecimento de domnio. Baseada nessa hiptese, a hiptese
H4 considera que o modelo da empresa as-is possui alternativas de refinamento
adequadas, uma vez que no h uma reengenharia completa da empresa. Por fim, a
hiptese H3 a hiptese central deste trabalho, considerando que possvel
transformar requisitos presentes em um modelo da empresa em especificaes.
Dessas hipteses, apenas a hiptese H3 ser analisada atravs de um experimento
(apresentado no captulo 7), cabendo a trabalhos futuros analisar as demais
hipteses.
1.6 Mtodo
Para atingir os objetivos propostos aplicou-se um mtodo hipottico-dedutivo,

descrito na Figura 1.1, usando BPMN (OMG, 2011a). O projeto se iniciou com uma
pesquisa bibliogrfica exploratria, considerando uma proposta bsica de obteno
de requisitos atravs de informaes do ambiente. Devido abrangncia dessa
proposta bsica, a pesquisa bibliogrfica enfatizou o uso de processos de negcio
como origem dos requisitos. Em seguida o problema foi definido, o que levou a
pesquisas bibliogrficas mais especficas: a representao da empresa, a
7
representao (e definio) de requistos e o estudo da rea de Engenharia Dirigida
por Modelos. Essas pesquisas levaram definio do objetivo deste trabalho.
Pesquisa
inicial
Definio do
problema
Pesquisa sobre a
representao da
empresa
Pesquisa sobre
Engenharia Dirigida
por Modelos
Pesquisa sobre a
representao de
requisitos
Definio do
objetivo
Anlise dos
trabalhos
relacionados
Definio dos
metamodelos
Criao de uma
verso inicial da
ferramenta
Realizao de um
teste inicial
Definio das
regras de
transformao
Concluso da
ferramenta
Execuo do
experimento
Figura 1.1: Mtodo empregado para a realizao da tese.
A partir do objetivo, foram definidos os metamodelos que servem de base para a

transformao, criando uma verso inicial de uma ferramenta para executar a
transformao proposta e realizando um teste da transformao. Em paralelo, foram
analisados os trabalhos relacionados e as implicaes da proposta. Aps essas
atividades, foram definidas as regras de transformao o que envolveu a definio
de um mtodo. A verso inicial da ferramenta foi ento atualizada, absorvendo as
regras de transformao e implementando outros detalhes necessrios. Por fim,
realizou-se um experimento para avaliar a principal hiptese deste trabalho, a
hiptese H3.
1.7 Organizao do trabalho
Para atingir o objetivo definido, este trabalho est organizado da seguinte forma:
Captulo 2 Representao de uma empresa: define o que empresa para

este trabalho e alguns conceitos relacionados, discutindo duas reas que
propem a criao de modelos de empresa abrangentes.
Captulo 3 Requisito, especificao e suas representaes: apresenta

as definies de requisitos e de especificaes usando um modelo como
quadro de referncia e contextualizando essas definies na rea de
Engenharia de Requisitos e em relao s abordagens de Engenharia de
Requisitos orientadas por metas. Tambm discute formas de representao
de requisitos, enfatizando o caso de uso.
Captulo 4 Engenharia dirigida por modelos (MDE): apresenta as linhas

gerais do paradigma da Engenharia Dirigida por Modelos, tratando do
conceito de modelo, metamodelo, metametamodelo, Espao Tcnico e de
uma operao especfica, a transformao.
Captulo 5 Modelo da empresa e a transformao de requisitos em

especificaes: discute a possibilidade de usar o modelo da empresa como
modelo dos requisitos e apresenta a proposta deste trabalho, de transformar
requisitos em especificaes usando conceitos de MDE. Tambm apresenta
os trabalhos relacionados.
Captulo 6 Transformao do modelo da empresa em modelo de caso

de uso: apresenta os detalhes da transformao proposta, analisando e
definindo o Espao Tcnico a ser usado, os metamodelos empregados, as
regras de transformao criadas e a ferramenta implementada.
Captulo 7 Experimento: apresenta o experimento realizado para analisar

a hiptese central deste trabalho.
Captulo 8 Concluso: apresenta a concluso deste trabalho, discutindo as

contribuies e trabalhos futuros, alm de apresentar os trabalhos publicados.
2 REPRESENTAO DE UMA EMPRESA

A empresa uma organizao, ou seja, um sistema social que organizado para
alcanar um tipo particular de meta (PARSONS, 1960, p.56). Seguindo a definio
de organizao, alguns trabalhos afirmam que uma das principais metas a serem
alcanadas por uma empresa o lucro, como o caso de (CHIAVENATO, 2000),
(MAXIMIANO, 2007) e (VERNADAT, 1996). Essa caracterstica evidenciada na
definio de empresa apresentada por esses trabalhos, como o caso de Vernadat
(1996, p.22) que define empresa como "uma organizao socioeconmica criada
para produzir produtos ou oferecer servios e para obter lucro". Dessa maneira, de
acordo com Maximiano (2007) existem dois outros tipos principais de organizao
alm da empresa: o governo e organizaes do terceiro setor.
Para outros trabalhos a empresa algo mais geral, englobando alguns tipos de
organizaes governamentais e do terceiro setor. Ao invs do lucro, esses trabalhos
evidenciam a existncia de atividade econmica ao definir empresa. Por exemplo,
Kwasnicka (2004) divide empresa em privada, pblica ou mista, sendo que nem
mesmo a empresa privada necessariamente almeja o lucro (como, por exemplo, no
caso de uma cooperativa). De forma similar, Daft (2005) apresenta trs tipos de
empresa seguindo um ponto de vista jurdico: a empresa individual, a sociedade e a
sociedade annima. Desses trs tipos, a sociedade no necessariamente almeja o
lucro. Essa mesma nfase atividade econmica seguida pela definio de
empresa presente no cdigo de direito civil brasileiro. Nele, a empresa pode ser vista
como uma sociedade empresria, a qual "tem por objeto o exerccio de atividade
prpria de empresrio sujeito a registro" (BRASIL, 2002, art.982). Nesse contexto, o
empresrio "quem exerce profissionalmente atividade econmica organizada para
a produo ou a circulao de bens ou de servios" (BRASIL, 2002, art.966). Ou
seja, no necessariamente a empresa almeja o lucro.
Este trabalho segue essa viso mais abrangente de empresa, definindo empresa
como (BRASIL, 2002):
Uma organizao que realiza atividade econmica para a produo ou a circulao
de bens ou de servios.
10
Uma empresa pode ser representada atravs de diversos modelos1, como o modelo
dos processos de negcio executados, da planta baixa de suas unidades, da
hierarquia de cargos existentes, do balano patrimonial, entre outras possibilidades.
Cada um desses modelos representa a empresa de uma forma diferente, sendo til
dependendo das necessidades e dos objetivos de quem o usa. Por exemplo, para
entender a relao entre os cargos da empresa, um organograma mais til que um
balano patrimonial.
Para tratar do projeto ou do reprojeto do funcionamento da empresa, um modelo
importante o que trata dos processos empresariais. De acordo com Davenport
(1994), os processos permitem observar uma empresa horizontalmente, ao
considerar as atividades realizadas pelas diversas unidades funcionais envolvidas
em um determinado trabalho; em contraposio, uma viso vertical considera uma
nica unidade funcional da empresa, no permitindo observar o trabalho como um
todo. Segundo Cury (2007), essa viso horizontal permite observar o cliente, o
produto e o fluxo de trabalho de uma forma mais clara, alm de permitir o
entendimento de como o trabalho realmente feito na empresa e evidenciar os
relacionamentos existentes entre as diversas partes da empresa.
De uma forma geral, o processo empresarial definido como um conjunto ordenado
de atividades que transformam entradas em sadas (CHASE; JACOBS; AQUILANO,
2006)
(CRUZ,
2005)
(DAVENPORT,
(HARRINGTON,
1993)
(VERNADAT,
1994)
1996).
(HAMMER;
Em
algumas
CHAMPY,
definies
1994)
so
evidenciados outros conceitos importantes para o processo, como o valor que a

sada gerada deve prover para a organizao (CHASE; JACOBS; AQUILANO, 2006)
(CRUZ, 2005) (HAMMER; CHAMPY, 1994) (HARRINGTON, 1993), o objetivo que o
processo deve possuir (VERNADAT, 1996), a existncia de um cliente (CRUZ, 2005)
(HAMMER; CHAMPY, 1994) e o fato de um processo cruzar as fronteiras funcionais
(LLEWELLYN; ARMISTEAD, 2000), entre outros. Alguns desses conceitos
importantes para o processo so considerados por trabalhos, como, por exemplo,
(CRUZ, 2005) e (DAVENPORT, 1994), para definir os elementos de um processo,
sendo usado para criar uma representao dele. Dada a importncia do processo,
alm desses trabalhos tambm existem alguns padres, como, por exemplo, o ISO
1
A definio de modelo apresentada na seo 4.1.
11
5807 (ISO, 1985), o IDEF3 (MAYER et al., 1995) e o BPDM (Business Process
Definition Metamodel) (OMG, 2008b) que definem formas de represent-lo.
Apesar da importncia dos processos para projetos e reprojetos do funcionamento
da empresa (incluindo melhoria e a reengenharia de processos2), alguns trabalhos
consideram modelos que incluem outras informaes alm do processo. Alguns
desses modelos so constitudos de diversos submodelos que proveem diferentes
vises e que so de alguma forma integrados (VERNADAT, 1996) (WHITMAN;
RAMACHANDRAN; KETKAR, 2001). Por exemplo, de acordo com Hammer e
Champy (1994) a empresa pode ser representada atravs de seus processos de
negcio, seus cargos e estruturas, seus sistemas de gesto e avaliao e seus
valores e crenas. Essas quatro vises esto inter-relacionadas: o processo
determina os cargos e as estruturas necessrias para a empresa; a partir dessas
estruturas definem-se como os funcionrios sero recrutados, avaliados e
remunerados, definindo os sistemas de gesto e avaliao; esses sistemas de
gesto e avaliao so a principal fonte para a definio de valores e crenas da
empresa; e finalmente, o tipo de cultura organizacional influenciar os processos
que precisam existir.
Alguns desses modelos mais abrangentes da empresa que tratam de seu
funcionamento so criados para outros fins, alm do projeto e do reprojeto da
empresa, como, por exemplo, para (KOUBARAKIS; PLEXOUSAKIS, 1999)
(VERNADAT, 1996) (WHITMAN; HUFF, 2001) (WHITMAN; RAMACHANDRAN;
KETKAR, 2001):
Analisar a empresa;
Construir um sistema ou um equipamento caro;
Melhorar o gerenciamento da empresa;
Permitir a integrao da empresa;
Ganhar aprovao das partes envolvidas;
Comunicar o entendimento comum da empresa; e
Ser uma ferramenta de documentao para outros esforos.
Segundo Davenport (1994), a melhoria de processo busca melhorar a eficincia e eficcia de um

processo j existente, enquanto que a reengenharia uma mudana radical da forma como o
trabalho realizado, definindo os processos sem base-los nos existentes.
12
Um desses usos para auxiliar a construo de sistemas computacionais, existindo
abordagens que usam representaes da empresa para auxiliar a definio dos
requisitos de um sistema computacional3.
A seguir so discutidas abordagens de duas reas que tratam da representao de
modelos empresariais mais abrangentes, mas com objetivos distintos: a rea de
Arquitetura Empresarial e a de Organizao e Mtodos.
2.1 Arquitetura empresarial
Segundo um levantamento realizado por Schenherr (2009), o termo arquitetura

empresarial comeou a ser utilizado com mais frequncia em publicaes
acadmicas a partir de 2003 e, pouco depois, por empresas que o relacionam a
produtos e a estratgias. Como se pode esperar de um conceito recente, ainda no
existe uma terminologia comum sobre o assunto at mesmo para definir o que
significa arquitetura empresarial (SCHENHERR, 2009).
Algumas definies de arquitetura empresarial, como as apresentadas por (LEIST;
ZELLNER, 2006), (ROOD, 1994), (SHAH; KOURDI, 2007) e (WHITMAN;
RAMACHANDRAN;
KETKAR,
2001),
seguem
conceito
de
arquitetura,
empregando-o no contexto da empresa. Seguindo o padro ISO/IEC 42010 (ISO,

2007, p.3) que trata de sistemas intensivos de software, a arquitetura " a
organizao fundamental de um sistema abrangendo seus componentes, suas
relaes entre si e com o ambiente e os princpios que guiam seu projeto e a sua
evoluo". Dessa maneira, a arquitetura empresarial permite representar os
elementos essenciais da empresa, sendo, portanto, um modelo especfico dela. Por
exemplo, Rood (1994, p.106) define arquitetura empresarial como "um arcabouo
conceitual que descreve como uma empresa est construda ao definir os
componentes primrios e as relaes entre esses componentes".
Mas, em geral, as definies de arquitetura empresarial possuem uma nfase na
Tecnologia da Informao (TI), seja ao apresentar uma definio orientada a
Na seo 5.1 so discutidos mais detalhes sobre o uso de modelos da empresa nas atividades de
Engenharia de Requisitos.
13
tecnologia ou ao considerar uma viso da arquitetura especfica que trata da TI
(SCHENHERR, 2009). Segundo Laudon e Laudon (2007, p.9) Tecnologia da
Informao "todo software e todo hardware de que uma empresa necessita para
atingir seus objetivos organizacionais". A importncia da TI para a arquitetura
empresarial fica evidente em alguns trabalhos como o de Lankhorst (2009) que
afirma que a arquitetura empresarial captura tanto a essncia do negcio quanto a
essncia da TI. Para esse autor, arquitetura empresarial "um conjunto coerente de
princpios, mtodos e modelos que so usados no projeto e na realizao da
estrutura organizacional, do processo de negcio, dos sistemas de informao e da
infraestrutura da empresa" (LANKHORST, 2009, p.3). Mesmo nos trabalhos que
definem arquitetura empresarial apenas seguindo o conceito de arquitetura, existe
uma relao prxima entre arquitetura empresarial e a TI. Em alguns casos, essa
relao discreta, como, por exemplo, em (ROOD, 1994) que somente enfatiza a
importncia da viso de TI ao apresentar os componentes de uma arquitetura
empresarial. Em outros, a TI um elemento central, como, por exemplo, para Shah
e Kourdi (2007) que afirmam que a arquitetura empresarial a lgica que organiza
os processos de negcio e a infraestrutura de TI.
Em alguns trabalhos a importncia da arquitetura empresarial para a TI tanta que a
definio de arquitetura empresarial voltada para a rea de sistemas de
informao. Por exemplo, Armour, Kaisler e Liu (1999, p.35) definem arquitetura
empresarial como "uma planta para criar sistemas de informao que tratam de toda
a empresa". Mesmo no considerando apenas a TI, Lindstrm et al. (2006) afirmam
que a arquitetura empresarial tem como a principal parte envolvida o CIO (Chief of
Information Officer) da empresa executivo responsvel pela rea de tecnologia de
informao e, por outro lado, o CIO tem como principal ferramenta a arquitetura
empresarial.
Considerando a relao entre a arquitetura empresarial e a rea de TI, diversas das
motivaes para se construir uma arquitetura empresarial tratam de seu uso para a
TI, mas tambm existem motivaes para a empresa de uma forma geral
(ARMOUR; KAISLER; LIU, 1999) (LANKHORST, 2009) (ROOD, 1994) (SHAH;
KOURDI, 2007):
Auxilia o alinhamento entre o negcio e a TI;
14
Facilita a comunicao sobre investimentos de TI;
Permite uma viso integrada sobre os recursos de informao;
Permite descrever novos sistemas de informao ou estratgias para

modernizar sistemas existentes;
Facilita a identificao e desenvolvimento de padres de informao e de

sistemas de informao;
Identifica e remove redundncias tecnolgicas e nos processos de negcio;
Permite a reviso e a reengenharia de processos;
Permite traduzir metas da empresa em operaes;
Captura o conhecimento de empregados e de consultores;
Auxilia a tomada de deciso e o planejamento empresarial;
Permite uma comunicao efetiva sobre a empresa; e
necessria ou til para atender leis e regulamentaes (como os atos

Clinger-Cohen ou Sarbanes-Oxley).
Para construir uma arquitetura empresarial em geral seguido um arcabouo de

arquitetura empresarial. Esses arcabouos facilitam a criao de uma arquitetura
empresarial, segundo Armour, Kaisler e Liu (1999, p.37), ao prover "um conjunto de
modelos,
princpios,
servios,
abordagens,
padres,
conceitos
de
projeto,
componentes e configuraes". Alguns desses arcabouos so especficos para

determinados domnios de aplicao, como o caso do Computer-Integrated
Manufacturing Open Systems Architecture CIMOSA (VERNADAT, 1996), que
voltado para a manufatura, ou mesmo para determinadas organizaes, como o
DoD Architecture Framework DoDAF (DOD, 2010), usado pelo departamento de
Defesa dos Estados Unidos da Amrica, e o Federal Enterprise Framework FEA
(THE EXECUTIVE OFFICE OF THE PRESIDENT OF THE UNITED STATES, 2007),
usado pelo Governo Federal dos Estados Unidos da Amrica. Outros so
independentes do domnio de aplicao e de organizao, como o caso do The
Open Group Architecture Framework (TOGAF) (THE OPEN GROUP, 2009) e o
arcabouo de Zachman (SOWA; ZACHMAN, 1992) (ZACHMAN, 1987).
15
2.2 Organizao e Mtodos

Na rea de conhecimento da administrao, a rea de Organizao e Mtodos 4
(O&M) a tradicionalmente responsvel pela institucionalizao da infraestrutura
necessria para a empresa atingir seus objetivos e pela definio e redefinio dos
processos e dos mtodos de trabalho (CURY, 2007). Para realizar essas atribuies
fundamental a existncia de um modelo da empresa, seja como um meio para
realizar as atividades de melhoria dos processos e dos mtodos administrativos, ou
como o resultado a ser obtido ao se criar um manual administrativo.
Diferentemente dos arcabouos empresariais, o modelo da empresa empregado no
contexto da O&M no considera os sistemas computacionais como um elemento
central, tendo uma viso mais geral da empresa.
No contexto da melhoria dos processos e dos mtodos administrativos, o modelo da
empresa criado durante o levantamento da situao atual da empresa, que serve
como base para as demais atividades de melhoria. Em cada trabalho de O&M
apresentado um mtodo diferente para realizar a melhoria, propondo diferentes
maneiras para levantar a situao atual e, consequentemente, obter diferentes
modelos de empresa. Por exemplo, Oliveira (1994) sugere o seguinte mtodo:
1. Seleo e reconhecimento do que ser analisado;
2. Estudo da viabilidade e alternativas;
3. Levantamento e anlise da situao atual;
4. Delineamento e estruturao do novo sistema;
5. Detalhamento do novo sistema;
6. Treinamento, teste e implantao; e
7. Acompanhamento, avaliao e atualizao.
De uma forma geral, o levantamento da situao atual da empresa envolve a anlise
da documentao existente na empresa, a aplicao de questionrios, a realizao
de entrevistas e a observao do trabalho executado (CURY, 2007), (LERNER,
1992) (OLIVEIRA, 1994). Um exemplo de resultado obtido por esse levantamento,
segundo Oliveira (1994), so as polticas e diretrizes existentes, os organogramas
Tambm chamada de Organizao, Sistemas e Mtodos (OSM).
16
da empresa, os fluxogramas detalhados e os documentos e formulrios existentes
que, assim, constituem um modelo da empresa5.
Normalmente o mesmo mtodo usado para realizar o levantamento da situao
atual da empresa tambm usado pela atividade de criao de um manual
administrativo. Esse manual contm as normas definidas pela empresa e que
formalizam o seu funcionamento (ANDERSON, 1980) (CURY, 2007) (LERNER,
1992) (OLIVEIRA, 1994), podendo ser visto como um modelo da empresa. Dada a
quantidade de informaes que ele prov, o manual pode ser organizado de
diferentes formas dependendo do contexto e dos objetivos da empresa. Segundo
Popper (1972), os principais manuais criados pelas empresas so:
Manual de instrues, que define as normas e polticas administrativas e os

processos executados;
Manual de organizao, que define a estrutura organizacional e as

responsabilidades dos funcionrios;
Manual de formulrios, que define a finalidade, o preenchimento, a

distribuio e o uso dos formulrios;
Manual do funcionrio, que define os direitos e obrigaes dos funcionrios; e
Manual didtico, que define as obrigaes e as tcnicas empregadas por um

determinado cargo.
A criao desses manuais possui algumas vantagens para a empresa, como, por
exemplo, facilitar o treinamento de novos funcionrios, ajudar os funcionrios a
desempenhar suas funes (principalmente aps a sua implantao), promover uma
uniformidade de entendimento do trabalho, ser usado como base para reviso dos
procedimentos existentes e auxiliar os profissionais de O&M a levantar informaes
em outras oportunidades (ANDERSON, 1980). Entretanto, para que esses manuais
sejam teis, eles precisam ser atualizados com frequncia, representando o
conhecimento atual da empresa, e criados por uma equipe com conhecimento do
assunto, o que exige naturalmente tempo e dinheiro seja para cri-lo ou para
mant-lo (ANDERSON, 1980).
Uma anlise mais detalhada do contedo dos modelos de empresa seguindo as abordagens de
O&M apresentada na seo 6.2.1.
17
Apesar das atribuies da O&M para a empresa, segundo um estudo realizado por
Caldas (1999a) (1999b), essa rea est sendo extinta nas empresas e a oferta de
empregos para atividades atribudas a ela est diminuindo. Os motivos para esse
declnio da O&M, segundo o autor, so (CALDAS, 1999a):
A mudana nos modelos de gesto empresariais que no foram

adequadamente absorvidas pela rea de O&M e por seus profissionais;
O desenvolvimento da tecnologia de informao que absorveu parte das

atribuies da O&M e deu acesso direto s informaes e ferramentas que
dependiam da Organizao e Mtodos para serem acessadas;
O aumento do ritmo de mudanas na empresa (causadas pelo aumento de

competitividade do mercado) que no conseguiu ser controlado pelas reas
de O&M; e
A autodeteriorao da Organizao e Mtodos devido centralizao de suas

atribuies, ao seu embasamento em modelos de gesto incompatveis com o
novo ambiente de negcio e falha em se adaptar s mudanas.
Com isso, essas atividades foram absorvidas pelas reas de computao, recursos
humanos e qualidade dentro da empresa e por consultores externos a ela (Caldas,
1999b).
2.3 Concluso
Uma empresa pode ser representada atravs de diferentes modelos que cobrem as
informaes relevantes sobre a empresa seguindo uma viso especfica. Um desses
modelos, a arquitetura empresarial, trata tanto de aspectos do negcio quanto de
aspectos de Tecnologia de Informao. Na rea de Organizao e Mtodos
definido um modelo da empresa com enfoque organizacional, que no considera
detalhes sobre os sistemas de informao existentes.
Este trabalho usa um modelo da empresa como modelo dos requisitos. Com isso, no
captulo seguinte ser discutido o que requisito, alm de apresentar o quadro de
referncia de requisitos que usado.
18
3 REQUISITO, ESPECIFICAO E SUAS REPRESENTAES

Uma empresa pode ser vista como um sistema (CHIAVENATO, 2000), ou seja, uma
"combinao de elementos que interagem organizados para atingir um ou mais
propsitos declarados" (ISO, 2008). Os propsitos declarados so aqueles
estabelecidos por sua misso; os elementos so seus funcionrios, suas
instalaes, suas mquinas, seus processos etc.
Ao planejar a substituio de qualquer um dos elementos da empresa preciso
entender o que ser necessrio para o novo elemento e tambm analisar o impacto
que essa mudana causa no sistema como um todo principalmente ao considerar
a misso definida. Quando a substituio envolve a automao de processos
empresariais atravs de sistemas computacionais, essas atividades de planejamento
so comumente realizadas no contexto da disciplina de Engenharia de Requisitos. O
principal resultado das atividades dessa disciplina, e que precisa ser continuamente
gerenciado, um conjunto de requisitos que buscam expressar o que necessrio
para o sistema computacional a ser construdo6.
3.1 Definies
Existem diversos termos que buscam representar as mltiplas vises do que um

requisito e tambm diferenciar outras informaes relevantes para a disciplina de
Engenharia de Requisitos. Com isso, definem-se termos como especificao,
funcionalidade, funo, necessidade, conhecimento do domnio, entre outros, alm
de requisito. Conforme a necessidade alguns desses termos sero definidos no
decorrer deste trabalho, entretanto dois deles sero mais bem detalhados, uma vez
que os conceitos que eles representam so fundamentais para o objetivo do
trabalho: requisito e especificao.
Dentre os diversos significados de requisito e de especificao, este trabalho
diferenciar esses dois termos seguindo as ideias apresentadas por Jackson e Zave
6
Como o foco principal deste trabalho so sistemas computacionais, ser usado o termo sistema
significando sistema computacional, enquanto que o termo sistemas em geral ser usado para se
referir a sistema do ponto de vista da (ISO, 2008).
19
(JACKSON, 1995) (JACKSON, 1997) (JACKSON, ZAVE; 1995) (ZAVE; JACKSON,
1997), seguindo como quadro de referncia o modelo WRSPM (chamado assim pelo
nome dos artefatos definidos: World, Requirement, Specification, Platform e
Machine) 7 (GUNTER et al., 2000), apresentado na Figura 3.1. Esse modelo tem
como objetivo definir uma base comum para discutir os atributos e as relaes entre
cinco artefatos e para isso os agrupa considerando a sua relevncia ao ambiente, a
parte do mundo em que o sistema ir interagir e na qual os efeitos do sistema sero
observados e avaliados (JACKSON, 1997), ou ao sistema. Esses artefatos so:
O conhecimento do domnio que possui informaes conhecidas e

assumidas sobre o ambiente;
Os requisitos que indicam o que os clientes desejam do sistema, descrito na

forma de efeitos no ambiente;
A especificao que permite que o sistema seja construdo satisfazendo os

requisitos;
O programa que implementa a especificao; e
A plataforma que permite programar o sistema.

Especificao
Conhecimento
do domnio
Requisito
Ambiente
Programa
Plataforma
Sistema
Figura 3.1: O modelo WRSPM, evidenciando os cinco artefatos por ele definidos (GUNTER et al.,
2000).
Cada um desses artefatos pode ser visto como uma descrio que usa um
vocabulrio especfico de diferentes termos primitivos. Entretanto, alguns desses
termos so compartilhados entre os artefatos, uma vez que os fenmenos que eles
buscam denotar tambm o so. Esses fenmenos representados como pontos na
figura representam estados, eventos e indivduos e so organizados em 4 classes
pelo modelo: os que pertencem ao ambiente e so visveis ou invisveis ao sistema
7
O modelo WRSPM apresenta algumas diferenas em relao aos demais trabalhos de Jackson e
Zave, apesar de seguirem a mesma viso a respeito de requisito e de especificao. Duas dessas
diferenas so importantes para este trabalho: o fato do WRSPM tratar de artefatos ao invs de
afirmaes e o emprego de uma terminologia mais elaborada (j que ele pretende ser um modelo de
referncia). Como neste trabalho se pretende tratar de afirmaes e ainda assim empregar a
terminologia do WRSPM, o modelo aqui adaptado.
20
e, da mesma forma, os que pertencem ao sistema e so visveis ou invisveis ao
ambiente. Seguindo essa diviso, apenas os fenmenos visveis so compartilhados
entre o ambiente e o sistema. Por exemplo, em um sistema computacional de
controle de venda de uma livraria, o fenmeno do ambiente invisvel ao sistema a
chegada de novos livros na livraria; um fenmeno do ambiente visvel a digitao
da nova quantidade de um determinado livro; um fenmeno do sistema visvel ao
ambiente a alterao da quantidade disponvel de livros; e por fim, um fenmeno
do sistema invisvel a mudana do valor de um registro no banco de dados
referente quantidade de livros.
Dadas essas classes de fenmenos, o artefato "conhecimento do domnio" restringe
os fenmenos que pertencem ao ambiente, o que permite definir o ambiente em si.
Alm disso, ele tambm pode restringir a relao entre fenmenos que pertencem
ao ambiente e aqueles que pertencem ao sistema e so visveis ao ambiente
(GUNTER et al., 2000), como, no caso de um sistema de controle de venda de uma
livraria, a restrio de que ao vender o livro, a quantidade de livros disponveis
diminui. O artefato "requisito" adiciona outras restries quelas definidas pelo
artefato "conhecimento do domnio" ao considerar o que os clientes desejam ou
seja, os requisitos so decididos pelo cliente (JACKSON; ZAVE, 1995). Usando
novamente o sistema de controle de vendas de uma livraria como exemplo, uma
restrio de o cliente comprar no mximo 10 livros por vez faria parte do artefato
"requisito". No outro extremo, o artefato "plataforma" restringe os fenmenos que
podem ser realizados pelo sistema enquanto que o artefato "programa" descreve
uma classe de possveis fenmenos do sistema considerando o programa em si.
Entre o ambiente e o sistema existe o artefato "especificao" que usa o vocabulrio
comum entre os dois para definir o que o sistema deve realizar considerando o
ambiente. A partir dessas ideias o modelo WRSPM define um conjunto de
propriedades, relacionando formalmente esses artefatos.
Em vez de tratar especificamente dos artefatos "conhecimento do domnio",
"requisito" e "especificao" propostos pelo modelo WRSPM, este trabalho aborda o
contedo deles. Cada artefato considerado aqui como composto de um conjunto
de afirmaes, chamadas de conhecimentos do domnio para o artefato
"conhecimento do domnio", requisitos para o artefato "requisito" e especificaes
para
artefato
"especificao".
Considerando
importncia
do
artefato
21
"especificao" e buscando evitar ambiguidades, ele ser daqui em diante chamado
de "especificao de requisitos". Dessa maneira, os requisitos so restries sobre
os fenmenos do ambiente, enquanto que as especificaes so um tipo especfico
de requisitos, considerando apenas os fenmenos compartilhados entre o ambiente
e o sistema (JACKSON, 1995). Com isso os requisitos so definidos como
afirmaes que descrevem "o ambiente como gostaramos que ele fosse e como
esperamos que ele seja quando mquina estiver conectada com o ambiente" (ZAVE;
JACKSON, 1997, p.7), o que so as afirmaes no modo optativo 8 . Uma
consequncia dessa definio que os requisitos devem tratar apenas do ambiente
e nada mais que isso (ZAVE; JACKSON, 1997) , o que fica claro no modelo
WRSPM. Essa afirmao segue a ideia de que os requisitos e a especificao no
devem tratar de uma soluo computacional especfica, mas do propsito do
sistema ao considerar o domnio de aplicao e o uso pretendido (JACKSON, 1995).
A especificao deve permitir que a equipe de desenvolvimento escolha a forma
mais adequada para implementar o sistema, sem restringi-lo desnecessariamente
(GILB, 1997) (IEEE, 1998) (LEFFINGWELL; WIDRIG, 2003) (WIEGERS, 2003)
(ZAVE; JACKSON, 1997).
Por mais que os requisitos e as especificaes devam seguir a ideia de tratar
apenas do propsito do sistema, nem sempre possvel fazer com que eles se
limitem ao ambiente. Segundo Kotonya e Sommerville (1998) algumas vezes
necessrio que os requisitos tratem de como o sistema ser implementado por trs
motivos principais: (1) porque as declaraes do problema podem ser abstratas
demais para que os leitores dos requisitos as entendam, (2) porque o sistema
precisa ser compatvel com outros sistemas em geral existentes, estar em
conformidade com outros sistemas em geral e considerar algumas preocupaes
organizacionais e (3) porque como geralmente os especificadores so especialistas
do domnio de aplicao, os requisitos podem ser definidos como descries de
como realizar a computao usando dados do domnio de aplicao. Um exemplo
disso a existncia de uma poltica na empresa que obriga a usar uma determinada
linguagem de programao em todos os seus softwares como era o caso do
8
Alm das afirmaes sobre o ambiente no modo optativo, Zave e Jackson tambm definem as
afirmaes no modo indicativo que descrevem o ambiente como ele na ausncia da mquina e
sem considerar as aes da mquina (1997, p.7). Esse tipo de afirmao representaria os fatos
assumidos, ou conhecimento do domnio.
22
departamento de defesa dos Estados Unidos da Amrica que obrigava o uso da
linguagem Ada at o fim da dcada de 1990 (LEFFINGWELL; WIDRIG, 2003). De
alguma forma essa poltica deve ser considerada como um requisito, j que o
sistema a ser construdo precisa obrigatoriamente atend-la. Devido sua diferena
de natureza, alguns autores chegam a classificar esse tipo de restrio como um
outro tipo de requisito: restries de projeto (LEFFINGWELL; WIDRIG, 2003) ou
restries de soluo (ROBERTSON; ROBERTSON, 2006). Independente de como
essas restries so chamadas, o relevante para este trabalho que os requisitos
tratam do ambiente e do sistema, mesmo que o foco deva ser no ambiente. Por
causa disso, a definio de requisitos usada neste trabalho tambm considera essas
restries, ainda que seguindo a filosofia do modelo WRSPM. Com isso requisito
definido seguindo a definio proposta pela IEEE (1990, p.172)9:
a) Uma condio ou capacidade necessria por um usurio para resolver um
problema ou atingir um objetivo.
b) Uma condio ou capacidade que deve ser cumprida ou possuda por um
sistema ou componente do sistema para satisfazer um contrato, padro,
especificao, ou outros documentos formalmente impostos.
Por mais que essa definio trate das origens e das fontes dos requisitos e no do
ambiente em si, h uma relao direta dessa definio com a viso de requisito
seguida pelo modelo WRSPM. Na clusula (a) as condies ou capacidades
representam afirmaes sobre o ambiente sob a perspectiva dos usurios,
considerando seus objetivos e as formas para resolver seus problemas. Ainda que o
termo usurio denote a presena de um sistema, o seu uso pode ser interpretado
como apenas uma forma de delimitar o ambiente considerado, sem fazer afirmaes
especficas sobre o sistema em si. Em compensao, na clusula (b) da definio, o
sistema em si explicitado: so condies ou capacidades do sistema ou de seus
componentes. Mesmo que isso ainda possa ser usado para definir o ambiente
pretendido, tambm possvel descrever aspectos especficos da soluo
9
Na definio da IEEE (1990) existe ainda uma outra interpretao de requisito que no foi
considerada: uma representao documentada de uma condio ou capacidade como em (a) ou (b)
(IEEE, 1990, p.172). O problema dessa interpretao que ela confunde o conceito de requisito com
a representao dele. Para evitar essa ambiguidade, neste trabalho ser empregado o termo
representao de requisitos para designar o termo requisito segundo essa interpretao presente na
norma.
23
computacional,
permitindo
tratar
das
restries
que
tambm
devem
ser
consideradas como requisitos.

Considerando a definio de requisito, preferiu-se adotar uma definio de
especificao mais ampla, que no referencia diretamente a fronteira entre o
ambiente e a mquina uma vez que os requisitos tambm podem representar
condies ou capacidades internas ao sistema. Dessa forma, a especificao
definida aqui como (JACKSON; ZAVE, 1995):
Um tipo de requisito refinado ao remover todas as caractersticas que impedem
que ele seja implementado.
A especificao , portanto, um requisito que no necessita de nenhuma informao

adicional para que a equipe de desenvolvimento o utilize para as prximas
atividades do processo adotado (como, por exemplo, as atividades de anlise,
projeto, implementao etc.). Ela descreve caractersticas do sistema desejado no
ambiente (JACKSON; ZAVE, 1995), tratando de fenmenos compartilhados entre o
ambiente e o sistema, alm de considerando a definio de requisitos adotada
detalhes internos do sistema.
Os requisitos que tratam de detalhes internos do sistema so, por essa definio,
especificaes. Mas alm deles, alguns outros requisitos podem j estar em um
nvel de detalhamento suficiente para que eles sejam vistos como especificaes.
Outros requisitos, entretanto, precisam ser detalhados em especificaes, o que
feito em um processo chamado de refinamento (JACKSON; ZAVE, 1995) (JIN, 2006)
(ZAVE; JACKSON, 1997). Esse processo consiste em dois passos: "(1) identificar os
aspectos de um requisito que no podem ser garantidos ou efetuados por um
computador sozinho e (2) detalh-los ou troc-los at que sejam completamente
implementveis" (ZAVE; JACKSON, 1997, p.19). Em relao ao primeiro passo,
segundo Zave e Jackson (1997) existe trs razes principais para no considerar um
requisito como especificao:
Eles restringem fenmenos controlados pelo ambiente, ao invs de restringir

fenmenos controlados pelo sistema;
Eles so descritos em termos de fenmenos no compartilhados (no visveis

ao sistema); e
Eles so descritos em termos do futuro.
24
Para esses trs casos, a soluo para obter especificaes envolve o emprego do
conhecimento do domnio, de diferentes formas. O emprego desse conhecimento
permite delimitar melhor o espao do problema, definindo a fronteira entre o
ambiente e o sistema. Entretanto, de uma forma geral no se tem uma nica opo
de refinamento possvel, mas diversas alternativas. Cada alternativa pode causar um
impacto diferente no sistema pretendido, influenciando de diferentes formas os
resultados desejados (de negcio ou tcnicos) (MYLOPOLOUS et al., 2001) ou
mesmo afetando o projeto em si (o tempo, o custo ou a equipe necessria). Por mais
que cada alternativa possa restringir de forma diferente o espao de soluo, elas
representam opes diferentes de o que o sistema deve fazer. Dessa forma, as
alternativas devem ser discutidas com as partes envolvidas, avaliadas frente aos
resultados desejados estabelecidos e negociados com os tomadores de deciso
(VAN LAMSWEERDE, 2009). Segundo Mylopoulos et al. (2001), uma maneira de
capturar e avaliar alternativas nos requisitos empregar tcnicas de anlise
orientadas por metas (discutidas na seo 3.3).
Um exemplo de alternativas de detalhamento pode ser visto em (MAIDEN, 2008),
durante a discusso sobre a diferena entre requisitos e especificaes. Um
requisito descrito textualmente seria: "um usurio de um sistema de aprendizado
baseado em trabalho deve ser capaz de localizar uma pessoa que responsvel por
um documento" (MAIDEN, 2008, p.90). Por mais que esse requisito seja o que as
partes envolvidas esperam do sistema, para a implementao essa afirmao ainda
vaga. O sistema pode localizar a pessoa de diversas formas, por exemplo, ao
informar um telefone, uma sala, ou at mesmo atravs de um mapa que apresenta a
localizao de onde a pessoa est naquele momento. Ainda que essas trs opes
sejam vlidas considerando esse requisito, o mapa poderia afetar negativamente a
privacidade das pessoas (que pode ser um outro requisito), ou a sala poderia ser
vista como uma soluo imprecisa demais. Com isso, o requisito poderia ser
detalhado para algo como "o sistema de aprendizado baseado em trabalho deve
retornar o nome e os dados de contato da pessoa responsvel por um determinado
documento" (MAIDEN, 2008, p.90). interessante notar que mesmo esse
detalhamento pode ser ainda vago, j que o termo dados de contato pode ser ainda
impreciso. Caso no haja um conhecimento do domnio que defina o que isso
exatamente significa para esse contexto, a afirmao ainda um requisito e no
25
uma especificao. Ou seja, possvel ter diferentes nveis de detalhamento de um
requisito, sendo que a especificao o nvel de detalhamento em que no existem
mais alternativas, permitindo seu uso pelas prximas atividades de desenvolvimento.
Por fim, considerando que especificao tambm um requisito, neste trabalho
usado o termo requisito para representar o termo geral, englobando tambm a
especificao. Para representar os requisitos sem considerar as especificaes,
ser empregado o termo requisitos no refinados. Alguns autores chamam os
conceitos aqui referidos como requisito no refinado e especificao por outros
nomes como, por exemplo, requisitos do usurio e requisitos de sistema (ou de
software) (GOTTESDIENER, 2008) (MAIDEN, 2008) (WIEGERS, 2003), metas e
requisitos (VAN LAMSWEERDE, 2009), requisitos de alto-nvel e requisitos de
negcio e tecnolgicos (ROBERTSON; ROBERTSON, 2006). Alm disso, em alguns
trabalhos o termo especificao se refere documentao dos requisitos (IEEE,
1990) (LEFFINGWELL; WIDRIG, 2003) (VAN LAMSWEERDE, 2009), muitas vezes
possuindo um ponto de vista mais formal (seja de linguagens formais ou de acordo
com as partes envolvidas).
3.2 Engenharia de Requisitos
Os requisitos e as especificaes so tratados, em geral, por atividades que fazem

parte da disciplina de Engenharia de Requisitos. Em especial no contexto dessa
disciplina que os requisitos so elicitados e posteriormente refinados em
especificaes. Dentre as diversas definies de Engenharia de Requisitos e de
quais so suas responsabilidades, comum evidenciar a importncia do ponto de
vista prtico, sistemtico e repetvel a ela necessrio como feito nas definies
apresentadas por (HSIA; DAVIS; KUNG, 1993), (GILB, 1997) (SOMMERVILLE;
SAWYER, 1997) e (VAN LAMSWEERDE, 2009) , o que faz essa disciplina ser uma
Engenharia. Na definio apresentada por Hsia, Davis e Kung (1993, p.75), por
exemplo, Engenharia de Requisitos definida como "a aplicao disciplinada de
princpios,
mtodos,
ferramentas
notaes
provadas
para
descrever
comportamento pretendido do sistema proposto e suas restries associadas".
26
Em alguns outros trabalhos, como (BUBENKO JR., 1995), (VAN LAMSWEERDE,
2009) e (ZAVE, 1997), a definio de Engenharia de Requisitos evidencia a
importncia do ambiente, reforando a ideia de requisito. Zave (1997, p.315), por
exemplo, define Engenharia de Requisitos como "um ramo de engenharia de
software preocupada com as metas do mundo real para funes e restries de
sistemas de software. Ela tambm est preocupada com o relacionamento desses
fatores com a especificao precisa do comportamento do software e a sua
evoluo no tempo e atravs de famlias de software".
Outras definies tratam das responsabilidades envolvidas na Engenharia de
Requisitos, algumas vezes de forma superficial. Por exemplo, na definio
apresentada por Wiegers (2003, p.488), Engenharia de Requisitos "o domnio que
abrange todas as atividades do ciclo de vida de um projeto associadas com o
entendimento das capacidades e dos atributos necessrios ao produto". Em outras
definies as responsabilidades so mais detalhadas, como, por exemplo, na
definio apresentada por van Lamsweerde (2009, p.6) em que Engenharia de
Requisitos "um conjunto coordenado de atividades para explorar, avaliar,
documentar, consolidar, revisar e adaptar os objetivos, capacidades, qualidades,
restries e fatos assumidos que o sistema a ser construdo (to-be) deve satisfazer
baseado em problemas levantados pelo sistema atual (as-is) e oportunidades
providas por novas tecnologias".
Neste trabalho ser usada a definio apresentada por Sommerville e Sawyer (1997,
p.5), na qual Engenharia de Requisitos :
A disciplina que cobre "todas as atividades envolvidas em descobrir, documentar e
manter um conjunto de requisitos para um sistema baseado em computador".
No h um consenso em quais so exatamente essas atividades, mas em geral as

seguintes atividades esto presentes (HSIA; DAVIS; KUNG, 1993) (KAVAKLI;
LOUCOPOULOS, 2005) (NUSEIBEH; EASTERBROOK, 2000) (SOMMERVILLE;
SAWYER, 1997) (VAN LAMSWEERDE, 2009):
Elicitao: trata da descoberta dos requisitos, podendo ser realizada ao

aplicar diferentes tcnicas, como, por exemplo, a aplicao de questionrios,
prototipao ou anlise do ambiente (NUSEIBEH; EASTERBROOK, 2000);
27
Anlise e negociao: trata da anlise dos requisitos elicitados considerando

conflitos, riscos, alternativas e prioridades (VAN LAMSWEERDE, 2009) e a
negociao dos requisitos com as partes envolvidas, em busca de um acordo.
Documentao: trata da criao do documento de especificao de

requisitos, que serve como uma declarao oficial para as partes envolvidas
de quais so as especificaes (SOMMERVILLE; SAWYER, 1997); e
Consolidao: trata da verificao dos requisitos definidos e da validao

deles com as partes envolvidas.
Considerando o quadro de referncia de requisitos considerado por este trabalho, o

modelo WRSPM, durante a atividade de anlise e negociao que as
especificaes so obtidas a partir dos requisitos.
Alm dessas atividades que esto inseridas no processo de desenvolvimento de
sistemas, tambm existe a Gerncia dos Requisitos (CMMI PRODUCT TEAM, 2010)
(SOMMERVILLE; SAWYER, 1997). Ela um processo executado em paralelo que
gerencia as mudanas nos requisitos, tratando de sua evoluo.
3.3 Engenharia de Requisitos orientada por metas
Nos projetos em que o sistema computacional faz parte de um ambiente

organizacional, os requisitos no devem ser afirmaes sobre o ambiente atual, mas
do ambiente que se pretende obter. Com isso, antes de definir os requisitos do
sistema computacional necessrio projetar esse novo ambiente, definindo de
alguma forma as responsabilidades dos diversos elementos que faro parte dele.
Algumas abordagens de Engenharia de Requisitos adotam uma premissa que a
definio desse novo ambiente, em especial as responsabilidades do sistema
computacional a ser construdo, de responsabilidade da Engenharia de Requisitos
(KAVAKLI; LOUCOPOULOS, 2005) (VAN LAMSWEERDE, 2001). Antes de elicitar
os requisitos, alguma atividade deve considerar como o sistema pretendido atinge os
resultados organizacionais desejados, entendendo o como e, principalmente, o
porqu dos requisitos obtidos (YU, 1995). Com isso seria possvel obter requisitos
mais significativos (ROLLAND; SALINESI, 2005), que representariam de forma mais
apropriada as necessidades pretendidas do novo ambiente. Para isso, essas
abordagens de Engenharia de Requisitos propem a modelagem de metas, sendo
28
que o uso de metas para realizar as atividades Engenharia de Requisitos o que se
chama de Engenharia de Requisitos orientada por metas (GORE Goal Oriented
Requirements Engineering) (VAN LAMSWEERDE, 2009).
Uma meta nesse contexto "um objetivo que o sistema sob considerao deveria
atingir" (VAN LAMSWEERDE, 2001, p.250) 10 . Dessa forma, uma meta pode se
referir desde a objetivos organizacionais e resultados estratgicos a serem obtidos
(em metas de alto nvel) a at detalhes tcnicos que uma determinada parte do
sistema deve atender (ROLLAND; SALINESI, 2005) (VAN LAMSWEERDE, 2009).
Mesmo as metas de mais baixo nvel no definem como elas sero atingidas,
podendo assim existir diversas alternativas a serem consideradas (YU, 1995).
Dependendo da meta pode at ser difcil avaliar se uma determinada alternativa
realmente a satisfaz essas metas que no tm um critrio claro de satisfao so
chamadas de metas flexveis (softgoals), em contraposio a metas concretas
(hardgoals) (BRESCIANI et al., 2004) (YU, 1995).
Para satisfazer uma meta necessria a cooperao de diversos agentes
(DARDENNE; VAN LAMSWEERDE; FICKAS, 1993). Um agente "um componente
ativo do sistema realizando um papel especfico na satisfao de uma meta" (VAN
LAMSWEERDE, 2009, p.260), podendo assim representar uma pessoa, um software
ou um sistema em geral. Para obter especificaes a partir das metas necessrio
refinar as metas de mais alto nvel, o que feito atravs de rvores E/OU
(ROLLAND; SALINESI, 2005) (VAN LAMSWEERDE, 2009), que tambm podem ser
vistas como diagramas de metas. Essas rvores representam relaes entre as
metas, sendo que as metas podem ser decompostas de forma que todas as metas
de mais baixo nvel precisam ser satisfeitas para que a meta de mais alto nvel seja
satisfeita (decomposio E), ou que apenas uma das metas de baixo nvel precise
ser satisfeita para que a meta de mais alto nvel seja satisfeita (decomposio OU).
Essas decomposies presentes nos diagramas de metas permitem representar as
alternativas de refinamento dos requisitos, enquanto que informaes de correlao
entre as metas permitem analisar como as alternativas tratam das metas envolvidas
10
A definio de meta seguida por mtodos GORE no a mesma seguida por alguns modelos com
ponto de vista de negcio, como o BMM (OMG, 2008a). A fim de evitar ambiguidades e ainda seguir
os termos usados pelas abordagens GORE, nesta seo ser usado apenas o termo meta, mas no
restante do trabalho se usar o termo meta GORE para referenciar o conceito de meta nesse tipo de
abordagem.
29
(MYLOPOULOS et al., 2001). Uma outra forma de representar as alternativas na
atribuio das metas a agentes, representando os possveis agentes que podem ser
responsveis por uma determinada meta (VAN LAMSWEERDE, 2009).
Como apenas a relao de decomposio entre as metas pode ser insuficiente para
o uso nas atividades de Engenharia de Requisitos, como, por exemplo, para a
anlise de alternativas, os diagramas de metas representam alguns outros
elementos e outras formas de relacionamentos entre eles (YAMAMOTO et al., 2006).
Esses elementos e relacionamentos, assim como a forma de refinamento das metas,
variam dependendo da abordagem GORE empregada.
3.3.1 Abordagens orientadas por metas
Entre as abordagens orientadas por metas pode-se citar KAOS, i*, Tropos, B-SCP,
Map e EKD.
KAOS11 um mtodo GORE para "elicitar, especificar e analisar metas, requisitos,
cenrios e atribuies de responsabilidades" (VAN LAMSWEERDE, 2001, p.8). Para
isso ele possui trs componentes (DARDENNE; VAN LAMSWEERDE; FICKAS,
1993): um modelo conceitual, um conjunto de estratgias e uma ferramenta. O
modelo conceitual permite adquirir e estruturar modelos de requisitos, sendo
composto por cinco submodelos 12 (RESPECT-IT, 2007) (VAN LAMSWEERDE,
2009): de metas, de objetos, de responsabilidade, de operao e de comportamento.
Esse modelo conceitual usado para elaborar um modelo dos requisitos ao
empregar um conjunto de estratgias que o mtodo empregado pelo KAOS,
descrito em (VAN LAMSWEERDE, 2009). As atividades propostas por esse mtodo
consideram algumas heursticas e um conjunto de critrios para analisar a
completude dos modelos criados, o que apresentado em (RESPECT-IT, 2007).
Por fim, o ltimo componente do mtodo KAOS uma ferramenta (DELOR;
DARIMOND; RIFAUT, 2003), que guia o processo de aquisio de requisitos. Ela
11
A sigla KAOS aparece com dois significados distintos: aquisio de conhecimento em

especificao automatizada (Knowledge Acquisition in Automated Specification) (DARDENNE; VAN
LAMSWEERDE; FICKAS, 1993) e mantenha todos os objetivos satisfeitos (Keep All Objectives
Satisfied) (VAN LASWEERDE, 2004) (VAN LAMSWEERDE; LETIER, 2004).
12
O modelo de comportamento apenas considerado em (VAN LAMSWEERDE, 2009).
30
permite criar diagramas para cada um dos modelos, alm de outras funcionalidades,
como por exemplo, gerar um documento de especificao de requisitos (RESPECTIT, 2007).
O i* (significando intencionalidade distribuda) um arcabouo para modelagem de
processos e para analisar e reprojetar processos que pode ser usado para diversos
fins, como, por exemplo, para a Engenharia de Requisitos, reengenharia, anlise de
impacto organizacional, modelagem de processos de software, entre outros (YU,
1995). Na rea de Engenharia de Requisitos, o i* trata da fase de requisitos iniciais,
que anterior formulao dos requisitos. Por ser um arcabouo, o i* no define um
mtodo para realizar as atividades de requisitos iniciais ou mesmo para seus outros
possveis usos. Ele apenas define dois modelos: o modelo de dependncia
estratgica e o modelo de razo estratgica. O modelo de dependncia estratgica
representa uma rede de dependncias entre os atores envolvidos em um processo.
Essas dependncias podem ser por recursos, tarefas, metas e metas flexveis,
sendo que um ator depende de outro para atingir alguma meta. Com isso, as
dependncias so estratgicas uma vez que representam oportunidades e
vulnerabilidades que fazem com que cada participante pense em seus interesses
(YU; MYLOPOULOS; LESPERANCE, 1996). No modelo de razo estratgica os
atores so representados de uma forma mais detalhada, com o objetivo de permitir a
anlise de diferentes alternativas de processos e auxiliar a definio de processos
mais adequados (YU, 1995). Dessa forma so representadas as relaes
intencionais internas aos atores, considerando suas tarefas, recursos, metas e
metas flexveis e relacionando-as atravs de relaes meio-fim e de decomposio
de tarefas s dependncias existentes com os outros atores.
Tropos um mtodo de desenvolvimento de software que segue o paradigma
orientado a agentes. Esse paradigma permite trabalhar com abstraes no nvel do
conhecimento como agentes, metas, planos e desejos, ao invs de abstraes
computacionais (BRESCIANI et al., 2004). Ao empreg-lo seria possvel criar uma
arquitetura aberta e evolutiva, em que os agentes podem lidar com situaes
imprevistas (MYLOPOULOS; KOLP; CASTRO, 2001). O mtodo dividido em cinco
fases (BRESCIANI et al., 2004) (MYLOPOULOS; KOLP; CASTRO, 2001): requisitos
iniciais, requisitos finais, projeto arquitetnico, projeto detalhado e implementao.
Um ponto central desse mtodo a nfase nas atividades da fase de requisitos
31
iniciais, o que feito usado o arcabouo i*, com algumas alteraes13. O uso do i*
permite que os desenvolvedores trabalhem desde o incio das atividades de
desenvolvimento com conceitos do nvel do conhecimento (BRESCIANI et al., 2004).
O B-SCP (Business Strategy, Context, and Process) um arcabouo para anlise
de requisitos que tem como objetivo permitir "a verificao e validao dos requisitos
em termos do alinhamento e do suporte estratgia de negcio e dos processos de
negcio que apoiam essa estratgia" (BLEISTEIN et al., 2006, p.847). Para isso ele
considera a estratgia de negcio, o contexto de negcio e o processo de negcio,
que so chamados de temas. Para cada um desses temas utilizada uma
abordagem especfica, sendo que o arcabouo permite a juno delas. A estratgia
de negcio representa como a empresa pretende usar a tecnologia de informao
do ponto de vista competitivo (BLEISTEIN et al., 2006), sendo usada como base a
representao do arcabouo i* (YU, 1995) mapeando-a a conceitos do BMM
(Business Motivation Model) (OMG, 2008a). Em relao ao contexto de negcio, ele
representa o ambiente de negcio no qual a organizao opera, sendo utilizado para
isso os diagramas de contexto de Jackson (JACKSON, 1995). Por fim, o processo
de negcio representa as atividades, os papis, os recursos, as entidades e a
interao entre eles, sendo usado o RAD (role activity diagram) (OULD, 1995). Para
aplicar o B-SCP no apresentado claramente um mtodo, sendo apenas descrito
em (BLEISTEIN; COX E VERNER, 2005) e (BLEISTEIN et al., 2006) um exemplo no
qual o arcabouo aplicado.
O Map (Intention/Strategy Map) um sistema de representao que segue a filosofia
da Engenharia de Requisitos orientada por metas, mas que, diferentemente das
outras abordagens GORE, considera a estratgia como forma para se atingir as
metas (ROLLAND, 2007). A motivao para isso , entre outras (ROLLAND, 2007),
captar a variabilidade dos sistemas no nvel de metas, j que podem existir diversas
estratgias que permitem alcanar uma mesma meta. Com isso seria possvel
representar de forma mais adequada a necessidade de os sistemas atenderem
13
Certas alteraes so apenas em relao terminologia, como o caso dos modelos de

dependncia estratgica e de razo estratgica do i* que so chamados de diagrama de ator e
diagrama de metas, respectivamente. Entretanto, tambm existem alteraes semnticas. Por
exemplo, a tarefa do i* chamada de plano, representando abstratamente a forma de fazer algo
(BRESCIANI et al., 2004). Tambm so propostos dois novos conceitos, a capacidade,
representando a habilidade de o agente definir, escolher e executar um plano, e a crena,
representando o conhecimento do mundo que o ator possui (BRESCIANI et al., 2004).
32
diferentes organizaes e clientes, adaptando-se a eles (ROLLAND; SALINESI,
2005). De forma geral, um Map um grafo em que os ns so intenes e os arcos
so estratgias, sendo que seu metamodelo apresentado em (ROLLAND, 2007).
Uma inteno so metas atingidas atravs da execuo de um processo, sendo
representadas atravs de um verbo, um alvo e um conjunto de parmetros
(ROLLAND, 2007). A partir de uma inteno definida uma abordagem, uma
maneira ou um meio para alcanar uma outra inteno, que so as estratgias
(ROLLAND, 2007). Assim, possvel expressar a variabilidade do sistema j que
uma inteno pode ser alcanada a partir de diferentes estratgias e at mesmo a
partir de diferentes intenes de origem. Apesar de no ser apresentado um mtodo
claro para se criar um Map, Rolland e Salinesi (2005) propem estratgias gerais
para sua criao. Porm, no claro como se pode obter os requisitos a partir de
um Map, uma vez que ele trata de metas de alto nvel e, principalmente, das
possveis estratgias que podem ser empregadas.
Por fim, o Enterprise Knowledge Development (EKD) um mtodo para modelagem
empresarial que prov "uma forma sistemtica e controlada para analisar, entender,
desenvolver e documentar uma empresa e seus componentes" (BUBENKO JR. et
al., 1998, p.18), o que permite a empresa desenvolver formas para implementar
mudanas (KAVAKLI; LOUCOPOULOS, 1999). Com isso, o EKD define um mtodo
de modelagem e um modelo a serem usados para a representao da empresa. O
modelo empresarial definido pelo EKD composto por seis submodelos que so
inter-relacionados (BUBENKO JR. et al., 1998) (STIRNA; PERSSON, 2007): o
modelo de metas, o modelo de regras de negcio, modelo de conceitos, modelo de
processos de negcio, modelo de atores e recursos e modelo de componentes
tcnicos e requisitos. Um aspecto central do EKD a representao dos interrelacionamentos entre esses modelos, o que permite que eles sejam rastreveis
(BUBENKO JR. et al., 1998). Isso permite representar, por exemplo, quais processos
de negcio cumprem um determinado objetivo de negcio ou mesmo quais regras
de negcio restringem os requisitos do sistema de informao. Para criar o modelo
da empresa, o EKD define um mtodo de modelagem que enfatiza a colaborao
entre os participantes. Apesar de ser um mtodo de modelagem empresarial, o fato
de ele considerar um modelo de bsico de requisitos para sistemas de informao
33
entre os submodelos de empresa e enfatizar a modelagem de metas, faz com que
ele tambm possa ser visto como uma abordagem GORE.
3.3.2 Vantagens e desvantagens de abordagens GORE
O emprego de abordagens orientadas por metas, assim como qualquer abordagem,

possui vantagens e desvantagens para as atividades de Engenharia de Requisitos.
Como exemplo das vantagens do emprego de metas pode-se citar (VAN
LAMSWEERDE, 2009):
O refinamento de metas prov um mecanismo para estruturar especificaes

complexas em diferentes nveis de preocupao;
Metas proveem a razo para os requisitos;
Metas dirigem a identificao de requisitos que as apoiam;
A relao entre as metas permite definir uma cadeia de argumentos de

satisfao das necessidades;
Metas proveem uma base para mostrar o alinhamento do sistema a ser

construdo com os objetivos estratgicos da organizao;
O uso de metas permite definir um critrio para completude e pertinncia de

requisitos;
Metas podem ser usadas para identificar riscos, criar rvores de riscos e
explorar formas de mitig-los;
O uso de metas prov formas para gerenciar conflitos entre requisitos;
Metas proveem critrios para delimitar o escopo do sistema;
Metas apoiam a anlise de dependncia entre agentes;
As alternativas de satisfao das metas permitem representar alternativas nos

requisitos;
Metas apoiam a rastreabilidade dos requisitos j que as rvores de metas

apresentam as cadeias de argumentos de satisfao; e
Metas proveem informaes para permitir a evoluo do sistema, j que

quanto mais alto o nvel da meta, mais estvel ela tende a ser.
Em relao ao uso de metas permitir a definio de um critrio de completude de

requisitos, importante ressaltar que para isso ocorrer necessrio que haja
completude das metas (VAN LAMSWEERDE, 2009). Por mais que se possa
34
empregar tcnicas para se tentar obter completude das metas, no possvel
garanti-la e, por decorrncia, no possvel garantir a completude dos requisitos. Da
mesma forma, para que as metas levem pertinncia dos requisitos, necessrio
que elas sejam completamente definidas e que elas tambm sejam pertinentes.
Em relao s desvantagens no emprego de abordagens GORE pode-se citar
(ROLLAND; SALINESI, 2005):
Especialistas do domnio tm dificuldade de tratar com conceitos abstratos

como a meta;
Obter as metas no uma tarefa simples. No caso de metas empresariais, as

metas tratariam de um contexto idealizado que no existe ainda o que
pode levar a requisitos pouco efetivos;
As metas inicialmente definidas so pouco claras, podendo ser interpretadas

de diferentes formas;
A derivao de metas no uma atividade simples;
Definir metas alternativas para uma determinada meta pai um processo

manual, ad hoc e insatisfatrio; e
A diversidade de terminologias e abrangncias das abordagens dificulta a

integrao delas (YAMAMOTO et al., 2006)14.
Para tentar diminuir a influncia dessas desvantagens nas atividades de Engenharia

de Requisitos, cada abordagem define um conjunto de tcnicas e heursticas que
buscam contorn-las.
3.4 Representao dos requisitos
Os requisitos, as especificaes e outras informaes relevantes para a Engenharia

de Requisitos podem ser representados de diversas formas, dependendo da
abordagem empregada. Em algumas abordagens h apenas uma representao
dos requisitos, como, por exemplo, no Extreme Programming que usa os cartes
com estrias como modelo dos requisitos (BECK, 1999). Em outras, h apenas uma
representao das especificaes, tratando assim do que deve ser usado nas
14
Existem propostas para unificar os conceitos empregados pelas abordagens GORE, como as
apresentadas em (JURETA; MYLOPOULOS; FAULKNER, 2008) e (VAN LAMSWEERDE, 2009).
35
atividades
seguintes
do
desenvolvimento.
Entretanto,
por
mais
que
as
especificaes sejam muitas vezes vistas como as afirmaes mais importantes

para o restante do projeto (j que elas sero usadas como base para as demais
atividades), algumas abordagens propem a representao de todas essas
informaes. At mesmo a norma IEEE 830 que define como deve ser o contedo,
as qualidades e algumas linhas gerais de um documento de especificao de
requisitos de software, independente do mtodo empregado (IEEE, 1998) permite
representar os requisitos em diversos nveis de abstrao (na forma de funes e
restries, principalmente) e conhecimentos do domnio (como fatos assumidos,
dependncias e caractersticas do usurio), apesar de o foco ser na documentao
das especificaes. No caso das abordagens GORE, o foco delas na
representao das metas, uma vez que a partir de seu refinamento e de outras
formas de raciocnio so obtidas as especificaes.
Em alguns casos a representao dos requisitos, das especificaes e dos
conhecimentos do domnio feita em diversos modelos. O uso de vrios modelos
uma forma de permitir uma descrio parcial, buscando assim lidar com a
complexidade do sistema ou at mesmo para permitir diferentes tipos de descrio
(JACKSON, 1995). Por exemplo, no caso do EKD os 6 modelos propostos
(objetivos, regras de negcio, conceitos, processos de negcio, atores e recursos e
componentes tcnicos e requisitos) so representados usando uma mesma
linguagem (BUBENKO JR. et al., 1998). Entretanto, o mais comum que sejam
usadas diversas linguagens, sejam elas formais, semiformais ou informais 15 . Por
exemplo, no mtodo orientado por metas KAOS so empregadas trs linguagens:
uma semiformal (grfica) para representar 4 modelos diferentes (de metas, de
responsabilidade, de objetos e de operao), uma formal para as operaes e
definies formais (se for necessrio) e a linguagem natural (informal) para as
definies bsicas (RESPECT-IT, 2007) (VAN LAMSWEERDE, 2009). De forma
semelhante, no arcabouo i* so usadas trs linguagens16: duas linguagens grficas
para os modelos de razo estratgica e de dependncia estratgica e uma formal
para documentar a descrio dos elementos presentes nos outros modelos (YU,
15
Na seo 4.4 so apresentadas as definies de linguagens formais, semiformais e informais

usadas neste trabalho.
16
Os dois modelos do i* podem tambm ser representados usando a mesma linguagem grfica, a
GRL (ITU-T, 2003).
36
1995). Cada um desses tipos de formalismos apresenta vantagens e desvantagens.
Por exemplo, as linguagens formais permitem representar mais precisamente as
informaes e tambm permitem alguns tipos de anlise (como, por exemplo,
cenrios de falhas e contraexemplos), mas em compensao elas em geral
expressam apenas aspectos funcionais do sistema e propriedades temporais, so
difceis de serem entendidas por no profissionais e exigem pessoal altamente
especializado para us-las (VAN LAMSWEERDE, 2009). Por causa disso, muitos
mtodos usam diferentes tipos de linguagem para obter uma representao mais
adequada.
Por mais que sejam usadas vrias linguagens para representao dos modelos,
muitas vezes elas tm um mesmo escopo de descrio, representando as mltiplas
vises de apenas uma das informaes pertinentes para Engenharia de Requisitos.
De acordo com Jackson (1995) so necessrias trs descries diferentes em um
projeto de desenvolvimento de sistemas: uma tratando do domnio de aplicao,
uma tratando da descrio em comum e uma tratando da mquina a ser construda.
A descrio do domnio de aplicao representa os requisitos no refinados e os
conhecimentos do domnio; a descrio em comum trata das especificaes; e a
descrio da mquina o modelo de projeto ou at mesmo a implementao em si.
Entretanto, no caso das representaes feitas pelas abordagens i*, Tropos, KAOS,
EKD e B-SCP, as descries dos requisitos, dos conhecimentos do domnio e das
especificaes no so representadas distintamente. Por mais que haja diversos
modelos, essas informaes acabam representadas em um mesmo lugar. Um
exemplo disso o modelo de razo estratgica do i* que representa ambos os
requisitos, as especificaes e os conhecimentos do domnio. No caso desse
arcabouo (e igualmente nos mtodos Tropos e KAOS), essas informaes so
representadas em um mesmo modelo como parte da tcnica proposta de se obter as
especificaes.
3.5 Caso de uso
Uma das formas de representao de requisitos mais usadas o caso de uso.

Originalmente o caso de uso foi criado como parte do processo Objectory, para o
desenvolvimento de software orientado a objetos. Esse processo era orientado por
37
casos de uso, ou seja, o modelo de caso de uso servia como base para a criao
dos demais modelos (JACOBSON, 1992). A mesma filosofia foi seguida pelo
Processo Unificado (JACOBSON; BOOCH; RUMBAUGH, 1999), a evoluo do
Objectory, e, consequentemente, pelos processos de desenvolvimento de software
orientados a objetos que foram baseados nele, como, por exemplo, o RUP (IBM,
2009) e o ICONIX (ROSENBERG; STEPHENS, 2007). Apesar disso, atualmente o
emprego de casos de uso no est limitado a projetos de software orientado a
objetos, podendo ser empregado em mtodos que seguem outros paradigmas de
desenvolvimento de software (KULAK; GUINEY, 2003).
O caso de uso pode ser definido como (OMG, 2011b, p.612):
"Uma especificao de um conjunto de aes executado por um sistema, o qual
gera um resultado observvel que , tipicamente, de valor para um ou mais atores
ou outra parte envolvida do sistema".
Dessa forma, ele representa a interao entre entidades externas ao sistema,

representadas a partir dos tipos de papis executados por elas chamados de
atores (OMG, 2011b), e o sistema em questo chamado tambm de sujeito (ou
tema) para a realizao de um determinado resultado desejado.
A forma como o caso de uso representa a interao entre os atores e o sistema faz
dele uma abordagem baseada em cenrio, assim como so as estrias, os
storyboards e os diagramas de processo de negcio (BITTNER, 2008). De acordo
com Jarke (1999, p.47), um cenrio descreve "um possvel conjunto de eventos que
podem razoavelmente acontecer". No uso para a Engenharia de Requisitos, o
cenrio representa uma descrio do uso real ou pretendido de alguma funo de
um sistema, o que pode ser feito usando a linguagem natural ou at mesmo usando
linguagens formais (WEIDENHAUPT et al., 1998). O caso de uso pode ser visto
como um conjunto de cenrios (JARKE; KURKI-SUONIO, 1998), sendo que uma
instncia do caso de uso um cenrio nico (ROLLAND et al., 1998). Dessa
maneira, assim como os cenrios, pode-se dizer que o caso de uso uma forma de
representao
de
requisitos
especificaes
(BITTNER, SPENCE,
2002)
(COCKBURN, 2000) (LEFFINGWELL; WIDRIG, 2003). Entretanto, dependendo do

nvel de detalhamento e do escopo dado ao caso de uso, ele pode tambm
descrever conhecimentos do domnio ou detalhes de implementao do sistema. Um
38
exemplo disso so os chamados casos de uso de negcio (COCKBURN, 2000)
(IBM, 2009) (LEFFINGWELL; WIDRIG, 2003) que permitem descrever o contexto
empresarial atual ou mesmo o ambiente idealizado. Uma forma de classificar os
diferentes tipos de casos de uso proposta por Cockburn (2000), que define
diferentes escopos e nveis de detalhamento que podem ser abordados por um caso
de uso. O escopo representa o sujeito descrito pelo caso de uso e pode ser
classificado como (COCKBURN, 2000):
Empresarial: descreve as interaes envolvendo a empresa como um todo (o

que inclui o sistema computacional), seja ela vista como uma caixa branca ou
caixa preta;
Sistema: descreve apenas as interaes entre o sistema computacional e

seus atores, podendo descrever o sistema computacional como uma caixa
branca ou como uma caixa preta; e
Subsistema:
descreve
as
interaes
entre
as
partes
do
sistema
computacional sob considerao.

Os casos de uso de negcio so os casos uso descritos no escopo empresarial,
enquanto que o escopo de sistema usado para representar casos de uso para a
definio de requisitos e especificaes. Ortogonalmente ao escopo, Cockburn
(2000) tambm define trs nveis de detalhamento de um caso de uso:
Nvel de sumrio: envolvem diferentes resultados desejados pelo usurio,

seja para apresentar o contexto que as metas do usurio operam, a
sequncia das atividades ou um sumrio dos contedos de casos de uso de
nvel mais baixo;
Nvel das metas do usurio: trata dos resultados desejados que o ator, ou o
usurio, pretende atingir ao usar o sistema; e
Nvel de subfunes: tratam dos sub-resultados desejados necessrios para

atingir um determinado resultado desejado pelo usurio.
Dessa forma, possvel ter, teoricamente, 9 tipos diferentes de casos de uso, como
por exemplo, com escopo empresarial e nvel de sumrio ou com escopo de
subsistema e nvel de metas do usurio. Cada um desses tipos de caso de uso
permite representar diferentes informaes do ambiente e do sistema teis para a
39
Engenharia de Requisitos17, com diferentes nveis de detalhamento. Na Tabela 3.1
apresentada uma viso geral da relao entre os tipos de caso de uso e as
informaes que podem ser representadas neles, seguindo o quadro de referncia
de requisitos usado (baseado no modelo WRSPM). De forma geral, os casos de uso
de escopo empresarial permitem representar o conhecimento do domnio j que
alm do sistema pode-se tambm descrever a empresa como um todo. Do outro
lado, casos de uso de escopo de subsistema representam detalhes de
implementao j que a prpria identificao de subsistemas acaba sendo uma
informao especfica do sistema (e no da fronteira dele com o ambiente).
Nvel de
detalhamento
Tabela 3.1: Viso geral da relao entre o escopo e o nvel de detalhamento do caso de uso e as
informaes que eles representam.
Sumrio
Metas do
usurio
Subfunes
Empresarial
Conhecimento do domnio
Requisito
Escopo
Sistema
Requisito
Requisito
Requisito
Especificao
Especificao
Especificao
Implementao
Subsistema
Requisito
Especificao
Implementao
Especificao
Implementao
Especificao
Implementao
3.5.1 Vantagens e limitaes do caso de uso
Apesar da variedade de informaes do ambiente e do sistema que pode ser

tratada, os casos de uso no conseguem representar todos os requisitos. Por mais
que dependendo do tipo de caso de uso seja possvel representar informaes de
implementao do sistema, alguns requisitos que tratam de detalhes de como o
sistema dever ser implementado no conseguem ser bem representados
(BITTNER; SPENCE, 2002) (LEFFINGWELL; WIDRIG, 2003). Segundo Leffingwell e
Widrig (2003), casos de uso no conseguem expressar adequadamente algoritmos e
frmulas matemticas que precisam ser executadas pelo sistema. Esses algoritmos
e frmulas representam, em geral, procedimentos, relacionamentos e guias que
dirigem o negcio em situaes particulares e que sero automatizados pelo sistema
17
Est se considerando que o sistema tratado pelo caso de uso o sistema a ser construdo. Caso o
sistema tratado pelo caso de uso seja o sistema existente, para o desenvolvimento do novo sistema
ele prover apenas conhecimento do domnio.
40
(AMOUR; MILLER, 2001). Para represent-los necessrio documentar essas
informaes de alguma outra forma, adicionalmente aos casos de uso.
Mesmo alguns requisitos que so afirmaes sobre o ambiente no conseguem ser
representados de uma forma adequada pelos casos de uso. Dividindo esse tipo de
requisito em duas categorias, os requisitos funcionais que descrevem o que o
sistema deve fazer e os requisitos no funcionais que definem restries de
como os requisitos funcionais sero implementados (SOMMERVILLE; SAWYER,
1997), os casos de uso no conseguem representar adequadamente os requisitos
no
funcionais
(ARMOUR;
MILLER,
2001)
(BITTNER;
SPENCE,
2002)
(COCKBURN, 2000) (LARMAN, 2003). Dependendo da forma de representao

usada, pode at ser possvel descrever, juntamente com o caso de uso alguns
requisitos no funcionais; entretanto isso gera alguns problemas como redundncia,
dificuldades de rastreabilidade, dificuldade de organizao, entre outros (CHUNG;
SUPAKKUL, 2005).
Apesar dessas limitaes na expresso dos requisitos, ainda assim o caso de uso
um mtodo popular de representao de requisitos (KULAK; GUINEY, 2003). Dentre
as vantagens e os pontos fortes atribudos a ele, pode-se citar:
O caso de uso relativamente fcil de escrever e de ler (LEFFINGWELL;

WIDRIG, 2003);
O caso de uso escrito na linguagem (ou perspectiva) do usurio (LARMAN,

2003) (LEFFINGWELL; WIDRIG, 2003);
O caso de uso permite ligar as atividades de requisitos ao projeto e

implementao,
levando
rastreabilidade
(KULAK;
GUINEY,
2003)
(LEFFINGWELL; WIDRIG, 2003);
Um cenrio descrito por um caso de uso pode ser quase que diretamente
usado como um roteiro de teste (COCKBURN, 2000) (LEFFINGWELL;
WIDRIG, 2003) (BOOCH; RUMBAUGH; JACOBSON, 2005);
O caso de uso auxilia a definio do escopo do sistema (KULAK; GUINEY,

2003);
O caso de uso um veculo para vislumbrar como ser o sistema, facilitando

a discusso e a obteno de um acordo sobre o que o sistema deve fazer
(BITTNER; SPENCE, 2002);
41
O caso de uso enfatiza os objetivos dos usurios (LARMAN, 2003); e
O caso de uso organiza os requisitos em grupos, contextualizando-os

(diferentes de uma lista de requisitos) (BITTNER; SPENCE, 2002) (LARMAN,
2003) (LEFFINGWELL; WIDRIG, 2003).
Apesar de muitas dessas vantagens tratarem da facilidade de criao e de

entendimento dos casos de uso, no h um consenso de como represent-lo.
possvel encontrar uma grande variedade de representaes, seja graficamente ou
textualmente. Entretanto, como o caso de uso definido na Unified Modeling
Language (UML), que tanto um padro de fato como de mercado para o projeto de
sistemas baseados em software, de se esperar que ele seja representado
seguindo a notao definida por ela.
3.5.2 Caso de uso na UML
A UML uma linguagem grfica de modelagem usada para visualizar, especificar,

construir e documentar sistemas intensivos de software (BOOCH; RUMBAUGH;
JACOBSON, 2005). Seu objetivo principal permitir a interoperabilidade entre
ferramentas de modelagem grfica para esse tipo de sistema e, para isso, definida
sua sintaxe concreta, sintaxe abstrata e semntica (OMG, 2011b). A sintaxe abstrata
definida atravs de metamodelos, usando o padro MOF (Meta Object Facility)
(OMG, 2006a), e sua semntica definida atravs de textos em linguagem natural.
Entretanto a sintaxe abstrata limitada pela expressividade da OCL (Object
Constraint Language), existindo algumas restries expressas apenas em linguagem
natural (com comentrio de "sem OCL disponvel"). Em relao semntica, a
ambiguidade proveniente do uso da linguagem natural e a existncia de pontos de
variao faz com que no seja possvel avaliar se uma determinada ferramenta est
ou no em conformidade com a especificao da UML em relao semntica
(OMG, 2011b).
Uma parte do metamodelo da UML trata especificamente dos casos de uso,
organizando os conceitos envolvidos e os relacionamentos entre eles em um pacote.
Alm das metaclasses UseCase e Actor que representam, respectivamente, o caso
de uso e o ator, nesse pacote tambm so definidas as metaclasses Include
(incluso),
Extend
(extenso)
ExtensionPoint
(ponto
de
extenso)
que
42
representam algumas formas especficas de relao entre os casos de uso. Com
elas possvel criar um diagrama de caso de uso que relaciona os casos de uso e
os atores. Entretanto esse diagrama representa os casos de uso como um sumrio
(BITTNER; SPENCE, 2002), descrevendo apenas o nome de cada um deles. Para
detalh-lo necessrio descrever o conjunto de aes que so especificadas por ele
seguindo a definio de caso de uso usada pela UML e que tambm a usada por
este trabalho. Na UML o conceito de ao representado pela metaclasse Action,
sendo definido como uma unidade de especificao de comportamento que converte
um conjunto de entradas em um conjunto de sadas, representando assim a
transformao ou processamento no sistema em questo (OMG, 2011b).
Para analisar como se pode detalhar um caso de uso usando a UML, necessrio
analisar especificamente a metaclasse UseCase. Na Figura 3.2 apresentada parte
do metamodelo da UML que representa os principais relacionamentos dessa
metaclasse, entre eles envolvendo as metaclasses do pacote do caso de uso. A
metaclasse UseCase uma especializao de um BehavioredClassifier, ou seja, o
caso de uso um classificador (Classifier) que pode possuir especificaes de
comportamento (OMG, 2011b). Sendo um Classifier, o caso de uso descreve um
conjunto de instncias com funcionalidades em comum (OMG, 2011b), o que
permite que existam instncias de caso de uso. Cada funcionalidade declara uma
caracterstica comportamental ou estrutural das instncias de classificador. Alm de
ser um classificador, um UseCase tambm est relacionado com outros
classificadores que representam o sujeito que ele trata e tambm com um
classificador do qual ele faz parte.
A execuo de um caso de uso feita por um sujeito com a colaborao dos atores,
podendo resultar em mudanas no estado do sujeito e em comunicaes com o
ambiente externo. Entretanto o caso de uso no especifica a estrutura interna do
sujeito: apenas o comportamento externo abordado. Ainda assim esse
comportamento pode incluir variaes, como excees e tratamento de erro. Do
ponto de vista do quadro de referncia de requisitos usado neste trabalho, isso
significa que o caso de uso trata apenas do ambiente, no abordando os fenmenos
especficos do sistema. Isso fica evidente na UML ao afirmar que o caso de uso
pode ser usado para especificar os requisitos de um sujeito ou mesmo as
funcionalidades que ele oferece (OMG, 2011b). Dessa maneira, por mais que, de
43
uma forma geral, o caso de uso possa ser usado para tratar de detalhes de
implementao ou mesmo de sistemas em geral, para a UML o caso de uso de um
sistema trata apenas das especificaes, dos requisitos ou de informaes de mais
alto nvel.
Type
subject
*
Classifier
Class
0..1
* * redefinedBehavior
*
1
*
Include include 1
*
0..1
ExtensionPoint
Actor
Extend
Parameter
*
*
extend *
0..1
isReentrant
0..1
1..*
Behavior
Activity
0..1
Behaviored context
Classifier
0..1
UseCase
1
0..1
* ownedUseCase
0..1
StateMachine
Trigger
precondition *
0..1
0..1
condition
0..1
* postcondition
Interaction
Constraint
Figura 3.2: Parte do metamodelo da UML a respeito do caso de uso (OMG, 2011b).
Para representar o comportamento de um caso de uso, a UML apresenta algumas

opes (OMG, 2011b):
1. Atravs de um tipo de Behavior (relacionado ao UseCase pela sua
metaclasse mais geral, o BehavioredClassifier);
2. Atravs de pr e ps-condies18;
3. Por linguagem natural;
4. Por uma colaborao que usa o caso de uso e seus atores como
classificadores que tipificam suas partes; e
5. Por uma combinao das opes anteriores.
Apesar de serem definidas no contexto da UML (que uma linguagem grfica),
essas opes apresentam diferenas no formalismo empregado, como o caso, por
exemplo, da opo (3) que usa linguagem natural e da opo (2) que pode usar OCL
18
Da forma como o metamodelo, as pr e ps-condies esto no Behavior (e no no caso de uso).
44
para expressar as pr e ps-condies. Alm disso, cada opo considera vises
diferentes do comportamento do caso de uso, nem sempre representando
diretamente um conjunto de aes que o esperado pela definio de caso de
uso. Por esses motivos, segundo a UML a escolha entre uma dessas opes deve
considerar a natureza do comportamento do caso de uso e quem ser seu leitor
(OMG, 2011b).
Analisando essas cinco opes em relao representao de um conjunto de
aes, a opo (2) permite representar o comportamento do caso de uso atravs do
"resultado observvel"19 e no atravs de aes. O comportamento do caso de uso
representado atravs das condies que so cumpridas antes de sua execuo
(pr-condies) e das condies que so cumpridas aps a sua execuo (pscondies). Ou seja, possvel inferir que o sistema executou um conjunto de aes
que o levou a um estado em que as ps-condies so verdadeiras, mas no se
sabe exatamente quais foram as aes executadas.
No caso da opo (4), o comportamento do caso de uso representado atravs de
uma colaborao, ou seja, atravs da representao de uma coleo de instncias
em que cada uma delas desempenha uma funo especializada e que
coletivamente realizam uma funcionalidade desejada (em geral atividade ou conjunto
de atividades) (OMG, 2011b). A colaborao representa a estrutura dessas
instncias (vistas como papis), apresentando as relaes entre elas que so
relevantes para explicar como as atividades so realizadas. Na especificao da
UML a colaborao representada pela metaclasse Collaboration que, assim como
a UseCase, um BehavioredClassifier. Dessa maneira, a colaborao no descreve
um comportamento diretamente, mas permite que ele seja especificado atravs de
um Behavior levando opo (1) para descrever o comportamento do caso de
uso20.
19
A UML no discute o significado do termo resultado observvel que usado para qualificar as
aes que so executadas pelo caso de uso. Entretanto, como o caso de uso trata apenas do
ambiente, considera-se aqui que esse resultado observvel representa fenmenos do sistema
visveis ao ambiente (seguindo o quadro de referncia de requisitos baseado no WRSPM).
20
Segundo Booch, Rumbaugh e Jacobson (2005) a colaborao pode ser usada para modelar a
realizao de um caso de uso, ou seja, uma soluo do ponto de vista de projeto para o caso de uso.
Portanto, ao usar a colaborao dessa forma no se est mais tratando da Engenharia de Requisitos,
que o escopo deste trabalho. Mas importante ressaltar que essa no a nica forma de usar a
colaborao para representar o comportamento do caso de uso.
45
Das trs outras opes, a opo (5) no define uma forma de representao por si
s, mas a juno das demais representaes que permite que se tenha diferentes
vises do comportamento do caso de uso. Entre as opes (1) e (3), a opo (1)
(atravs de um Behavior) , a princpio, a opo mais adequada para descrever o
comportamento do caso de uso j que segue o metamodelo da UML. De acordo com
a especificao da UML, as seguintes especializaes de Behavior esto
disponveis (OMG, 2011b):
OpaqueBehavior: comportamento com implementao especfica, mas no

definida. Ele deve ser usado temporariamente at que algum outro
comportamento seja escolhido;
StateMachine: representa o comportamento de parte de um sistema atravs

de estados e transies entre eles causadas por eventos;
Interaction: representa unidades de comportamento de um classificador,

tratando da troca de mensagens entre elementos do classificador; e
Activity: representa um modelo de comportamento que trata da sequncia,

das condies, das entradas e das sadas das aes (BOCK, 2003).
Dentre essas opes, o uso de um OpaqueBehavior no suficiente para descrever

o comportamento de um caso de uso. Como esse tipo de Behavior de uso
temporrio, ele apenas diz que existe um comportamento, mas no o define.
Quando se decidir qual o comportamento adequado, o OpaqueBehavior ento
substitudo pela especializao de Behavior escolhida. Dessa maneira, se ele fosse
usado para representar um caso de uso, a definio do comportamento seria apenas
adiada mas em algum momento ela precisaria ser definida de alguma outra forma.
Em relao StateMachine, o seu uso como o Behavior para descrever o
comportamento do caso de uso no permite descrever diretamente as aes. Ao
invs disso, o comportamento representado basicamente pelos estados
situaes durante a qual algumas condies invariantes so vlidas (OMG, 2011b)
que o caso de uso possui e pelas transies de um estado para outro. As aes
podem ser vistas implicitamente ao considerar as transies entre os estados, ou at
mesmo podem ser descritas explicitamente ao associar alguns objetos Behavior,
seja para executar um comportamento ao entrar, enquanto estiver ou ao sair de um
estado (OMG, 2011b). Com isso, possvel associar um outro Behavior que define
as aes especificadas pelo caso de uso, mas no possvel defini-las.
46
Diferentemente
do
OpaqueBehavior
especializaes
de
Behavior,
da
Interaction
StateMachine,
e
Activity,
as
permitem
duas
outras
representar
diretamente aes. Considerando o objetivo da Interaction representar a troca de

mensagens , a existncia de aes est restrita a um tipo especfico de fragmento
de interao, o ActionExecutionSpecification. Nesse tipo de fragmento possvel
especificar mensagens que so resultantes de uma ao, sendo que essa ao
tambm pode ser possuda por outros comportamentos (OMG, 2011b). No caso da
Activity as aes so o elemento principal desse tipo de Behavior, sendo que uma
Activity na realidade composta por aes e por outros objetos Activity. Portanto,
considerando a UML, a forma de descrever as aes que so especificadas por um
caso de uso atravs de Interaction ou Activity. Entretanto, para representar o
comportamento do caso de uso atravs de uma dessas opes necessrio, antes,
analisar exatamente o que so aes para a UML.
A metaclasse Action, que trata do conceito de ao para a UML, representa uma
unidade fundamental de comportamento, ou seja, "todos os comportamentos devem
eventualmente se reduzir a aes para terem qualquer efeito em objetos, ou mesmo
invocar outros comportamentos" (BOCK, 2003, p.42). Uma Action no um
Behavior, mas contida por um que prov o seu contexto e define restries entre
as aes para determinar quando elas so executadas e que informaes so
passadas para elas (OMG, 2011b). Essa metaclasse especializada em 45 tipos de
ao que podem ser organizadas da seguinte forma21:
Aes de invocao: aes especializadas da metaclasse InvocationAction,

representando a invocao de comportamento. Por exemplo, se tem aes
para chamar um comportamento (CallBehaviorAction), chamar uma operao
(CallOperationAction) ou enviar um sinal (SendSignalAction).
Aes de objetos: aes que se referem a objetos, como, por exemplo, a

criao (CreateObjectAction), a destruio (DestroyObjectAction) ou a
obteno do objeto que possui a ao (ReadSelfAction).
Aes
de
caractersticas
estruturais:
aes
especializadas
de
StructuralFeatureAction, que operam sobre uma caracterstica estrutural de

21
Essa organizao das aes segue a organizao dos diagramas de sintaxe abstrata apresentada
na especificao da UML (OMG, 2011b), uma vez que a diviso em pacotes proposta pela UML
divide-as por complexidade e no por similaridade de comportamento.
47
um classificador, como, por exemplo, a leitura (ReadStructuralFeatureAction)
e escrita (WriteStructuralAction) da caracterstica estrutural.
Aes de ligao: aes especializadas da metaclasse LinkAction, que trata

da ligao entre objetos, e a ao ClearAssociationAction que destri todas
as ligaes de uma associao envolvendo um objeto. Como exemplo de
outras aes de ligao se tem a leitura de uma ligao (ReadLinkAction), a
criao de uma ligao (CreateLinkAction) e a destruio de uma ligao
(DestroyLinkAction).
Aes
de
aceitao
de
eventos: aes envolvidas com a ao
AcceptEventAction que espera por eventos considerando uma determinada

condio.
Aes sobre variveis: aes especializadas de VariableAction que operam

sobre variveis, como, por exemplo, ler variveis (ReadVariableAction) e
escrever variveis (WriteVariableAction).
Outras aes: ao para gerar uma exceo (RaiseExceptionAction), ao

para reduzir uma coleo a um elemento (combinando os elementos seguindo
um determinado comportamento) (ReduceAction), ao que avalia uma
especificao de valor (ValueSpecificationAction) e ao que usada de
forma temporria at que uma outra ao seja escolhida (OpaqueAction).
Alguns desses tipos de ao possuem uma semntica muito prxima a recursos de

linguagem de programao, como, por exemplo, as aes sobre variveis e aes
de objetos. Entretanto, considerando o uso delas para representar o comportamento
de um caso de uso, uma preocupao que o uso delas no deve tratar da soluo
computacional em si, mas da descrio do ambiente. Ou seja, a descrio deve
tratar apenas dos requisitos e no de uma soluo especfica. Com isso, usando,
por exemplo, uma Activity para descrever um determinado caso de uso,
necessrio definir as aes que sero executadas considerando esses tipos
disponveis e definir a sequncia delas (usando os demais elementos definidos pelo
metamodelo referente Activity). Isso pode ser feito de duas formas:
a. As aes definidas no caso de uso poderiam trabalhar com instncias de um
modelo de domnio (que representa os conceitos do domnio do problema). As
informaes passadas pelos atores e devolvidas a eles seriam manipuladas
atravs de aes que tratam de variveis e de sinais. O comportamento
48
externamente observvel realizado pelo caso de uso seria representado
atravs da manipulao de objetos e de ligaes, considerando as classes do
modelo de domnio e seus relacionamentos.
b. Uma vez que os casos de uso especificam aes que sero posteriormente
implementadas em um sistema, poder-se-ia usar apenas OpaqueAction,
deixando para as atividades seguintes de desenvolvimento detalhar o
comportamento de cada ao.
A principal diferena entre essas duas abordagens que na primeira o caso de uso
detalhado de tal forma que seria possvel execut-lo, enquanto que na segunda o
caso de uso representado de forma superficial, no sendo possvel execut-lo
usando a semntica da UML o leitor do diagrama criado quem deve inferir a
semntica das aes. Por mais que a opo (a) possa ser vista como uma
especificao formal do comportamento do caso de uso, a UML no prov formas
para aproveitar esse formalismo para, por exemplo, avaliar propriedades no modelo
criado, encontrar cenrios de falha e obter contraexemplos (como outras linguagens
formais de especificao de requisitos permitem). Ainda assim, a preciso para
elaborar uma representao desse tipo dificultaria a sua criao e seu entendimento
por no profissionais, ou seja, se teria os problemas de uma especificao formal
sem as vantagens que ela prov. Com isso, muitas das vantagens do caso de uso
principalmente aquelas relacionadas sua facilidade de criao no existiriam ao
usar essa forma de representao.
No caso da opo (b), a falta de uma semntica clara para as aes faria com que
uma representao desse tipo seja praticamente equivalente a uma descrio
textual. A diferena, alm do fato de ser grfica ao invs de textual, que se usa a
semntica dos demais elementos da UML para, por exemplo, representar condies,
laos e paralelismo.
Considerando essas duas opes de representao do comportamento do caso de
uso usando os recursos da UML, a representao em linguagem natural acaba
sendo uma opo to adequada, ou at mais que essas, ao considerar o conceito de
caso de uso. Alm das desvantagens que uma representao usando o modelo de
domnio possui e as poucas vantagens que uma representao usando
OpaqueAction traz, alguns autores afirmam que a representao em linguagem
natural a forma mais apropriada pra representar os casos de uso (BITTNER;
49
SPENCE, 2002) (COCKBURN, 2000) (KULAK; GUINEY, 2003) principalmente
porque eles devem ser entendidos por desenvolvedores e tambm por outras partes
envolvidas (JACOBSON; BOOCH; RUMBAUGH, 1999). Mesmo a UML afirma que
os casos de uso "so tipicamente especificados em vrios formatos idiossincrticos
como linguagem natural, tabelas, rvores etc." (OMG, 2011b, p.608).
3.5.3 Representao textual do caso de uso
Apesar de a representao em linguagem natural ser uma das opes apresentadas

pela UML para descrever o comportamento do caso de uso, na especificao da
UML no definido como deve ser essa representao textual: se atravs de
linguagem natural irrestrita ou estruturada e se estruturada, qual o formato.
Entretanto isso no uma falha do padro: como a UML uma linguagem de
modelagem grfica, no est no escopo de sua especificao apresentar detalhes
de uma representao textual. O problema que, por causa disso, no h um
padro para a representao textual do comportamento do caso de uso.
Existem diversos trabalhos que propem formatos para a descrio textual do
comportamento do caso de uso, sejam trabalhos que tratam de descries gerais de
casos de uso no contexto das atividades de Engenharia de Requisitos
(LEFFINGWELL; WIDRIG, 2003) (SUBRAMANIAM; FAR; EBERLEIN, 2004)
(WIEGERS, 2003) ou de outras atividades de desenvolvimento (CABRAL;
SAMPAIO, 2008) (YUE; BRIAND; LABICHE, 2009), trabalhos que propem mtodos
ou mesmo processos de desenvolvimento de software que empregam casos de uso
como (IBM, 2009), (JACOBSON; BOOCH; RUMBAUGH, 1999), (LARMAN, 2003) e
(ROSENBERG; STEPHENS, 2007), trabalhos que detalham a tcnica de caso de
uso como (ARMOUR; MILLER, 2001), (BITTNER; SPENCE, 2002), (COCKBURN,
2000), (KULAK; GUINEY, 2003) e (SCHNEIDER; WINTERS, 2001), ou at mesmo
em trabalhos que propem metamodelos ou gabaritos de casos de uso como
(BARRET et al., 2009), (DURN et al., 2004), (NAKATANI et al., 2001),
(PETTERSSON; IVARSSON; HMAN; 2005), (RUI; BUTLER, 2003), (SMIALEK et
al., 2007), (SOM, 2009) e (ZELINKA; VRANIC, 2009).
50
Em geral as propostas indicam o uso de linguagem natural estruturada e sugerem,
alm do comportamento em si do caso de uso, a representao de outras
informaes a respeito dele. Os elementos mais comumente apresentados nessas
propostas so: nome, descrio, ator, pr-condio, ps-condio, fluxo bsico e
fluxo alternativo 22 . Dentre esses elementos, o comportamento do caso de uso
representado pelos fluxos que permitem representar a interao entre os atores e o
sujeito. Para isso o fluxo representa as aes executadas pelas duas partes, sendo
que a representao de cada ao varia de acordo com a proposta, podendo possuir
diferentes tipos, como, por exemplo, em (RUI; BUTLER, 2003). Como a ao o
elemento principal do caso de uso, alguns trabalhos definem guias de como
escrev-las de forma adequada, como em Bittner e Spence (2002) e Cockburn
(2000), por exemplo. Alguns autores tambm propem heursticas para restringir o
contedo do fluxo e tambm formas de controle e organizao das aes (como
laos, condies etc.).
Dos outros elementos comuns nas representaes de caso de uso, apenas as pr e
ps-condies acrescentam informaes ao comportamento do caso de uso. O
nome usado para identificar o caso de uso, devendo ser nico no modelo; a
descrio busca facilitar o entendimento do caso de uso ao apresentar um resumo
de seu propsito; o ator uma forma de evidenciar os elementos externos que
executaro aes descritas no fluxo; enquanto que as pr e ps-condies permitem
representar comportamentos dependentes de estados. Em geral, as pr e pscondies indicam relaes entre os casos de uso, permitindo que um determinado
caso de uso s seja executado aps um ou mais casos de uso deixarem o sistema
em um estado especfico (AMOUR; MILLER, 2001).
Do ponto de vista de representao de requisitos, alm dos fluxos e das pr e pscondies, outros elementos propostos por alguns trabalhos podem contribuir com a
capacidade de representao do caso de uso. Por exemplo, o elemento requisitos
especiais permite representar, mesmo que limitadamente, os requisitos no
funcionais, enquanto que o elemento interface com o usurio permite representar
alguns requisitos de usabilidade. Ainda assim, no possvel afirmar que ao
representar os casos de uso considerando todos os elementos possveis se ter
22
A anlise dos elementos mais comuns e o detalhamento deles so apresentados na seo 6.3.1.
51
uma representao completa dos requisitos. Por isso, autores como (ARMOUR;
MILLER, 2001), (COCKBURN, 2000), (LARMAN, 2003) e (LEFFINGWELL; WIDRIG,
2003) sugerem que a representao dos casos de uso seja englobada ou a ela
adicionada um documento que possui outras informaes dos requisitos.
3.5.4 Avaliao da qualidade de um caso de uso
Trabalhos que tratam da redao de descries textuais muitas vezes apresentam

guias para obter casos de uso mais apropriados, seja atravs do uso de modelos,
heursticas ou tcnicas de redao. Entretanto, em geral esses trabalhos no
discutem formas de avaliar a qualidade de um caso de uso. Um trabalho que trata de
uma forma geral da avaliao da qualidade de casos de uso apresentado por
Ramos et al. (2009). Nesse trabalho proposto um processo para melhoria de casos
de uso baseado na abordagem Goal Question Metric, empregando um conjunto de
padres de refatoramento para a atividade de melhoria. Apesar de tratar da
qualidade do caso de uso, esse trabalho no apresenta critrios para avaliar essa
qualidade: cada usurio deve definir o que ser medido e avaliado.
Uma proposta que apresenta critrios para a avaliao da qualidade de casos de
uso apresentada por Achour et al. (1999), no contexto de um experimento para
avaliar guias de estilo e guias de contedo. Como as hipteses formuladas tratam de
aspectos da qualidade de casos de uso, as variveis as quais se espera que sejam
afetadas como resultado do experimento (variveis dependentes) podem ser vistas
como critrios quantitativos da qualidade do caso de uso. Essas variveis so
(ACHOUR et al., 1999):
Descries completas de ao: contagem de elementos previstos pelas

heursticas do guia de contedo que no foram representados;
Descries apropriadas: uso de um gabarito de caso de uso para anlise

das aes relevantes, atribuindo uma nota pela presena da ao esperada;
Descrio correta e no ambgua do fluxo de aes: atribuio de uma

nota pelo uso correto de palavras relativas ao fluxo de ao que foram
previstas pelo gabarito de caso de uso; e
52
Uso consistente de terminologia: nmero de sinnimos e homnimos

usados.
Esse experimento replicado por Cox e Phalp (2000), que obtm resultados
diferentes. Os autores discutem o experimento e os resultados obtidos, criticando as
hipteses formuladas (que seriam vagas), o gabarito usado (que violam algumas
regras de escrita de casos de uso) e a forma de avaliao das hipteses (que seria
enviesada e que faria com que algumas hipteses fossem inadequadamente
validadas junto com outras). Dessa maneira, Cox e Phalp (2000) propem uma
avaliao subjetiva que considera 4 outros critrios a serem aplicados por um
avaliador: plausibilidade (se o caso de uso realstico), facilidade de leitura (se a
leitura do caso de uso flui), estrutura consistente (se a terminologia usada
consistente) e fluxo alternativo (se alternativas viveis do caso de uso foram
consideradas).
Esses critrios e os critrios propostos por (ACHOUR et al., 1999) foram usados
como base por Anda, Sjberg e Jrgensen (2001) para a avaliao do impacto de
diferentes guias (menores, de modelo e de estilo) na qualidade do caso de uso. Os
autores propuseram tambm outros critrios, uma vez que os experimentos de
Achour et al. (1999) e de Cox e Phalp (2000) considerarem apenas um caso de uso
e no um modelo de caso de uso (composto por um diagrama de caso de uso e
por um conjunto de casos de uso). Dessa forma, foram considerados os seguintes
critrios (ANDA; SJBERG; JRGENSEN, 2001):
Diagrama nico: se existe um diagrama nico;
Atores: se os atores corretos foram identificados;
Casos de uso: se os casos de uso corretos foram identificados;
Contedo: se a descrio de cada caso de uso contm as informaes

definidas pelo conjunto de guias;
Nvel de detalhe: se a descrio de cada evento est em um nvel apropriado

de detalhe (sem detalhes sobre interface e eventos devem ser atmicos);
Realismo: se os eventos em um fluxo seguem uma sequncia lgica e

completa; e
Consistncia: se a terminologia usada consistente.
Esses critrios so estendidos para uma taxonomia de defeitos em (ANDA;

SJBERG, 2002) para a avaliao experimental da inspeo de casos de uso. Essa
53
taxonomia considera omisses, fatos incorretos, inconsistncias, ambiguidades e
informaes irrelevantes em relao aos atores, casos de uso, fluxo de eventos,
variaes, relaes entre casos de uso e gatilhos, pr e ps-condies. Para cada
um desses elementos do caso de uso so aferidas notas, subjetivamente,
considerando a taxonomia de defeitos proposta.
Estendendo os trabalhos de (ANDA; SJBERG; JRGENSEN, 2001), (ACHOUR et
al., 1999) e (COX; PHALP, 2000) e baseado no padro IEEE 830 (IEEE, 1998),
Trner et al. (2006) propem um conjunto de critrios para avaliao de defeitos de
casos de uso, considerando os seguintes elementos (TRNER et al., 2006):
completude (elementos faltando e meta no alcanada), correo (fluxo incorreto e
fora do escopo), consistncia (numerao de passos inconsistente, passos
irrelevantes e decomposio de casos de uso), facilidade de leitura (mal uso de
fluxos alternativos), no ambiguidade (condio no clara de fluxo alternativo e uso
incorreto de linguagem), nvel de detalhe e mau uso de pr-condies. Assim como
no trabalho de (ANDA; SJBERG, 2002), esse conjunto de critrios usado para a
definio de notas. Um conjunto de atributos de qualidade similar a esse
apresentado em (ANDA; HANSEN; SAND, 2009), adicionando redundncia,
facilidade de manuteno e facilidade de verificao, mas desconsiderando o mau
uso de pr-condies. Esses atributos so usados para o estudo das mudanas
ocorridas em um modelo de caso de uso em um projeto real.
Por fim, Phalp, Vincent e Cox (2007a) apresentam 7 fatores de qualidade para
ajudar a comunicao de casos de uso. Esses fatores so apresentados na Tabela
3.2. Apesar de esses fatores poderem ser usados para a avaliao de casos de uso
(PHALP; VINCENT; COX, 2007a), no so definidos critrios objetivos para avaliar
cada um deles assim como nos demais trabalhos (com exceo de (ACHOUR et
al., 1999)). Em um trabalho subsequente, Phalp, Vincent e Cox (2007b) avaliam a
qualidade de dois conjuntos de regras empregando esses fatores de qualidade, o
que feito atravs da correo dos casos de uso por avaliadores. Um outro
problema recorrente nos trabalhos de avaliao da qualidade de casos de uso a
falta de uma anlise dos fatores e dos critrios propostos, ou seja, no se analisa se
esses fatores so realmente importantes para a avaliao de casos de uso.
54
Por fim, uma abordagem para avaliao indireta da qualidade de casos de uso
proposta por Yue, Briand e Labiche (2009). Os autores propem analisar a
qualidade do caso de uso atravs do entendimento do caso de uso (empregando um
questionrio) e atravs da qualidade do modelo de anlise criado a partir do modelo
de caso de uso. Essa abordagem usada uma vez que os autores propem uma
abordagem para criao de casos de uso para auxiliar a criao de modelos anlise.
Tabela 3.2: Fatores de qualidade propostos por (PHALP; VINCENT; COX, 2007a).
Fator
Subfator
Explicao
O caso de uso deve conter tudo o que requerido para responder
Faixa
o problema.
Cobertura
O caso de uso deve conter apenas detalhes relevantes
Escopo
declarao do problema.
O caso de uso deve seguir um caminho lgico com eventos na
Ordem do texto
descrio em uma ordem correta.
Convencimento Dependncias
O caso de uso deve ser completo como uma transao fim-a-fim.
A lgica da descrio do caso de uso deve prover uma resposta
Resposta racional
plausvel para o problema.
As sentenas devem repetir um substantivo da sentena anterior,
Coerncia
se possvel.
Consistncia da abstrao
O caso de uso deve estar em nvel consistente de abstrao.
Caminhos alternativos devem ser excludos do fluxo principal.
Consistncia de Variaes
estrutura
Sequncia
Numerao de eventos no fluxo de eventos deve ser consistente.
Uso do presente. Evitar advrbios, adjetivos, pronomes, sinnimos
Consistncia da gramtica
e negativas.
Deve haver uma seo separada para cada fluxo alternativo do
Separao
fluxo principal.
Considerao de
Viabilidade
Alternativas devem ser viveis e devem fazer sentido.
alternativas
A numerao das alternativas deve combinar com os nmeros do
Numerao
fluxo principal.
3.6 Concluso
Neste captulo foram apresentadas as definies de requisito e de especificao

empregadas neste trabalho, contextualizando-as na rea de Engenharia de
Requisitos e em relao s abordagens de Engenharia de Requisitos orientadas por
metas. Tambm foram discutidas algumas formas de representao de requisitos,
enfatizando o caso de uso. Aps uma anlise das possibilidades de representao
do caso de uso previstas pela UML, foi apresentada uma viso geral da
representao atravs de linguagem natural estruturada. Por fim, discutiu-se a
avaliao da qualidade dos casos de uso, o que ser necessrio para o experimento
discutido no captulo 7.
55
Esse embasamento terico ser usado para a argumentao da proposta deste
trabalho, usando o modelo WRSPM como quadro de referncia. Alm disso, esse
embasamento ser usado para definir a entrada e a sada transformao. No
captulo seguinte ser discutido uma outra rea de conhecimento fundamental para
viabilizar a transformao, a Engenharia Dirigida por Modelos.
56
4 ENGENHARIA DIRIGIDA POR MODELOS (MDE)

Tanto a empresa como os requisitos e as especificaes de um sistema podem ser
representados de diversas maneiras. Neste trabalho essas representaes sero
tratadas na perspectiva da Engenharia Dirigida por Modelos (MDE). A MDE um
paradigma de desenvolvimento e manuteno de sistemas intensivos de software
que, segundo Bzivin (2005), baseado no princpio de que tudo modelo. Com
isso sero considerados neste trabalho modelos de empresa, de requisitos e de
especificaes.
4.1 Modelo
De uma forma geral, um modelo uma representao simplificada da realidade

criada para um determinado propsito. Com isso, ele uma abstrao do que
modelado, apresentando apenas os detalhes pertinentes para o uso pretendido e
omitindo os demais. Esse conceito geral de modelo detalhado por diversos
autores, dependendo da rea de aplicao. Em uma viso de Engenharia, em
(IEEE, 1990, p.133) um modelo definido como "uma aproximao, representao
ou idealizao de aspectos selecionados da estrutura, do comportamento, da
operao, ou de outras caractersticas de um processo, conceito, ou sistema do
mundo real". Essa definio evidencia que um modelo no necessariamente usado
para representar algo que j existe, mas tambm pode ser usado para a criao ou
construo. Alm disso, o modelo no precisa ser uma representao precisa, mas
uma aproximao em que o grau de preciso depende do uso pretendido. O que
modelado, que ser aqui chamado de sujeito, tambm restringido por essa
definio para um processo, conceito ou sistema em geral. Em contraposio, na
definio apresentada por Mellor et al. (2004, p.13), em que "modelos consistem em
conjuntos de elementos que descrevem alguma realidade fsica, abstrata ou
hipottica", o sujeito algo geral. Nesta definio, um outro aspecto do modelo
evidenciado que ele representa diversos elementos, sendo que um desses
elementos pode ser um outro modelo.
57
Especificamente na Engenharia Dirigida por Modelos (MDE), que o foco deste
trabalho, a definio de modelo limita, em geral, o sujeito para sistemas e evidencia
a importncia do uso computacional do modelo. Na definio apresentada por
Kleppe, Warmer e Bast (2003, p.16), por exemplo, um modelo "uma descrio de
parte de um sistema escrita em uma linguagem bem definida". Essa definio
considera que o modelo pode ser uma descrio parcial de um sistema, podendo ser
necessrios diversos modelos para um determinado propsito. Alm disso, essa
definio evidencia a importncia da linguagem usada para criar o modelo. Essa
linguagem, para ser bem definida, deve ter sintaxe e semntica que podem ser
interpretadas de forma automatizada por um computador (KLEPPE; WARMER;
BAST, 2003). Uma outra definio que evidencia a importncia da linguagem usada
pelo modelo apresentada por Bzivin (2006, p.40), na qual modelo "uma
estrutura baseada em grafo representando alguns aspectos de um determinado
sistema e conforme a uma definio de um outro grafo chamado de metamodelo". A
linguagem, nesse caso, um outro modelo o metamodelo (definido na seo 4.2).
Por mais que essa definio seja restrita MDE, as ideias gerais de modelo esto
ainda presentes nesta definio: a questo da abstrao, ao considerar apenas
alguns aspectos do sistema, e a questo da representao simplificada, no caso
limitada ao uso de grafos.
Uma outra definio de modelo, tambm na rea de Engenharia Dirigida por
Modelos e que ser a seguida por este trabalho apresentada por Seidewitz (2003).
Segundo ela, modelo :
Um conjunto de afirmaes sobre um determinado sistema em geral.
Essas afirmaes so expresses que podem ser avaliadas como verdadeiras ou

falsas, como, por exemplo, no modelo de um software a afirmao que uma classe
possui determinados atributos, expressa em um diagrama de classes da UML (OMG,
2011b). De acordo com Seidewitz (2003) e Miller e Mukerji (2003), um modelo pode
ser usado com dois fins: a descrio ou a especificao do sujeito. Caso o modelo
seja usado como descrio, o seu propsito analisar o sistema ao pensar no
modelo; caso o modelo seja usado como especificao, seu propsito definir
restries para a construo de um sistema (SEIDEWITZ, 2003).
58
Essas ideias esto tambm presentes na definio apresentada por Gonzalez-Perez
e Henderson-Sellers (2008) que definem um modelo como um conjunto de
afirmaes sobre um sistema que so homomrficos com o sujeito, isto , o modelo
relacionado ao sujeito via um mapeamento que preserva a estrutura (GONZALEZPEREZ; HENDERSON-SELLERS, 2008). Essa definio evidencia a importncia do
mapeamento entre elementos do modelo e elementos do sujeito, permitindo uma
interpretao do modelo (SEIDEWITZ, 2003). Para que seja possvel concluir algo
sobre o sujeito a partir do modelo necessrio, alm da interpretao, uma teoria,
ou seja, uma forma para deduzir novas afirmaes a respeito do sistema a partir das
afirmaes j expressas no modelo (SEIDEWITZ, 2003). Sendo o modelo uma
descrio, a teoria e a interpretao permitiro dizer, por exemplo, o que acontecer
com um software caso uma determinada entrada seja informada, para isso levando
em considerao o modelo existente. Com isso, a teoria estar correta caso as
afirmaes deduzidas correspondam ao que observado no sistema (com o grau de
preciso considerado). Caso o modelo seja uma especificao, a teoria servir como
base (sendo, portanto, assumida correta) para definir as propriedades que se espera
do sistema, permitindo testar o sistema construdo ao considerar a interpretao.
Por fim, importante ressaltar que assim como podem ser criados diversos sistemas
a partir de um determinado modelo usado como especificao, um sistema pode ser
descrito por diversos modelos. Os modelos podem possuir diferentes propsitos,
diferentes
formas
de
mapeamento
com
sistema,
diferentes
elementos
representados e diferentes representaes, entre outras possveis variaes.
4.2 Viso geral da MDE
Na Engenharia Dirigida por Modelos, os modelos so usados nas atividades de

desenvolvimento e de manuteno como entradas e sadas de ferramentas que
realizam diversas operaes sobre eles e no como simples documentaes
(BZIVIN, 2005). Esse paradigma pode ser aplicado tanto para engenharia direta
em que um sistema criado a partir do modelo , para engenharia reversa em que
um modelo criado a partir de um sistema j existente ou mesmo para obter
modelos em tempo de execuo em que o modelo mantido sincronizado com o
sistema (BZIVIN; BARBERO; JOUAULT, 2007).
59
Segundo Atkinson e Khne (2003), o principal objetivo da MDE aumentar o nvel
de abstrao em que se trabalha com o software. Ao invs da preocupao com
detalhes especficos do ambiente de programao e questes tecnolgicas em
geral, prope-se o foco em ideias e elementos do domnio do problema, o que
permitiria uma representao direta dos conceitos nos modelos criados (BOOCH et
al., 2004). Para isso podem ser usadas linguagens criadas especificamente para um
determinado domnio de aplicao e que permitem representar elementos dele,
chamadas de linguagens especficas de domnio (DSL) (COOK, 2004). Ao permitir
um trabalho em um nvel de abstrao mais alto, as atividades rotineiras de
programao podem ser automatizadas como, por exemplo, o suporte
persistncia, interoperabilidade e distribuio (ATKINSON; KHNE, 2003).
Ferramentas tambm podem apoiar as atividades envolvendo os modelos,
permitindo, por exemplo, a verificao de modelos, o apoio ao mapeamento de
modelos e o teste orientado a modelos (KENT, 2002). Essas diversas formas de
automao aumentariam tanto a produtividade como a adequao das aplicaes ao
negcio (ATKINSON; KHNE, 2003) (BOOCH et al., 2004). Alm da representao
direta e da automao, segundo Booch et al. (2004) e Bzivin (2006), um outro
ponto fundamental do MDE a existncia de padres abertos, o que permite tanto a
interoperabilidade dos modelos entre diferentes ferramentas como tambm encoraja
a criao de ferramentas de uso geral e de uso em domnios especficos.
Um conceito central na MDE, alm do conceito de modelo (apresentado na seo
4.1), o conceito de metamodelo. Seguindo o princpio da MDE de que tudo
modelo, metamodelo ser definido como (CLARK; SAMMUT; WILLANS, 2008a)
(KLEPPE; WARMER; BAST, 2003) (MELLOR; CLARK; FUTAGAMI, 2003):
O modelo que define a linguagem de modelagem usada por um outro modelo.
Dessa forma, metamodelos, segundo Bzivin (2006, p.41), "descrevem os diversos

tipos de elementos contidos no modelo e a forma como eles so arranjados,
relacionados e restringidos". Eles definem a abstrao que ser usada por modelos
que esto em conformidade com ele. Um exemplo de um metamodelo
apresentado na Figura 4.1 em que so representados alguns elementos de uma
biblioteca (vista como um sistema) e seu modelo e metamodelo, seguindo um
modelo de domnio usando a UML (OMG, 2011b). Na biblioteca real existem livros,
60
Classe
instncia de
0..1
*
Propriedade
atributo
2..*
0..1
instncia de
Associao
instncia de
Metamodelo
conforme
Livro
Nome
Autor
1
ISBN
Nmero de pginas
Editora
instncia de
Ficha de
Emprstimo
Cdigo
instncia de
Emprstimo
1
instncia de
Modelo
Data retirada
Data devoluo
instncia de
representado por
Sistema
Livro A
Livro B
Ficha de Emprstimo
(Livro A)
Figura 4.1: Modelo de domnio de uma biblioteca e o metamodelo usado.
como, por exemplo, o livro A e o livro B e fichas de emprstimo associadas a cada

um dos livros, como, por exemplo, a ficha de emprstimo do livro A. Em um modelo
de domnio, esses livros e fichas e as relaes entre eles podem ser representados
como classes e associaes. No caso, h uma classe que representa o livro e seus
atributos a classe Livro. Tanto o livro A quanto o livro B so instncias dessa
classe. Da mesma forma, a ficha de emprstimo representada pela classe Ficha
de Emprstimo e tambm pela classe Emprstimo, sendo que esta ltima representa
cada um dos emprstimos que j foram realizados e que esto anotados na ficha de
emprstimo. Essas classes possuem associaes, representando a relao
existente no domnio entre livros e suas fichas de emprstimo e entre a ficha de
emprstimos e os emprstimos que esto anotados nelas. Para representar esse
modelo foi usado o diagrama de classes da UML e por esse motivo foram descritas
as classes, os atributos e as associaes. Esses conceitos usados pela UML so
especificados em um modelo que define a sintaxe e a semntica deles: o
metamodelo. Nele existe um conceito de classe metaclasse Classe , do qual as
classes Livro, Ficha de Emprstimo e Emprstimo que esto no modelo so
instncias. Da mesma forma, as associaes existentes no modelo so instncias
da metaclasse Associao. Na figura, a relao entre os elementos da biblioteca e
do modelo representada pela seta "instncia de", assim como a relao entre os
elementos do modelo e do metamodelo. Seguindo a terminologia apresentada por
Bzivin (2005), a relao entre o sistema e o modelo chamada de "representado
61
por", enquanto que a relao entre o modelo o metamodelo chamada de
"conforme". Portanto, o modelo est conforme esse metamodelo, enquanto que o
sistema representado pelo modelo.
Classe
instncia de
Classe
instncia de
Metametamodelo
instncia de
0..1
* Propriedade
2..*
atributo
0..1
Associao
conforme
Metamodelo
Figura 4.2: A relao entre os elementos do metamodelo usado no exemplo da Figura 4.1 e o seu
metametamodelo.
A definio de metamodelos fundamental para o MDE, uma vez que como se

pretende operar sobre modelos necessrio que eles sejam definidos formalmente
e os metamodelos permitem essa definio formal. Entretanto, para que o modelo
seja adequadamente definido, o metamodelo tambm precisa ser formalmente
definido. No caso da biblioteca, caso no haja uma definio formal das metaclasses
e de suas metarrelaes, no seria possvel dizer se o conceito de Livro deve ser
expresso como uma Classe, uma Propriedade ou uma Associao. Da mesma
maneira, no se saberia como expressar esse modelo precisamente. Com isso,
necessrio mais um modelo que define a linguagem de metamodelagem, chamado
de metametamodelo. A existncia de um metametamodelo permite que se tenham
diversos metamodelos que seguem a mesma estrutura de representao e o
sistema de tipos definidos por ele (BZIVIN, 2006). Alm disso, a existncia dele
essencial para permitir a coordenao entre os metamodelos, como, por exemplo,
ao permitir algumas operaes entre eles (BZIVIN, 2005). No exemplo da
biblioteca, os elementos definidos no metamodelo (a Classe, a Propriedade e a
Associao) seriam definidos como instncia de um outro conceito, que tambm
chamado de Classe, conforme representado na Figura 4.2 (essa relao
representada na figura pela seta "instncia de"). Entretanto esse conceito de Classe
no o mesmo conceito apresentado pela Classe do metamodelo: um definido
pela UML e outro definido por uma outra especificao, que define a linguagem de
metamodelagem usada pela UML, o MOF (OMG, 2006a). Assim como o modelo
est em conformidade com o metamodelo, o metamodelo est em conformidade
com o metametamodelo (representado na figura pela seta "conforme").
62
Em teoria, assim como um metamodelo precisa de um metametamodelo, poder-se-ia
definir um outro nvel de modelagem um que especifica a linguagem de
modelagem usada pelo metametamodelo. Pelo mesmo motivo que se precisa do
metametamodelo, esse outro nvel de modelagem tambm deveria ser especificado
e assim por diante, obtendo possivelmente infinitos nveis de modelagem. Uma das
formas para evitar esse problema fazer com que o ltimo nvel seja definido
reflexivamente, ou seja, a linguagem usada para defini-lo a prpria linguagem que
ele define (SEIDEWITZ, 2003). Essa soluo, por exemplo, seguida pelo MOF,
citado anteriormente. Mas alm do MOF existem outras especificaes que
permitem a metamodelagem e que seguem essa abordagem como, por exemplo, o
XML Schema (W3C, 2004) e o EBNF (ISO, 1996). Essas especificaes em geral
no so equivalentes, tratando de diferentes Espaos Tcnicos (TS) ou Espaos
Tecnolgicos, ou ainda Infraestrutura de Metamodelagem (CLARK; SAMMUT;
WILLANS, 2008a). Segundo Kurtev, Bzivin e Aksit (2002, p.1), os espaos tcnicos
so um "contexto de trabalho com um conjunto de conceitos associados, corpo de
conhecimento, ferramentas, habilidades necessrias e possibilidades". Na Figura 4.3
exemplificado um TS geral (representado em cinza) que possui 3 nveis de
modelagem dentro dele (modelo, metamodelo e metametamodelo). Cada nvel de
modelagem est em conformidade com o nvel superior (representado pela relao
"conforme") e o nvel mais superior est em conformidade com ele mesmo. Essa
estrutura, por exemplo, a seguida pelo Espao Tcnico da Arquitetura Dirigida por
Modelos (MDA) 23 que usado como base para o exemplo da biblioteca
(representado na Figura 4.1 e na Figura 4.2).
O TS tambm pode ser visto como um arcabouo de gerenciamento de modelos,
definindo os nveis de modelagem existentes (BZIVIN, 2006). Com isso, em um
determinado TS podem existir diversos modelos em um mesmo nvel de
modelagem, a menos do nvel mais superior. No caso de uma organizao em 3
nveis, podem-se ter diversos metamodelos que esto em conformidade com um
mesmo metametamodelo. Como exemplo disso pode-se citar no TS do MDA a
23
O MDA considerado aqui como apenas uma forma de aplicao dos princpios do MDE
(BZIVIN, 2005) (BZIVIN, 2006) (KENT, 2002) (MENS; GORP, 2006). Ele ser discutido na seo
6.1.1.
63
existncia de padres como o UML e o BPDM (OMG, 2008b) que so metamodelos
em conformidade com o MOF (o metametamodelo).
Espao Tcnico
conforme
Metametamodelo
conforme
Metamodelo
conforme
Sistema
representado por
Modelo
Figura 4.3: Representao de um espao tecnolgico com trs nveis de modelagem, segundo
Bzivin (2006).
4.3 Transformao de modelos
Em um determinado TS podem-se realizar diversas operaes entre os modelos

(BZIVIN, 2005). Uma dessas operaes a transformao que, segundo Miller e
Mukerji (2003, p.3.7), "o processo de converter um modelo em outro modelo do
mesmo sistema". Essa converso pode ter como entrada no apenas um modelo,
mas diversos deles, sendo que eles so combinados em um ou mais modelos de
sada (MENS; GORP, 2006). Alm dos modelos de sada, a transformao tambm
tem como resultado um registro que detalha o que foi realizado (MILLER; MUKERJI,
2003). Esse registro ajuda a manter a consistncia entre os modelos caso ocorra
uma mudana em algum deles (KLEPPE; WARMER; BAST, 2003).
Dependendo da transformao, os modelos de entrada e de sada podem estar em
conformidade com o mesmo metamodelo ou com metamodelos diferentes, o que
Mens e Gorp (2006) chamam de transformaes endgenas e exgenas,
respectivamente. Um exemplo de transformao endgena o refatoramento, em
que a estrutura interna do software reorganizada para melhorar alguma
caracterstica de qualidade, enquanto que um exemplo de transformao exgena
a migrao, que transforma um programa de uma linguagem para outra (MENS;
GORP, 2006). No caso das transformaes exgenas, os modelos e os
metamodelos podem at mesmo ser de diferentes espaos tcnicos. Esse tipo de
64
transformao, chamado de Projetor (BZIVIN, 2006), serve como ponte entre os
TSs, permitindo que modelos criados em um determinado TS aproveitem vantagens
que outros Espaos Tcnicos oferecem uma vez que algumas operaes podem
ser mais facilmente realizadas em um determinado TS (KURTEV; BZIVIN; AKSIT,
2002). Um exemplo disso o Projetor que transforma um modelo do espao do
MDA em um modelo do espao do XML (linguagem de marcao extensvel
Extensible Markup Language), buscando com isso aproveitar as facilidades de
intercmbio entre ferramentas que os modelos XML permitem (BZIVIN, 2006).
Para efetivamente transformar os modelos, Miller e Mukerji (2003) apresentam 5
possveis abordagens. Por mais que essas abordagens sejam discutidas no contexto
do TS do MDA, os autores afirmam que elas podem ser usadas "para transformar
qualquer modelo em outro" (MILLER; MUKERJI, 2003, p.5.2). Com isso, elas podem
ser generalizadas para quaisquer transformaes, sejam elas endgenas ou
exgenas. Essas transformaes so baseadas em mapeamentos que proveem
especificaes para transformao do modelo de origem no modelo de destino
(MILLER; MUKERJI, 2003). Dessa forma, Miller e Mukerji (2003) propem as
seguintes abordagens de transformao (MILLER; MUKERJI, 2003):
Marcao: marcas no modelo de origem permitem guiar a transformao ao

modelo de destino, considerando um determinado mapeamento. Essas
marcas representam a identificao de conceitos do modelo de destino
considerando os elementos do modelo de origem.
Transformao de metamodelos: o metamodelo do modelo de origem

mapeado ao metamodelo do modelo de destino.
Transformao de modelos usando tipos: o modelo de origem

especificado usando tipos que podem ter diversos subtipos. Em um modelo
de destino, um desses subtipos escolhido. Com isso, a transformao
considera um determinado mapeamento de um tipo para um determinado
subtipo.
Aplicao de padres: a transformao de metamodelos e de modelos

usando tipos estendida ao considerar padres. Na transformao de
modelos usando tipos uma forma de aplicao de padres identificar os
padres usados no modelo de origem e mape-los a padres (considerando
subtipos especficos) no modelo de destino. No caso da transformao de
65
metamodelos, uma possibilidade que padres identificados no metamodelo
de origem so transformados em padres do metamodelo de destino.
Unio de modelos: dois ou mais modelos podem ser unidos para obter o
modelo de destino.
Por mais que um dos pontos fundamentais do MDE seja a automao, no

necessariamente a transformao deve ser realizada de forma automtica. No caso
da abordagem via marcao obrigatria a interveno humana, j que
necessrio que algum marque o modelo de origem. Nas outras formas de
transformao e mesmo adicionalmente marcao podem tambm ser
acrescentadas algumas informaes, adicionando conhecimento ao modelo de
origem e guiando a transformao (MILLER; MUKERJI, 2003). Em um caso extremo,
a transformao em si pode ser realizada manualmente (MILLER; MUKERJI, 2003).
O importante para que essa transformao siga a ideia da MDE que a origem e o
destino da transformao sejam modelos e que haja um registro da transformao
realizada.
Seguindo o princpio do MDE de que tudo modelo, a transformao tambm pode
ser vista como um modelo (BZIVIN, 2005) (BZIVIN, 2006). Assim como qualquer
outro modelo, a transformao deve estar em conformidade com um metamodelo e
esse modelo em conformidade com um metametamodelo. Essa ideia apresentada
esquematicamente na Figura 4.4. Nela representada uma transformao exgena
em que o modelo de origem tem um metamodelo diferente do modelo de destino,
mas no qual ambos os metamodelos esto em conformidade com o mesmo
metametamodelo. Com isso a transformao opera sobre esses modelos e/ou
metamodelos (dependendo da abordagem seguida), dentro de um mesmo Espao
Tcnico. A transformao em si est em conformidade com um outro metamodelo,
condizente com o mesmo metametamodelo que os metamodelos de origem e de
destino.
Caso a transformao seja um Projetor, ela deve estar ou no Espao Tcnico de
origem ou no destino (BZIVIN, 2006). Considerando o Espao Tcnico como um
arcabouo para gerenciamento de modelos, a transformao um dos recursos que
ele prov, assim como Projetores e linguagens de navegao (BZIVIN, 2006).
Como exemplo de metamodelos de transformao, pode-se citar o padro QVT
66
(Query/View/Transformation) (OMG, 2009) no Espao Tcnico do MDA, o ATL (Atlas
Transformation Language) (JOUAULT; KURTEV, 2006) no Espao Tcnico do EMF
e o XSLT (Extensible Stylesheet Language Transformation) (W3C, 2007) no Espao
Tcnico do XML.
conforme
Metametamodelo
conforme
conforme
conforme
Metamodelo de
origem
Metamodelo de
Transformao
Metamodelo de
destino
conforme
conforme
conforme
Modelo de origem
Transformao
Modelo de destino
representado por
representado por
Sistema
Figura 4.4: Os modelos envolvidos em uma transformao de modelos e a relao entre eles.
4.4 Formas de representao de metamodelos
Como os metamodelos so vistos como linguagens de modelagem para os modelos

que esto em conformidade com eles, uma possibilidade represent-los da mesma
forma como se representa linguagens. Na rea de computao isso feito ao
descrever a sintaxe concreta, a sintaxe abstrata e a semntica (MEYER, 1990). A
sintaxe concreta trata da representao externa da linguagem (MEYER, 1990), ou
seja, da sua notao (GONZALEZ-PEREZ; HENDERSON-SELLERS, 2008). A
sintaxe abstrata define os conceitos, as relaes entre eles e as regras de formao
que definem como eles podem ser combinados (CLARK; SAMMUT; WILLANS,
2008a). Por fim, a semntica define o significado da linguagem (CLARK; SAMMUT;
WILLANS, 2008a), o que pode ser feito de diversas formas (MEYER, 1990). Como
exemplo de metamodelos descritos atravs desses trs aspectos pode-se citar a
UML, o MOF e o BPDM.
Dependendo de como a sintaxe concreta, a sintaxe abstrata e a semntica so
descritas, a linguagem pode ser chamada de formal, semiformal ou informal. As
linguagens informais usam a linguagem natural e, portanto, seguem a sintaxe e a
67
semntica dela (que imprecisa); as linguagens semiformais definem a sintaxe
concreta e abstrata (nem sempre de forma detalhada), mas no definem uma
semntica (ou a fazem usando linguagem natural); e as linguagens formais
representam tanto a sintaxe concreta, abstrata e a semntica. Por mais que um
metamodelo definido como uma linguagem formal permita uma maior preciso em
seu uso, alguns metamodelos no so definidos dessa forma. Por exemplo, o
metamodelo da UML definido usando como sintaxe abstrata o MOF (OMG, 2006a)
e a OCL (OMG, 2006b), como sintaxe concreta grficos para os conceitos e os
relacionamentos entre eles e como semntica uma explicao em linguagem natural
ou seja, ela semiformal.
Uma outra maneira para representar um metamodelo sugerida por Bzivin (2006).
Nela os metamodelos so descritos atravs de diversas informaes, entre elas: o
conhecimento estrutural, que descreve os conceitos definidos pelo metamodelo; o
conhecimento assertivo, que descreve as relaes entre os conceitos e suas
restries; o conhecimento de execuo, que descreve a forma de execuo do
metamodelo, considerando os conceitos e restries existentes; e o conhecimento
de apresentao, que descreve uma forma de representao usada pelo usurio
final (por exemplo, grfica ou textual). Esses conhecimentos so similares s
informaes existentes em uma representao atravs de sintaxe concreta
(equivalente ao conhecimento de apresentao), de sintaxe abstrata (conhecimento
estrutural e assertivo) e de semntica (conhecimento de execuo, considerando
para isso uma semntica de execuo). Uma diferena que a sintaxe abstrata
separada em duas partes, assim como na proposta apresentada por Atkinson e
Khne (2003) em que a sintaxe abstrata trata apenas dos conceitos em si e a "boa
formao" trata das regras usadas para aplicar os conceitos. Mas a principal
diferena dessa diviso em conhecimentos que cada um deles pode ser visto
como um modelo seguindo o princpio do MDE de que tudo modelo e, portanto,
esto em conformidade com um determinado metamodelo. Alm disso, cada um
desses conhecimentos deve ser representado de forma separada, levando a uma
separao de responsabilidades e permitindo a definio de mdulos e o reuso
(BZIVIN, 2006). Por exemplo, o conhecimento de apresentao pode ser descrito
usando os metametamodelos do EBNF ou do XML Schema. Da mesma forma, o
68
conhecimento assertivo pode seguir a metamodelo do OCL (OMG, 2006b), ou algum
outro.
Na prtica, as informaes necessrias para representar um metamodelo so
apresentadas de diversas maneiras, no sendo necessariamente organizadas
atravs de sintaxe e semntica ou atravs de diferentes conhecimentos. Por
exemplo, Yu (1995) apresenta o metamodelo do i* usando a linguagem Telos,
descries textuais, descries grficas e lgica proposicional. Ainda assim, uma
forma comum para se representar parte da sintaxe abstrata (ou do conhecimento
estrutural e assertivo) do metamodelo usando a UML e OCL, devido
popularidade do MDA (BZIVIN, 2005).
4.5 Concluso
Neste captulo foram apresentadas as linhas gerais do paradigma da Engenharia

Dirigida por Modelos, tratando do conceito de modelo, metamodelo e de uma das
operaes que podem ser realizadas no contexto dele, a transformao. Seguindo
esse paradigma, no captulo seguinte ser apresentada a proposta deste trabalho. A
operao de transformao de modelos ser usada para obter um modelo das
especificaes, considerando o WRSPM como quadro de referncia.
69
5 MODELO
DA
EMPRESA
TRANSFORMAO
DE
REQUISITOS
EM
ESPECIFICAES
Uma das principais responsabilidades do engenheiro de requisitos obter um

modelo dos requisitos e transform-lo em um modelo das especificaes, que ento
pode ser usado pelos desenvolvedores como base para as prximas atividades do
desenvolvimento de sistemas. A passagem de um modelo para o outro exige a
aplicao de conhecimento do domnio e representa a tomada de decises que
restringe o espao da soluo.
Neste trabalho proposto que essa passagem seja realizada usando os conceitos
de Engenharia Dirigida por Modelos. Para isso necessrio que haja dois modelos:
um modelo de origem, que o modelo dos requisitos, e um modelo de destino, que
o modelo das especificaes. Como discutido anteriormente, esses modelos
podem ser representados de diversas maneiras, cada um apresentando diferentes
vantagens e desvantagens. A seguir ser discutida a possibilidade e as vantagens
de empregar o modelo da empresa como um ou como esses dois modelos.
5.1 Modelo da empresa, requisitos e especificaes
Em geral modelos do ambiente so usados como modelos de requisitos, conforme

sugerido por Zave e Jackson (1997). Modelos de empresa, por outro lado, so
usados no contexto de desenvolvimento de sistemas para (LEFFINGWELL;
WIDRIG, 2003): (1) entender a estrutura e a dinmica da organizao, (2) garantir
que as partes envolvidas possuam um conhecimento comum da organizao e (3)
entender como novos sistemas podem auxiliar o aumento de produtividade e como
os sistemas existentes sero afetados por ele. O primeiro uso do modelo da
empresa permite entender melhor o ambiente em que o sistema ser inserido,
facilitando a identificao de alguns requisitos e de conhecimentos do domnio que
no seriam normalmente observveis. Dessa maneira o modelo da empresa
apenas mais uma das fontes de requisitos, assim como entrevistas e aplicao de
questionrios. Um exemplo desse uso ocorre no Processo Unificado (JACOBSON;
BOOCH; RUMBAUGH, 1999) ao criar o modelo de negcio. O segundo uso do
70
modelo da empresa permite definir os termos em comum, usando-o para definir
conhecimento do domnio ao invs de ajudar a definir requisitos. A terceira forma
est relacionada com a melhoria do processo de negcio ou reengenharia. A
modelagem empresarial usada para projetar uma nova empresa (ou uma parte
dela) que atenda melhor as condies do negcio, evidenciando como sistemas de
informao podem contribuir para essa melhoria. Esse modelo ento usado como
base para definir os requisitos, detalhando a relao do sistema de informao com
o ambiente que considera essa nova empresa. Abordagens como (BUBENKO JR. et
al., 1998), (CHAMPION; MOORES, 1996) (DECREUS; POELS, 2008) e (DIETZ,
2003) seguem essa viso.
Ao invs de usar um modelo da empresa como um modelo de apoio s atividades
de Engenharia de Requisitos, este trabalho prope o uso do modelo da empresa
diretamente como um modelo dos requisitos. Para isso, a seguir analisada a
relao entre o ambiente e a empresa, posteriormente relacionando a empresa aos
requisitos e, por fim, modelos de empresa modelos dos requisitos e modelos das
especificaes.
5.1.1 Relao entre o ambiente, a empresa e o sistema
Como definido pelo quadro de referncia de requisitos apresentado na seo 3.1, o

ambiente a parte do mundo que ser afetada pelo sistema. Essa parte do mundo
no precisa necessariamente tratar apenas de elementos fsicos; ela tambm pode
incluir informaes, assim como outros elementos intangveis (JACKSON, 1995). O
ambiente , portanto, uma abstrao do mundo, considerando como escopo o
sistema sob considerao. Esse sistema sob considerao pode ser uma empresa,
sendo seu ambiente o mercado que ela se insere, a legislao local que ela deve
seguir, os sindicatos envolvidos etc. Por outro lado, um sistema (computacional)
pode fazer parte do ambiente quando o sistema sob considerao um subsistema
interno a ele ou um outro sistema que o usa. Ou seja, o posicionamento de algo no
ambiente ou no sistema relativo, sendo dependente do sistema que se est
considerando (JACKSON, 1995).
71
Considerando o desenvolvimento de sistemas computacionais, na Figura 5.1
apresentada esquematicamente a relao entre o ambiente, o sistema e a empresa.
Essa relao depende do sistema, sendo que a empresa representada atravs de
uma linha tracejada pode possuir fenmenos que so compartilhados com o
ambiente e/ou com o sistema. Quando o sistema no afeta a empresa, como, por
exemplo, em sistemas de uso pessoal, a empresa no parte do ambiente. Por
outro lado, a empresa claramente faz parte do ambiente no caso de sistemas de
apoio empresa. O sistema oferece suporte ou o meio para que a empresa, ou
parte dela, alcance os fins estabelecidos, portanto afetando-a diretamente. Nesse
caso a empresa uma das principais interessadas no sistema, avaliando a
adequao do sistema ao seu negcio. Alm disso, o sistema interage com partes
da empresa, como seus funcionrios e outros sistemas em geral que existem nela.
Entretanto, normalmente a empresa no todo o ambiente. Outras entidades podem
sofrer efeitos do sistema e o avaliar, muitas vezes at interagindo diretamente com
ele. Por exemplo, tm-se agncias que definem regulamentaes (padres, leis
etc.), empresas parceiras e clientes que utilizaro o sistema, ou mesmo outros
sistemas com os quais o sistema em questo se comunicar. Com isso, por mais
que o sistema seja desenvolvido para a empresa, o ambiente normalmente engloba
fenmenos externos a ela. Da mesma forma, existem partes da empresa que no
fazem parte do ambiente, uma vez que elas no esto envolvidas diretamente ou
indiretamente com o sistema.
Empresa
Ambiente
Sistema
Figura 5.1: Relao entre o ambiente, o sistema e a empresa.
De forma similar relao entre empresa e ambiente, alguns sistemas podem ser
visto como uma parte da empresa. Sistemas empresariais so um dos elementos da
empresa que permitem que ela atinja seus fins, participando de seus processos de
negcio assim como os outros sistemas em geral internos a ela. Entretanto, isso
no significa necessariamente que um sistema precisa ser restrito a uma nica
empresa. Dependendo do caso ele pode ser tambm parte de outras empresas,
72
como, por exemplo, em um sistema de comrcio eletrnico entre empresas
(business to business B2B) disponibilizado por uma empresa para a negociao
de produtos com possveis fornecedores (ou seja, outras empresas): somente os
fornecedores acessam a funcionalidade de venda e a empresa a funcionalidade de
compra. Entretanto, o fato de somente os fornecedores acessarem uma determinada
funcionalidade do sistema no impede que o sistema seja interno empresa. Nesse
caso parte do sistema est na fronteira entre a empresa e seu fornecedor, uma vez
que os fenmenos so compartilhados. Tambm possvel existir um sistema cujos
elementos esto dispersos em vrias empresas, como, por exemplo, um sistema de
agendamento de viagens que precisa reservar um hotel e uma passagem area. A
reserva do hotel ser feita pela parte do sistema que controlada pelo hotel e a
reserva de passagem area ser feita por uma outra parte do sistema que
controlada pela companhia area. Nesse caso tambm possvel analisar a
situao de outras maneiras: cada subsistema pode ser visto como parte de uma
empresa, ou at possvel considerar uma nica empresa, formada pela relao de
negcio dessas duas outras empresas. Portanto o fundamental definir a fronteira
da empresa e do sistema que est sendo considerado.
Em casos limite a empresa pode englobar todo o sistema (quando o sistema
interno empresa) ou todo o ambiente (quando somente a empresa afetada pelo
sistema). Em outras situaes, o ambiente e o sistema podem englobar toda a
empresa (quando toda a empresa afetada pelo sistema, mas existem outros
participantes). Mas de uma forma geral existem fenmenos que so especficos da
empresa, ou seja, no so visveis pelo ambiente e nem pelo sistema, assim como
existem fenmenos do ambiente e do sistema invisveis empresa.
5.1.2 Relao entre a empresa e os requisitos
A relao entre a empresa, o ambiente, o sistema e os requisitos, seguindo o quadro

de referncia, apresentado esquematicamente na Figura 5.2. Os requisitos,
representados como a rea em cinza na figura, so em sua maioria afirmaes
sobre o ambiente. Considerando a relao da empresa com ambiente, algumas das
afirmaes sobre o ambiente so tambm afirmaes sobre a empresa. Essas
afirmaes representam fenmenos da empresa relevantes para o sistema.
73
Entretanto, essas afirmaes no so necessariamente requisitos: algumas delas
podem tratar de conhecimentos do domnio. Por exemplo, para um sistema de
anlise de crdito, as afirmaes que tratam dos relacionamentos entre os cargos
que esto envolvidos com o sistema so, normalmente, conhecimentos do domnio.
Como podem existir partes da empresa que no so afetadas pelo sistema (no
fazendo parte do ambiente), algumas afirmaes sobre a empresa podem no ser
nem conhecimentos do domnio e nem requisitos. No exemplo anterior, afirmaes
sobre os relacionamentos entre cargos que no esto envolvidos com o sistema no
fazem parte do ambiente ou do sistema. Tambm possvel existir afirmaes que
consideram o sistema, mas que tratam de detalhes da operao ou da manuteno
do sistema na empresa, como, por exemplo, o processo de controle de mudana ou
mesmo o processo de implantao do sistema. Essas afirmaes tambm no so
requisitos (ou melhor, podem no s-los) e tampouco conhecimento do domnio.
Empresa
Requisitos
Ambiente
Sistema
Figura 5.2: A relao entre os requisitos e a empresa, considerando o ambiente e o sistema.
Assim como afirmaes sobre a empresa no so necessariamente requisitos,

alguns dos requisitos no so necessariamente afirmaes sobre a empresa.
Quando parte do sistema gerenciada e usada exclusivamente por uma outra
empresa, alguns dos requisitos so afirmaes sobre ela (e no da empresa em
questo). Em outros casos, as afirmaes esto na fronteira entre a empresa e
diferentes partes envolvidas, no sendo, portanto, de exclusividade de uma
empresa.
Como as especificaes so um tipo de requisito que esto na fronteira do ambiente
e do sistema, elas tambm podem estar tanto dentro como fora da fronteira da
empresa. Alm disso, seguindo a definio de requisitos usada por este trabalho,
alguns dos requisitos podem ser tambm afirmaes sobre o sistema por mais que
isso no seja desejvel. Por esse motivo a rea em cinza na Figura 5.2 passa da
fronteira com o sistema. Nos casos em que o sistema interno empresa, essas
74
afirmaes podem ser afirmaes sobre a empresa. Entretanto, nos casos em que
parte do sistema est localizada em outra parte envolvida, esses requisitos tambm
no estaro dentro da fronteira da empresa.
5.1.3 Modelo da empresa e os modelos dos requisitos e das especificaes
Se algumas afirmaes sobre a empresa so afirmaes sobre o ambiente e essas

afirmaes tratam de condies ou capacidades necessrias por um usurio do
sistema ou que precisam ser cumpridas ou possudas pelo sistema, isto ,
requisitos, ento um modelo da empresa que um conjunto de afirmaes sobre a
empresa pode ser visto como um modelo dos requisitos. Mesmo que apenas uma
parte dos requisitos esteja presente nesse modelo, ainda assim ele ser um modelo
dos requisitos, da mesma forma que, por exemplo, um modelo de caso de uso com
escopo de sistema e nvel de detalhamento de sumrio no consegue representar
todos os tipos de requisitos mas no deixa de ser um modelo dos requisitos. Caso
as afirmaes da empresa tratem de especificaes, o modelo da empresa poder
ser visto como um modelo das especificaes.
A principal vantagem do uso do modelo da empresa como modelo dos requisitos ou
das especificaes auxiliar o alinhamento entre a TI e o negcio. A introduo de
um novo sistema causa um impacto na empresa, afetando de diversas formas os
demais elementos envolvidos. Entretanto esse impacto nem sempre o que foi
idealizado e que motivou o desenvolvimento do sistema, seja porque os objetivos
organizacionais no foram adequadamente considerados durante as atividades de
Engenharia de Requisitos (SIKDAR; DAS, 2009), o ambiente considerado durante o
desenvolvimento do sistema diferente do ambiente quando de sua implantao
(THEVENET; SALINESI, 2007), ou at mesmo porque os funcionrios no usam o
sistema como deveriam usar (RAMOS; BERRY; CARVALHO, 2005). Com isso, uma
das preocupaes no desenvolvimento de sistemas em aplicar a "Tecnologia da
Informao de uma forma apropriada e no momento certo, em harmonia com
estratgias, metas e necessidades de negcio" (LUFTMAN, 2000), ou seja, obter o
alinhamento entre a TI e o negcio. Uma das formas de se obter esse alinhamento
incorporar a modelagem empresarial nas atividades de Engenharia de Requisitos
(DECREUS; POELS, 2008) (SIKDAR; DAS, 2009) ou, de uma forma mais geral,
75
considerar um modelo empresarial adequado durante essas atividades (CHAMPION;
MOORES, 1996). Dessa maneira o uso do modelo da empresa como modelo dos
requisitos ou modelo das especificaes pode ser visto como uma forma de se obter
esse alinhamento uma vez que os requisitos esto diretamente relacionados com o
ambiente empresarial.
Alm do alinhamento, o uso do modelo da empresa como modelo dos requisitos ou
das especificaes permite contextualizar os requisitos, representando suas origens
na empresa. Esse mesmo argumento usado pelas abordagens orientadas por
metas, como o i*, Tropos e KAOS, discutidas na seo 3.3, ao considerar a
representao de metas GORE. A possibilidade de relacionar os requisitos a
elementos da empresa permite rastrear decises (BUBENKO JR. et al., 1998) e, ao
representar a origem dos requisitos, possvel compreender mudanas nas
necessidades da empresa (YU; MYLOPOULOS; LESPERANCE, 1996). Entretanto,
o quanto essas informaes so evidenciadas depende da representao usada,
sendo possvel, por exemplo, relacionar os resultados desejados aos requisitos
pretendidos de forma similar s abordagens GORE , relacionar os requisitos aos
processos de negcio que o sistema participa, ou mesmo relacionar os requisitos a
outras informaes da empresa.
Por fim, uma outra vantagem que o uso do modelo da empresa facilita a
comunicao entre o engenheiro de requisitos e os especialistas do domnio (DE LA
VARA; SANCHEZ; PASTOR, 2008). Como os especialistas do domnio muitas vezes
no possuem experincia em computao, algumas das representaes usadas
dificultam o entendimento e a validao dos requisitos (DE LA VARA; SANCHEZ;
PASTOR, 2008). Em contraposio, o modelo da empresa pode ser expresso em
uma linguagem mais prxima daquela usada por esses especialistas, o que pode
facilitar o entendimento evitando erros na definio dos requisitos.
Por outro lado, o uso do modelo da empresa dessa forma apresenta alguns
problemas ou desvantagens:
Outras partes envolvidas definem requisitos. No caso de sistemas

computacionais distribudos entre diversas empresas, apenas uma parte do
ambiente representada pelo modelo de uma dessas empresas. Com isso,
apenas alguns dos requisitos esto representados nesse modelo, sendo
76
necessrio considerar os modelos das demais empresas (ou das partes
envolvidas) para obter um modelo dos requisitos mais completo.
Dificuldade de expresso de restries de projeto (design) e alguns

requisitos no funcionais. Como um modelo da empresa busca descrever a
empresa e no os requisitos de um sistema computacional interno a ela a
linguagem usada pode no possuir termos capazes de representar
adequadamente os requisitos. Como as restries de projeto representam
detalhes internos do sistema ou do projeto dele, dificilmente elas estaro
presentes em um modelo da empresa. Por outro lado, os requisitos funcionais
s sero descritos se a linguagem permitir representar o uso do sistema,
permitindo inferir suas funcionalidades. Algumas restries a essas
funcionalidades, que so os requisitos no funcionais, dificilmente estaro
representadas no modelo da empresa, uma vez que elas no causam um
efeito direto no ambiente empresarial. Usando a norma ISO 9126 (ISO, 2001)
como terminologia para os requisitos no funcionais, requisitos que tratam de
qualidades como confiabilidade e manutenibilidade dificilmente estaro
representados uma vez que so especficas ao sistema e no afetam
diretamente (ou constantemente) outras partes da empresa. Mesmo
qualidades como usabilidade, portabilidade, funcionalidade e eficincia, que
de alguma forma afetam diretamente outros elementos da empresa, s sero
representadas se essas qualidades forem relevantes para a linguagem usada
para a descrio do modelo da empresa.
Excesso de informaes irrelevantes ao sistema. Uma empresa engloba

outros elementos alm do sistema que est sendo considerado. Muitos
desses elementos no interagiro com o sistema em questo e tampouco
sero afetados por ele ou seja, no faro parte do ambiente. Do ponto de
vista de um modelo dos requisitos ou das especificaes, essas outras
informaes
no
so
relevantes
e,
portanto,
no
precisariam
ser
representadas. Mais que isso, o excesso delas pode at tornar difcil o uso do
modelo da empresa para esse fim, uma vez que o tornaria mais complexo que
o necessrio.
Dificuldade de criar e manter um modelo da empresa. A quantidade de

elementos que fazem parte de uma empresa e a relao muitas vezes
complexa entre eles faz com que no seja simples criar um modelo da
77
empresa. Alm disso, a dinmica dos negcios faz com que o contexto do
qual a empresa faz parte altere-se rapidamente e frequentemente (FOX,
1993). Com isso, manter um modelo como esse atualizado pode ser uma
atividade bastante trabalhosa.
Por mais que esses problemas dificultem o uso de modelos de empresa como
modelo dos requisitos e das especificaes, algumas consideraes e at mesmo
algumas heursticas podem diminuir o impacto desses problemas. O fato de o
modelo da empresa ser uma descrio incompleta dos requisitos pode ser superado
ao considerar que esse modelo apenas uma descrio parcial deles, assim como
um modelo de caso de uso, por exemplo. Para que ele seja usado, necessrio
acrescentar outras informaes que permitam descrever os demais requisitos. O
mesmo vale para a dificuldade de representao das restries de projeto e de
alguns requisitos no funcionais. Quanto ao excesso de informaes, uma soluo
simplificar o modelo para o uso na Engenharia de Requisitos, abstraindo algumas
das informaes. Ao fazer isso tambm se tornaria mais fcil criar e manter um
modelo da empresa, endereando essa outra dificuldade.
Especificamente no uso do modelo da empresa como um modelo das
especificaes, parecem existir dois outros problemas. O primeiro que o
metamodelo da empresa deve permitir a representao detalhada da relao do
sistema com o ambiente. Para isso seria necessrio definir um metamodelo de
empresa especial para seu uso como especificao, o que diminuiria algumas das
vantagens de se usar um modelo da empresa. O segundo problema que como a
especificao trata da fronteira do ambiente com o sistema, ela deve ser mais
tcnica para que seja usada pela equipe de desenvolvimento. Com isso,
fundamental que ela seja mais objetiva, sem representar algumas das informaes
do modelo da empresa que no so relevantes para o desenvolvimento. Dessa
maneira, por mais que um modelo da empresa possa ser usado como modelo das
especificaes, j que tais afirmaes podem estar presentes nesse modelo, no
parece ser apropriado us-lo para esse fim.
78
5.1.4 Modelo da empresa e sistemas de automao de processos
Para que o modelo da empresa seja usado como modelo dos requisitos ou das
especificaes fundamental que ele represente afirmaes sobre o sistema
computacional em questo. Por exemplo, no caso de um sistema de automao do
processo de contratao de funcionrios, poucos requisitos (ou talvez nenhum)
estaro presentes em um modelo financeiro da empresa. Isso pode ser visto tanto
como um problema da capacidade de representao do metamodelo usado, quanto
da adequao desse metamodelo ao escopo ou tipo de sistema em questo. No
caso, um modelo financeiro talvez seja apropriado para representar os requisitos de
um sistema contbil (adequao do metamodelo ao sistema), mas se esse modelo
financeiro apenas for um balano patrimonial, ele dificilmente possuir afirmaes
sobre o sistema (incapacidade de representao do metamodelo). Dessa maneira,
importante que a representao da empresa seja condizente com o tipo de sistema
tratado.
Em relao ao tipo de sistema, mesmo que a representao da empresa seja
apropriada, dependendo da relao entre a empresa e o ambiente alguns requisitos
importantes podem no ser representados no modelo usado. Isso fica evidente ao
considerar um sistema distribudo que tem uma pequena parte gerenciada e usada
pela empresa modelada. Se nesse caso o modelo da empresa for usado como
modelo dos requisitos, ento muitos dos requisitos no estaro representados.
Portanto, o uso do modelo da empresa como modelo dos requisitos ou modelo das
especificaes est limitado a apenas uma classe de problemas. De uma forma
geral, a modelagem empresarial na Engenharia de Requisitos mais til quando o
domnio de aplicao complexo e existem diversas pessoas diretamente
envolvidas com o sistema (LEFFINGWELL; WIDRIG, 2003). O mesmo parece ser o
caso para o uso como modelo dos requisitos ou das especificaes. Quando o
impacto causado pela insero do sistema est limitado a uma pequena parte da
empresa, ou seja, a poucos elementos empresariais, o uso do modelo da empresa
permitir representar uma parcela muito pequena dos requisitos, sendo pouco til.
Da mesma forma, para sistemas em que algoritmos e frmulas matemticas
possuem grande importncia (como o caso de sistemas especialistas), o modelo
da empresa tambm no ser um bom modelo dos requisitos ou das especificaes.
79
Dessa forma, este trabalho trata de um tipo especfico de sistemas que interno
empresa e que enfatiza a troca de informaes entre elementos dela. Nesse caso, a
empresa engloba todo o sistema e boa parte do ambiente (quando o sistema no
tem influncias de elementos externos empresa, ele engloba todo o ambiente).
Esse tipo de sistema ser chamado de sistemas de automao de processos,
possuindo as seguintes caractersticas:
Automatizam processos de negcio, com foco no fluxo de trabalho; e
So internos a uma empresa, mas podem possuir algumas interfaces com

outros participantes.
Mesmo para esse tipo de sistema fundamental escolher um metamodelo

adequado, que consiga representar os requisitos. Considerando que o escopo deste
trabalho apenas os requisitos funcionais, uma primeira ideia seria considerar um
modelo de processo de negcio como modelo da empresa. Porm, apesar da
importncia do processo de negcio, ele apenas uma das vises da empresa. Ao
considerar apenas essa viso, talvez no seja possvel representar um conjunto
suficiente de requisitos funcionais em um modelo da empresa. Uma outra
possibilidade seria seguir as abordagens orientadas por metas e representar a
empresa atravs de suas motivaes. Entretanto, o mesmo argumento contra o
modelo de processo pode ser usado, j que essa representao limitada a apenas
uma das vises da empresa. Por mais que conceitos como, por exemplo, planos e
recursos tambm sejam representados, eles so feitos de forma bastante
simplificada.
Buscando uma representao mais abrangente da empresa, uma possibilidade
usar a arquitetura empresarial (discutida na seo 2.1) como modelo da empresa.
Entretanto, como a arquitetura empresarial enfatiza a relao do negcio com a
Tecnologia da Informao, esse modelo trata naturalmente de detalhes dos sistemas
como, por exemplo, na arquitetura tecnolgica no TOGAF (THE OPEN GROUP,
2009) e nos modelos de sistema, tecnologia e componentes do arcabouo de
Zachman (SOWA; ZACHMAN, 1992). Dessa maneira, os requisitos e, dependendo
do caso, at outras informaes mais detalhadas sobre ele j esto representados
explicitamente nesses modelos. Diferentemente disso, a proposta deste trabalho
usar um modelo da empresa em que os requisitos esto representados na descrio
80
dos elementos empresariais e das relaes entre eles. Portanto, se pretende usar
apenas uma parte da arquitetura empresarial a que trata especificamente da
organizao da empresa. Como discutido na seo 2.2, as representaes da
empresa na rea de Organizao e Mtodos tratam exatamente dessa viso, no
considerando os sistemas computacionais como um elemento central. Os modelos
criados por abordagens dessa rea possuem um ponto de vista organizacional,
representando, por exemplo, a estrutura hierrquica da empresa, seus processos,
suas polticas etc. Por isso, sero usadas neste trabalho como base para o
metamodelo de empresa. Dessa forma, este trabalho considera a seguinte hiptese:
H1. Um modelo da empresa do ponto de vista organizacional representa
requisitos funcionais de sistemas de automao de processos.
importante ressaltar que no se est considerado nessa hiptese que todos os
requisitos estaro representados em um modelo desse tipo, mas supe-se que uma
grande parte deles possa ser.
5.2 Transformao de requisitos em especificaes
A obteno das especificaes a partir dos requisitos pode ser feita de diversas
formas. Um engenheiro de requisitos pode empregar mtodos, utilizar ferramentas e
aproveitar bases de conhecimentos para obter um a partir do outro. Por exemplo,
nas abordagens orientadas por metas Tropos (BRESCIANI et al., 2004) e KAOS
(DARDENNE; VAN LAMSWEERDE; FICKAS, 1993) o refinamento feito,
basicamente, atravs de diagramas de metas GORE. Em outras abordagens as
especificaes so obtidas a partir de mtodos baseados em heursticas a respeito
dos modelos empregados, como, por exemplo, nas propostas de Molina et al. (2000)
e De La Vara, Sanchez e Pastor (2008). Seguindo essa linha, uma possvel forma de
obter especificaes atravs de transformao de modelos, empregando os
conceitos de Engenharia Dirigida por Modelos (MDE).
Para transformar requisitos em especificaes seguindo a MDE necessrio definir
um modelo dos requisitos como origem para obter um modelo das especificaes
como destino. Uma vez que as especificaes restringem a soluo ao considerar
uma alternativa especfica essa transformao no apenas uma mudana da
81
notao usada, mas uma mudana semntica. Para isso so necessrias regras de
transformao que usam o conhecimento do domnio e que consigam abstrair a
escolha de uma alternativa especfica.
Existem alguns benefcios de se executar o refinamento dos requisitos em
especificaes
como
uma
transformao.
Primeiramente,
uso
de
uma
transformao ajudaria a evitar alguns erros durante o processo de refinamento,

uma vez que as regras empregadas dariam apoio atividade do engenheiro de
requisitos mesmo no caso de uma transformao semiautomtica. Mais que isso,
seria mais simples realizar a atividade de refinamento, diminuindo o tempo
necessrio para realiz-la. Um outro benefcio que mudanas nos requisitos ou no
ambiente, o que comum em contextos empresariais, seriam mais bem gerenciadas
em uma transformao. De uma forma geral, caso a mudana impacte nos
requisitos, necessrio rever apenas o refinamento realizado; se a mudana
impacte nas decises tomadas durante o refinamento, apenas essas decises
precisam ser reanalisadas; e se a mudana impacte nas especificaes, apenas as
especificaes precisam ser revistas, no precisando analisar os requisitos ou o
refinamento realizado. Portanto, importante representar tanto os requisitos quanto
as especificaes, juntamente com as decises tomadas durante o refinamento o
que feito em uma transformao. Alm disso, caso os requisitos no sejam
representados, o sistema pode ser inadequadamente restrito e, caso as
especificaes no sejam representadas pode ser difcil realizar as prximas
atividades de desenvolvimento (MAIDEN, 2008). Por fim, a definio do refinamento
como uma transformao tem o benefcio terico de melhorar o entendimento da
relao entre os requisitos e as especificaes.
Considerando esses benefcios, este trabalho prope a transformao de requisitos
em especificaes, limitando-a aos requisitos funcionais. Entretanto, como cada
domnio de aplicao possui particularidades que afetam diretamente o refinamento
e, consequentemente, as regras de transformao, necessrio escolher um
domnio especfico para realizar a transformao. Dessa forma, este trabalho
considera como escopo sistemas de automao de processos, propondo o uso do
modelo da empresa como modelo dos requisitos. Alm das vantagens de usar o
modelo da empresa dessa forma auxiliar o alinhamento entre a TI e o negcio,
permitir a contextualizao dos requisitos e facilitar a comunicao com os
82
especialistas do domnio , ao considerar a hiptese H1 o modelo da empresa para
esse tipo de sistema seria capaz de representar os requisitos funcionais. Porm,
para viabilizar a transformao necessrio tanto os requisitos como o
conhecimento do domnio, uma vez que o refinamento feito ao empregar esse
conhecimento, conforme discutido na seo 3.1. Dessa forma, o modelo da empresa
usado na transformao proposta por este trabalho representa dois momentos
distintos da empresa: como ela atualmente (as-is) e como ela ser ou como se
espera que ela fique com o sistema idealizado (to-be), seguindo a representao
do ambiente proposta por Zave e Jackson (1997). O motivo disso que, a menos
que haja uma reengenharia completa da empresa, as atribuies do sistema
computacional na empresa to-be estaro representadas no modelo as-is como
atribuies de outros elementos da empresa. Portanto os requisitos estaro
presentes apenas no modelo to-be, uma vez que apenas nesse modelo existe o
sistema, mas o conhecimento do domnio estar presente em ambos os modelos.
Como no modelo to-be o sistema absorve algumas responsabilidades de outras
partes da empresa, parte do conhecimento do domnio relacionado a algumas
dessas responsabilidades est presente apenas no modelo as-is. Dessa forma, este
trabalho considera a seguinte hiptese:
H2. Em projetos em que no h uma reengenharia completa da empresa, o
modelo as-is da empresa possui parte do conhecimento de domnio
necessrio para se refinar requisitos em especificaes.
Considerando as hipteses H1 e H2, a proposta deste trabalho empregar os
conceitos de MDE para transformar um modelo dos requisitos funcionais, descrito
atravs de modelos de empresa as-is e to-be, em especificaes ao empregar um
conjunto de regras. Portanto, a hiptese central deste trabalho :
H3. Em sistemas de automao de processos possvel automatizar a
transformao de requisitos presentes em um modelo da empresa em
especificaes.
83
5.2.1 Limitaes da transformao
A transformao proposta por este trabalho apresenta algumas particularidades em

relao a um refinamento de requisitos em especificaes. A ideia do refinamento,
de acordo com Zave e Jackson (1997), uma analogia ao refinamento de
programas no qual um programa gradualmente desenvolvimento a partir de
especificaes atravs de passos de refinamento (DIJKSTRA, 1968) (WIRTH, 1971).
Em cada passo de refinamento so tomadas vrias decises de projeto pelo
programador (WIRTH, 1971), sendo assim possvel obter como resultado diferentes
programas que atendem as especificaes definidas (DIJKSTRA, 1968) (WIRTH,
1971). No caso de uma transformao de requisitos em especificao, no h
claramente passos sendo executados ainda que se possa considerar que cada
regra de transformao aplicada um passo. Alm disso, este trabalho considera
como hiptese que, em algumas situaes, essa passagem pode ser automatizada
(hiptese H3). Mesmo assim a transformao toma diversas decises de projeto e
aplica o conhecimento do domnio de forma similar ao refinamento de requisitos em
especificaes apresentado por Zave e Jackson (1997). Por esse motivo, essa
transformao ser considerada aqui como uma forma de refinamento seguindo os
conceitos de MDE.
Alm do refinamento de requisitos em especificaes e o refinamento das
especificaes em programas, em abordagens orientadas por metas como i*, Tropos
e KAOS, h um refinamento de metas GORE at se obter os requisitos e,
finalmente,
as
especificaes
(CASTRO;
KOLP;
MYLOPOULOS,
2001)
(DARDENNE; VAN LAMSWEERDE; FICKAS, 1993) (VAN LAMSWEERDE, 2009),

usando para isso os diagramas de metas. De acordo com Robinson e Elofson
(2004), as metas GORE so apenas afirmaes sobre o ambiente, no definindo
uma restrio ao comportamento do sistema. Com isso, elas so refinadas ao
adicionar detalhes at se obter os requisitos que estes sim, restringem o
comportamento do sistema.
Considerando essas trs formas de refinamento, possvel extrapolar que o
desenvolvimento de software nada mais que uma sequncia de refinamentos. Um
conjunto de metas GORE refinado at se obter requisitos; os requisitos so ento
84
refinados em especificaes; e as especificaes so refinadas at um software. De
uma forma geral esse refinamento envolve a tomada de decises que restringem o
espao da soluo ao selecionar entre possveis alternativas. Ao final do processo
de desenvolvimento se tem o espao da soluo restrito a uma nica opo que
o software construdo. Dependendo da abordagem considerada, os momentos
nesse processo de refinamento podem ser diferenciados em, por exemplo:
Resultado desejado: representa o que as partes envolvidas pretendem com

a construo do sistema (representado em um modelo motivacional usando,
por exemplo, o BMM (OMG, 2008a));
Ambiente desejado: o resultado desejado refinado atravs de decises

sobre o ambiente, obtendo uma representao de como se deseja que o
ambiente fique com a presena do sistema (representado em um modelo dos
requisitos);
Sistema desejado: o ambiente desejado refinado atravs de decises

sobre o sistema no ambiente em questo, definindo detalhadamente as
responsabilidades
do
sistema
(representado
em
um
modelo
das
especificaes);
Sistema projetado: as responsabilidades do sistema so refinadas atravs

de decises de projeto do sistema, obtendo uma definio de como o sistema
deve realizar as suas responsabilidades (representado em um modelo de
projeto); e
Sistema construdo: a partir do sistema idealizado so tomadas decises de

implementao que resulta no sistema criado.
Cada um desses momentos restringe mais o espao da soluo que o momento

anterior, como representado esquematicamente na Figura 5.3. Quando se tem
definido o resultado desejado, j h uma restrio no espao da soluo, mas ainda
assim existem diversos sistemas possveis. Ao tomar decises de como se deseja
que o ambiente fique ao considerar o sistema, o espao da soluo restrito a um
subconjunto do espao inicial. Essas restries so sucessivamente realizadas at
se chegar ao sistema construdo que corresponde a uma nica soluo.
Dentre esses momentos, dois so especialmente importantes para este trabalho: o
do ambiente desejado, que representado atravs de um modelo dos requisitos, e o
do sistema desejado, que representado atravs do modelo das especificaes.
85
Como discutido anteriormente na seo 3.1, esse refinamento feito atravs do
emprego de conhecimentos do domnio que, portanto, permitem restringir o espao
da soluo. Tratando da proposta deste trabalho, isso significa que a transformao
envolve a tomada de um conjunto de decises, usando as informaes presentes no
modelo da empresa, para obter como resultado um modelo de caso de uso. Por
mais que o escopo de sistemas de automao de processos proveja algumas
hipteses para auxiliar essa tomada de decises, como o escopo ainda muito
abrangente, algumas das decises tero que ser tomadas por uma pessoa. Dessa
maneira, algumas heursticas exigiro a interveno humana seja atravs do uso
de marcaes, ou de alguma outra forma.
Espao da soluo
Resultado Desejado
Ambiente Desejado
Sistema Desejado
Sistema Projetado
Sistema Construdo
Figura 5.3: A restrio do espao da soluo, considerando alguns momentos especficos, at se

obter o sistema construdo.
Uma outra limitao proveniente da impossibilidade de garantir que a

transformao
cubra
todos
os
casos
de
refinamento
de
requisitos
em
especificaes. Alm de possveis problemas no metamodelo de empresa que

impeam a representao de algumas informaes e no metamodelo de
transformao que impeam a representao de algumas regras, dada a
abrangncia do escopo, talvez no seja prtico ou mesmo possvel representar
todas as regras de transformao. Pelo mesmo motivo, possvel que algumas
regras no sejam aplicveis em algumas situaes especficas. De forma similar,
algumas informaes adicionais ou mesmo decises podem ser necessrias para
que uma regra seja aplicada. A implicao disso que, dependendo do sistema, a
transformao ou o resultado dela pode necessitar a interveno de um engenheiro
de requisitos, possivelmente realizando alguns refinamentos manualmente. Ou seja,
no se espera obter uma transformao completamente automtica.
Mesmo caso o metamodelo de empresa permita representar todos os tipos de
informao, existem alguns fenmenos que no esto dentro da fronteira da
86
empresa estando na fronteira de outras partes envolvidas , conforme discutido
anteriormente. Alm disso, nem todos os requisitos estaro presentes em um
modelo da empresa. Dessa maneira, no se espera que o modelo da empresa
represente todos os requisitos de qualquer sistema de automao de processos.
Por fim, existe a limitao do uso de linguagem natural. Por mais que seja definido
um metamodelo, como um modelo da empresa tem que ser naturalmente entendido
por especialistas do conhecimento do domnio, algumas informaes devero ser
representadas usando linguagem natural. Dada a dificuldade de processar
linguagem natural, isso significa que algumas informaes do modelo da empresa
no podero ser usadas pela transformao, restringindo as regras.
5.3 Trabalhos relacionados
A obteno das especificaes a partir dos requisitos no um problema novo,

existindo diversos trabalhos que tratam disso de forma metdica e com apoio
ferramental. A seguir so apresentados alguns desses trabalhos, analisando suas
diferenas em relaes a esta proposta.
5.3.1 Abordagens orientadas por metas
Assim como a proposta deste trabalho, as abordagens orientadas por metas i*,
Tropos e KAOS definem formas para obter especificaes a partir de uma abstrao
do ambiente. Porm, nessas abordagens o ambiente representado de uma forma
fragmentada: os elementos do ambiente abstrados como metas GORE e agentes
so representados caso seja identificada alguma relao com o sistema. Ainda
que sejam representadas algumas outras informaes do ambiente que no so
diretamente relacionadas com o sistema (como relaes entre agentes), a viso do
ambiente como um todo limitada. Alm disso, alguns elementos relevantes
precisam ser abstrados como metas GORE para que possam aparecer no modelo,
desassociando-os da sua origem. Considerando o contexto empresarial, a
expectativa deste trabalho que ao se representar o ambiente de forma mais
detalhada se obtenha uma viso mais precisa dos elementos relevantes,
87
apresentando o seu contexto. Alm de auxiliar a obteno de requisitos, isso permite
o alinhamento da TI com o negcio e facilita a rastreabilidade com os elementos do
negcio.
Uma outra diferena que a proposta deste trabalho separa os requisitos no
refinados das especificaes, enquanto que nessas abordagens ambos so
representados em um nico modelo. Tanto os requisitos como as especificaes so
representados como metas GORE, sendo que a diferena o refinamento dela. Por
exemplo, no mtodo Tropos os requisitos so inicialmente representados pela
relao entre os agentes e o sistema atravs de metas de sistema e outros
conceitos delegados ao sistema (BRESCIANI et al., 2004), enquanto que as
especificaes so obtidas com o refinamento dessas informaes. De forma similar,
no mtodo KAOS (RESPECT-IT, 2007) (VAN LAMSWEERDE, 2009) o diagrama de
metas representa os requisitos no refinados e as especificaes, sendo que as
especificaes so as metas que esto sob responsabilidade de apenas um agente.
A organizao empregada pelas abordagens GORE tende a evitar a restrio dos
requisitos sem uma anlise apropriada o que um problema caso apenas as
especificaes sejam representadas (JACKSON, 1995) , alm de permitir a
discusso de alternativas, o que no possvel nesta proposta. Por mais que os
requisitos e as especificaes sejam representados em apenas um modelo, h uma
grande preocupao na passagem de um para o outro, sendo possvel distinguir
essas informaes e o motivo das especificaes obtidas. Entretanto, o impacto
disso que o modelo criado nessas abordagens se torna mais complexo e, alm
disso, os conhecimentos do domnio acabam sendo descritos de forma limitada, uma
vez que eles so restritos representao em metas GORE e outros elementos
relacionados. Em compensao representada a razo da passagem de requisitos
em especificao, algo que ao se utilizar modelos separados deve ser feita em
alguma outra representao no caso dessa proposta, atravs da transformao.
Em todas as abordagens GORE a passagem dos requisitos para especificaes
feita manualmente, apresentando algumas tcnicas para que seja realizado o
refinamento. Ainda assim existem ferramentas que podem ser usadas para apoiar a
atividade de modelagem, como o caso da Objectiver para o KAOS (DELOR;
DARIMOND; RIFAUT, 2003) e da TAOM4E para o Tropos (SUSI et al., 2005). Em
contraposio, neste trabalho a ferramenta proposta trata tanto da modelagem
88
quanto da transformao, permitindo que parte do refinamento seja realizada de
forma automtica.
Uma outra diferena entre as abordagens GORE e esta proposta elas adotam uma
premissa que o engenheiro de requisitos deve definir as responsabilidades do
sistema computacional a ser construdo (como apresentado na seo 3.3). Nelas, o
ambiente as-is (ou, de uma forma geral, as intenes das partes envolvidas)
representado e serve como base para determinar o ambiente to-be, incluindo as
responsabilidades do sistema. Isso feito pelo engenheiro de requisitos ao levantar
e analisar as metas GORE. No mtodo Tropos e no arcabouo i* o engenheiro de
requisitos quem delega as responsabilidades de outras partes envolvidas ao
sistema; no mtodo KAOS, ele quem levanta novas oportunidades e atribui
responsabilidades ao sistema; no arcabouo B-SCP, ele quem detalha o ambiente
de negcio. Em contraposio, esta proposta assume que a responsabilidade de
definir o ambiente to-be no precisa fazer parte da Engenharia de Requisitos. Essa
modelagem pode ser feita por um especialista do negcio com ajuda de um
engenheiro de requisitos, o que permite alinhar mais adequadamente o sistema ao
negcio e no o negcio ao sistema.
Especificamente em relao ao arcabouo B-SCP, nele no h uma separao do
ambiente as-is do ambiente to-be, j que o arcabouo aplicado apenas ao
ambiente to-be. Assim como as abordagens i*, Tropos e KAOS, o B-SCP no separa
os requisitos das especificaes. Em compensao, o B-SCP considera o contexto
empresarial, assim como a proposta deste trabalho, ao considerar um diagrama de
contexto e relacion-lo s metas. Porm, por ser um arcabouo, ele no trata
claramente de atividades de Engenharia de Requisitos, similarmente ao i*. Ainda
assim, tanto ele como o i* podem ser usados para a elicitao e anlise e
negociao ou tambm para a atividade de consolidao.
Existem alguns trabalhos que se baseiam nas abordagens GORE e as estendem ao
considerar a importncia de alguns dos aspectos tratados pela proposta deste
trabalho. O alinhamento do sistema ao negcio , por exemplo, tratado por Sikdar e
Das (2009) que propem uma abordagem baseada no i* para a avaliao inicial da
viabilidade de um sistema. O modelo de razo estratgica modificado para
incorporar resultados esperados e crenas (representados como metas GORE),
89
alm de dados que indicam como alguns fatores decididos pelo analista so
tratados por cada alternativa de soluo. Uma outra abordagem baseada no i* que
trata do alinhamento apresentada por Decreus e Poels (2008). Ao invs de
modificar o modelo de razo estratgica, ele mapeado em dois outros modelos:
um de negcio (que representa os atores envolvidos no negcio e os recursos
transferidos entre eles) e um de processo de negcio. O mapeamento das metas
GORE em um modelo de negcio permite alinh-las ao negcio enquanto que o
mapeamento em um processo de negcio permite detalh-las. O objetivo com esse
mapeamento fazer com que as metas GORE sejam mais bem especificadas numa
fase de requisitos iniciais, considerando informaes do negcio. Entretanto, por
mais que essas duas abordagens permitam um melhor alinhamento com o negcio e
representem mais informaes que as originalmente propostas pelo i*, ambas tratam
apenas da fase de requisitos iniciais. Dessa forma, ambas tratam apenas dos
requisitos, no tratando das especificaes.
Baseando-se na abordagem Tropos e tambm tratando do alinhamento do sistema
ao negcio, Martnez et al. (2008) apresentam um mtodo para a transformao
manual de um modelo empresarial, representado em diagramas de metas, em um
diagrama de metas do sistema to-be, usando padres. O mtodo, portanto, restrito
s fases de requisitos iniciais e finais do Tropos, podendo ser usados outros
mtodos para as demais fases. De uma forma geral, as principais diferenas desse
mtodo em relao ao Tropos so a definio e uso de critrios organizacionais de
seleo de alternativas, chamados de fatores de qualidade, e a existncia de uma
forma sistemtica para se obter o diagrama de metas na fase de requisitos finais,
considerando alguns padres de alto nvel e marcaes nos diagramas de metas.
Em relao aos modelos de requisitos e de especificaes, pode-se dizer que essa
proposta separa-os, uma vez que o modelo dos requisitos pode ser visto como os
planos que devem ser automatizados no diagrama de metas da fase de requisitos
iniciais. Em compensao, esse diagrama se torna uma representao tanto do
modelo as-is como do modelo to-be.
90
5.3.2 Abordagens que empregam casos de uso
Diversas propostas de transformao envolvendo requisitos e especificaes tm

como resultados modelos de casos de uso. Em algumas delas, os casos de uso
podem ser vistos como modelos de requisitos, como o caso do trabalho de
Dijkman e Joosten (2002a) (2002b) e Stolfa e Radeck (2004). Nessas duas
propostas, a transformao tem como origem modelos de processo de negcio
descritos em diagrama de atividades e como destino diagramas de casos de uso,
ambos baseados na UML. Nessas abordagens, os modelos de processo de negcio
representam o ambiente as-is, ou seja, no consideram a presena do sistema. Para
a transformao esse modelo anotado com informaes do que ser
automatizado, tambm sendo agrupadas algumas das atividades. O resultado, na
proposta de Stolfa e Radeck (2004) um diagrama de casos de uso24, enquanto
que em Dijkman e Joosten (2002a) (2002b), alm do diagrama, se obtm o cenrio
principal e o cenrio secundrio, alm de seus passos entretanto, esses passos
so apenas as tarefas do processo as-is, sem um detalhamento. Especificamente na
proposta de Dijkman e Joosten (2002a) (2002b) seguida a filosofia da MDE ao
descrever uma transformao de metamodelos, tambm sendo apresentado um
algoritmo de transformao. Com isso, pode-se dizer que essas abordagens
transformam o ambiente as-is em um modelo dos requisitos.
Tambm transformando um ambiente as-is em requisitos, Dietz (2003) prope um
mtodo que transforma o modelo de uma organizao, descrito seguindo o mtodo
DEMO (DIETZ, 1999), em casos de uso. A obteno do caso de uso feita de
acordo com trs passos. No primeiro, o modelo de construo (que representa os
24
Por mais que o diagrama de casos de uso possa ser visto como um dos contedos de um modelo
das especificaes, as informaes presentes nele no permitem dizer se os casos de uso esto
abordando os requisitos, as especificaes ou detalhes de implementao do sistema (considerando
que os casos de uso tratam do escopo de sistema, conforme discutido na seo 3.5). Portanto, existe
um problema para classificar o resultado de transformaes que tm apenas esse diagrama como
resultado, sem detalhar os casos de uso. Uma soluo seria considerar que o diagrama tem o mesmo
nvel de abstrao que a abordagem prope para os casos de uso que devero ser criados, o que
faria no caso desse trabalho que o diagrama de casos de uso fosse visto como uma parte do modelo
das especificaes. Entretanto, essa soluo permitiria, por exemplo, a existncia de uma
transformao exatamente igual essa abordagem, com o mesmo modelo como resultado, mas com
classificao diferente ou seja, o importante no seria o resultado, mas o que se espera dele. Para
evitar isso, o diagrama de casos de uso ser considerado por este trabalho, em geral, como um
modelo dos requisitos. A ideia que, como o caso de uso precisa ser posteriormente detalhado, o
seu nome restringe pouco o espao de soluo de forma semelhante a um requisito ou a um requisito
de alto nvel que so representados em um modelo dos requisitos.
91
papis dos atores, transaes que eles participam e informaes usadas)
mapeado em um diagrama de caso de uso, anotando na associao os tipos de atos
relacionados. Em seguida, o diagrama de casos de uso gerado revisado
considerando as relaes de incluso e de extenso da UML e tambm so
adicionados casos de uso para os fatos que so usados pelos atores. Por fim, no
terceiro passo decidido qual ator ser automatizado, incorporando informaes
deles nas relaes entre os demais casos de uso. Dessa maneira, nesse mtodo o
modelo da organizao representa apenas o ambiente as-is, enquanto que o caso
de uso representa inicialmente uma viso do ambiente as-is que se tornar,
posteriormente, o sistema to-be, abordando o modelo dos requisitos.
Tratando de especificaes, Robinson e Elofson (2004), propem um mtodo que
transforma um modelo de metas GORE em uma descrio textual do caso de uso.
De uma forma geral esse mtodo prescreve que as metas GORE devem se tornar
casos de uso ou passos dele. Com isso, o modelo de metas GORE trata tanto dos
requisitos quanto das especificaes, no havendo refinamento. Similarmente,
Santander e Castro (2002) propem um conjunto de heursticas para obter casos de
uso a partir dos modelos do i* (dependncia estratgica e razo estratgica).
Novamente, o modelo de metas usado tanto como modelo dos requisitos e das
especificaes, sendo proposto, portanto, um conjunto de heursticas para
transformar um modelo das especificaes em i* em um modelo das especificaes
em casos de uso. Com isso, a transformao tambm sinttica, tratando de
representaes das especificaes.
As heursticas propostas por Santander e Castro (2002) so usadas por Estrada,
Martnez e Pastor (2003) para propor um mtodo que obtm casos de uso a partir de
um modelo de metas GORE expresso em diagramas do i*. Esse mtodo similar ao
Tropos, considerando como escopo as fases de requisitos iniciais e finais. As
principais diferenas so o uso de uma tabela com as metas GORE (que leva em
considerao o tipo da meta e os atores) para gerar o diagrama de dependncia
estratgica que o ponto de partida do Tropos e a transformao de um
diagrama de razo estratgica em casos de uso, empregando as heursticas de
Santander e Castro (2002). Com isso, esse mtodo faz uma transformao entre
modelos de especificao para obter os casos de uso, mas ainda assim segue
basicamente o mesmo mtodo que o Tropos para passar de requisitos para
92
especificaes. Dessa forma, esse trabalho possui as mesmas diferenas que o
mtodo Tropos e esta proposta. A nica alterao que o modelo das
especificaes representado por dois modelos diferentes: o de caso de uso e o
composto pelos diagramas de metas e de ator. Com isso, existe uma representao
que separa o modelo das especificaes do modelo dos requisitos.
Uma transformao entre um modelo dos requisitos e um modelo das
especificaes apresentada por Molina et al. (2000) que propem um mtodo que
usa um modelo empresarial para obter os casos de uso. Esse modelo empresarial
representado por casos de uso de negcio, um diagrama de papis (seguindo a
sintaxe concreta do diagrama de classes da UML), um diagrama de processo
(usando o diagrama de atividades da UML) e um conjunto de regras de negcio
(representadas textualmente). Apesar de no existir uma representao das metas
GORE, elas so consideradas como parte do mtodo para a criao dos casos de
uso de negcio. Entretanto, como cada meta GORE se torna um caso de uso de
negcio, no considerada a interdependncia entre as metas e as diferenas
semnticas entre elas. Alm disso, a relao entre o modelo dos requisitos e o
modelo das especificaes limitada. Os casos de uso so baseados nos nomes
das atividades expressas no workflow que devem ser automatizadas e o ator ser o
participante do processo, sendo tambm gerado um modelo de domnio (como
diagrama de classes da UML) a partir dos conceitos tratados pelo modelo de regras
de negcio. Com isso, embora haja uma transformao, ela apenas inicial e
realizada manualmente.
Uma outra abordagem para anlise de requisitos que usa uma representao
detalhada da organizao proposta por De La Vara, Sanchez e Pastor (2008).
Essa abordagem possui 3 fases: a modelagem organizacional, a anlise de
propsito e a especificao de requisitos. Na primeira fase, a organizao as-is
modelada atravs de um glossrio, eventos de negcio, regras de negcio e um
modelo de papis. Essas informaes so usadas para criar diagramas de processo
de negcio em BPMN (OMG, 2011a), que devem ser validados pelos usurios finais.
Na fase seguinte, a anlise de propsito, os problemas ou as necessidades da
organizao so analisados, buscando definir estratgias do sistema que podem
san-las. Para isso criado um Map (ROLLAND, 2007), definindo as metas GORE
idealizadas e as estratgias para atingi-las. Esse Map ento operacionalizado,
93
decidindo como as estratgias sero alcanadas e redefinindo o diagrama de
processo de negcio criado na modelagem organizacional, obtendo o ambiente tobe. Os elementos desse diagrama de processo de negcio so por fim rotulados de
acordo com o suporte do sistema a eles, o que realizado com o apoio ao usurio
final. Na ltima fase, a especificao de requisitos, as especificaes so definidas
usando um formato especfico de caso de uso. Esses casos de uso so criados a
partir de um mapeamento de algumas informaes existentes nos diagramas de
processo de negcio rotulados. Dessa forma, por mais que essa abordagem
considere uma viso mais abrangente da empresa, a sua nfase na melhoria do
ambiente organizacional, existindo um conjunto de atividades especfico para a
anlise e redefinio do ambiente podendo at ser vista, em parte, como uma
abordagem de melhoria de processo. Considerando apenas as atividades que so
tratadas por este trabalho, percebe-se que o modelo da empresa usado limitado
ao processo de negcio, sendo que as demais informaes obtidas no modelo da
empresa as-is so apenas usadas para que esse diagrama seja criado. At mesmo
o mapa no representa um modelo motivacional da empresa, mas sim uma
representao de alternativas de soluo usadas para a melhoria do processo. Em
relao obteno dos casos de uso, ela bastante simplificada e no realizada de
forma automtica. Ainda assim, h uma separao clara dos requisitos e das
especificaes.
5.3.3 Abordagens de transformao seguindo a MDA
Transformaes envolvendo o modelo dos requisitos e o modelo das especificaes

so tratadas por alguns trabalhos no contexto da Arquitetura Dirigida por Modelos
(MDA) (discutido na seo 6.1.1) ao propor a transformao do modelo
independente de computao (CIM) em um modelo independente de plataforma
(PIM). Entretanto, embora em algumas abordagens seja possvel observar
claramente modelos dos requisitos e das especificaes, no possvel dizer que o
CIM seja equivalente ao modelo dos requisitos e tampouco que o PIM seja
equivalente ao modelo das especificaes.
No caso do CIM, como ele definido pela MDA apenas como um modelo que
descreve as situaes em que o sistema ser usado e no qual no so
94
apresentados detalhes da soluo, ele pode tratar das especificaes, dos
requisitos, ou de algo de mais alto nvel (como metas GORE de alto nvel ou
processos de negcio relacionados). O que far com que o CIM seja um modelo ou
outro a forma como o sistema detalhado na representao do ambiente.
Entretanto esse detalhamento no discutido pela MDA e, portanto, pode variar
entre as abordagens. Uma outra dificuldade para analisar as abordagens que
seguem a MDA que o modelo das especificaes no apenas um possvel CIM,
mas tambm pode ser visto como um PIM. Essa dualidade causada pelo fato de o
PIM ser um modelo que descreve o sistema, mas cuja definio atrelada ao
conceito de plataforma. Como um modelo das especificaes ao mesmo tempo
uma descrio do ambiente e uma descrio do sistema (JACKSON, 1995), a qual
isenta de detalhes de tecnologia (a menos que eles sejam requisitos), ele um
modelo do sistema independente de qualquer plataforma. Ou seja, o modelo das
especificaes pode ser visto como o PIM mais bsico possvel, j que em um
desenvolvimento usando MDA pode-se empregar diversas plataformas e, portanto,
possvel se ter diversos PIMs. Assim como no caso do CIM, isso no significa que
um dos PIMs seja obrigatoriamente o modelo das especificaes. Cada abordagem
pode considerar o PIM que for mais apropriado, como, por exemplo, ao usar um
modelo de anlise como um PIM ou mesmo um modelo de projeto do sistema
especificado detalhadamente usando a UML.
Uma das abordagens que faz a transformao do CIM para o PIM apresentada por
Rodrguez, Fernndez-Medina e Piattini (2007), considerando requisitos de
segurana. Para isso, o CIM uma extenso do BPMN (chamada de BPSec) em
que requisitos de segurana so representados graficamente. O modelo de
processo de negcio trata apenas do ambiente as-is, sendo considerado para a
transformao que todo o processo ser automatizado. A partir desse modelo, os
autores propem um conjunto de regras definidas em QVT, listas de verificao
(checklists) e regras de refinamento que permitem transform-lo em diagramas de
casos de uso. Comparado s propostas discutidas anteriormente, essa proposta
apresenta uma particularidade: a definio do escopo do sistema feita ao criar o
modelo as-is (de processo de negcio), j que a abordagem considera que tudo ser
automatizado. Com isso, possvel observar nesse modelo tanto o ambiente as-is
quanto o to-be, o que o torna um modelo dos requisitos at porque nele esto
95
alguns requisitos de segurana do sistema. Como o modelo de caso de uso um
modelo dos requisitos e no das especificaes, j que apenas um diagrama de
casos de uso a transformao trata apenas de modelos de requisitos, sendo
apenas sinttica25.
Assim como na proposta de Rodrguez, Fernndez-Medina e Piattini (2007), na
proposta de Dias et al. (2006) o CIM tambm trata tanto do ambiente as-is quanto do
ambiente to-be. No caso, ele composto por dois modelos: um de processo que
representado atravs de diagramas de atividades da UML, e um de regras de
negcio que representado usando linguagem natural estruturada (no caso, o
portugus limitado a termos e fatos, permitindo representar os termos usados pelo
negcio). Novamente, esses modelos no representam o sistema, mas a abordagem
considera que tudo ser automatizado e, portanto, todos os processos so do
sistema e todas as regras de negcio tratam do sistema. Como resultado da
transformao tem-se como PIM o diagrama de casos de uso e o diagrama de
classes de domnio (representando as entidades do sistema e suas definies),
ambos usando a UML. A transformao do CIM para o PIM feita atravs de um
conjunto de heursticas que mapeiam os termos em classes e um outro conjunto de
heursticas que mapeiam os processos em diagramas de casos de uso. Analisando
em relao aos requisitos e s especificaes, esse trabalho trata tambm apenas
de uma transformao entre modelos dos requisitos.
Uma proposta que trata do modelo das especificaes na transformao do CIM em
PIM apresentada por Valderas, Fons e Pelechano (2005) ao propor um mtodo
para desenvolvimento de aplicaes Web seguindo a MDA. Nesse mtodo o CIM
representado por dois submodelos: um chamado de taxonomia das tarefas e um de
atividades (baseado na UML). No primeiro submodelo, as tarefas que os usurios
devem executar so detalhadas at se obter as tarefas que so ou executadas
apenas pelo usurio ou apenas pelo sistema chamadas de tarefas elementares.
No modelo de atividades, cada tarefa elementar ento detalhada ao representar as
25
Seguindo a discusso apresentada anteriormente do contedo do PIM em relao aos requisitos e

s especificaes, pode-se dizer que o PIM considerado pelo trabalho de Rodrguez, FernndezMedina e Piattini (2007) , na verdade, um CIM e, portanto, a transformao de CIM para CIM.
Entretanto, como os autores consideram o diagrama de casos de uso como um dos contedos do
modelo das especificaes (devendo ser detalhado cada caso de uso como tal), a proposta
considera-o como PIM.
96
aes do usurio (seleo de informao ou operaes) e aes realizadas pelo
sistema. A partir desses dois modelos, deve ser usada uma ferramenta proposta
pelos autores que possui um conjunto de regras para a transformao do CIM em
um PIM. Esse PIM obtido composto por trs modelos, mas na proposta apenas
apresentado um deles: o modelo navegacional. Nele so apresentados contextos
(que so vises do diagrama de classes) e as ligaes entre eles, representando
como um contexto pode ser obtido a partir de outro. Do ponto de vista dos requisitos
e das especificaes, pode-se dizer que o CIM trata de ambos, j que o modelo de
taxonomia das tarefas trata apenas dos requisitos e o de atividades trata das
especificaes. A transformao de requisitos em especificaes, portanto, ocorre
de forma manual, j que cabe ao engenheiro de requisitos detalhar cada uma das
tarefas no modelo de atividades. Como o PIM trata de detalhes do software (classes,
atributos e operaes), ele j faz parte do modelo de anlise orientado a objetos,
estando fora do contexto da Engenharia de Requisitos.
5.3.4 Outras abordagens
Alguns trabalhos no propem abordagens para a transformao de requisitos em

especificaes, mas ainda assim tratam de alguns aspectos abordados por este
trabalho. Champion e Moores (1996), por exemplo, propem um metamodelo de
empresa para ser usado nas atividades de Engenharia de Requisitos. Um modelo
em conformidade a ele deve ser criado em uma atividade de anlise de negcio,
servindo de entrada para a elicitao dos requisitos, e para permitir o rastreamento
dos requisitos ao contexto empresarial. Contudo o trabalho discute apenas as linhas
gerais desses usos, alm de no apresentar um mtodo a ser usado ou tampouco
as razes para esse modelo.
Um outro trabalho que considera um modelo mais abrangente de empresa o
mtodo EKD (BUBENKO JR. et al., 1998). Como apresentado na seo 3.3.1, o
escopo do EKD a modelagem empresarial e a melhoria da empresa, mas tambm
pode ser usado no contexto de Engenharia de Requisitos j que ele permite definir
os requisitos iniciais de um sistema de informao. Isso feito atravs do modelo de
componentes tcnicos e de requisitos que permite representar metas GORE,
problemas e requisitos de um novo sistema e relacion-los entre si e com os demais
97
modelos propostos pelo arcabouo. Dependendo do nvel de detalhamento dado aos
requisitos representados, possvel usar esse modelo como modelo dos requisitos
ou mesmo como modelo das especificaes. Entretanto, de acordo com Bubenko Jr.
et al. (1998, p.58) esse modelo serve "para descrever e relacionar entre si os
requisitos de sistemas de informao iniciais e que no estejam claros", ou seja, no
se pretende us-lo como modelo das especificaes. Por causa disso, o mtodo
proposto no discute como obter um nvel de detalhamento de especificao, ou
mesmo como obter os requisitos a partir dos demais modelos. Apenas so
apresentados um conjunto de questes que orientam a criao dele e algumas
linhas gerais para a criao desse modelo e do modelo da empresa como um todo.
Dessa maneira, analisando o EKD do ponto de vista deste trabalho, o modelo da
empresa criado um modelo dos requisitos (inicialmente um modelo da empresa
as-is, mas conforme o mtodo aplicado, o modelo evolui para o modelo to-be),
mas
no
representa
claramente
transformao
desses
requisitos
em
especificaes.
Ainda tratando do modelo da empresa, alguns trabalhos discutem a transformao
entre partes dele. Decreus, Snoeck e Poels (2009) discutem algumas abordagens
que transformam modelo de metas em modelos de processos de negcio,
analisando-as sob o ponto de vista metodolgico e organizacional. A importncia
desse tipo de transformao, segundo os autores, que modelos de metas
permitem representar o espao do problema enquanto que o modelo de processo de
negcio pode representar tanto o espao do problema quanto o espao da soluo
ao descrever como as metas organizacionais esto sendo cumpridas. Alm disso,
segundo Koliadis et al. (2006), esse tipo de transformao permite que modelos de
processo de negcio sejam fundamentados em modelos de mais alto nvel da
empresa que o caso do modelo de metas organizacionais. Entretanto, por mais
que existam essas abordagens, neste trabalho considerou-se que esses modelos
possuem informaes complementares para a definio dos requisitos. O motivo
disso que os dois modelos no so equivalentes, havendo uma transformao
semntica que necessita de um analista para verificar e adicionar informaes ao
modelo obtido. Dessa forma, ao considerar apenas um desses modelos no se teria
uma viso adequada, do ponto de vista deste trabalho, do outro modelo. Um
exemplo dessa diferena semntica pode ser visto ao analisar uma dessas
98
propostas, a de Koliadis et al. (2006), em que so apresentados mtodos para obter
um modelo de processo de negcio em BPMN a partir dos modelos do i* e viceversa. Ainda que os modelos do i* possuam algumas informaes da abstrao
processo, essas informaes no so suficientemente detalhadas. Por exemplo, a
tarefa do i* representa uma estratgia, uma ttica ou mesmo uma atividade no
modelo BMM (OMG, 2008a) e dessa forma o mapeamento entre uma tarefa e uma
atividade no modelo de processo pode no ser direto. Em relao
intencionalidade, o prprio mtodo indica a necessidade de uma pesquisa mais
detalhada para descobrir as metas GORE a partir do processo.
Alguns outros trabalhos relacionados no tratam de uma representao da empresa,
mas discutem diretamente a obteno das especificaes a partir dos requisitos. O
trabalho de Jackson e Zave (1995), por exemplo, faz essa discusso ao apresentar
um exemplo de requisitos e de refinamento para especificaes. Em um outro
trabalho, Johnson (1988) alm de discutir a obteno de especificaes tambm
apresenta uma viso geral de um conjunto de comandos que podem ser usados por
uma linguagem de especificao formal de alto nvel para refinar os requisitos em
especificaes.
Apesar
de
esses
comandos
poderem
ser
vistos
como
transformaes (JOHNSON, 1988), o trabalho apresenta apenas alguns exemplos

de heursticas. Alm disso, a entrada da transformao no um modelo de uma
empresa, mas uma descrio formal dos requisitos.
5.4 Concluso
A partir do embasamento terico apresentado nos captulos 2, 3 e 4, neste captulo

foi apresentada a proposta deste trabalho: a transformao de um modelo dos
requisitos, descrito atravs de um modelo da empresa, em um modelo das
especificaes, usando os conceitos da Engenharia Dirigida por Modelos.
Para chegar a essa proposta primeiramente discutiu-se a possibilidade e as
vantagens de usar um modelo da empresa como um modelo dos requisitos,
seguindo o quadro de referncia de requisitos descrito no captulo 3. Ao restringir o
escopo para sistemas de automao de processos foram definidas trs hipteses
99
que sustentam esta proposta. Por fim, discutiu-se as limitaes de uma
transformao desse tipo e os trabalhos relacionados.
No
prximo
captulo
ser
apresentada
materializao
dessa
proposta,
descrevendo a transformao atravs de seus metamodelos, regras e da ferramenta

de apoio.
100
6 TRANSFORMAO DO MODELO DA EMPRESA EM MODELO DE CASO DE USO

Conforme discutido no captulo anterior, este trabalho prope que o modelo das
especificaes seja obtido a partir de uma transformao que tem como origem o
modelo dos requisitos, representado atravs dos modelos de empresa as-is e to-be
seguindo um ponto de vista organizacional.
Para o modelo de destino, ou seja, o modelo das especificaes, diferentes
representaes podem ser usadas, seja uma linguagem de especificao formal
(como Z), afirmaes em linguagem natural, estrias, casos de uso, entre outras.
Uma vez que o modelo da empresa pode ser usado tanto como modelo dos
requisitos quanto das especificaes, essa transformao poderia ter como origem e
destino modelos de empresa. Entretanto, como discutido na seo 5.1.3, esse uso
apresenta alguns problemas. Com isso, este trabalho usar como modelo das
especificaes uma outra representao: o modelo de caso de uso de sistema, no
nvel de metas do usurio. A escolha pelo caso de uso se deve ao fato dele ser uma
representao muito usada e tratar apenas das especificaes sem representar os
requisitos no refinados.
Seguindo a perspectiva da Engenharia Dirigida por Modelos (MDE), existem
algumas abordagens de transformao (discutidas na seo 4.3) que podem ser
usadas para transformar o modelo da empresa em modelo de casos de uso. Dentre
elas, este trabalho empregar uma transformao de metamodelos. Com isso, sero
definidas regras que mapeiam elementos do metamodelo de empresa em elementos
do metamodelo de caso de uso.
Portanto, para realizar a transformao, o primeiro passo definir os Espaos
Tcnicos (TS) que sero usados, que provero a infraestrutura para a definio dos
metamodelos e para a transformao. Uma vez definido os TSs, o prximo passo
definir os dois metamodelos, de empresa e de casos de uso. Por fim, deve-se definir
as regras de transformao, em conformidade com o metamodelo de transformao
escolhido. A seguir apresentada a anlise e os resultados obtidos ao realizar cada
um desses passos, tambm apresentando a ferramenta criada que permite executar
a transformao.
101
6.1 Escolha do Espao Tcnico
Uma transformao de metamodelos pode envolver diversos Espaos Tcnicos (TS)

caso as necessidades de descrio dos metamodelos de origem e de destino sejam
diferentes, ou mesmo se a infraestrutura de transformao provida pelo TS no seja
adequada. De forma esquemtica, na Figura 6.1 apresentada o caso mais geral
em que se usa trs espaos tcnicos para a transformao proposta por este
trabalho. O metamodelo de empresa est no TS1, a transformao de requisitos em
especificao ocorre no TS2 e o metamodelo de caso de uso est no TS3. Nessa
situao so necessrias trs transformaes, representadas na figura como setas
cheias (ao invs de modelos, por simplicidade): um projetor para passar o modelo da
empresa do TS1 para o TS2 (Projetor 1), a transformao de requisitos em
especificao (Transformao) e um projetor para passar o modelo de caso de uso
do TS2 para o TS3 (Projetor 2). Caso o modelo da empresa possa ser representado
no mesmo espao tcnico da transformao, o metamodelo e o modelo de origem
seriam equivalentes ao metamodelo e ao modelo da empresa, no sendo necessrio
o Projetor 1. O mesmo vale para o caso do modelo de caso de uso poder ser
representado no TS2.
TS1
TS2
TS3
conforme
conforme
conforme
Metametamodelo
Metametamodelo
Metametamodelo
conforme
conforme
Metamodelo de
empresa
Metamodelo
de origem
conforme
conforme
Modelo de
empresa
Projetor 1
Modelo de
origem
conforme
conforme
Metamodelo de
Transformao
conforme
Transformao
conforme
Metamodelo
de destino
Metamodelo de
caso de uso
conforme
conforme
Modelo
destino
Projetor 2
Modelo de caso
de uso
Figura 6.1: Representao dos Espaos Tcnicos e as transformaes entre os modelos para o caso
de trs Espaos Tcnicos.
Para decidir quantos e quais sero os Espaos Tcnicos necessrio definir os

requisitos para os metamodelos e modelos de empresa e de casos de uso.
Considerando os objetivos deste trabalho, existem trs requisitos:
O TS deve permitir a execuo da transformao com o apoio de uma

ferramenta;
102
O modelo da empresa deve ser representado graficamente; e
O modelo de casos de uso deve ser representado textualmente.
Em relao ao modelo de caso de uso, apesar de o caso de uso estar definido na

UML, conforme discutido na seo 3.5.2 existem alguns problemas para representar
o seu comportamento atravs desse padro. Por esse motivo, ser empregada uma
representao textual dos casos de uso.
Dados esses requisitos, a seguir so apresentados e analisados trs Espaos
Tcnicos: o MDA (MILLER; MUKERJI, 2003), o EMF (BUDINSKY et al., 2003) e o
XML (W3C, 2004).
6.1.1 Arquitetura Dirigida por Modelos (MDA)
O MDA um arcabouo para o desenvolvimento de software que tem como objetivo

obter portabilidade, interoperabilidade e reuso atravs da separao de questes
arquitetnicas (MILLER; MUKERJI, 2003). Para isso so definidos trs modelos
(MILLER; MUKERJI, 2003): o modelo independente de computao (CIM Computation Independent Model), o modelo independente de plataforma (PIM Platform Independent Model) e o modelo de plataforma especfica (PSM - Platform
Specific Model).
O modelo independente de computao representa os requisitos do sistema ao
descrever a situao na qual o sistema ser usado (MILLER; MUKERJI, 2003).
Nesse modelo no so especificados detalhes da soluo; so apenas descritos
detalhes do problema (o que pode envolver o ambiente). Dessa maneira, o CIM no
considera uma tecnologia ou implementao especfica, o que permite que ele
possa ser at mesmo implementado sem usar sistemas de software (MESERVY;
FENSTERMACHER, 2005).
A partir do CIM criado um modelo mais concreto que j considera aspectos da
soluo, o PIM. Apesar de o PIM ser menos abstrato, a sua principal caracterstica
o fato dele ser independente de plataforma. O conceito de plataforma um ponto
central do MDA, sendo a diferena entre o PIM e o PSM. Segundo Miller e Mukerji
(2003, p.2-3), plataforma "um conjunto de subsistemas e tecnologias que proveem
um conjunto coerente de funcionalidades atravs de interfaces e padres
103
especficos de uso", sendo abstrados os seus detalhes de implementao. Com
isso, a plataforma pode representar desde sistemas operacionais, linguagens de
programao
ou
mesmo
prticas
de
desenvolvimento
(MESERVY;
FENSTERMACHER, 2005).
A adio de informaes de uma plataforma especfica faz com que o PIM se torne
um PSM. Entretanto, para que esse modelo seja transformado em um cdigo
executvel pode ser necessrio tomar outras decises de plataforma. Ou seja, o
PSM pode ser tanto um modelo de implementao que pode ser transformado em
cdigo ou um outro PIM que, assim, precisa ser transformado novamente ao
considerar a deciso por uma determinada plataforma.
De forma esquemtica, na Figura 6.2 apresentada a relao entre os modelos,
evidenciado a possibilidade de um PSM ser transformado em outros PSMs (nesse
caso, o PSM origem visto como um PIM). O foco do MDA a transformao do
PIM em PSM e do PSM em cdigo. Dessa maneira o CIM pouco detalhado, assim
como a obteno do PIM a partir dele o nico requisito que o PIM deve ser
rastrevel ao CIM (MILLER; MUKERJI, 2003).
transformado em
CIM
permite obter
PIM
transformado em
PSM
transformado em
Cdigo
Figura 6.2: A relao entre os modelos do MDA e o cdigo.
Um aspecto importante do MDA que ele apenas especifica algumas caractersticas

e requisitos que os modelos CIM, PIM e PSM devem possuir. Dessa forma, cabe a
cada usurio do MDA definir qual o modelo ser efetivamente usado. Alm disso, a
MDA no demanda um processo de desenvolvimento especfico, podendo ser
aplicado usando diferentes mtodos (KLEPPE; WARMER; BAST, 2003).
Do ponto de vista da Engenharia Dirigida por Modelos, o MDA pode ser visto como
um Espao Tcnico (BZIVIN, 2006) uma vez que a partir dessa viso existem
diversos padres que permitem a representao de modelos e a execuo de
operaes entre eles. Como apresentado na seo 4.2, o TS do MDA segue uma
organizao em 3 nveis tendo como metametamodelo o MOF (OMG, 2006a). Um
dos principais metamodelos desse Espao Tcnico a UML (OMG, 2011b), mas
104
possvel criar e empregar nesse TS outros metamodelos em conformidade com o
MOF. Assim como apresentado anteriormente, o metamodelo de transformao
desse TS o padro Query/View/Transformation (QVT) (OMG, 2009), sendo
tambm definido um projetor, o XMI (XML Metadata Interchange) (OMG, 2007) para
transformar um modelo desse TS para o TS do XML.
6.1.2 Eclipse Modeling Framework (EMF)
O MDA foi uma das primeiras propostas de Engenharia Dirigida por Modelos
(BZIVIN, 2006) (GHERBI; MESLATI; BORNE, 2009) e oferece um grande conjunto
de padres em seu Espao Tcnico, como apresentado em (FRANKEL et al., 2003),
alm de diversas ferramentas compatveis. Entretanto, segundo Kent (2002), o MDA
enfatiza as questes envolvidas com a ideia de plataforma, apesar de reconhecer a
existncia de um Espao Tcnico maior que trata de modelos em geral sem
ponderaes sobre a plataforma.
Uma forma de trabalhar com esse TS de modelos em geral considerar os padres
e as tecnologias envolvidas com o MDA, como o MOF, UML, XMI e o QVT, e abstrair
o conceito de plataforma. Mas tambm existem outros Espaos Tcnicos que tratam
de modelos como o caso do AMMA (BZIVIN et al., 2005), do XMF (CLARK;
SAMMUT; WILLANS, 2008b), das Ferramentas da Microsoft para Linguagens
Especficas de Domnio (DSL Tools) (COOK et al., 2007) e do Eclipse Modeling
Framework (EMF) (BUDINSKY et al., 2003), por exemplo. Em especial, no EMF
possvel usar diversos dos padres do MDA. Isso acontece devido ao fato de seu
metametamodelo, o Ecore, ter sido originalmente criado como uma implementao
da especificao do MOF, mas que acabou evoluindo de forma diferente (THE
ECLIPSE
FOUNDATION,
2011b).
Apesar
disso,
ele
apresenta
diversas
similaridades com uma parte do padro MOF, havendo diferenas principalmente

em relao ao nome das metametaclasses (THE ECLIPSE FOUNDATION, 2011b).
Com isso, padres definidos no TS do MDA, como, por exemplo, XMI, OCL e QVT,
podem ser usados no TS do EMF. No caso da transformao de modelos, alm do
QVT tambm pode ser usada uma outra linguagem de transformao nesse TS, a
ATL (Atlas Transformation Language) (JOUAULT; KURTEV, 2006), alm de outras
solues do TS do AMMA.
105
De uma forma geral, o EMF um arcabouo de software e uma infraestrutura de
gerao de cdigo para a ferramenta Eclipse (THE ECLIPSE FOUNDATION, 2011a)
que permite construir ferramentas e aplicaes baseadas em um modelo estruturado
(THE ECLIPSE FOUNDATION, 2011b). Para criar um metamodelo em EMF
possvel usar tanto a linguagem Java, usando o EMF como um arcabouo de
software, ou a XML, criando um documento XML, ou um subconjunto da UML,
criando um diagrama classes simplificado (BUDINSKY et al., 2003). Usando a
infraestrutura do EMF, esse metamodelo automaticamente transformado em
cdigo fonte Java que permite visualizar e modificar modelos em conformidade com
esse metamodelo. A ideia por trs do EMF que os desenvolvedores podem criar
seus prprios metamodelos, alternado o cdigo fonte gerado conforme a
necessidade para gerar uma aplicao. Em especial para a criao de ferramentas
grficas, existe o Graphical Modeling Framework (GMF), que integra o EMF com um
outro arcabouo de software para criao de editores grficos, o Graphical Editing
Framework (GEF), permitindo criar plug-ins para o Eclipse.
Apesar da proximidade com o TS do MDA, o EMF no segue a viso do MDA em
relao plataforma, at porque emprega tecnologias e ferramentas que podem ser
vistas como plataformas especficas: a ferramenta Eclipse e a linguagem Java.
6.1.3 Linguagem de marcao extensvel (XML)
A XML (Extensible Markup Language) uma linguagem de marcao usada para

representar informao estruturada (W3C, 2010). Por ser uma linguagem extensvel,
a especificao da XML no define um conjunto fixo de marcaes, permitindo que
elas sejam definidas dependendo do uso pretendido (HAROLD; MEANS, 2004).
Essa flexibilidade faz com que a XML seja usada como base para a representao
de pginas de Internet, imagens vetoriais, entre diversos outros usos.
Entre as caractersticas da XML esto a facilidade de leitura pelo ser humano, a
facilidade de processamento pelo computador, a facilidade de criao e a pouca
nfase conciso, entre outras (W3C, 2006). O resultado disso que um
documento XML tem sua estrutura e contedo explcitos, representando-os como
texto puro no usando codificaes especficas , o que facilita a portabilidade das
106
informaes contidas nele (HAROLD; MEANS, 2004) alm de sua criao e
interpretao.
Ainda que a XML defina apenas um formato de texto, um documento XML pode ser
visto como um modelo. Dessa forma, possvel considerar um Espao Tcnico da
XML (BZIVIN, 2006), que trata de documentos texto. Nesse TS existem algumas
possibilidades de metametamodelos: o XML Schema (W3C, 2004) e o Document
Type Definition (DTD) definido juntamente com a especificao da XML (W3C,
2006). O DTD no definido reflexivamente, sendo usada uma gramtica em EBNF
(ISO, 1996) e explicaes em linguagem natural para defini-la (W3C, 2006)26. Alm
disso, ele apresenta alguns outros problemas, como a falta de tipos de dados e o
fato dele no ser um documento XML (HAROLD; MEANS, 2004). Para solucionar
essas deficincias foi definido o XML Schema que, alm disso, pode ser definido
reflexivamente.
Os metamodelos do Espao Tcnico do XML esto em conformidade com o DTD ou
com o XML Schema. Os modelos em si so arquivos XML compatveis com esses
metamodelos. Entre os metamodelos definidos para trabalhar com documentos XML
h
metamodelo
de
transformao
Extensible
Stylesheet
Language
Transformations (XSLT) (W3C, 2007), que permite a transformao entre diferentes

metamodelos.
6.1.4 Anlise dos Espaos Tcnicos
Na Tabela 6.1 apresentada uma comparao entre os trs Espaos Tcnicos

discutidos anteriormente em relao ao metametamodelo empregado, forma de
representao do metamodelo, forma de representao do modelo, ao
metamodelo de transformao, disponibilidade de ferramentas, a ser ou no
padro e ao escopo.
Em relao ao metametamodelo, os TSs do MDA e do EMF apresentam uma
proximidade sinttica e semntica j que o Ecore (do TS do EMF) baseado em
26
Nesse caso o DTD no seria o ltimo nvel de metamodelagem, havendo o EBNF como quarto
nvel.
107
Tabela 6.1: Comparao entre os Espaos Tcnicos do MDA, XML e EMF.
Metametamodelo
Forma de representao do
metamodelo
Forma de representao do
modelo
Metamodelo de transformao
Disponibilidade de ferramentas
Definido por padres
Escopo
MDA
XML
MOF
XML Schema ou DTD
Indefinida, mas usualmente Textual
o diagrama de classes
Indefinida
Textual
QVT
Sim
Sim
Modelo (plataforma)
XSLT
Sim
Sim
Documento
EMF
Ecore
Java, XML ou diagrama de
classes da UML
Textual (XMI), grfica (GMF)
ou na ferramenta
QVT e ATL
Sim
No
Modelo
uma parte do MOF (do TS do MDA). No TS do XML podem ser considerados dois
metametamodelos diferentes: o XML Schema ou o DTD. Sobre o emprego desses
metametamodelos para representar os metamodelos, no caso do TS do XML a
representao apenas textual (por mais que ferramentas possam permitir
representaes grficas); no TS do EMF pode ser tanto atravs da linguagem de
programao Java, da XML ou do diagrama de classes da UML; e no TS do MDA
no h nada definido a respeito disso nos padres, por mais que seja comumente
usada a UML uma vez que ela o metamodelo mais popular do TS do MDA e pelo
alinhamento do MOF a um subconjunto da UML (BZIVIN, 2005). A respeito da
forma de representao dos modelos, tanto no TS do MDA quanto no TS do XML a
forma de representao a mesma que para o metamodelo (ou seja, indefinida e
textual, respectivamente). No TS do EMF, o modelo pode ser representado
textualmente usando XMI, graficamente usando o GMF ou mesmo usando a
ferramenta Eclipse (em um intermedirio entre representao grfica e textual).
Quanto ao metamodelo de transformao, em todos os TSs existe pelo menos um:
no TS do MDA ele o QVT, no TS do XML o XSLT e no TS do EMF ele pode ser
tanto o QVT quanto o ATL. No caso do TS do MDA e do TS do EMF existe ainda um
Projetor, o XMI, que permite transformar um modelo para o Espao Tcnico do XML.
Em relao disponibilidade de ferramentas, os trs TSs possuem ferramentas que
permitem o seu uso, sendo que parte das ferramentas do TS do EMF pode tambm
ser usada no TS do MDA. Sobre a padronizao, desses TSs apenas o EMF no
um padro e, mais que isso, emprega um conjunto de tecnologias especfico,
enquanto que o MDA e o XML no esto atrelados a tecnologias podendo ser
implementados da forma que for mais conveniente. Por fim, tanto os TSs do MDA e
do EMF tratam de modelos, com a diferena na nfase da plataforma no MDA,
enquanto que o XML trata de documentos.
108
Embora essa comparao seja superficial no discutindo as limitaes e a
capacidade de representao desses Espaos Tcnicos ela permite chegar a
algumas concluses. A primeira delas que o TS do XML no atende a um dos
requisitos da transformao proposta por este trabalho, j que a representao do
modelo da empresa no pode ser feita de forma grfica. Alm disso, o TS do XML
trata de documentos, sendo que o ideal para a transformao seria tratar de
modelos em geral. Em compensao, esse TS apropriado para o modelo de casos
de uso. Uma outra concluso que, apesar do TS do EMF empregar um conjunto
especfico de tecnologias, ele apresenta uma variedade de representao maior que
o XML. Dadas essas concluses, por mais que os trs Espaos Tcnicos possam
ser empregados, os TSs do MDA e do EMF so mais apropriados para a
transformao proposta por este trabalho.
Sobre os dois outros Espaos Tcnicos, a princpio o TS do MDA seria o mais
apropriado por ser baseado em padres e por ser mais flexvel27, ou seja, permitir
um nmero maior de ferramentas e de solues j que no empregado um
conjunto especfico de tecnologias. Porm, o problema ao escolher o TS do MDA
que a ideia de plataforma, central a esse TS, teria que ser abstrada. Como, por
definio, a plataforma trata de escolhas tecnolgicas internas ao sistema, do ponto
de vista dos requisitos e das especificaes e, portanto, deste trabalho esse
conceito no relevante. Outros conceitos importantes ao MDA, os modelos CIM e
PIM, tambm no poderiam ser considerados uma vez que no h um mapeamento
claro entre eles e os modelos dos requisitos e das especificaes (discutido na
seo 5.3.3). Portanto o ideal utilizar um TS mais geral que o do MDA, que
tratasse apenas de modelos.
Dadas essas consideraes, este trabalho usar como base o TS do EMF,
buscando seguir ao mximo os padres do MDA que so compartilhados. A ideia
usar o TS do EMF como se fosse um TS de modelos em geral, evitando usar
solues e outros detalhes especficos ao Espao Tcnico do EMF. Dessa maneira,
a sintaxe abstrata especificada usando o diagrama de classes da UML (que
27
A flexibilidade uma vantagem discutvel ao considerar que ela limitada pela disponibilidade e
funcionalidade das ferramentas e, principalmente, pelo fato de algumas dessas ferramentas serem
compartilhadas com o TS do EMF.
109
representa um metamodelo em Ecore) 28 e a OCL, e a transformao ser descrita
usando o metamodelo de transformao do QVT. Para o modelo da empresa, a
sintaxe concreta ser grfica, usando o GMF. Por outro lado, para o modelo de caso
de uso ser usado o TS do XML para a sintaxe concreta uma vez que esse modelo
deve ser textual e devido simplicidade do XML. Com isso, na Figura 6.3
apresentada a transformao proposta. Os detalhes em relao escolha da
linguagem QVT Operational como linguagem de transformao e da linguagem Java
para o projetor sero discutidos na seo 6.5.
TS do EMF
TS do XML
conforme
conforme
Ecore
XSD
conforme conforme conforme
conforme
Metamodelo de
empresa
QVT
Metamodelo
de caso de uso
Metamodelo de
caso de uso em
XSD
conforme
conforme
conforme
conforme
Modelo de
empresa
(as-is e to-be)
QVT Operational
Modelo de
caso de uso
Java
Modelo de caso
de uso em XML
Figura 6.3: A transformao proposta.
6.2 Metamodelo de empresa
Como o objetivo principal deste trabalho no propor um metamodelo de empresa,

mas apenas us-lo para uma transformao, o ideal utilizar algum padro, de fato
ou de mercado, que defina um metamodelo de empresa seguindo um ponto de vista
organizacional. A vantagem em usar um padro que ele representaria um
consenso da rea e evitaria discusses sobre decises e outros detalhes do
metamodelo usado. Porm, no existe um padro que apresente um metamodelo
abrangente de empresa nesse ponto de vista e tampouco um consenso de qual o
metamodelo mais adequado.
28
Existem ferramentas que transformam o diagrama de classes UML para Ecore, como, por exemplo,
a Rational Software Architect (IBM, 2008) que foi usada neste trabalho.
110
Uma forma de obter algo prximo a um consenso escolher ou definir o
metamodelo mais abrangente possvel que permita representar tudo o que qualquer
outro metamodelo permite. Isso pode ser feito ao fundir (merge) os diversos
metamodelos, operao similar a uma unio, mas que considera a semntica dos
elementos e a resoluo de violaes de restries, chamadas de conflitos
(POTTINGER; BERNSTEIN, 2003). De uma forma geral, na fuso dois modelos so
compostos usando um mapeamento entre os elementos do modelo, obtido atravs
de uma outra operao de modelos: a correspondncia (match) (BERNSTEIN, 2003)
(BRUNET et al., 2006). Por mais que existam diversas abordagens para realizar a
correspondncia de modelos, como apresentado em (RAHM; BERNSTEIN, 2001), e
propostas de algoritmos de fuso de modelos, como por exemplo, (POTTINGER;
BERNSTEIN, 2003) e (SABETZADEH; EASTERBROOK, 2006), neste trabalho
optou-se por no tratar da fuso dos metamodelos por dois motivos principais:
Heterogeneidade dos metametamodelos: os metamodelos de empresa so

descritos usando metametamodelos diferentes e, em alguns casos, no h
sequer uma representao formal dos metamodelos sendo apenas
discutido textualmente. Para realizar a fuso seria necessrio homogeneizar
as representaes em um determinado TS, para ento aplicar as operaes
de correspondncia e fuso.
Tamanho e complexidade do metamodelo resultante: a complexidade

inerente ao conceito de empresa e as diferenas de objetivos e hipteses
considerados nos diversos metamodelos faz com que o metamodelo
resultante da fuso tenda a ser grande e complexo, dificultando o seu uso.
Esses motivos, entretanto, no impedem que seja realizada uma fuso desses
metamodelos, sendo um possvel trabalho futuro realiz-la. Um trabalho que segue
esse caminho, apesar das dificuldades envolvidas, apresentado em (COUTINHO,
2009), para a definio de modelos organizacionais de sistemas multi-agentes
usando o TS do EMF.
Uma outra forma para obter um metamodelo consensual definir uma interseo29
dos diversos metamodelos que, assim como na fuso, considera a semntica dos
29
Dependendo da semntica das operaes de metamodelos, a interseco pode ser obtida atravs
da aplicao de diferentes operaes. Isso ocorre pela diferena de semntica da operao de
diferena de modelos (diff) usada, por exemplo, por (BERNSTEIN, 2003) e por (BRUNET et al.,
2006).
111
elementos e resolva conflitos. Por mais que o metamodelo obtido seja o real
consenso dos diversos metamodelos, caso apenas um dos metamodelos no
considere um elemento fundamental para os demais metamodelos, a interseo no
poderia cont-lo. Considerando que os metamodelos possuem diferentes objetivos e
pressupem diferentes hipteses, de se esperar que alguns elementos
importantes para um metamodelo, ou para um conjunto deles, no esteja presente
em um determinado metamodelo ou, mesmo que presente, possua uma semntica
de alguma forma limitada. O resultado disso que a interseo pode ter como
resultado um metamodelo simples demais que no permitiria criar um modelo da
empresa que pudesse ser visto como um modelo dos requisitos suficientemente
detalhado para definir as especificaes ou, em um caso limtrofe, ter como
resultado um metamodelo vazio. Uma maneira de evitar esse problema seria
analisar os metamodelos antes de consider-los na interseo, mas isso acarretaria
em uma arbitrariedade em definir o que um metamodelo adequado.
Considerando os problemas da fuso e da interseo de metamodelos, a soluo
que ser adotada por este trabalho a de buscar um conjunto de elementos comuns
para o metamodelo de empresa ao considerar os conceitos que so mais
frequentes. Ou seja, ser realizada uma anlise dos elementos definidos em
diferentes propostas de metamodelos de empresa e os conceitos que estiverem
presentes em mais da metade das propostas sero considerados no metamodelo
resultante. O principal problema dessa soluo em relao anlise realizada, que
pode ser vista como uma forma de correspondncia dos metamodelos. Por mais que
essa correspondncia considere a semntica dos elementos (ao invs de fazer uma
anlise meramente sinttica), existe uma dificuldade em concluir a equivalncia ou
mesmo a similaridade semntica dos elementos. Caso fosse definido um novo
elemento para cada elemento semanticamente nico, as diferenas semnticas
em alguns casos provenientes do uso da linguagem natural e, em outros, do nvel de
detalhamento dado pelo autor impossibilitariam a obteno de elementos comuns.
Com isso a soluo adotada foi relacionar elementos semanticamente similares e
escolher o nome consistente com o restante deste trabalho (ou seja, nem sempre
usando o nome mais frequente). Apesar da arbitrariedade envolvida, essa
simplificao pretende permitir a consolidao dos conceitos existentes sem que
haja uma perda do significado principal proposto pelo autor do trabalho analisado.
112
6.2.1 Anlise
Considerando a abordagem proposta anteriormente, no Apndice A apresentada

uma tabela que representa o resultado da anlise dos seguintes trabalhos que
seguem uma viso organizacional da empresa: (ADDISON, 1979), (ANDERSON,
1980), (CRUZ, 2005), (CURY, 2007), (HARRINGTON, 1993), (LERNER, 1992) e
(OLIVEIRA, 1994). Esses trabalhos foram escolhidos por fazerem parte da biblioteca
bsica para cursos em graduao do Brasil (na matria de "Organizao, Sistemas e
Mtodos") elaborado pelo Ministrio da Educao do Brasil em conjunto com o
Conselho Federal de Administrao e a Universidade do Estado de Santa Catarina
(CFA, 2011) 30 no caso (CRUZ, 2005), (CURY, 2007), (HARRINGTON, 1993),
(LERNER, 1992) e (OLIVEIRA, 1994) ou por serem trabalhos bsicos sobre o
assunto em ingls (ADDISON, 1979), (ANDERSON, 1980).
Os elementos que aparecem na maioria desses trabalhos (portanto, em 4 ou mais
deles) so os seguintes, organizados por diagramas ou grupos de elementos:
Organograma:
representa
hierarquia
empresarial,
descrevendo
autoridade e a responsabilidade entre os elementos (ADDISON, 1979)

(HARRINGTON, 1993).
o Contedo: cargos e rgos, funes, tarefas, vnculo e vnculo de
hierarquia.
Fluxograma: representa o fluxo de trabalho ou de documentos entre os

diversos responsveis (CURY, 2007) (LERNER, 1992) (OLIVEIRA, 1994).
o Contedo: documento, operao, operao de conferncia, transporte,
espera, arquivo, sentido do fluxo, deciso e cargo.
Arranjo fsico: representa a distribuio de mveis, equipamentos, pessoas

etc. nos espaos da organizao (CURY, 2007) (LERNER, 1992).
o Contedo: planta e equipamento.
Normas, polticas e diretrizes: nos trabalhos analisados no h um

consenso sobre o significado desses termos (e, principalmente, a diferena
entre eles), mas em geral correspondem aos critrios estabelecidos que
formalizam o funcionamento da empresa (LERNER, 1992) e que so
30
Nos casos em que foi possvel, usou-se uma edio mais atual da bibliografia.
113
organizados e descritos em manuais (ANDERSON, 1980) (CURY, 2007)
(LERNER, 1992) (OLIVEIRA, 1994).
Um outro elemento que no normalmente representado detalhadamente atravs
de diagramas, mas fundamental para uma empresa do ponto de vista
organizacional, o formulrio (ou documento). Em geral possvel encontrar nos
trabalhos mtodos para cri-los, o que envolve questes de diagramao,
impresso, qualidade do papel, cor do papel etc. (ADDISON, 1979) (ANDERSON,
1980) (CURY, 2007) (OLIVEIRA, 1994). Diagramas como o fluxograma, por
exemplo, descrevem seu uso e seu armazenamento, mas no so comuns
diagramas ou outras representaes que descrevam seus detalhes internos talvez
porque o formulrio seja textual e um elemento fsico de fcil manipulao. Apesar
disso, como a informao contida neles fundamental para o funcionamento dos
processos empresariais, uma representao da empresa precisa de alguma forma
cont-lo. Por esse motivo, considerou-se mais um elemento, ou melhor, conjunto de
elementos, relativos aos formulrios como importantes para o metamodelo de
empresa.
Analisando esses elementos e grupos de elementos sob o ponto de vista dos
requisitos, alguns deles no parecem ser teis para a transformao proposta. Por
exemplo, as plantas e os equipamentos usados (do arranjo fsico) parecem ser
informaes muito especficas do contexto empresarial. Porm, no possvel
afirmar que essas informaes no sero teis para a transformao: caso o
sistema a ser construdo deva tratar da localizao fsica de um equipamento, por
exemplo, talvez a representao desses elementos seja necessria. Mais que isso,
sem analisar as regras de transformao criadas no parece ser apropriado
simplificar o metamodelo. Na realidade, como este trabalho prope uma
transformao inicial, os metamodelos sero tratados de uma forma conservadora:
mesmo que nenhuma regra de transformao use um determinado conceito, ele no
ser removido. Caber a trabalhos futuros alterar esse metamodelo (remover ou
adicionar elementos) considerando detalhes da transformao.
A partir desses diagramas ou grupos de elementos, possvel criar um metamodelo
de empresa ao definir a sintaxe abstrata, a sintaxe concreta e a semntica. Para a
sintaxe abstrata necessrio relacionar os elementos encontrados e criar alguns
outros elementos necessrios para obter um modelo consistente; para a sintaxe
114
concreta necessrio definir se os diagramas sero representados juntos ou
separados e selecionar ou definir a notao empregada; e para a semntica
necessrio definir o significado mais comum de cada elemento e adapt-lo
considerando os demais elementos existentes. Uma maneira de simplificar a criao
desse metamodelo considerar padres que tratam dos diagramas (ou grupo de
elementos) que aparecem na maioria dos trabalhos. Alm de definirem a sintaxe e a
semntica de um subconjunto do metamodelo facilitando a criao dele , o uso
de padres tambm auxilia a obteno de um consenso em uma parte do
metamodelo de empresa. No caso do fluxograma podem ser usados padres como
a ISO 5807 (ISO, 1985), que convenciona a representao de um fluxograma, o
IDEF3 (MAYER et al., 1995), que define um mtodo para descrever processos
(envolvendo uma notao para represent-los), o diagrama de atividades da UML
(BOOCH; RUMBAUGH; JACOBSON, 2005), que permite representar a sequncia
de atividades no contexto de um sistema, e o BPDM (OMG, 2008b), que um
metamodelo usado para entender e especificar processos de negcio. No caso das
normas, polticas e processos existe o padro BMM (Business Motivation Model)
(OMG, 2008a) que prov um metamodelo para desenvolver, comunicar e gerenciar
planos de negcio. Para as demais vises, entretanto, no existem padres que
possam ser usados31.
Usando essa ideia de considerar padres, o metamodelo ser definido usando o
BPDM e o BMM. A escolha desses padres, em especial o BPDM em detrimento
aos demais, motivada pelo fato de eles seguirem uma viso de negcio, serem
recentes, descreverem um metamodelo claramente (no so apenas uma notao)
e fazerem parte do TS do MDA (podendo ser facilmente usado no TS do EMF).
Considerando esses padres e os conceitos mais frequentemente propostos para os
demais diagramas, a seguir apresentada a sintaxe abstrata, a semntica e a
sintaxe concreta do metamodelo de empresa criado. A sintaxe abstrata ser
apresentada usando diagramas de classe UML (OMG, 2011b) e restries em OCL
(OMG, 2006b), representando os conceitos em ingls para uniformiz-los com os
31
Existe um padro em desenvolvimento pela OMG que trata exatamente de uma descrio da
empresa similar a do organograma: o Modelo de Estrutura Organizacional (Organization Structure
Model OSM). Entretanto, como no existe uma verso desse padro disponvel, ele no ser
usado.
115
padres BMM e BPDM. A semntica ser apresentada usando linguagem natural,
enquanto que a sintaxe concreta ser grfica. Por fim, para facilitar a organizao do
metamodelo, os diagramas foram considerados como vises: o organograma
considerado como uma viso de estrutura organizacional; o fluxograma como uma
viso processual; o arranjo fsico como uma viso de ambiente fsico; as normas,
polticas e diretrizes como uma viso motivacional; e os formulrios como uma viso
dos documentos.
6.2.2 Sintaxe abstrata
Considerando os elementos mais frequentes e os padres BPDM e BMM, a seguir

apresentada a sintaxe abstrata do metamodelo de empresa. As vises so interrelacionadas considerando as referncias existentes no BMM (a respeito das vises
de estrutura organizacional e processual) e outras relaes que foram consideradas
importantes
para
unificar
modelo.
Para
facilitar
entendimento
dos
relacionamentos entre as vises, foram criados pacotes correspondentes a cada

viso: Organizational para a viso de estrutura organizacional, Process para a viso
processual, Layout para a viso do ambiente fsico, Motivation para a viso
motivacional, Document para a viso de documentos e Core para elementos gerais,
independentes de uma viso especfica. Nas figuras usado o nome completo da
metaclasse quando ela de um pacote diferente daquele expresso pelo diagrama.
Por fim, nas figuras so apresentados em cinza os elementos que no foram
encontrados na anlise realizada, mas que ainda assim foram adicionados ao
metamodelo por diversos motivos em geral para torn-lo consistente.
Na viso da estrutura organizacional, os elementos mais comuns nos trabalhos
analisados so: cargo, rgo, funo, tarefa, vnculo e vnculo de hierarquia. No
caso da tarefa, como ela tambm faz parte da viso processual, ela no foi
considerada nesta parte do metamodelo. Na Figura 6.4 apresentada a sintaxe
abstrata para essa viso. A metaclasse central dessa viso a entidade (Entity) que
foi criada para representar a generalizao de um rgo (chamado de Department
por ser um rgo de uma nica empresa) e de um cargo (Position). Um cargo faz
parte de um rgo, trabalhando nele. Voltando entidade, ela possui vnculos com
outras entidades representados pela metaclasse EntityRelationship e, em
116
especial representa-se tambm a relao hierrquica (HierarchicalRelationship).
Uma entidade tambm possui funes (Function) que so realizadas por um papel
(PerformerRole), que o responsvel por executar atividades em um processo.
is part of
Department
Entity
Relationship
Hierarchical
Relationship
0..1
source
Entity
1
*
target
Name
*
1
*
has
*
Position
Function
Description
realizes
Process::
0..1 Performer Role
Figura 6.4: A sintaxe abstrata da viso da estrutura organizacional.
Duas restries foram definidas para essa viso: a de que uma relao hierrquica
no pode ter uma mesma entidade como origem e destino e que uma entidade no
pode ser alvo de mais de uma relao hierrquica (ou seja, s se pode ter um chefe
hierrquico). Essas restries so apresentadas na Figura 6.5.
context HierarchicalRelationship
inv: self.source <> self.target
context Entity
inv: self.targetInRelations->collect(er | er.oclIsKindOf(
HierarchicalRelationship))->size() < 2
Figura 6.5: Restries nas metaclasses da viso estrutura organizacional.
Na viso de ambiente fsico, os elementos mais comuns so a planta e o

equipamento. Com isso, foi criado o modelo apresentado na Figura 6.6. A entidade,
da viso da estrutura organizacional, est colocada em um ou mais locais (Place),
que foram considerados bidimensionais. Esses locais no so um conceito comum
nos trabalhos analisados, mas so necessrios para representar a localizao fsica
dos elementos que o objetivo da representao de um diagrama de arranjo
fsico. Esses locais esto em uma planta (Layout) e esta planta pode estar localizada
dentro de uma outra planta e assim sucessivamente. Os equipamentos (Equipment)
e os mveis de escritrio (Furniture) metaclasse criada para que pudesse ser
representada uma planta completa so itens do ambiente fsico que podem ser
usados por alguma atividade. Dessa maneira ambos foram generalizados na
metaclasse UsableItem, estando em um determinado local. Tanto o item utilizvel
117
como a planta so itens (Item), possuindo assim uma dimenso (necessrio para
que haja um arranjo fsico) e um nome (para identificao).
0..1
Layout
owns
*
1
*
Place
Item
Name
Width
Height
Name
XPosition
YPosition
1
is in
*
UsableItem
Equipment
Furniture
Figura 6.6: A sintaxe abstrata do metamodelo de empresa referente viso de ambiente fsico.
A nica restrio na viso de ambiente fsico que uma planta (Layout) no pode se
localizar dentro dela mesmo ou de uma planta filha, representada na Figura 6.7. Por
simplicidade e pela dificuldade de expressar restries desse tipo em OCL , a
restrio apresentada apenas considera que a planta no pode se conter.
context Layout
inv: not self.ownedLayout->exists(o| o = self)
Figura 6.7: Restrio na metaclasse Layout da viso de ambiente fsico.
Na viso de documentos, apresentada na Figura 6.8, como no foram encontrados

elementos em comum, foi necessrio definir metaclasses que permitissem
representar os formulrios e as informaes contidas neles. A metaclasse central o
artefato (Artifact), que possui um nome e est em uma mdia (representada como um
atributo, por simplicidade). Essa metaclasse abstrata e representa um relatrio
(Report) ou um formulrio (Form). O artefato possui um ou mais espaos reservados
para o preenchimento dos dados (ReservedSpace), os quais possuem uma
descrio. Quando o artefato um relatrio, esses espaos reservados so sees
(Section), enquanto que quando o artefato um formulrio, eles so campos (Field).
Essa restrio de tipo de espao reservado por tipo de artefato apresentada em
OCL, na Figura 6.9.
118
Artifact
Name
Media
Report
ReservedSpace
1
1..*
Form
Description
Section
Field
Figura 6.8: A sintaxe abstrata do metamodelo de empresa referente viso de documento.

context Form
inv: self.reservedSpaces->forAll(r | r.oclIsKindOf(Field))
context Report
inv: self.reservedSpaces->forAll(r | r.oclIsKindOf(Section))
Figura 6.9: Restries nas metaclasses da viso de documentos.
As duas outras vises, a motivacional e a processual, so baseadas nos padres

BMM e BPDM, respectivamente. Dada a complexidade e, por consequncia,
quantidade de metaclasses definidas em cada um desses padres (especialmente
no BPDM), decidiu-se fazer algumas simplificaes para diminuir o tamanho do
metamodelo resultante. Essas simplificaes so feitas ao retirar metaclasses
opcionais,
ou
seja,
metaclasses
que
no
necessariamente
precisam
ser
representadas em um modelo. Do ponto de vista do metamodelo, as classes

opcionais so classes especializadas (e outras classes relacionadas a ela) e classes
que permitam multiplicidade zero. Considerando que o trabalho trata de uma
primeira proposta de transformao com esse metamodelo, essas simplificaes
permitem concentrar as regras nos conceitos centrais dessas vises. Em trabalhos
futuros o impacto dessas simplificaes pode ser analisado, observando o reflexo na
transformao proposta.
Para a viso motivacional, foram feitas duas simplificaes. A primeira foi no
representar a misso e a viso. A razo disso que tanto a viso quanto a misso
representam informaes de longo prazo e pouco especficas, existindo outras
metaclasses que absorvem as informaes contidas nelas e que permitem que elas
sejam alcanadas no caso a meta e a estratgia, respectivamente. Com isso no
foram consideradas as metaclasses Mission e Vision. A segunda simplificao foi
no tratar do contexto no qual os meios e os fins e fins so formulados. Esse
contexto, que envolve influenciadores e avaliaes deles sobre os meios e fins, tem
como principal uso permitir a anlise da empresa e a tomada de decises. Um dos
resultados dessas atividades a alterao dos meios e dos fins, para que a
119
empresa possa se adequar melhor a esse contexto ou aproveit-lo. No mbito da
transformao proposta por este trabalho, considerou-se que esses resultados so
expressos por um dos modelos criados: o modelo to-be da empresa. Por mais que o
contexto seja til para a criao desse modelo, como o objetivo deste trabalho
apenas a transformao e no a criao dos modelos considerou-se que apenas
o modelo to-be suficiente, pelo menos para uma transformao inicial. Em relao
viso motivacional no modelo to-be, considerou-se que a descrio do contexto
nesse modelo no to til, j que a empresa da forma que est representada ainda
no existe e, novamente, porque o objetivo apenas a transformao. Com isso
foram
removidas
Regulation,
as
seguintes
metaclasses:
InfluencingOrganization,
Influencer,
InfluencerCategory,
OrganizationCategory,
Assessment,
AssessmentCategory, PotentialImpact, PotentialReward, Risk e MotivationElement.

O modelo resultante apresentado na Figura 6.10. Mais detalhes sobre a sintaxe
abstrata (incluindo as restries existentes) podem ser vistos em (OMG, 2008a).
enables
includes
includes more specific
Strategy
*
*
implements
*
channels efforts towards

*
CourseOfAction *
DesiredResult
MotivationElement
*
Name
Description
Tatic
*
Goal
effects enforcement
level of
governs is source of
quantifies
End
Means
Objective
BusinessRule
*
*
is basis for
*
Directive
supports achievement of
*
BusinessPolicy
*
includes
Figura 6.10: A sintaxe abstrata do metamodelo de empresa referente viso motivacional, baseado
no BMM (OMG, 2008a).
Na
viso
motivacional
elemento
central
elemento
motivacional
(MotivationElement) que tem um nome e uma descrio. A partir dele so definidos

meios (Means) e fins (End). Um tipo de fim o resultado desejado (DesiredResult),
120
que pode incluir outros resultados desejados e pode ser especializado em meta
(Goal) e objetivo (Objective), sendo que os objetivos quantificam as metas. Sobre o
meio, ele pode ser especializado em curso de ao (CourseOfAction) e diretiva
(Directive). O curso de ao uma abordagem para atingir os resultados desejados,
podendo incluir outros cursos de ao, permitir que outros cursos sejam realizados e
especializado em ttica e estratgia. Sobre as diretivas, elas governam e so as
origens dos cursos de ao (OMG, 2008a). Alm disso, elas tambm podem apoiar
a obteno dos resultados desejados. As diretivas so especializadas em poltica de
negcio (BusinessPolicy) e regra de negcio (BusinessRule). Uma poltica de
negcio inclui polticas de negcio mais especficas e base para algumas regras
de negcio. Por fim, o nvel de aplicao de uma regra de negcio afetado pelas
tticas definidas.
Para a viso processual foram feitas 10 simplificaes, permitindo que apenas
processos bastante simples possam ser representados o que se considerou
suficiente para uma primeira proposta de transformao. As simplificaes
realizadas so apresentadas na Tabela 6.2. Algumas das simplificaes feitas
apenas aumentam a complexidade do modelo criado, que o caso dos
subprocessos, reuso de interaes, transformao de informao durante a sua
transferncia e extenses do BPMN. No caso dos subprocessos e do reuso de
interaes, o modelo resultante dever possuir atividades copiadas ou atividades
especficas para tratar do subprocesso. Em relao transformao de informao,
ela pode ser realizada atravs de uma atividade especfica ao invs de definir uma
expresso de transformao. Quanto s extenses do BPMN, como elas proveem
"nome para usos especiais de conceitos do BPDM e funcionalidade adicional
especfica ao BPMN" (OMG, 2008c, p.68), a soluo usar apenas os nomes do
BPDM (alguns detalhes relacionados a isso foram tratados durante a definio da
sintaxe concreta).
Outras simplificaes impedem a representao de alguns conceitos, como o caso
da representao de erros, interrupo, rivalidade de BehaviorSteps (que faz com
que BehaviorSteps executados em paralelo sejam abortados quando um
BehaviorStep termina), laos que tratam de multi-instncias (que permite executar
um grupo de atividades sequencialmente ou paralelamente ao avaliar uma
informao no incio da execuo), restrio dos tipos de eventos e derivaes (que
121
permitem explorar possveis configuraes de um elemento composto). Por causa
delas, alguns processos no podero ser representados usando o metamodelo de
empresa proposto.
Tabela 6.2: Simplificaes feitas no metamodelo do BPDM.
Simplificao
Sem erros durante a execuo do processo
Sem interrupo de processo
Sem rivalidade de BehaviorSteps
Sem subprocessos
Sem lao que trata de vrias instncias
Sem extenses para BPMN
Apenas eventos de mensagem, tempo e simples
Sem derivaes
Sem reuso de iteraes
Transferncia de informao no transformam
informaes
Mudanas
Remoo das classes ErrorActivity e AbortActivity,
Remoo das classes CompoundBehavioral Connection e
GroupAbortConnection
Remoo da classe RaceConnection
Remoo das classes Sub-ProcessActivity,
EmbeddedProcess e BehaviorStepGroup
Remoo das classes ActivityLoop, ConditionalLoop,
MultiInstanceLoop e MultiInstanceLoopOrdering
Todas do pacote BPMN Extensions
No representao dos demais tipos de eventos (sejam
intermedirios, de incio ou de fim).
Remoo das classes Derivation, PartReplacement,
IndividualFromSet, SelectorSpecification, Individual e
SubstitutableDerivation
Remoo das classes CompoundInteraction,
InteractionProtocol e CompoundInteractionBinding
Remoo da relao entre Expression e SimpleInteraction
Considerando essas simplificaes, na Figura 6.11 so apresentados alguns dos

principais elementos da sintaxe abstrata do BPDM. O processo (Process) descreve
as atividades (Activity) que devem ser executadas e as interaes (Interaction) que
sero de responsabilidades dos papis do processo (ProcessorRole) j que ele
um InteractiveBehavior. Uma atividade um tipo de BehaviorStep, ou seja, um
HappeningPart cujo acontecimento um comportamento (Behavior), e que assim
ativa um comportamento ao ser executada. A atividade tambm interage com outros
elementos, recebendo entradas e sadas, sendo assim um InteractivePart. A
atividade de responsabilidade de um papel (PerformerRole), que pode deleg-la a
outros papis. Quem realiza o papel um ator (Actor), tambm existindo um papel
de mais alto nvel (ProcessorRole). Um tipo de interao a interao simples
(SimpleInteraction) em que algo transferido entre os participantes da interao.
Uma das possveis transferncias a de mensagens (Message), existindo
mensagens de incio (StartMessage), mensagens de fim (EndMessage) e trocas de
mensagens (MessageFlow). Mais detalhes sobre a sintaxe abstrata dessa viso
podem ser vistos na especificao do BPDM (OMG, 2008b) (OMG, 2008c).
122
*
Gateway
Interaction
CoursePart
1
predecessor
1
successor
*
Succession
*
*
Hapening
Part
ExclusiveSplit
0..1
*
Behavior
Step
Interactive
Behavior
Behavior
1
0..1 *
2..*
0..1
Simple
Interaction
*
*
Interactive
Part
0..1
Activity
Process
*
*
0..1
0..1
*
Simple
Activity
Message
Performer
Role
0..1
Processor
Role
*
0..1
Start
Message
End Message
Message
flow
Actor
Figura 6.11: Parte da sintaxe abstrata do metamodelo de empresa referente viso processual,
baseado no BPDM (OMG, 2008b) (OMG, 2008c).
As cinco vises do metamodelo de empresa so relacionadas conforme apresentado

na Figura 6.12 (uma relao entre as vises de processo e estrutura organizacional
apresentada na Figura 6.4). No BMM definido que uma entidade (Entity, da viso
organizacional) estabelece meios (Means), determina estratgias (Strategy) e define
fins (End). A entidade tambm responsvel por processos (Process), enquanto
que as polticas de negcio (BusinessPolicy) governam os processos, as regras de
negcio (BusinessRule) os guiam e os cursos de ao (CourseOfAction) os realizam.
Alm dessas relaes definidas pelo padro, considerou-se que uma entidade est
em um local (Place) e uma atividade simples faz um movimento de artefatos
(Movement) de um local para outro (outras formas de movimento, como movimento
de pessoas, foram desconsideradas, por simplicidade). Uma atividade simples
(SimpleActivity) tambm usa um item usvel (UsableItem) e pode acessar e
preencher espaos reservados (ReservedSpace), alm de ler e escrever em
artefatos (Artifact). Por fim, uma atividade pode ser executada com auxlio do
software to-be (Software).
123
Motivation::
Means
*
establishes
*
from
* Environment:: 1
Motivation:: determines Organizational:: *
* Environment::
to
Strategy
Entity
Place
Movement
is in
*
*
*
1
*
1..*
0..1
*
defines
plays
Motivation::
does
End
*
1
*
1
reads
Process::
Environment:: *
Process::
*
* writes * Document::
* ProcessorRole
UsableItem
Artifact
uses SimpleActivity
Core::Software 0..1
*
*
plays
0..1
*
*
Name
1
accesses
fills
owns
*
*
0..1
1..*
Document::
Process::
ReservedSpace
Process
*
*
governs
*
Motivation::
BusinessPolicy
*
guides
*
Motivation::
BusinessRule
realizes
*
Motivation::
CourseOfAction
Figura 6.12: Relaes entre os elementos definidos pelas 5 vises do metamodelo de empresa.
Apenas uma restrio foi definida entre os elementos de diferentes vises: a que um
ProcessorRole realizado por um software ou por uma entidade. Essa restrio
apresentada na Figura 6.13.
context ProcessorRole
inv: self.software.oclIsUndefined() xor self.entity.oclIsUndefined()
Figura 6.13: Restrio entre as vises de processo e organizacional.
Para agrupar os elementos do metamodelo e para representar a empresa foi

definido um outro conceito, no encontrado na anlise realizada: a organizao
(Organization). A metaclasse que representa esse conceito e a relao dela com os
outros elementos so apresentados na Figura 6.14. Os relacionamentos foram
definidos para que todos os elementos possam ser vistos como parte de uma
organizao: as plantas, os artefatos, e elementos motivacionais so de uma
organizao; a entidade, a funo e a relao de entidades so definidas no
contexto de uma organizao; o processo e o papel so de uma organizao; e, por
fim, o modelo da empresa pode tratar da criao de um software.
124
Environment
:: Layout
Document::
Artifact
*
Process::
PerformerRole
Core::
Organization
0..1
Core::
Software
name
*
Process::
Process
Motivation::
* MotivationElement
Organizational::
Entity
Organizational::
Function
Organizational::
EntityRelationship
Figura 6.14: A relao da organizao com os demais elementos do metamodelo de empresa.
6.2.3 Semntica
A seguir apresentada a semntica em linguagem natural para as vises

organizacional, de documento e de ambiente fsico, alm das metaclasses gerais
(Core), organizadas pelo pacote definido para a sintaxe abstrata. A semntica das
vises processual e motivacional no ser apresentada, sendo detalhada
respectivamente nos padres BPDM (OMG, 2008b) (OMG, 2008c) e BMM (OMG,
2008a).
Pacote Core:
o Organization: a organizao.
o Software: software que se deseja construir nessa Organization.
Viso Organizacional:
o Entity:
um
elemento
da
estrutura
organizacional
de
uma
Organization.
Name: a identificao da Entity.
o Department: uma Entity que representa um rgo ou unidade da
Organization, o qual composto por diversas Positions.
o Position: uma Entity que representa um cargo na Organization.
o EntityRelationship: relao de interdependncia entre Entities.
o HierarchicalRelationship: tipo de EntityRelationship que representa
uma relao de subordinao entre uma Entity e outra.
o Function: a atribuio sob a responsabilidade de uma Entity.
125
Description: texto breve que apresenta a Function.
Viso de documento:
o Artifact: um documento usado na Organization.
Name: a identificao de um Artifact.
Media: a mdia usada pelo Artifact ou na qual ele est
armazenado, como, por exemplo: CD, papel, pgina web etc.
o Report: Artifact que representa uma narrao ou descrio de algo
relevante para ou sobre a Organization.
o Form: Artifact padronizado e estruturado segundo sua funcionalidade
especfica (CURY, 2007).
o ReservedSpace: contedo do Artifact que acessado ou preenchido
por alguma Activity (do BPDM).
Description: um texto breve que apresenta o propsito do
ReservedSpace.
o Section: um ReservedSpace que representa uma diviso de um
Report.
o Field: um ReservedSpace que possui (ou possuir) uma unidade de
informao em um Form.
Viso de ambiente fsico:

o Item: um elemento fsico de posse de uma Organization (representado
bidimensionalmente).
Name: a identificao do Item.
Width: a largura do Item.
Height: a altura do Item.
o UsableItem: um Item que pode ser usado durante a execuo de uma
SimpleActivity.
o Layout: um Item que representa um espao fsico.
o Place: uma rea bidimensional em um Layout.
Name: identificao do Place.
XPosition: ponto inicial, no eixo X, do Place no Layout.
YPosition: ponto inicial, no eixo Y, do Place no Layout.
o Movement: a mudana de um Artifact de um Place para outro.
o Equipment: ferramentas e mquinas usadas em uma Organization.
o Furniture: uma moblia da Organization.
126
6.2.4 Sintaxe concreta
A sintaxe concreta do metamodelo de empresa grfica. Apenas a viso processual

usa um padro, o BPMN (OMG, 2011a) que compatvel com o BPDM (OMG,
2008b). Dessa forma, ela no ser descrita nesse trabalho. A sintaxe concreta das
demais vises (at mesmo a motivacional) seguem notaes especficas, algumas
inspiradas em notaes usadas por outras abordagens. Um exemplo da aplicao
dessa sintaxe concreta apresentado no Apndice C.
A sintaxe concreta da viso organizacional apresentada na Tabela 6.3. Essa
sintaxe baseada em organogramas definidos em trabalhos da rea de
Organizao e Mtodos.
Tabela 6.3: Sintaxe concreta da viso organizacional.
Elemento/Conceito
Representao
Department
Nome
Position
Nome
Function
Description
HierarchicalRelationship
Relao entre Function e Entity
(seta aponta a Entity)
Relao entre Position e Department
(seta aponta a Position)
Tabela 6.4: Sintaxe concreta da viso de ambiente fsico.

Elemento/Conceito Representao
Nome
Layout
Place
Nome
Equipment
Nome
Furniture
Nome
127
A sintaxe concreta da viso ambiente fsico apresentada na Tabela 6.4. O
tamanho do retngulo de um Item depende de sua largura (width) e altura (height).
Os Places so colocados dentro de um Layout, assim como os UsableItems so
colocados dentro de um Place. Em relao sintaxe concreta da viso motivacional,
ela apresentada na Tabela 6.5. Essa sintaxe baseada na notao usada pelos
diagramas de metas e de ator propostos pelo mtodo Tropos (BRESCIANI et al.,
2004).
Tabela 6.5: Sintaxe concreta da viso motivacional.
Elemento/Conceito
Representao
Goal
Nome
Objective
Nome
Strategy
Nome
Tactic
Nome
BusinessRule
Nome
BusinessPolicy
Nome
Incluso entre CourseOfActions, DesiredResults ou BusinessPolicies

(seta aponta o que includo)
CourseOfAction canaliza esforos para um DesiredResult
(a seta aponta o DesiredResult)
Directive apoia a obteno do DesiredResult
(a seta aponta o DesiredResult)
Objective quantifica Goal
(a seta aponta o Goal)
BusinessRule base para BusinessPolicy
(a seta aponta a BusinessPolicy)
Tactic implementa Strategy
(a seta aponta a Strategy)
Directive governa CourseOfAction
(losango fica prximo CourseOfAction)
Directive fonte de CourseOfAction
(losango fica prximo CourseOfAction)
Tactic afeta o nvel de aplicao da BusinessRule
(a seta aponta a BusinessRule)
CourseOfAction permite a realizao de outros CourseOfAction
(a seta aponta o CourseOfAction que se permite a realizao)
128
Por fim, a sintaxe concreta da viso de documento apresentada na Tabela 6.6. A
Section representada dentro de um Report, assim como o Field est dentro de
um Form.
Tabela 6.6: Sintaxe concreta da viso de documento.
Elemento/Conceito Representao
Nome
Form e Field
Descrio
Descrio
Nome
Report e Section
Descrio
Descrio
6.3 Metamodelo de caso de uso
O resultado da transformao de requisitos em especificaes ser um modelo

textual de casos de uso. Idealmente o metamodelo usado deveria considerar as
particularidades de sistemas de automao de processos que o escopo deste
trabalho. Entretanto, como no se sabe quais so essas particularidades, decidiu-se
considerar um metamodelo que contempla os aspectos usuais de uma descrio de
caso de uso, sendo, portanto, geral. Um possvel trabalho futuro definir as
caractersticas desse tipo de sistema e especializar o metamodelo usado. De
qualquer forma, a seguir apresentada a anlise realizada e o metamodelo de caso
de uso definido.
6.3.1 Anlise
Uma vez que se pretende empregar um metamodelo de caso de uso geral, ser
aplicado o mesmo mtodo usado para a criao do metamodelo de empresa, ou
seja, a anlise dos conceitos mais comuns em algumas propostas. Para evitar uma
escolha arbitrria de quais propostas seriam consideradas, decidiu-se realizar um
levantamento (survey) em bases de artigos cientficos e em livros sobre o assunto32.
As bases escolhidas foram a ACM, Elsevier, IEEE e Springer, enquanto que os livros
foram escolhidos atravs de uma pesquisa no site Amazon.com.
32
Esse levantamento foi realizado em 27 de outubro de 2010.
129
Nas bases de artigos cientficos foram feitas pesquisas com as palavras-chaves "use
case" e "template" ou "meta-model" (ou "metamodel") nos ttulos ou resumos. Foram
analisados apenas os artigos que tinham como um de seus objetivos propor um
gabarito ou um metamodelo para uma representao textual de caso de uso. Essa
restrio foi considerada para impedir que representaes simplificadas de caso de
uso criadas apenas para testar ou analisar uma proposta fossem consideradas.
Alm disso, para evitar representaes repetidas, quando havia mais de um artigo
de um mesmo grupo de pesquisa considerou-se apenas o artigo mais recente. O
nmero de artigos encontrados e considerados para a criao do metamodelo,
dadas as restries, apresentado na Tabela 6.7.
Tabela 6.7: Resultados do levantamento realizado nas bases de artigos cientficos.
Artigos encontrados
Artigos considerados
IEEE ACM Springer Elsevier

36
30
23
7
5
2
4
1
Em relao ao levantamento de livros, ele foi realizado no site Amazon.com usando

as palavras-chaves "use case" e limitando a pesquisa ao departamento de livros
(Books) e categoria "Computer & Internet". Como resultado obteve-se 109 livros.
Uma vez que mais difcil acessar e analisar livros, foram analisados apenas os 10
primeiros livros ordenados pelo critrio "relevncia" da Amazon. Dessa lista, dois
livros no propem claramente um gabarito ou um metamodelo: em (ALEXANDER;
MAIDEN, 2004) so apenas apresentadas guias gerais para escrever descries
adequadas de cenrios empregando casos de uso e em (DENNEY, 2005) so
discutidos aspectos de qualidade relacionados a casos de uso.
Como resultado do levantamento, foram analisados 20 gabaritos ou metamodelos de
representao textual de casos de uso. Alguns desses trabalhos discutem a
representao textual de casos de uso no contexto da Engenharia de Requisitos
(ER). Leffingwell e Widrig (2003) discutem atividades de ER enfatizando o uso de
casos de uso, dessa forma propondo um gabarito e guias para criar e empregar
casos de uso durante outras atividades de ER. Diferentemente de Leffingwell e
Widrig, Wiegers (2003) discute atividades de ER sem propor uma abordagem
especfica. O caso de uso apresentado como uma tcnica que auxilia o
entendimento de requisitos funcionais.
130
Alguns outros trabalhos so especificamente sobre casos de uso, discutindo seus
conceitos, guias e gabaritos em detalhes. Em (BITTNER; SPENCE, 2002),
(COCKBURN, 2000) e (SCHNEIDER; WINTERS, 2001) discutida a redao de
casos de uso, sendo que em (COCKBURN, 2000) tambm proposto um
metamodelo. Alm de discutir como escrever casos de uso e propor um gabarito, em
(ARMOUR; MILLER, 2001) so apresentados outros assuntos sobre o emprego de
casos de uso no processo de desenvolvimento de software.
Existem tambm alguns trabalhos que propem gabaritos considerando abordagens
especficas. Rosenberg e Stephens (2007) propem um gabarito simples de caso de
uso para ser usado em um processo de desenvolvimento de software (o processo
ICONIX). Tratando apenas de ER, Kulak e Guiney (2003) propem um mtodo de
ER dirigido por casos de uso, portanto tambm propondo um gabarito. Outros
trabalhos propem gabaritos para serem usados em um subconjunto de atividades
de ER: em (SUBRAMANIAM; FAR; EBERLEIN, 2004) proposto um mtodo para
transformar requisies de partes envolvidas em casos de uso; em (CABRAL;
SAMPAIO, 2008) proposto um gabarito usando linguagem natural controlada que
pode ser transformado em lgebra de processos permitindo a verificao de casos
de uso e a gerao de casos de testes; em (LU; SONG, 2008) proposta uma
abordagem para criar casos de uso considerando 4 categorias de aspectos; e em
(BARRET et al., 2009) apresentado um gabarito de caso de uso que permite a
fuso de modelos. Finalmente, em (PETTERSSON; IVARSSON; HMAN; 2005)
proposto um gabarito especificamente para o domnio automotivo, envolvendo
sistemas embarcados.
Mesmo que um gabarito defina os elementos de uma representao textual de um
caso de uso, essa informao descrita em maiores detalhes em um metamodelo.
Entretanto, trabalhos que propem metamodelos geralmente apresentam apenas as
suas sintaxes abstratas, no apresentando sua semntica ou sintaxe concreta
claramente. Alm disso, cada metamodelo considera diferentes vises ou objetivos:
em (DURN et al., 2004) o escopo uma ferramenta de gerncia de requisitos; o
metamodelo em (NAKATANI et al., 2001) prov mltiplas perspectivas de casos de
uso; em (ZELINKA; VRANIC, 2009) proposto um metamodelo que pode ser
configurado; o metamodelo de Smialek et al. (2007) segue uma abordagem
lingustica, usando gramtica para representar aes do caso de uso e propondo
131
trs representaes diferentes de casos de uso; Rui e Butler (2003) propem um
metamodelo para discutir refatoramento de casos de uso; (LEI; JIANG, 2008) prope
um metamodelo que considera diversos conceitos do diagrama de atividades da
UML; e (YUE; BRIAND; LABICHE, 2009) busca transformar automaticamente
modelos de caso de uso em modelos de anlise.
Considerando esses trabalhos, analisou-se os conceitos, metaclasses e metaatributos diretamente relacionados metaclasse ou conceito de caso de uso. Isso foi
feito para simplificar a anlise, evitando a considerao de subelementos de
elementos no frequentes. O resultado dessa anlise apresentado na Tabela 6.8,
sendo que A (ARMOUR; MILLER, 2001), B (BARRET et al., 2009), C
(BITTNER; SPENCE, 2002), D (CABRAL; SAMPAIO, 2008), E (COCKBURN,
2000), F (DURN et al., 2004), G (KULAK; GUINEY, 2003), H (LEFFINGWELL;
WIDRIG, 2003), I (LEI; JIANG, 2008), J (LU; SONG, 2008), K - (NAKATANI et al.,
2001), L (PETTERSSON; IVARSSON; HMAN; 2005), M (ROSENBERG;
STEPHENS, 2007), N (RUI; BUTLER, 2003), O (SCHNEIDER; WINTERS, 2001),
P (SMIALEK et al., 2007), Q (SUBRAMANIAM; FAR; EBERLEIN, 2004), R
(WIEGERS, 2003), S (YUE; BRIAND; LABICHE, 2009) e T (ZELINKA; VRANIC,
2009). Apenas 7 elementos foram propostos por pelo menos a metade dos
trabalhos. Seguindo a terminologia mais frequente, esses elementos so: nome,
descrio breve (tambm chamado de objetivo, descrio, contexto de uso, sumrio
e servio), ator, precondio, ps-condio (algumas vezes dividido em garantias de
sucesso, quando ela deve ser vlida apenas para o caso de sucesso, e garantias
mnimas, quando ela deve ser vlida em qualquer caso), fluxo bsico (tambm
chamado de fluxo principal, cenrio de sucesso principal, curso bsico de eventos e
fluxo primrio) e fluxo alternativo (tambm chamado de extenses, caminhos
alternativos e cursos alternativos).
Seguindo o mesmo mtodo empregado para criar o metamodelo de empresa,
procurou-se por algum padro, ou padres, que consideram esses elementos para
definir um metamodelo. Entretanto no h um padro, apenas algumas propostas
parte delas consideradas no levantamento , como as de (COCKBURN, 2000),
(DURN et al., 2004), (NAKATANI et al., 2001), (RUI; BUTLER, 2003) e (SOM,
132
Tabela 6.8: Frequncia dos elementos nos trabalhos analisados, evidenciando os mais comuns.
Elementos
Nome
Identificador
Autor
Data
Descrio
Escopo
Nvel
Prioridade
Se abstrato
Ator
Primrio
Secundrio
Instncia
Humano
Sistema
Evento
Partes envolvidas
Interesses das partes envolvidas
Pr-condio
Ps-condio (geral ou no especificado)
Garantias de sucesso
Garantias mnimas
Gatilho
Fluxo de eventos
Fluxo bsico
Fluxo alternativo
Especfico a um passo
Para um conjunto de passos
Para todos os passos
Fluxo de exceo
Opcional
Subfluxos
Lista de variao de tecnologia e dados
Fonte
Informao relacionada
Entidade
Regras de negcio
Outros artefatos
Fatos assumidos
Questes
Requisitos especiais
Aspectos no funcionais
Pontos de juno
Interface do usurio
Frequncia
Caso de uso subordinado
Relacionamentos
Incluso
Extenso
Diagramas
de contexto
de caso de uso subordinado
de atividades
de classes
de sequncia
ABCDEFG
X XXX X
X
X
X
X
XXXXX X
X
X
X X
X
X
XX
XX
XX
X
X
X
X
XXX XXX
X X XXX
X
X X
X X
XXX
X
XXXXX X
XXXXX X
XX
X
X
X
X
XX
X
X
X
X
X
X
X
X
X
X
H I J K L M N O P Q R S T Total
X XXXX
X X XX
14
X
X
4
X
2
X
2
XXX
XX X XX
14
X
X
3
3
X
2
1
XX X X
X X X 11
X
X
5
X
X
3
X
1
X
1
X
1
X
1
1
X
2
X
X X X X X X X X 15
X
X X X X X X X X 14
X
X X
6
X
X
X X
6
X X
5
X X
X XX
6
X X XX
X X X X X 15
X
XXX
X X X X 14
X
1
X
1
X
1
X
5
1
X 2
XX
3
1
X 3
X
1
X
X
3
X
1
X
3
X
X
3
X X X
X X X
8
X
1
X
1
X
1
X
2
X
X
2
1
XXX
X X 5
XXXXX
X
X 9
1
X
1
X
1
X
1
X
1
X
1
133
2009). Uma soluo seria escolher entre uma dessas propostas. Porm, essa
soluo seria arbitrria, uma vez que nenhuma delas possui o mesmo escopo deste
trabalho. Alm disso, as propostas consideram vises e objetivos distintos. Dadas
essas diferenas, preferiu-se criar um novo metamodelo de caso de uso simples e
que define apenas os elementos mais comuns sugeridos por propostas de
representaes textuais de casos de uso. A vantagem de um metamodelo desse tipo
que ele pode ser mais facilmente entendido e estendido ao considerar outros
conceitos. Dessa forma, ele pode ser facilmente mudado ao absorver conceitos
definidos por outras propostas sem muitas mudanas sintticas ou semnticas.
Alm dos elementos mais comuns, previamente levantados, necessrio considerar
outras informaes para definir esse metamodelo. Primeiramente foram analisados
os subelementos para cada um dos 7 elementos encontrados. O resultado dessa
anlise apresentado na Tabela 6.9. Apenas para o fluxo bsico e para o fluxo
alternativo encontrou-se elementos em comum. Para o fluxo bsico encontrou-se
passos (tambm chamados de aes, eventos e sentena de cenrio), com um
nmero associado. Similarmente, no fluxo alternativo existem passos, mas tambm
o passo da ramificao (tambm chamados de pontos de insero) e condies.
Por mais que haja um consenso em relao existncia de passos nos fluxos
bsico e alternativo, h uma grande variao em relao ao que permitido a
respeito da organizao e do sequenciamento deles. Essas variaes no so
sempre explicitadas da mesma forma que os elementos da descrio textual, sendo
em alguns casos apontados como boas prticas para a redao do fluxo. Dessa
forma, em seguida foi analisado o posicionamento dos trabalhos em relao s
formas de organizao e sequenciamento que aparecem mais comumente nos
trabalhos: condies, laos, paralelismo (aes executadas em paralelo) e blocos ad
hoc (no qual as aes so executadas sem uma ordem definida). O resultado
apresentado na Tabela 6.10, na qual se considera se o trabalho a favor (F), contra
(C) ou no discute a opo (N) no sendo, portanto, nem contra e nem a favor.
Para as opes em que a maioria dos trabalhos no a discute, considerou-se que
elas no devem ser representadas. Dessa anlise, a concluso que o metamodelo
deve considerar apenas condies e laos.
134
Tabela 6.9: Frequncia dos subelementos nos trabalhos analisados, evidenciando os mais comuns.
Elemento
Nome
Subelementos
Papel
Objetivo
Condio de ocorrncia
Descrio
Texto
Prioridade
Status
Nome
Ator
Objetivo
Condies
Pr-condio
de requisio
de insero
Se sucesso foi alcanado
Ps-condio
Condies
Nmero
Nome
Passos
Incluso
Texto
Pr-condio
Fluxo bsico
Gatilho
Condio de fim
Condio de exceo
Exceo
Ps-condio
Agente origem e destino
ID
Nome
Descrio
Prioridade
Passo da ramificao
Ponto final
Nmero
Nmero do fluxo
Passos
Condio
Nmero da condio
Texto
Fluxo alternativo
Ator
Gatilho
Incluso
Pr-condio
Ps-condio
Fonte
Fatos assumidos
Questes
Requisitos especiais
Condio de exceo
Condio de fim
Abortar ou resumir
A B C D E F G H I J K L M N O P Q R S T Total
X
XX
X
X
X
X
X
X
X
X
X
X
XX
X X
X
X
X
X
X
XX
XX
XXXX
XXXX
X
XX X
X
XXXXXXX
X
X
X
XX
X
X X
X
XXX XX
X
X XX XXX
X
X
X
X
X
X
X
X
X X
X
X
XX XXXX
X
X X
X
X
XXXXXX
X
X X
XX
XX
XX
X X XXX XXX
X X
X
X
X
XXX
XXX XX
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
2
4
1
1
1
1
3
1
6
1
1
1
6
15
3
16
1
3
2
1
2
2
1
2
1
1
2
1
1
11
1
11
1
16
8
1
2
1
1
1
2
2
1
1
1
1
2
1
2
Especificamente em relao aos passos, em alguns trabalhos so propostos

diferentes tipos. Porm no h um consenso sobre quais so eles. Por exemplo, em
(BITTNER; SPENCE, 2002), (COCKBURN, 2000) e (DURN et al., 2004) so
separados os passos executados pelo sistema daqueles executados pelos atores.
135
Alm dessa diviso, Bittner e Spence (2002) tambm dividem os passos em
principais e secundrios, enquanto que Cockburn (2000) divide em interao entre
atores, validao e mudana interna. Outros trabalhos consideram tipos especficos
de passos: Rui e Butler (2003) dividem os passos em estmulos, resposta e ao; e
Schneider e Winters (2001) diferenciam o passo inicial e o passo final. Uma vez que
nenhuma dessas divises em tipos de passos frequente, nenhuma delas foi
considerada no metamodelo.
Tabela 6.10: O posicionamento dos trabalhos em relao organizao dos passos.
Tipo
Condio
Lao
Paralelismo
Bloco ad hoc
ABCDEFGH I JKLMNOPQRST
F
F
F
F
F
F
F
N
F
F
F
N
N
N
N
N
C
F
F
F
F
F
N
N
C
F
N
N
F
N
N
N
N
N
N
N
N
N
N
N
F
F
N
N
F
F
F
N
N
N
N
N
C
C
N
N
F
F
F
F
F
N
N
N
F
F
N
N
C
N
N
N
F
F
F
N
F
F
N
N
Total
A favor Contra No discute
12
4
4
12
1
7
7
0
13
3
0
17
Alguns trabalhos tambm propem heursticas para restringir o contedo dos fluxos
de eventos, como, por exemplo, Cockburn (2000) sugere que devem existir de 3 a
10 aes por fluxo bsico, Armour e Miller (2001) sugerem que no deve ter mais de
um nvel de aninhamento de condio ou interao em um fluxo de eventos e Durn
et al., (2004) sugere que deve haver por volta do mesmo nmero de passos do ator
e do sujeito. Porm, como essas regras tambm no so frequentes, preferiu-se no
limitar o metamodelo com elas.
Por fim, para criar o metamodelo de caso de uso foi necessrio decidir se ele
deveria ser compatvel com a UML ou no. Considerando que o caso de uso faz
parte da UML, a princpio o metamodelo deveria ser compatvel, usando para isso o
mecanismo de extenso disponvel pela UML, os perfis (OMG, 2011b). Entretanto,
de acordo com a especificao da UML, os perfis no permitem que restries sejam
mudadas, sendo possvel apenas adicionar outras restries s j existentes no
metamodelo da UML (OMG, 2011b). Com isso, o metamodelo de caso de uso
deveria usar como base as metaclasses da UML e as restries j existentes, ou
estendendo o pacote de casos de uso ou definindo um novo tipo de Behavior.
Qualquer uma dessas solues tornaria o metamodelo criado mais complexo do que
o necessrio para a transformao e no traria vantagens prticas apenas a
compatibilidade com a UML. Por exemplo, seria necessrio considerar restries
existentes no padro, assim como conceitos de incluso e extenso e a semntica
136
de ao para os passos nos fluxos de eventos similar ao que feito em (SOM,
2009). Dessa forma, decidiu-se que o metamodelo no ser compatvel com a UML.
A seguir apresentada a sintaxe abstrata, a semntica e a sintaxe concreta do
metamodelo criado.
6.3.2 Sintaxe abstrata
A sintaxe abstrata do metamodelo de casos de uso, representada atravs de um

diagrama de classes UML (OMG, 20011b), apresentada na Figura 6.15 33 . As
metaclasses criadas a partir dos conceitos obtidos atravs da anlise realizada so
representadas em branco. Algumas outras metaclasses, representadas em cinza,
foram criadas para simplificar o metamodelo ou por representar informaes que
foram consideradas teis para a transformao.
A metaclasse UseCase foi adicionada para permitir representar mais de um caso de
uso em um mesmo modelo. Como o nome e a descrio so apenas textos (j que
na maioria dos trabalhos eles no possuem outras informaes), eles foram
considerados como atributos dessa metaclasse (Name e Description). A metaclasse
FlowOfEvents foi criada para simplificar o metamodelo, representando o fato de o
fluxo bsico (BasicFlow) e de o fluxo alternativo (AlternativeFlow) possurem uma
semntica similar e conterem um conjunto ordenado de passos. Por motivo similar
foi criada a metaclasse Statement, representando a generalizao de laos
(LoopStatement) e condies (ConditionalStatement). Por fim, como apenas os
passos que no so Statement definem um comportamento, foi necessrio criar uma
metaclasse Action, com um atributo descrio (Description).
Alm dessas metaclasses, tambm foram criadas outras duas que descrevem
informaes especficas da transformao. A metaclasse Subject representa o
sistema em questo que tratado pelo caso de uso. Considerando esse conceito,
criou-se tambm a metaclasse abstrata Agent (definindo seu nome atravs do metaatributo Name), representando a generalizao de sujeito e ator. Essa metaclasse
33
O diagrama apresenta os conceitos em ingls por consistncia ao metamodelo de empresa.
137
permite representar quem realiza o passo (se o ator ou o sujeito), diferenciando-as
no modelo.
Agent
Subject
Name
0..1
1
Condition preCondition
1
Expression postCondition
1
1
0..1
1
is target of
*
UseCase
Name
Description
0..1
1
1..*
takes part in
Actor
AlternativeFlow
BasicFlow
considers
*
FlowOfEvents
executes
extends
has
0..1
1
branchingStep
1..*
{ordered}
1..* {ordered}
Step
0..1
0..1
Statement
Loop
Statement
Action
Description
Conditional
Statement
Figura 6.15: A sintaxe abstrata do metamodelo de caso de uso.
Considerando essas mudanas, no metamodelo o caso de uso (UseCase) tem como

escopo um determinado Subject. Um ou mais atores, representados pela metaclasse
Actor, participam de um caso de uso, sendo que cada ator pode participar de
diversos casos de uso. Cada caso de uso pode possuir uma pr e ps-condies
(associaes entre UseCase e Condition). Para descrever o comportamento do caso
de uso existem dois tipos de fluxos de eventos, representados pela especializao
da metaclasse FlowOfEvents: o fluxo bsico (BasicFlow) e o fluxo alternativo
(AlternativeFlow). Cada fluxo de eventos composto por um conjunto ordenado de
passos (Step). Os passos podem ser comandos (Statement) ou aes (Action),
sendo que o comando uma metaclasse abstrata e deve ser um lao
(LoopStatement) ou uma condio (ConditionalStatement). O comando pode
considerar mais de um passo, tratando de um conjunto ordenado de passos. Por fim,
o fluxo alternativo possui um passo da ramificao (associao entre AlternativeFlow
e Step), que um passo no qual ocorre o desvio, sendo que esse desvio
representado por uma condio (associao entre AlternativeFlow e Condition).
138
Existem duas restries que precisam ser consideradas nesse metamodelo: um Step
deve estar em um FlowOfEvents ou (exclusivamente) em um Statement e que um
AlternativeFlow no pode ter como passo da ramificao um de seus Steps. Na
Figura 6.16 essas restries so apresentadas em OCL (OMG, 2006b). Em relao
restrio do fluxo alternativo, por simplicidade no foram consideradas definies
circulares, como, por exemplo, impedir que um fluxo alternativo tenha como passo
da ramificao um passo de um fluxo alternativo que tem como passo da
ramificao um passo do primeiro fluxo alternativo.
context Step
inv: self.statement <> null xor self.flowOfEvents <> null
context AlternativeFlow
inv: self.branchingStep.flowOfEvents <> self
Figura 6.16: Restries em OCL (OMG, 2006b) da sintaxe abstrata do metamodelo de caso de uso.
6.3.3 Semntica
A seguir apresentada a semntica em linguagem natural de cada uma das

metaclasses e meta-atributos do metamodelo de casos de uso. A semntica desses
conceitos foi definida a partir da anlise realizada e segue a definio mais comum
ou baseando-se na UML, caso possvel:
UseCase: especificao de um conjunto de Steps executados pelo Subject, o

qual gera um resultado observvel que , tipicamente, de valor para um ou
mais Actors ou outras partes envolvidas (OMG, 2011b).
o Name: a identificao do UseCase.
o Description: texto breve que apresenta o propsito do UseCase.
Agent: um Actor ou um Subject do UseCase, o qual executa Steps.

o Name: o nome do Agent.
Actor: o tipo de papel executado por entidades externas ao Subject e que

interagem com ele (OMG, 2011b).
Subject: o sistema em questo o qual os casos de uso se aplicam (OMG,

2011b).
FlowOfEvents: um conjunto ordenado de Steps executados por Agents para

atingir o objetivo do UseCase.
BasicFlow: o FlowOfEvents mais comum e/ou de sucesso do UseCase.
139
AlternativeFlow: um FlowOfEvents que trata de desvios de um outro

FlowOfEvents.
Condition: uma expresso que pode ser avaliada como verdadeira ou falsa.
Precondition: uma Condition do Subject que precisa ser verdadeira para que
o UseCase inicie.
Post-condition: uma Condition do Subject que precisa ser verdadeira ao fim

da execuo do BasicFlow.
Step: uma unidade de comportamento.
Action: um Step que representa a interao entre um Actor e o Subject.

o Description: a representao textual da Action.
Statement: um tipo de Step com uma Condition e um conjunto ordenado de

Steps.
ConditionalStatement: um Statement cujo conjunto ordenado de Steps

executado caso a Condition seja verdadeira.
LoopStatement: um Statement que executa o conjunto ordenado de Steps

enquanto a Condition seja verdadeira (ou seja, ele executa zero ou mais
vezes o conjunto de Steps).
BranchingStep: o Step onde o desvio tratado pelo AlternativeFlow ocorre,

dada uma Condition.
6.3.4 Sintaxe concreta
Foram definidas duas sintaxes concretas para o metamodelo de caso de uso: uma
no TS do XML e outra na forma de um gabarito. A sintaxe concreta no TS do XML foi
feita para que modelos de caso de uso pudessem ser mais facilmente gerados e
processados por ferramentas. Ainda que a linguagem XML tenha como uma de suas
caractersticas a facilidade de leitura por um ser humano (W3C, 2006), considerouse que um modelo XML no seria to facilmente legvel quanto um gabarito
principalmente para a realizao do experimento apresentado no captulo 7. Com
isso, criou-se um gabarito que permite representar as mesmas informaes. O XML
Schema que define a sintaxe concreta em XML est apresentado no Apndice B,
enquanto que o gabarito apresentado na Figura 6.17. As meta-informaes no
gabarito so apresentadas entre "<" e ">", opes entre "[" e "]", separadas por "|" e
140
repetio atravs de "*" (zero ou mais) ou "+" (um ou mais). Um exemplo de um
modelo usando a sintaxe concreta em XML apresentado no Apndice E e um
modelo usando o gabarito apresentado no Apndice D.
<UseCase.name>
Descrio
<UseCase.description>
Ator
<Agent.name> [, <Agent.name>]*
Pr-condio:
<UseCase.preCondition.Expression>
Fluxo bsico:
[<Nmero do passo>. [<Action.description> |

Enquanto <LoopStatement.condition.Expression> |
Se <ConditionalStatement.condition.Expression>].]+
Fluxo Alternativo
[Passo <Nmero do branchingStep>: <Condition>.

[<Nmero do passo>. [<Action.description> |
Enquanto <LoopStatement.condition.Expression> |
Se <ConditionalStatement.condition.Expression>].
]+
]*
Ps-condio:
<UseCase.postCondition.Expression>
Figura 6.17: Gabarito como sintaxe concreta do metamodelo de caso de uso.
6.4 Regras de transformao
Para transformar o modelo da empresa em um modelo de caso de uso so

necessrias regras de transformao. Considerando o quadro de referncia de
requisitos, existem dois tipos de regras: (1) as que extraem do modelo da empresa
requisitos ou especificaes (ou informaes relacionadas a eles) e os representam
no modelo de casos de uso e (2) as que extraem requisitos existentes no modelo da
empresa e os refinam em especificaes que devem ser representadas no modelo
de casos de uso. As regras do tipo (1) sero chamadas de regras sintticas, uma
vez que elas apenas mudam a notao dos requisitos ou das especificaes, mas
no alteram o seu contedo. Por outro lado, as regras do tipo (2) sero chamadas
de regras de refinamento, uma vez que elas refinam os requisitos considerando o
conhecimento do domnio e, em alguns casos, ao escolher uma determinada
alternativa de refinamento.
Uma possvel fonte dessas regras de transformao a anlise de heursticas
propostas por trabalhos relacionados, em especial aqueles que propem
abordagens para a obteno de um modelo de casos de uso. Alguns desses
trabalhos definem explicitamente regras, como o caso de (DIAS et al., 2006),
141
(RODRGUEZ; FERNNDEZ-MEDINA; PIATTINI, 2007), (SANTANDER, 2002) e
(SANTANDER; CASTRO; 2002), por exemplo, enquanto que outros definem
implicitamente regras durante a descrio da abordagem proposta, como em (DE LA
VARA; SANCHZ; PASTOR, 2008) e (MOLINA et al., 2000). Ainda que alguns
trabalhos considerem um metamodelo de empresa (ou, genericamente, um contexto
empresarial) como origem das regras e um metamodelo de casos de uso como
destino, necessrio adaptar essas regras para os metamodelos aqui empregados.
Essa adaptao envolve uma anlise semntica da regra para mapear os conceitos
envolvidos em metaclasses dos metamodelos de empresa e de casos de uso. Dessa
maneira, a obteno dessas regras envolve algumas decises arbitrrias, mas
permite facilmente obter um conjunto inicial de regras.
Seguindo essa abordagem, na Tabela 6.11 so apresentadas as regras obtidas
atravs da anlise dos seguintes trabalhos: (DE LA VARA; SANCHZ; PASTOR,
2008), (DIAS et al., 2006), (DIJKMAN; JOOSTEN, 2002a), (DIJKMAN; JOOSTEN,
2002b), (MOLINA et al., 2000), (RODRGUEZ; FERNNDEZ-MEDINA; PIATTINI,
2007), (SANTANDER, 2002), (SANTANDER; CASTRO; 2002) e (STOLFA;
RADECK, 2004). As regras consideram os metamodelos apresentados nas sees
6.2 e 6.3: as metaclasses do metamodelo de empresa esto em itlico e as
metaclasses do modelo de casos de uso esto sublinhadas. Para obter esse
conjunto foram desprezadas regras que tratam de requisitos no funcionais (que no
fazem parte do escopo deste trabalho) e regras que tratam de conceitos no
existentes no metamodelo de caso de uso (como relaes de incluso e
generalizao). A exceo so as regras relativas extenso entre casos de uso, as
quais se considerou que poderiam ser adaptadas para tratar dos fluxos alternativos
apesar das diferenas semnticas entre esses dois conceitos.
Enquanto que algumas regras so propostas por diversos trabalhos, outras so
embasadas em apenas um trabalho ou at mesmo foram criadas para permitir a
obteno de uma transformao coerente ao considerar as demais regras. As regras
mais comuns so as que permitem identificar atores e casos de uso. Os atores so
obtidos a partir de elementos externos ao sistema papel (DIJKMAN; JOOSTEN,
2002a) (DIJKMAN; JOOSTEN, 2002b), raia e participante (DE LA VARA; SANCHZ;
PASTOR, 2008) (DIAS et al., 2006) (RODRGUEZ; FERNNDEZ-MEDINA;
142
Tabela 6.11: Regras obtidas atravs da anlise dos trabalhos relacionados.
Nmero
RS1
RS2
RS3
RS4
RS5
RS6
RS7
RS8
RS9
RS10
RS11
Descrio
Um PerformerRole executando SimpleActivities que tem MessageFlow (enviam ou recebem
mensagens) com uma SimpleActivity executada por um PerformerRole interpretado pelo sistema
um Actor.
Uma Function executada por um PerformerRole que um Actor um UseCase. Esse Actor
participa no UseCase.
Uma SimpleActivity que tem MessageFlow com o PerformerRole interpretado pelo sistema ser
um Step do UseCase. Se diversas SimpleActivities interagem com o sistema, ento o primeiro
PerformerRole que interage com ele define o UseCase. As SimpleActivities dos outros
PerformerRoles sero tambm um Step, mas elas no definem um UseCase.
Uma SimpleActivity interna ao PerformerRole interpretado pelo sistema, a qual tem um
MessageFlow com uma SimpleActivity identificada como um Step (na RS3), ser um Step do
mesmo UseCase.
Uma Succession entre SimpleActivities define a ordem dos Steps.
Uma SimpleActivity que recebe um MessageFlow representada por um Step antes da
SimpleActivity que envia o MessageFlow.
Se em um caminho de um ExclusiveSplit existe uma SimpleActivity que tem um MessageFlow
com o PerformerRole interpretado pelo sistema e existe uma CoursePart que junta os caminhos,
ento criado um ConditionalStatement com a SplittingExpression como Condition.
Se na regra RS7 mais de um caminho tem MessageFlows, ento cada um deles define um
ConditionalStatement diferente.
Se na regra RS7 um caminho do ExclusiveSplit contm o mesmo ExclusiveSplit, ento ele um
LoopStatement.
Se na regra RS7 existe mais de um caminho que tem um MessageFlow com o PerformerRole
interpretado pelo sistema, e esses caminhos no se juntam, ento o caminho definido como
DefaultSucession (um atributo do ExclusiveSplit) um Step no FlowOfEvents original. Os outros
caminhos definem um AlternativeFlow, com o Step relativo ao DefaultSuccession como o
branchingStep.
Se na regra RS10 o ExclusiveSplit no tiver um DefaultSuccession, ento o caminho mais longo
(com mais CourseParts) ser considerado no FlowOfEvents original.
PIATTINI, 2007) (STOLFA; RADECK, 2004), ou agentes (SANTANDER, 2002)

(SANTANDER; CASTRO; 2002), dependendo do metamodelo usado. Considerando
o metamodelo de empresa, a regra RS1 usa o PerformerRole para obter um Actor.
Em relao aos casos de uso, alguns trabalhos propem uma correspondncia com
uma atividade (DE LA VARA; SANCHZ; PASTOR, 2008) (DIAS et al., 2006)
(MOLINA et al., 2000) (RODRGUEZ; FERNNDEZ-MEDINA; PIATTINI, 2007),
enquanto que outros propem uma correspondncia com um conjunto de atividades
(DIJKMAN; JOOSTEN, 2002a) (DIJKMAN; JOOSTEN, 2002b) (SANTANDER, 2002)
(SANTANDER; CASTRO; 2002) (STOLFA; RADECK, 2004). Como no metamodelo
de empresa uma SimpleActivity executada por apenas um PerformerRole, a regra
RS2 considera a segunda opo. Assim sendo, o UseCase obtido a partir de uma
Function (da viso organizacional), a qual tem vrias SimpleActivities relacionadas.
A escolha pela Function ao invs do nome do Process devido importncia do
objetivo do ator na definio do caso de uso.
143
Uma vez que um grupo de atividades define o caso de uso, as regras RS3 e RS4
identificam as SimpleActivities desse grupo que so Steps no caso de uso. Essas
regras so baseadas em (DIJKMAN; JOOSTEN, 2002a) e (DIJKMAN; JOOSTEN,
2002b) e identificam Steps executados por Actors (RS3) e pelo sistema (RS4). A
ordem desses passos definida pelas regras RS5 e RS6, sendo que a regra RS6 foi
criada, mesmo sem ser proposta por nenhum trabalho, para se obter um modelo
coerente ao considerar as regras RS3 e RS4.
Tambm
relacionada
ordem
dos
Steps,
regra
RS7
identifica
os
ConditionalStatements a partir dos ExclusiveSplits. Ela baseada na regra sobre a

relao de extenso em diagramas de caso de uso proposta em (DIAS et al., 2006),
mas considerando que um Step relacionado SimpleActivity. As regras RS8 e
RS9 so extenses da regra RS7, seja para representar vrias condies ou para
representar um LoopStatement. Relacionada regra RS7, a regra RS10 identifica os
AlternativeFlows de um caso de uso, baseado nas regras de (DIJKMAN; JOOSTEN,
2002a), (DIJKMAN; JOOSTEN, 2002b), (SANTANDER, 2002) e (SANTANDER;
CASTRO; 2002), alm da regra de (DIAS et al., 2006) sobre a relao de extenso.
Como um ExclusiveSplit pode ter vrias Successions e como o DefaultSuccession
no obrigatrio em um ExclusiveSplit, foi necessrio criar a regra RS11. Essa
regra considera a hiptese que o maior caminho o caminho mais importante do
processo e, portanto, deve fazer parte do fluxo corrente (o que no
necessariamente verdadeiro).
Por fim, alguns trabalhos propem regras relacionadas s pr e ps-condies que
no foram aqui consideradas. De La Vara, Sanchz e Pastor (2008) e Dijkman e
Joosten (2002a) (2002b) propem uma regra para obter uma pr-condio a partir
de uma condio antes da atividade mapeada como primeiro passo. Entretanto,
essa regra pode no ser verdadeira ao considerar o metamodelo de empresa e a
semntica da pr-condio em um caso de uso: um ExclusiveSplit que trata dessa
condio no necessariamente uma condio do sistema, mas uma condio
sobre o trabalho do PerformerRole. Outras informaes so necessrias para decidir
se o ExclusiveSplit realmente pode ser mapeado pr-condio. Com isso, essa
regra no foi aqui considerada. Um problema similar ocorre com a regra proposta
por De La Vara, Sanchz e Pastor (2008) que mapeia uma condio depois da
ltima atividade a uma ps-condio. Caso essa condio seja um ExclusiveSplit em
144
um PerformerRole no executado pelo sistema, ela no representaria o estado do
sistema, mas uma condio para executar atividades do PerformerRole dependendo
da sada dada pelo sistema. Por outro lado, caso esse ExclusiveSplit fosse interno
ao PerformerRole executado pelo sistema, ele teria atividades aps ele no sendo
mais a ltima atividade do fluxo ou conflitaria com as regras RS7, RS8 e RS9.
Ao analisar as 11 regras obtidas, percebe-se que elas so regras sintticas, ou seja,
elas no refinam requisitos em especificaes. Esse resultado esperado ao
considerar que as regras foram obtidas de trabalhos relacionados cuja maioria no
prope a transformao de requisitos em especificaes. As regras apenas
mapeiam conceitos do metamodelo de empresa a outros conceitos do metamodelo
de casos de uso, no adicionando outras informaes. Isso fica evidente ao analisar
as regras R3 a R11 que tratam da obteno dos fluxos principais e alternativos dos
casos de uso. Essas regras no consideram o contedo das atividades ou condies
representadas na viso processual da empresa: o nome da atividade corresponde
ao passo, enquanto que uma condio corresponde a um lao ou uma condio.
Nenhuma das regras altera o nome da atividade ou da condio ao considerar o
contexto, ou mesmo cria uma atividade a partir de outras informaes do modelo.
6.4.1 Mtodo para obteno de regras de refinamento
Como nenhuma regra de refinamento foi obtida atravs da anlise dos trabalhos
relacionados, necessrio aplicar uma outra abordagem para defini-las. Uma
possibilidade realizar a engenharia reversa de um modelo de casos de uso,
procurando no modelo da empresa as origens para os elementos obtidos. Ou seja,
um analista deve rastrear o conhecimento de domnio que foi usado em um
refinamento bem sucedido, identificando-o no modelo da empresa e criando uma
regra que generaliza esse refinamento para outros sistemas similares. Para que isso
seja possvel necessrio que a hiptese H2 seja verdadeira, ou seja, que em um
desenvolvimento de sistemas de automao de processo o modelo da empresa do
ponto de vista organizacional consiga representar o conhecimento do domnio de
uma empresa. Entretanto, o problema dessa abordagem que as regras obtidas so
dependentes de diversos fatores: o sistema no qual ela foi usada, o caso de uso
empregado e o analista que realiza a engenharia reversa. Para os dois primeiros
145
fatores o sistema e o caso de uso , a hiptese aqui considerada que a
influncia deles seria diminuda ao aplicar a abordagem em diversos projetos. Em
trabalhos futuros essa hiptese dever ser analisada. Para a dependncia ao
analista, uma possvel forma de diminuir a sua influncia criar ferramentas para
apoiar as atividades do analista34.
Analisar cada caso de uso

Existe Existe uma regra
diferena?
definida?
Analisar os
Aplicar
regras
existentes
elementos ideais
frente aos
elementos obtidos
Sim
Sim
Alterar regra
existente
Sim
No
No
No
Criar nova
regra
Houve mudana
nas regras?
Figura 6.18: Mtodo para obteno das regras de refinamento, descrito em BPMN (OMG, 2011a).
Seguindo essa abordagem, este trabalho prope o mtodo apresentado de forma

esquemtica na Figura 6.18, como um diagrama BPMN. Para execut-lo so
necessrios trs modelos como entrada: um as-is e um to-be da empresa onde o
sistema ser construdo e um de casos de usos que especifique o sistema proposto
(chamado de "modelo de caso de uso ideal"). Alm disso, necessrio um conjunto
inicial de regras, que pode ser vazio. Os passos desse mtodo so:
1. Aplicar as regras existentes para obter um conjunto de casos de uso.
2. Para cada caso de uso, analisar cada um dos elementos do caso de uso ideal
e os elementos do caso de uso obtido. Para cada elemento diferente:
a. Se o elemento do caso de uso obtido for diferente do elemento no caso
de uso ideal, procure nos modelos as-is e to-be pelos elementos que
tm a informao necessria e que so a fonte dele.
i. Identifique a regra que gerou o elemento no caso de uso obtido.
ii. Analise se a regra deve ser especializada, melhorada ou
revisada, uma alternativa para ela deve ser criada, ou se no
possvel melhorar a regra.
34
Uma discusso mais detalhada dessas possveis ferramentas, considerando o mtodo proposto por
este trabalho, apresentada na seo 6.4.3.
146
iii. Caso a regra existente deva ser melhorada ou revisada,
primeiramente verifique se a mudana realmente relevante
para todos os casos da regra. Caso seja, adicione os elementos,
ou a nova informao, ou revise a regra; caso no seja, a regra
precisa ser especializada.
iv. Caso a regra deva ser especializada, identifique a condio para
especializ-la, considerando os modelos as-is e to-be. Com isso
defina a nova regra, considerando esses modelos e os
elementos esperados como resultado.
v. Caso uma alternativa para a regra deva ser criada, crie uma
regra inicial considerando os modelos as-is e to-be e os
elementos que devem ser obtidos. Em seguida crie uma regra
mais geral que vlida para a regra existente e para a regra
inicial. Por fim, represente as alternativas como itens dessa
regra geral (se a regra j possuir alternativas, apenas adicione a
nova alternativa a ela).
vi. Caso no seja possvel melhorar a regra, continue com o passo
2.
b. Se no houver um elemento correspondente ao elemento do caso de
uso ideal no modelo de casos de uso obtido, ou seja, no houver uma
regra relacionada, crie uma nova regra:
i. Procure nos modelos as-is e to-be por elementos que possuem
as informaes necessrias para a regra.
ii. Analise a condio para que a regra seja vlida.
iii. Crie a regra.
3. Caso uma mudana seja feita no conjunto de regras, reexecute a abordagem
a partir do passo 1.
A ideia principal desse mtodo melhorar o conjunto de regras, seja pela
especializao, reviso, representao de alternativas, ou a proposta de novas
regras.
Para aplicar esse mtodo necessrio considerar mais uma hiptese:
H4. Em sistemas de automao de processo, o modelo da empresa as-is pode
ser usado como referncia para decises de refinamento.
147
Ou seja, em sistemas de automao de processos, o modelo da empresa as-is
apresenta alternativas adequadas de refinamento. Considerando a hiptese H2, as
mudanas no ambiente to-be sero restritas a insero do sistema, no ocorrendo
em paralelo uma melhoria do processo ou reengenharia. Caso essa hiptese no
seja vlida, o conhecimento do domnio presente no modelo da empresa as-is ser
de pouca utilidade para o mtodo.
6.4.2 Aplicao do mtodo e as regras de refinamento
A fim de gerar um conjunto de regras de refinamento que permita a execuo da

transformao de um modelo da empresa em casos de uso, o mtodo proposto foi
executado em um exemplo. Como esse exemplo foi a primeira aplicao do mtodo
proposto, ele foi escolhido pela sua simplicidade e pela familiaridade do domnio, o
que facilitaria sua aplicao35. O exemplo escolhido foi o de uma biblioteca fictcia
que deseja automatizar seu processo de emprstimo de livros. A biblioteca tem um
processo manual de emprstimo que envolve o uso de cartes. Por exemplo,
quando um cliente quer pegar um livro emprestado, ele deve entregar o livro ao
bibliotecrio. O bibliotecrio ento verifica o carto do livro para ver se o livro pode
ser emprestado. Caso ele possa ser emprestado, o bibliotecrio pergunta ao cliente
o seu cdigo para obter o carto de registro dele. Em seguida o bibliotecrio
preenche o carto do livro, o carto de registro do cliente e o carto de sada do
livro. Nesse contexto, o objetivo do sistema computacional controlar o processo de
emprstimo de livros, aposentando o sistema de cartes.
Para aplicar o mtodo, foram criados os modelos as-is e to-be da biblioteca,
considerando o metamodelo apresentado na seo 6.2. Esses modelos so
apresentados no Apndice C 36 . O caso de uso ideal para esse sistema
apresentado no Apndice D e composto por 7 casos de uso: cadastrar livro,
35
Considerando o mtodo proposto, a simplicidade do exemplo influencia diretamente as regras

obtidas. Entretanto, mesmo que um exemplo complexo composto por um modelo de empresa com
mais elementos e que resulta em mais casos de uso fosse empregado, ainda seria necessrio
aplicar o mtodo em mais projetos a fim de obter um conjunto de regras adequado. Dessa forma,
preferiu-se usar um exemplo mais simples.
36
Os modelos sero apresentados em ingls, uma vez que eles foram originalmente criados nessa
lngua. Como ser apresentado na seo 6.5.3, a ferramenta criada transforma tanto modelos em
ingls como em portugus.
148
emprestar livro, devolver livro, cadastrar cliente, pagar multa, gerenciar cliente e
gerenciar livro. Considerando esses modelos, o mtodo foi aplicado. Primeiramente
as regras sintticas, obtidas atravs da anlise dos trabalhos relacionados, foram
aplicadas para esses modelos usando a ferramenta apresentada na seo 6.5. O
resultado obtido apresentado no Apndice E. Em seguida, o mtodo foi aplicado e
obteve-se ao final o modelo de caso de uso (que no foi representado aqui devido
ao seu tamanho). As regras obtidas so apresentadas na Tabela 6.12 (as regras de
refinamento) e na Tabela 6.13 (as regras sintticas). Assim como na Tabela 6.11, as
metaclasses do metamodelo de empresa esto em itlico e as metaclasses do
modelo de casos de uso esto sublinhadas. Alm disso, as metainformaes nos
passos so representadas entre "<" e ">" e caso a regra especialize outra, o nmero
dela apresentado no comeo da descrio da regra. As regras de refinamento
obtidas so chamadas de RR, enquanto que as regras sintticas so chamadas de
RS, e continuam a numerao das regras obtidas atravs da anlise dos trabalhos
relacionados.
Das regras de refinamento encontradas, a regra RR8 a nica que trata de um caso
de uso completo. Alm de ser um resultado do mtodo, ela tambm foi baseada nas
regras propostas por Dias et al. (2006) que mapeiam objetos interagindo com
atividades de um processo a casos de uso. Essas regras no foram consideradas
durante a anlise dos trabalhos relacionados porque em (DIAS et al., 2006) no h
um detalhamento do contedo desse caso de uso apenas dito que haver um
caso de uso. Com isso, ao aplicar o mtodo proposto foi possvel definir o caso de
uso completamente. Entretanto, a necessidade dessa regra discutvel. Se algum
participante do processo precisa "gerenciar" alguma informao, o correto seria
haver atividades para isso no modelo to-be provavelmente em um processo
especfico. Porm, no modelo criado tais atividades no existem. Apenas o
cadastramento de livros foi considerado e, por isso, h um caso de uso especfico
para isso que separado da "Gerncia de carto de livro". Dessa maneira, uma
possibilidade considerar que essa regra foi criada devido a um erro do modelo tobe. Ainda assim preferiu-se manter a regra ao considerar que algumas dessas
atividades podem no ser modeladas uma vez que elas podem corresponder a
processos separados dos demais processos da empresa e que por isso no foram
modeladas (como foi o caso).
149
Tabela 6.12: As regras de refinamento obtidas ao aplicar o mtodo no exemplo da biblioteca.
Nmero
Descrio
RR1 Se existem SimpleActivities no modelo as-is que escrevem em Artifacts e elas so substitudas
no modelo to-be por SimpleActivities que tem MessageFlow com o PerfomerRole interpretado
pelo sistema, ento crie dois Steps:
"O <nome do sistema> solicita a seguinte informao", com os ReservedSpaces do

Artifact como a informao a ser preenchida. O engenheiro de requisitos precisa
escolher quais desses ReservedSpaces devem ser considerados.
"O <nome do ator>" + o nome da SimpleActivity executada pelo PerformerRole

respectivo a esse Actor no modelo to-be.
Um AlternativeFlow tambm deve ser criado:
BranchingStep: o Step executado pelo Actor.
Condition: "O <nome do ator> no preenche as informaes.".
O AlternativeFlow dever ter apenas 1 Step: " O <nome do sistema> apresenta uma
mensagem de erro e termina o caso de uso.".
RR2 Se existirem SimpleActivities no modelo to-be executadas pelo PerformerRole interpretado pelo
sistema que escrevem em um Artifact, ento um Step deve ser criado:
"O <nome do sistema> imprime o <nome do Artifact> com a seguinte informao:

<ReservedSpaces do Artifact>."
RR3 (Especializao de RS14) Se a SimpleActivity que envia o MessageFlow para a SimpleActivity
executada pelo PerformerRole interpretado pelo sistema substitui a uma SimpleActivity do
processo as-is que l um Artifact, ento o passo referente a SimpleActivity executada pelo
PerformerRole interpretado pelo sistema apresentar os ReservedSpaces do Artifact em
questo como elementos apresentados pelo Step. O engenheiro de requisitos precisa escolher
quais desses ReservedSpaces devem ser considerados.
RR4 (Especializao de RS12) Caso o caminho correspondente ao AlternativeFlow no leve a uma
interao com o sistema, ento o Step o seguinte:
"O <nome do sistema> informa <SplittingExpression> e encerra o caso de uso.".

RR5 (Especializao de RS3 e RR1) Se a SimpleActivity que envia o MessageFlow SimpleActivity
executada pelo PerformerRole interpretado pelo sistema substitui a um ExclusiveSplit do
processo as-is, ento o FlowOfEvents em questo considera a SplittingExpression e so
criados AlternativeFlows para cada ExclusiveSplit:
Condition: a SplittingExpression.
Step: "O <nome do sistema> informa que <SplittingExpression> e termina o caso de

uso".
RR6 (Especializao de RR3 e RS14) Caso a SimpleActivity que envia o MessageFlow
SimpleActivity executada pelo PerformerRole interpretado pelo sistema tenha um ExclusiveSplit
em seguida, mas esse ExclusiveSplit no tenha caminhos executados pelo software, ento
criado um AlternativeFlow:
Condition: a SplittingExpression.
Step: "O <nome do sistema> informa <SplittingExpression>" ou no caso de ser a

especializao de RR3, informa tambm os Fields do Artifact.
RR7 (Alternativa da RH1) Caso nenhum dos ReservedSpaces sejam necessrios (de acordo com o
engenheiro de requisitos), a regra RR1 no deve ser aplicada.
RR8 Para cada Artifact do modelo as-is que no existente mais no modelo to-be, deve-se perguntar
ao engenheiro de requisitos se deve ser criado um caso de uso CRUD. O engenheiro de
requisitos tambm deve definir o ator (inicialmente ele o Actor referente ao PerformerRole
que executa as SimpleActivities que escrevem no Artifact) e os campos que sero usados. O
formato do UseCase apresentado no Apndice F (O engenheiro de requisitos deve selecionar
quais AlternativeFlows devem ser considerados).
Tabela 6.13: As regras sintticas obtidas ao aplicar o mtodo no exemplo da biblioteca.

Nmero
Descrio
RS12 (Especializao de RS9) Deve-se colocar no passo correspondente ao defaultSuccession o texto
do ExclusiveSplit, com o valor da SplittingExpression que leva a ele.
RS13 (Especializao de RS3) Deve-se colocar "O <nome do Actor>" antes do texto da SimpleActivity.
RS14 (Especializao de RS5) Deve-se colocar "O <nome do sistema>" antes do texto da
SimpleActivity.
150
Em relao s regras sintticas encontradas, duas delas, a RS13 e RS14, servem
para adequar o contedo dos passos ao formato idealizado no caso, colocando o
nome do ator no comeo do passo. A outra regra, a RS12, apenas prov a
informao de qual a condio que faz o caminho seguir o fluxo corrente.
Por fim, algumas das regras propostas necessitam da interveno do engenheiro de
requisitos, o que torna a transformao semiautomtica. Essa interveno para ou
decidir se a regra deve ser aplicada (para as regras RR7 e RR8) ou quais
informaes devem ser consideradas (para as regras RR1, RR3 e RR8).
6.4.3 Problemas e limitaes do mtodo
O mtodo proposto possui alguns problemas e limitaes. O primeiro problema

que algumas decises desse mtodo so subjetivas e dependem da experincia de
um analista. Como exemplo dessas decises, o analista deve realizar uma anlise
semntica (no passo 2), encontrar relaes entre elementos de diferentes modelos
(nos passos 2.a.iii, 2.a.iv, 2.a.v e 2.b.ii) e redigir novas regras (nos passos 2.a.iii,
2.a.iv, 2.a.v e 2.b.iii). Dessa forma, a adequao e a qualidade das regras so
diretamente influenciadas pelo analista. Um outro problema a gerncia das regras
obtidas. Conforme o mtodo for aplicado, possvel obter um grande conjunto de
regras (por mais que a expectativa seja que as regras estabilizem com o tempo),
sendo algumas delas complexas. Analisar essas regras para considerar alguma
mudana que seja necessria pode no ser uma atividade simples. Alm disso, ao
criar uma regra difcil garantir que ela no ter um impacto nas demais regras
existentes. Apesar de o passo 3 ter sido definido para evitar alguns desses erros,
uma nova regra pode afetar uma outra em uma situao que no foi considerar no
sistema o qual atualmente se aplica o mtodo.
Por fim, uma outra dificuldade para a aplicao desse mtodo que escrever uma
regra exige conhecimento tanto dos metamodelos, quanto da linguagem de
transformao empregada (na seo 6.5.1 ser discutida a linguagem empregada
para definir as regras na ferramenta usada). Em alguns casos redigir a regra de
transformao na linguagem de transformao pode ser complexo.
151
Dados esses problemas e limitaes, alguns trabalhos futuros podem ser realizados
a fim de melhorar a aplicabilidade do mtodo. Primeiramente, uma ferramenta para
auxiliar a redao das regras ajudaria o analista ao evitar a tomada de algumas
decises incorretas. Essa ferramenta tambm poderia ajudar a gerncia das regras
existentes e evidenciar os relacionamentos entre as regras existentes. Um outro
trabalho futuro definir um conjunto bsico de teste para as regras, o que ajudaria a
prevenir que uma regra nova gere um efeito colateral em outras regras. Outros
trabalhos futuros devem ser realizados a fim de analisar a eficcia do mtodo aqui
proposto, considerando tambm um ambiente real de uma empresa.
6.5 Ferramenta
Uma ferramenta, chamada de EMUCase (Enterprise Model to Use Case Model) foi
criada a fim de permitir a aplicao prtica da transformao proposta.
Considerando a escolha do dos Espaos Tcnicos discutida na seo 6.1.4, a
ferramenta foi criada como um plug-in para o IDE Eclipse (THE ECLIPSE
FOUNDATION, 2011a), usando o Graphical Modeling Framework (GMF) (THE
ECLIPSE
FOUNDATION,
2011c).
Esse
framework
automatiza
parte
do
desenvolvimento de ferramentas grficas, gerando automaticamente cdigo fonte de

um plug-in para o IDE Eclipse. Para isso, a partir do metamodelo em Ecore devem
ser criados 5 modelos (THE ECLIPSE FOUNDATION, 2011c): EMF Generator
Model, Graphical Definition Model, Tooling Definition Model, Mapping Definition
Model e o GMF Generator Model. As transformaes desses modelos para a
obteno do cdigo fonte Java do plug-in so apresentadas esquematicamente na
Figura 6.19. Os modelos so representados como caixas brancas, os cdigos fontes
como caixas cinzas e as transformaes so representadas como setas.
O EMF Generator Model obtido automaticamente a partir do modelo Ecore e gera,
tambm automaticamente, o cdigo Java que permite acessar e modificar os
modelos criados o que necessrio para o GMF. A sintaxe concreta do
metamodelo definida atravs do Graphical Definition Model, que relaciona
elementos da sintaxe abstrata do metamodelo (descrita no modelo em Ecore) a
figuras. Para que seja possvel construir um diagrama, o GMF tambm necessita de
um modelo para definio da barra de ferramentas a ser usada, o que feito pelo
152
Tooling Definition Model
Modelo em
Ecore
Mapping Definition Model
GMF Generator
Model
Graphical Definition
Model
EMF Generator
Model
Cdigo Java para acessar e

modificar modelos
Cdigo Java do
Plug-in
Figura 6.19: As transformaes entre os modelos do GMF e do EMF para obter cdigo fonte Java
de um plug-in grfico (baseado no GMF dashboard (THE ECLIPSE FOUNDATION, 2011a)).
Tooling Definition Model. O mapeamento dos elementos grficos (do Graphical

Definition Model) e as ferramentas (do Tooling Definition Model), considerando a
sintaxe abstrata, feito atravs do Mapping Definition Model. Esse modelo ento
transformado no GMF Generator Model que possui as informaes do plug-in a ser
criado e que pode ser transformado diretamente em cdigo Java. Por fim, o cdigo
obtido pode ser manualmente alterado para, por exemplo, tratar de alguns detalhes
da sintaxe concreta (como para um elemento mudar de cor dependendo de um
valor) e do uso do plug-in (por exemplo, permitir mais de um diagrama por modelo e
permitir drag-and-drop nos diagramas).
Usando esse framework foi criado um plug-in para o metamodelo de empresa,
seguindo a sintaxe apresentada na seo 6.2. No caso do metamodelo de casos de
uso, como a sintaxe concreta escolhida textual (e no grfica), criou-se apenas o
cdigo Java para acessar e modificar modelos, o que necessrio para realizar a
transformao. Ainda assim foi necessrio fazer algumas alteraes na sintaxe
abstrata do metamodelo de casos de uso. Devido necessidade de existir um
elemento raiz no EMF, foi necessrio adicionar mais uma metaclasse: a
UseCaseModel. Essa metaclasse composta por UseCase (0 ou mais), Actor (0 ou
mais) e Subject (apenas 1). Considerando que o Subject do modelo inteiro,
removeu-se a associao entre UseCase e Subject.
153
6.5.1 Roteiro da transformao
Para criar um roteiro de transformao foi usado o padro QVT. Entretanto, uma vez
que o padro especifica trs linguagens diferentes (QVT Relations, QVT Operational
e QVT Core), foi necessrio escolher entre uma delas. As linguagens declarativas
(Relations ou Core) so, a princpio, mais apropriadas uma vez que elas permitem
uma transformao bidirecional enquanto que a linguagem QVT Operacional permite
apenas uma transformao unidirecional (OMG, 2009). Entre as linguagens
declarativas, a linguagem QVT Relations est em um nvel de abstrao mais alto
que a QVT Core, o que evidenciado no padro QVT ao apresentar uma analogia
Mquina Virtual Java: a linguagem QVT Core seria a linguagem do byte code
enquanto que a QVT Relations seria a linguagem Java (OMG, 2009). Dessa
maneira, a linguagem QVT Relations , aparentemente, a mais indicada.
Como a especificao do QVT relativamente recente e existem poucas
implementaes disponveis, um outro critrio importante a disponibilidade de
ferramentas. Foram analisadas duas solues disponveis para uso no comercial37:
a ferramenta Medini QVT (IKV++ TECHNOLOGIES AG, 2008) e o plug-in
Operational QVT Runtime do projeto Eclipse M2M (THE ECLIPSE FOUNDATION,
2011e) para o IDE Eclipse. As duas solues apresentam funcionalidades similares,
permitindo a depurao do roteiro e a possibilidade de embutir a transformao em
um cdigo Java. Apesar disso, a ferramenta Medini QVT na poca dessa anlise
apresentava uma melhor documentao e uma aparente estabilidade, enquanto que
o Operational QVT Runtime estava em desenvolvimento e a sua documentao era
praticamente limitada s mensagens enviadas a um frum. Considerando essa
diferena prtica e a bidirecionalidade da linguagem QVT Relations, escolheu-se
essa linguagem e a ferramenta Medini QVT para desenvolver o roteiro de
transformao.
Primeiramente foi desenvolvido um roteiro para as 11 regras obtidas dos trabalhos
relacionados. Entretanto, o desenvolvimento apresentou alguns problemas e
dificuldades:
37
Essa anlise foi realizada no primeiro semestre de 2010, quando se iniciou a definio das regras
de transformao.
154
Problemas na ferramenta: no possvel usar o comando "let", para

declarar variveis, usar recurses em relaes e h problemas no uso de
metaclasses abstratas em relaes.
Problema na linguagem QVT Relations: o reuso de relaes limitado

chamada de uma relao e h dificuldade em obter listas ordenadas como
resultado, uma vez que as relaes so executadas sem uma ordem definida
(isso obrigou uma mudana na sintaxe abstrata do metamodelo de casos de
uso).
Dificuldade de uso de uma linguagem declarativa: como o paradigma

bastante diferente do orientado a objetos e do imperativo, houve uma
dificuldade de aprendizado.
Dificuldade para testar as relaes: apesar de a ferramenta ter um

depurador embutido, esse depurador no considerava operaes auxiliares
usadas por mapeamentos (query). Para test-las, foi necessrio usar uma
outra ferramenta, a OCL Tools, do projeto Eclipse Model Development Tools
(THE ECLIPSE FOUNDATION, 2011d), o que exigiu alterao no cdigo
usado devido s diferenas na implementao da linguagem OCL.
Tamanho do roteiro: o roteiro obtido possua 1628 linhas para tratar de

apenas 11 regras.
Esses problemas e dificuldades levaram a uma reanlise da opo escolhida ao

considerar que ainda faltava desenvolver as regras de refinamento. Com isso,
decidiu-se traduzir parte do roteiro obtido para a linguagem QVT Operational,
usando o plug-in Operational QVT Runtime, a fim de analisar os problemas e as
dificuldades dessa opo. A anlise concluiu que o desenvolvimento seria menos
trabalhoso, mesmo ao considerar a traduo do roteiro j existente, devido a
algumas diferenas da linguagem e de algumas vantagens da ferramenta. Em
relao linguagem, ela imperativa, permite realizar herana de mapeamentos e
possui uma biblioteca padro que define alguns tipos e alguns mtodos de apoio.
Em relao ferramenta, ela permite a depurao de funes auxiliares, possui uma
melhor compatibilidade com OCL e permite logar informaes (por mais que esse
recurso no seja especificado pelo padro). Dessa forma, o roteiro que trata das 11
regras iniciais foi traduzido para QVT Operational, resultando em um roteiro de 984
linhas (ao invs das 1628 linhas em QVT Relations).
155
O roteiro final, considerando as 14 regras sintticas e as 8 regras de refinamento,
contm 1817 linhas, com 20 mapeamentos, 1 construtor (para criar AlternativeFlows
considerando a regra RR8) e 40 funes auxiliares (query). Esse roteiro
apresentado esquematicamente na Figura 6.20, Figura 6.21 e Figura 6.22, onde os
mapeamentos so representados como retngulos arredondados, as chamadas a
um outro mapeamento como setas com ponta vazada, as opes (mapeamentos
alternativos) como setas tracejadas com ponta vazada e a herana de mapeamento
como uma seta com ponta fechada.
Na Figura 6.20 apresentada a parte central do mapeamento. A operao main
obtm o objeto raiz (no caso uma organizao to-be) e inicia a transformao ao
chamar o mapeamento organization2UseCaseModel, passando a organizao as-is
como parmetro (na realidade, todas as regras recebem esse parmetro). Esse o
mapeamento principal que chama os demais mapeamentos: software2Subject,
performerRole2Actor, artifact2UseCase e function2UseCase. Os mapeamentos
software2Subject e performerRole2Actor tratam do mapeamento dos agentes ao
caso de uso: o software2Subject define um Subject para o caso de uso a partir do
Software e o performerRole2Actor define os Actors seguindo a regra RS1. Os casos
de uso so tratados pelos mapeamentos artifact2UseCase e function2UseCase. O
artifact2UseCase trata da regra RR8 enquanto que o function2UseCase trata da
RS2, considerando a RS5 e RS6, e chama os demais mapeamentos atravs do
activity2Action e gateway2Statement.
main
organization2UseCaseModel
software2Subject
performerRole2Actor
artifact2UseCase
function2UseCase
activity2Action
gateway2Statement
Figura 6.20: A parte central do mapeamento.
Em relao ao mapeamento activity2Action, ele trata da definio de aes em um

fluxo, sendo detalhado na Figura 6.21. Esse mapeamento executa uma das
seguintes
opes:
activityWithArtifact2ActorAction,
activity2ActorAction
ou
activity2SoftwareAction. O mapeamento activityWithArtifact2ActorAction trata da
156
regra RR1 e, para isso, usa os mapeamentos substituedGateway2AlternativeFlow,
que trata da RR5, e simpleActivity2Action, que um mapeamento bsico para criar
uma Action a partir de uma SimpleActivity. A segunda opo o mapeamento
activity2ActorAction que trata da definio de aes dos atores (considerando as
regras
RS3
RS13),
qual
envolve
tambm
os
mapeamentos
substituedGateway2AlternativeFlow e simpleActivity2Action. A ltima opo o

activity2SoftwareAction que trata dos mapeamentos envolvendo aes do sujeito.
Esse mapeamento por sua vez executa um dos seguintes mapeamentos:
activity2PrintingSoftwareAction,
activity2ShowingSoftwareAction
ou
activity2SoftwareBasicAction. O mapeamento activity2SoftwareBasicAction trata da

regra RS4 (considerando a RS14), usando o mapeamento simpleActivity2Action e o
activityWithSplit2AlternativeFlow,
que
trata
da
regra
RR6.
mapeamento
activity2PrintingSoftwareAction trata da RR2, usando apenas o mapeamento

simpleActivity2Action. Por fim, o activity2ShowingSoftwareAction trata da RR3,
usando os mapeamentos simpleActivity2Action e activityWithSplit2AlternativeFlow.
activityWithArtifact2ActorAction
substitutedGateway2AlternativeFlow
activity2Action
activity2ActorAction
activity2SoftwareAction
simpleActivity2Action
activity2PrintingSoftwareAction
activity2ShowingSoftwareAction
activityWithSplit2AlternativeFlow
activity2SoftwareBasicAction
Figura 6.21: Detalhe do mapeamento activity2Action.
Por fim, o mapeamento gateway2Statement trata das regras que envolvem

Gateways,
sendo
representado
esquematicamente
na
Figura
6.22.
Esse
mapeamento executa uma das duas opes: gateway2LoopStatement, que trata da

obteno de laos seguindo a regra RS9, e gateway2ConditionalStatement que trata
da obteno de condies seguindo as regras RS7 e RS8. Ambos os mapeamentos
herdam de abstractGateway2Statement que um mapeamento abstrato para
transformar um Gateway em um Statement. Para fazer isso, esse mapeamento usa
dois outros: o activity2Action (representado na Figura 6.21), para gerar as Actions
157
dentro dos Statements, e o succession2AlternativeFlow, que gera fluxos alternativos
considerando as regras RS10, RS11 e RR4.
succession2AlternativeFlow
gateway2LoopStatement
activity2Action
gateway2Statement
gateway2ConditionalStatement
abstractGateway2Statement
Figura 6.22: Detalhe do mapeamento gateway2Statement.
6.5.2 Projetor para o TS do XML
O resultado da transformao criada em QVT Operational um modelo de caso de

uso no TS do EMF. Entretanto, como a sintaxe concreta escolhida para o modelo de
caso de uso de sada textual, no TS do XML, foi necessrio criar um projetor. Esse
projetor poderia ser criado como uma transformao no TS do XML (usando XSLT),
uma vez que o TS do EMF disponibiliza um projetor para o XML seguindo o padro
XMI (OMG, 2007). Apesar da elegncia dessa opo, devido complexidade do
documento XMI gerado pela implementao de QVT Operational usada, preferiu-se
criar um programa Java que transforma um modelo de caso de uso em EMF para
um modelo de caso de uso em XML.
6.5.3 Viso geral da ferramenta EMUCase
Na Figura 6.23 apresentada a viso geral da ferramenta EMUCase. A ferramenta

permite representar modelos de empresa atravs de diagramas de processo, de
documento, de motivao, de layout e de estrutura organizacional. Um modelo da
empresa as-is e um modelo da empresa to-be podem ser transformados em um
modelo de caso de uso em XML. Essa transformao executada em duas partes,
o que transparente para o usurio: primeiramente executado um roteiro em QVT
Operational que obtm um modelo de caso de uso no TS do EMF e, em seguida,
executado um cdigo Java que obtm um modelo de caso de uso em XML.
158
Diagrama de
processo
Diagrama de
motivao
Transformao
Modelo as-is
Diagrama de
documento
Diagrama de
layout
QVT Operational
Java
Modelo to-be
Modelo de
caso de uso
(XML)
Modelo de
caso de uso (EMF)
Diagrama de
estrutura org.
Figura 6.23: Viso geral da ferramenta EMUCase.
Como exemplo da possibilidade de criao de diagramas para cada uma das vises
do metamodelo de empresa, na Figura 6.24 apresentada a tela de edio do
diagrama de estrutura organizacional. O usurio pode criar mais de um diagrama
para cada viso, por exemplo, criando um diagrama de processo para cada
processo da empresa. Tambm possvel reusar elementos do modelo da empresa
em outros diagramas (atravs de arrastar e soltar), sejam diagramas do mesmo tipo
ou de tipos diferentes. Por fim, possvel imprimir os diagramas ou mesmo gerar
imagens a partir dos diagramas. Um exemplo desse recurso apresentado no
Apndice C em que so apresentadas as figuras geradas usando a ferramenta
EMUCase para os modelos de empresa as-is e to-be do sistema de biblioteca.
A transformao dos modelos as-is e to-be em um modelo de caso de uso feita
atravs de um assistente (wizard), cujo primeiro passo apresentado na Figura
6.25. No assistente possvel selecionar os modelos de empresa que sero usados
para a transformao, verificando se eles so condizentes com a sintaxe abstrata
definida. Tambm possvel escolher o arquivo XML que ser obtido como
resultado e a pasta onde sero colocados os arquivos intermedirios da
transformao (no caso, apenas o arquivo com o modelo de caso de uso em EMF).
Tambm possvel selecionar qual ser a linguagem do modelo de caso de uso
resultante (ingls ou portugus). Esse recurso foi necessrio para a aplicao do
159
experimento (discutido no captulo 7), uma vez que a transformao originalmente
resultava em casos de uso em ingls38.
Figura 6.24: A edio de um diagrama de estrutura organizacional na ferramenta EMUCase.
Figura 6.25: O primeiro passo do assistente para a transformao dos modelos de empresa em
casos de uso.
38
A seleo da linguagem implementada no roteiro em QVT Operational atravs de duas

operaes auxiliares que usam uma propriedade de configurao, passada pelo assistente.
160
6.6 Problemas e limitaes da transformao
A transformao proposta por este trabalho possui algumas limitaes e problemas,

seja por questes tericas, decises sobre o metamodelo ou restries da
ferramenta. Talvez o principal problema seja a subutilizao do metamodelo de
empresa pelas regras definidas. As vises motivacional e de layout no so usadas
para nenhuma das regras, enquanto que a viso organizacional usada de forma
bastante limitada (apenas a metaclasse Function usada). Do ponto de vista
prtico, o no uso de algumas vises poderia levar sua desconsiderao,
retirando-as do metamodelo de empresa. Porm, do ponto de vista terico no
possvel desprez-las: apesar desta aplicao do mtodo no ter gerado regras que
consideram metaclasses dessas vises, no possvel afirmar que elas no sejam
necessrias talvez para um outro sistema elas sejam importantes. Por exemplo, a
viso de layout pode ser necessria para a automao de um fluxo de trabalho que
seja baseado na localizao de alguns itens; as regras de negcio da viso
motivacional provavelmente so importantes para definir fluxos alternativos.
Conforme o mtodo proposto for aplicado em um maior nmero de casos ser
possvel discutir mais adequadamente sobre a necessidade dessas vises. Portanto,
caber a trabalhos futuros essa discusso. Uma outra limitao deste trabalho que
as regras foram obtidas de uma nica execuo do mtodo, considerando um
projeto simples. Esse mtodo precisa ser aplicado a um conjunto maior de projetos,
seja para obter mais regras e aperfeio-las, como para permitir uma anlise das
regras obtidas e do mtodo aplicado.
Em relao ao metamodelo de casos de uso, existe um problema em relao falta
de relaes de incluso e extenso. Apesar de a anlise realizada concluir que elas
no so comumente representadas em descries textuais de caso de uso, em
algumas situaes tais relaes evitam a redundncia de informao nos casos de
uso e permitem reduzir a complexidade de um caso de uso (BITTNER; SPENCE,
2002). Por exemplo, no caso de uso ideal da biblioteca (apresentado no Apndice
D), a incluso poderia ser usada para permitir que o caso de uso de registro de
membros (UC4) fosse executado quando a pessoa que tenta pegar um livro
emprestado no membro (durante o caso de uso de emprstimo de livros, o UC2).
Sem a existncia da incluso, essa funcionalidade s pode ser expressa atravs da
161
cpia do contedo do caso de uso UC4 para o UC2. Alm da deselegncia dessa
soluo devido redundncia, caso o UC4 precisasse incluir outro caso de uso, o
caso de uso UC2 ficaria desnecessariamente complexo. Com isso, a existncia das
relaes entre os casos de uso precisa ser mais bem analisada em trabalhos
futuros. A falta de relaes entre casos de uso diminui o problema da decomposio
funcional de casos de uso (BITTNER; SPENCE, 2002). Ainda assim, nesse trabalho
no ser discutido se a transformao proposta leva ou no a uma decomposio
funcional de casos de uso.
Um outro problema da transformao proposta devido ferramenta usada. A
verso atual da ferramenta no permite a interveno do engenheiro de requisitos
durante a transformao, apesar de as regras RR1, RR3, RR7 e RR8 considerarem
isso. Por simplicidade, sempre considerado que as regras devem ser aplicadas e
que todas as informaes so necessrias. Como a linguagem QVT Operational no
permite a interveno do usurio durante a transformao, uma possvel forma de
permitir que o engenheiro de requisitos tome decises durante a transformao
atravs do uso de marcas, conforme discutido no MDA (MILLER; MUKERJI, 2003).
Tambm possvel criar uma biblioteca para QVT que permita a interao com o
usurio, o que pode ser feito atravs da criao de uma implementao caixa-preta
em QVT (OMG, 2009). Uma outra possibilidade fazer com que a transformao
gere um modelo intermedirio a ser alterado pelo engenheiro de requisitos, o que
exigiria a definio de mais um metamodelo. Cabe a trabalhos futuros analisar essas
e outras possibilidades e implement-las na ferramenta.
Por fim, a proposta deste trabalho se limita transformao dos modelos, no
tratando da validao deles. Na Figura 6.26 apresentada esquematicamente a
questo da validao dos modelos no contexto deste trabalho. Para executar a
transformao necessrio que os modelos de empresa criados considerem desde
as restries definidas pela sintaxe abstrata e a semntica dos elementos, como
alguns critrios que foram implicitamente considerados pelas regras propostas e
ainda critrios para que tal modelo seja considerado efetivamente um modelo dos
requisitos. De forma similar, o modelo de casos de uso resultante da transformao
tambm deve seguir a sintaxe abstrata e a semntica do seu metamodelo, assim
como critrios para que ele seja considerado uma especificao. A ferramenta
criada realiza a validao da conformidade do modelo da empresa ao seu
162
metamodelo, entretanto no so considerados os demais critrios. A anlise de
quais so esses critrios e a implementao deles na ferramenta proposta no sero
tratados por este trabalho, sendo possveis trabalhos futuros. Em relao ao modelo
de casos de uso, nenhuma das validaes realizada. O motivo disso que a
transformao aqui proposta no busca obter automaticamente um modelo de casos
de uso. Caber a um engenheiro de requisitos corrigir possveis problemas desse
modelo e valid-lo, o que pode ser abordado em trabalhos futuros.
Modelo as-is
Transformao
Modelo to-be
Validar modelo
de empresa
Validar modelo
de caso de uso
Modelo de
caso de uso
(XML)
Figura 6.26: Validao dos modelos de entrada e sada da transformao.
6.7 Concluso
Este captulo apresentou os detalhes da transformao de requisitos em

especificao proposta por este trabalho. Os requisitos so representados pelos
modelos as-is e to-be da empresa cujo metamodelo baseado em trabalhos da rea
de Organizao e Mtodos. A especificao obtida um modelo de casos de uso,
em conformidade com um metamodelo que considera os elementos mais comuns de
representaes textuais de casos de uso. A transformao segue um conjunto de
regras obtidas atravs da anlise de trabalhos relacionados e da aplicao de um
mtodo em um exemplo de uma biblioteca. Para apoiar a execuo dessa
transformao, foi criada uma ferramenta como plug-in do IDE Eclipse, usando a
linguagem QVT Operational para representar as regras. No prximo captulo essa
transformao ser usada em um experimento que busca discutir algumas das
hipteses deste trabalho.
163
7 EXPERIMENTO
Para analisar a transformao proposta foi realizado um experimento, ou melhor, um
quasi-experimento uma vez que os seus participantes no foram escolhidos
aleatoriamente (WOHLIN et al., 2000). A seguir so apresentados a declarao do
problema, o planejamento, a operao, os resultados e as concluses do
experimento, seguindo o formato para reportar experimentos proposto em (WOHLIN
et al., 2000).
7.1 Declarao do problema
O objetivo deste trabalho propor a transformao de um modelo dos requisitos em

um modelo das especificaes. Para atingir esse objetivo foi apresentado o
embasamento terico para realizar essa transformao, propondo o uso de modelos
especficos para os modelos dos requisitos e das especificaes, um conjunto de
regras de transformao e uma ferramenta de apoio. Apesar disso, no claro se
essa transformao pode ser usada na prtica e, caso possa, se vantajoso utilizla. Portanto, o objetivo desse experimento exatamente analisar essas duas
questes, que se referem hiptese H3. Outras questes necessrias para esta
transformao tambm poderiam ser tratadas pelo experimento: a adequao das
regras e a correo e as vantagens dos metamodelos. Porm, tais questes no
sero tratadas neste trabalho, cabendo a trabalhos futuros realizar experimentos
para analis-las. Da mesma forma, as demais hipteses de pesquisa no sero
abordadas.
Uma forma de analisar a possibilidade de uso e as vantagens da transformao
proposta analisar o resultado obtido por ela, ou seja, o modelo de casos de uso.
Pode-se analisar desde a correo, a qualidade e a facilidade de entendimento
desse modelo, assim como outros aspectos referentes criao dele (tempo
necessrio para criao, tempo despendido com as partes envolvidas, dificuldades
de aplicar a transformao e percepo subjetiva do engenheiro de requisitos, por
exemplo). Idealmente essa anlise poderia comparar o resultado obtido com o
resultado de modelos de especificaes de uma forma geral, ou seja, no
164
necessariamente modelos de casos de uso, mas, por exemplo, modelos obtidos por
abordagens como Tropos e KAOS. Entretanto, uma vez que os modelos obtidos so
diferentes, necessrio um quadro de referncia que permita tratar esses modelos
de uma mesma forma. Dado esse complicador, preferiu-se apenas comparar os
modelos de caso de uso obtidos atravs da transformao com outros modelos de
casos de uso, que foram criados aplicando outras tcnicas.
Alguns trabalhos j realizaram experimentos para analisar a aplicao de diferentes
tcnicas para a criao de casos de uso. Trabalhos de (ACHOUR et al., 1999),
(ANDA; SJBERG; JRGENSEN, 2001), (COX; PHALP, 2000) e (PHALP;
VINCENT; COX, 2007b) analisam o uso de guias de estilo na redao de casos de
uso, considerando fatores e critrios para avaliar a qualidade dos casos de uso. A
qualidade dos casos de uso tambm usada para analisar o uso de uma lista de
verificao (checklist) para inspeo de casos de uso em (ANDA; SJBERG, 2002).
Diferentemente desses trabalhos, Yue, Briand e Labiche (2009) analisam uma
abordagem para redao de casos de uso atravs da qualidade do modelo de
anlise criado a partir dele e do entendimento dos casos de uso. De forma similar
aos experimentos de (ACHOUR et al., 1999), (ANDA; SJBERG, 2002), (ANDA;
SJBERG; JRGENSEN, 2001), (COX; PHALP, 2000) e (PHALP; VINCENT; COX,
2007b), a transformao ser analisada ao considerar a qualidade do caso de uso
obtido. Tambm sero considerados dois outros aspectos para analisar as
vantagens da transformao: o tempo despendido e a percepo subjetiva dos
engenheiros de requisitos. Alm disso, o experimento buscar seguir uma dinmica
similar desses experimentos, o que permite que os dados obtidos possam ser
futuramente usados em outras anlises.
7.2 Planejamento do experimento
No contexto deste experimento, ser considerado que possvel usar a

transformao caso ela no afete negativamente a criao dos casos de uso. Dessa
forma, a seguinte hiptese (chamada de hiptese experimental HE) foi formulada
para analisar a possibilidade de uso da transformao:
HE10: A qualidade do caso de uso obtido atravs da transformao menor
que a qualidade do caso de uso ao aplicar outras tcnicas.
165
HE11: A qualidade do caso de uso obtido atravs da transformao maior ou
igual qualidade do caso de uso ao aplicar outras tcnicas.
A hiptese HE10 a hiptese nula, sendo que se considerar possvel usar a
transformao na prtica caso ela seja rejeitada.
Em relao vantagem de usar a transformao, foram formuladas as seguintes
hipteses:
HE20: A qualidade do caso de uso obtido atravs da transformao igual
qualidade do caso de uso ao aplicar outras tcnicas.
HE21: A qualidade do caso de uso obtido atravs da transformao maior
que a qualidade do caso de uso ao aplicar outras tcnicas.
HE30: O tempo para a criao do caso de uso atravs da transformao
igual ao tempo para a criao do caso de uso ao aplicar outras tcnicas.
HE31: O tempo para a criao do caso de uso atravs da transformao
menor que o tempo para a criao do caso de uso ao aplicar outras tcnicas.
Nesse caso, a transformao ser considerada vantajosa caso pelo menos uma das
hipteses nulas (HE20 e HE30) sejam rejeitadas. importante ressaltar que a
hiptese HE2 similar hiptese HE1, mas mais restrita. Enquanto a hiptese HE1
analisa se a qualidade do caso de uso obtido igual ou maior, a hiptese HE2
analisa apenas se a qualidade maior.
Alm dessas trs hipteses, ser aplicado um questionrio ao final do experimento
em que ser avaliado, subjetivamente, se os sujeitos consideram que o resultado da
transformao atrapalha a criao dos casos de uso (tratando da possibilidade de
uso) e se ele ajudou a criar os casos de uso (tratando da vantagem). Ou seja, as
hipteses trataro de uma anlise quantitativa, enquanto que o questionrio tratar
da anlise qualitativa dessas questes.
7.2.1 Ambiente do experimento
O experimento foi realizado em alunos de ps-graduao lato sensu do curso de

Tecnologia de Software, realizado pelo Programa de Educao Continuada da
Escola Politcnica da Universidade de So Paulo (PECE). Esse curso tem durao
166
de 2 anos e trata dos principais temas de Engenharia de Software, incluindo
disciplinas especficas de Engenharia de Requisitos, Qualidade de Software e
Processos de Software (PECE, 2011). As turmas possuem de 20 a 30 alunos e so
formadas uma vez por ano.
Os sujeitos do experimento foram os 29 alunos da turma 2010-2011, os quais
estavam cursando o ltimo perodo do curso que composto por duas disciplinas:
"Gerncia de Projetos de Desenvolvimento e Aquisio de Software" e "Projeto
Integrado". Ou seja, os sujeitos j haviam concludo a disciplina de Engenharia de
Requisitos que tem como um dos seus contedos a criao de modelos de caso de
uso. O experimento foi realizado dentro da disciplina "Projeto Integrado" em duas
aulas diferentes, com uma separao de 1 semana entre elas (o motivo de serem
duas aulas ser discutido na seo 7.3). No final do curso fez-se uma apresentao
dos resultados obtidos, detalhando o experimento realizado.
7.2.2 Variveis e fatores
Existem dois tipos de variveis a serem consideradas em um experimento: as

variveis dependentes e as variveis independentes (PFLEEGER, 1995) (WOHLIN
et al., 2000). As variveis dependentes so as variveis de resposta, as quais se
espera que sejam afetadas como resultado do experimento. Por outro lado, as
variveis independentes so as variveis que influenciam a realizao e o resultado
obtido e que, portanto, so manipuladas e controladas em um experimento. As
variveis independentes estudadas em um experimento so chamadas de fatores.
As demais variveis independentes devem ou ser mantidas fixas ou randomizadas a
fim de no influenciar o resultado de experimento.
As variveis independentes consideradas neste experimento so apresentadas na
Tabela 7.1, indicando tambm como elas foram tratadas pelo experimento
(abordagem). Os fatores considerados foram a forma de criar o caso de uso, o
projeto (tamanho, complexidade e escopo) e a existncia de um modelo da
empresa. Algumas variveis independentes foram randomizadas, o que foi feito
atravs de um questionrio inicial, apresentando no Apndice H. Outras variveis
foram mantidas fixas. Seguindo a proposta do trabalho, considerou-se para o
167
experimento que os metamodelos usados seriam os propostos nas sees 6.2 e 6.3
com algumas simplificaes no caso do metamodelo de empresa devido sua
complexidade. Pelo mesmo motivo, foram usadas as regras de transformao
propostas na seo 6.4. Por outro lado, considerou-se que o uso da ferramenta
pelos sujeitos iria afetar o resultado do experimento. Dessa maneira, planejou-se
uma dinmica para o experimento (discutida na seo 7.3) para que a ferramenta
fosse usada apenas pelo aplicador do experimento. Devido ao ambiente do
experimento, considerou-se que os sujeitos seriam apenas estudantes, mas que o
trabalho no seria avaliado como nota. A tcnica de redao seria a aprendida
durante o curso e o conhecimento sobre modelagem de processo seria
homogeneizado atravs de uma apresentao. As justificativas para os valores das
demais variveis independentes mantidas fixas so apresentadas durante a
discusso do projeto do experimento, na seo 7.2.3.
Tabela 7.1: As variveis independentes e como elas foram tratadas pelo experimento (abordagem):
fator, randomizada ou fixa.
Varivel independente
Abordagem
Forma de criar o caso de uso
Fator
Projeto: tamanho, complexidade e escopo do projeto Fator
A existncia de um modelo da empresa
Fator
Experincia em criao de casos de uso
Randomizada
Experincia em criao de modelos de empresa
Randomizada
Experincia do sujeito com o escopo do projeto
Randomizada
Experincia em Engenharia de Requisitos
Randomizada
Forma de apresentao dos requisitos aos sujeitos Fixa: texto
Detalhamento dos requisitos/conhecimento do Fixa
domnio no enunciado do experimento
Forma de representao dos casos de uso
Fixa: metamodelo proposto
Forma de representao do modelo da empresa
Fixa: verso simplificada do metamodelo
Nmero de pessoas envolvidas
Fixa: 1
Tempo disponvel
Fixa: 1 hora em cada fase
Uso de ferramenta de apoio
Fixa: no
Se o experimento ser realizado com estudantes
Fixa: sim
Se os trabalhos sero avaliados como nota ou no
Fixa: no
Tcnica de redao do caso de uso
Fixa: curso
Conhecimento sobre modelagem de processos
Fixa: apresentao
Regras usadas
Fixa: obtidas pelo mtodo
Considerando as hipteses experimentais formuladas, o resultado do experimento

ser avaliado atravs de trs variveis dependentes:
Qualidade do caso de uso: a qualidade do caso de uso criado pelos sujeitos;
Tempo para criao do caso de uso: quanto tempo foi necessrio para criar
o caso de uso, a partir da entrega do enunciado; e
168
Percepo subjetiva: o quanto a transformao atrapalhou e/ou auxiliou a

criao dos casos de uso, segundo a percepo subjetiva dos sujeitos.
Dessas variveis, a qualidade do caso de uso ser usada para testar as hipteses
HE1 e HE2, enquanto que o tempo ser usado para testar a hiptese HE3. A
percepo subjetiva ser usada para analisar qualitativamente a possibilidade de
uso e a vantagem de usar a transformao.
7.2.3 Projeto do experimento
Considerando os fatores, o projeto do experimento apresentado na Figura 7.1. Os

fatores "forma de criar o caso de uso" e "existncia de um modelo da empresa"
foram representados como tcnicas de criao de casos de uso: Diretamente (ad
hoc, a partir dos requisitos), Modelo da Empresa (criando um modelo da empresa e
usando-o para gerar os casos de uso) e Transformao (criando um modelo da
empresa e usando o caso de uso resultante da transformao para gerar os casos
de uso). A tcnica de criao direta (Diretamente) representa o grupo de controle do
experimento.
Tcnicas de criao de caso de uso
Diretamente Modelo da Empresa Transformao
Projeto
ATM
Locadora
Figura 7.1: O projeto do experimento.
Em relao ao projeto, decidiu-se apenas considerar o escopo do projeto, abstraindo

o tamanho e a complexidade. Essa deciso foi tomada ao considerar a dinmica do
experimento os sujeitos so alunos de uma mesma disciplina e, principalmente,
ao buscar seguir a mesma dinmica de outros experimentos realizados com casos
de uso. Pelo mesmo motivo, os sujeitos devem realizar o experimento
individualmente, recebendo uma descrio textual e devem criar apenas 1 caso de
uso, similar ao que foi feito nos trabalhos de Achour et al. (1999), Cox e Phalp
(2000) e Phalp, Vincent e Cox (2007b). Apesar de esses trabalhos proporem 1 hora
de durao para todo o experimento, esse tempo parece insuficiente para os
tratamentos usando as tcnicas Modelo da Empresa e Transformao j que
necessrio criar um modelo da empresa e depois criar um modelo de casos de uso.
Dessa forma, preferiu-se dividir o experimento em duas fases para esses
169
tratamentos, cada uma de 1 hora: na primeira cria-se o modelo da empresa e na
segunda cria-se o modelo de casos de uso.
Considerando o nmero de sujeitos, o escopo foi limitado a duas opes, o que
permitiria analisar as diferenas de projeto. Os escopos foram escolhidos ao analisar
os demais experimentos que tratam da qualidade de casos de uso. As opes de
sistemas encontradas nesses trabalhos foram: sistema de pesquisa de opinio
(ANDA; SJBERG; JRGENSEN, 2001), sistema de troca de deveres entre
enfermeiros (ANDA; SJBERG; JRGENSEN, 2001), sistema de caixa de
supermercado (ACHOUR et al., 1999) (COX; PHALP, 2000) (PHALP; VINCENT;
COX, 2007b), sistema de autoatendimento bancrio (PHALP; VINCENT; COX,
2007b), sistema de venda de peas de carro (YUE; BRIAND; LABICHE, 2009) e
sistema de locadora de vdeo (YUE; BRIAND; LABICHE, 2009). Como o sistema de
caixa de supermercado foi explorado em uma das disciplinas do curso que todos os
sujeitos realizaram, esse escopo foi desconsiderado. Dentre as demais opes, a
escolha foi por um sistema de autoatendimento bancrio (ATM) e um sistema de
locadora de vdeo.
7.2.4 Estratgia de anlise dos dados
Para decidir qual o teste de hiptese mais adequado para cada hiptese
experimental existem dois fatores importantes a serem considerados:
Paramtrico ou no paramtrico: se o teste considera uma distribuio

especfica (em geral normal) ou no (WOHLIN et al., 2000); e
Se os dados so pareados ou no: se os objetos experimentais so os

mesmos nas duas amostras obtidas, ou seja, se os valores devem ser
considerados como pares.
Como cada sujeito trabalhou de forma independente, os dados no so pareados.

Em relao distribuio, no possvel afirmar que as notas ou os tempos seguem
uma distribuio especfica. Porm, necessrio que a distribuio seja normal para
aplicar o teste t (um dos testes mais comuns) quando o tamanho de pelo menos
uma das amostras pequeno (DEVORE, 2003) o que o caso deste experimento.
Portanto, um teste no paramtrico e no pareado parece ser mais apropriado. A
escolha foi pelo teste de Wilcoxon (tambm chamado de Mann-Whitney) (DEVORE,
170
2003).
Usando
esse
teste,
as
hipteses
experimentais
sero
analisadas
separadamente para cada um dos escopos, considerando como nvel de

significncia ( ) de 0,05.
Dada a formulao do teste de Wilcoxon apresentada em (DEVORE, 2003), a
hiptese nula deve ser
, onde
a mdia da primeira amostra e
mdia da segunda amostra. A hiptese alternativa pode ser tanto

ou
>
a
<
. Portanto, no caso da hiptese HE1 foi necessrio alterar a ordem das
hipteses, alm de definir duas sub-hipteses (uma para cada tcnica de criao do
caso de uso):
1
1 :
<
1" :
$ %
1" :
<
$ %
Com essa formulao no necessrio testar se a qualidade obtida maior: a

concluso de que ela no menor suficiente para a hiptese experimental. Com
isso, a hiptese HE1 ser considerada verdadeira caso as hipteses nulas no
possam ser rejeitadas.
Em relao hiptese HE2, ela ser testada da seguinte forma:
2
2 :
>
2" :
$ %
2" :
>
$ %
Nesse caso a hiptese HE2 ser considerada verdadeira caso as hipteses nulas
sejam rejeitadas.
De forma similar, a hiptese HE3 ser testada atravs das seguintes hipteses:
3
3 :
<
171
3" :
% #
$ %
3" :
<
% #
$ %
A hiptese HE3 ser considerada verdadeira caso as hipteses nulas sejam

rejeitadas. Considerando que o experimento possui duas fases de 1 hora para
alguns tratamentos e apenas uma fase de 1 hora para outros, os tempos sero
analisados tanto para a soma dos tempos das duas fases como apenas para a fase
em que o caso de uso criado.
Em relao s hipteses HE1 e HE2, necessrio definir como avaliar a qualidade
de um caso de uso. Algumas propostas existentes foram apresentadas na seo
3.5.4. Dessas abordagens, o ideal seria usar um critrio objetivo de avaliao, como
o proposto por Achour et al. (1999). Porm, considerando as crticas e as propostas
posteriores, este trabalho avaliar a qualidade baseando-se na definio de notas
por um avaliador, por mais que essa avaliao no seja completamente objetiva.
Dessa forma, o trabalho de Phalp, Vincent e Cox (2007a) ser usado como base
para avaliao, uma vez que ele o mais recente sobre o assunto e considera o
conhecimento apresentado pelos demais trabalhos na rea.
De forma a tornar a avaliao da qualidade dos casos de uso menos subjetiva,
foram definidos critrios para cada um dos fatores propostos em (PHALP; VINCENT;
COX, 2007a). Esses critrios so apresentados no Apndice G, considerando que a
pontuao para cada um deles vai de 0 a 5, totalizando 65 pontos (uma vez que so
13 fatores e subfatores). Os critrios foram definidos ao analisar cada um dos
fatores, atribuindo notas para cada possvel problema. Parte dos critrios foi definida
antes do experimento; o restante foi definido durante a avaliao da qualidade dos
casos de uso, ao encontrar problemas que no se encaixavam nos critrios
existentes. A definio das notas para cada critrio foi feita ao comparar a
importncia desse problema em relao aos demais problemas e definio do
fator, o que naturalmente envolve decises subjetivas. Apesar disso, espera-se que
esses critrios permitam uma avaliao mais homognea da qualidade dos casos de
uso criados pelos sujeitos.
As notas obtidas sero analisadas graficamente usando um grfico boxplot
(DEVORE, 2003) (WOHLIN et al., 2000). A representao usada ser a apresentada
172
por Devore (2003), na qual a barra no meio da caixa representa a mediana da
amostra, enquanto que a barra inferior da caixa representa o quartil inferior e a barra
superior representa o quartil superior. As caudas superiores e inferiores do grfico
representam, respectivamente, o maior elemento e o menor elemento da amostra.
Usando esse grfico sero analisados valores atpicos (outliers) que, dependendo
do caso, sero desconsiderados na anlise.
Por fim, os questionrios respondidos pelos sujeitos que empregaram a tcnica
Transformao sero analisados como um todo, sem diferenciar o escopo. Essa
deciso se deve ao nmero de sujeitos executando esse tratamento (que ser
detalhado na seo 7.3).
7.2.5 Validade dos resultados
As ameaas validade dos resultados obtidos no experimento sero apresentadas

seguindo a organizao proposta em (WOHLIN et al., 2000): validade de concluso,
validade interna, validade de construo e validade externa. A validade de concluso
trata de questes que afetam a relao estatstica entre as variveis independentes
e as variveis dependentes, impedindo a obteno de concluses corretas. A
validade interna trata de questes que afetam as variveis independentes e que
"afetam a relao causal entre o tratamento e o resultado" (WOHLIN et al., 2000,
p.68). Ou seja, a validade interna discute a possibilidade de fatores no
considerados terem afetado os resultados. A validade de construo trata de
questes que impedem que o experimento seja visto como uma situao normal de
aplicao do tratamento. Por fim, a validade externa trata de questes que impedem
a generalizao dos resultados do experimento.
Neste experimento foram consideradas as seguintes ameaas validade de
concluso:
Baixo poder estatstico: o nmero de sujeitos que realizaram o experimento

no foi estatisticamente suficiente, considerando um poder (1 )) de 0,8,
nvel de significncia ( ) de 0,05 e a menor significncia para que a hiptese
nula seja rejeitada (*) de 0,1. Segundo Noether (1987), o nmero de sujeitos
mnimo (+) para o teste de Wilcoxon pode ser calculado como:
173
+=
(-. + -0 )
122(1 2)(* 0,5)
Em que -. e -0 so os valores crticos de 6 (varivel aleatria normal padro)

para os valores de
e ) , e 2 a proporo de um dos nmeros de
observao em relao ao nmero de sujeitos (7 = 2+), considerado aqui

como 0,5 (ou seja, nmero igual de observaes). No caso, o + =12,86, ou
seja, so necessrios 7 sujeitos para cada tratamento (aproximando para
cima). Como ser apresentado na seo 7.3, o nmero de sujeitos foi inferior
a esse valor. Apesar disso, preferiu-se no simplificar o experimento
(considerado apenas um escopo ao invs de dois, por exemplo) ou aplic-lo a
outros tipos de sujeitos disponveis (alunos de graduao, por exemplo) a fim
de manter a adequao do experimento e no introduzir outras variveis
independentes. De qualquer forma, a considerao de um nmero menor de
sujeitos no invalida os resultados obtidos apenas aumenta o risco de uma
concluso errada ser obtida.
Confiana da medida: para testar as hipteses HE1 e HE2, foram usados

critrios para cada um dos fatores de qualidade considerados. Por mais que
os critrios procuram tornar a avaliao mais objetiva, seu uso apresenta dois
problemas. O primeiro que a avaliao continua envolvendo decises
subjetivas. Cada avaliador pode interpretar diferentemente o texto dos casos
de uso, aplicar diferentemente os critrios definidos, ou mesmo no perceber
um problema no caso de uso analisado. Dessa forma, diferentes avaliadores
podem obter pontuaes diferentes para um mesmo caso de uso. O segundo
problema a adequao dos valores definidos para cada um dos critrios. Os
valores foram definidos ao considerar a importncia do critrio para o fator,
comparando com os demais critrios definidos. Dessa forma, possvel que
alguns valores sejam inadequados, privilegiando os casos de uso que
cometeram algum tipo de erro.
Em relao validade interna foram consideradas as seguintes ameaas:
Seleo: como ser discutido na seo 7.3, no foi possvel distribuir os

sujeitos entre os tratamentos de forma completamente aleatria. Os sujeitos
receberam o enunciado do exerccio dependendo de sua posio na sala,
mas sem uma ordem de distribuio especfica. Ou seja, os sujeitos foram
174
distribudos entre os tratamentos de uma forma quase aleatria, mas no
foram consideradas adequadamente as variveis independentes para isso.
Portanto, possvel, por exemplo, que sujeitos com experincia similar
tenham ficado com um mesmo tratamento.
Instrumentao: os sujeitos que realizaram o experimento aplicando a

tcnica Diretamente recebem menos informao que os demais sujeitos. Essa
informao no era necessria para a realizao da atividade planejada, mas
ela pode conter informaes que ajudem o sujeito a realiz-la e, portanto,
possvel que tenha afetado os resultados.
Familiaridade dos sujeitos com o aplicador: como os sujeitos foram alunos

de uma disciplina previamente ministrada pelo aplicador39, possvel que a
experincia anterior com o aplicador tenha afetado os resultados. Por
exemplo, sujeitos que tiveram problemas na disciplina podem se esforar
menos ou at mesmo propositadamente responder errado.
Escopo: o fator projeto tratou apenas do escopo, buscando manter constante

a complexidade e o tamanho do projeto. Porm, o escopo foi explorado
apenas ao considerar duas possibilidades diferentes. possvel que ambos
os escopos escolhidos sejam mais apropriados para uma das tcnicas
usadas.
Diferena de tempo: os sujeitos que aplicaram a tcnica Diretamente tiveram

menos tempo para realizar a atividade (apenas 1 hora). Os demais sujeitos
puderam realizar a atividade em 2 horas, o que pode afetar o resultado
obtido, por mais que as atividades realizadas em cada hora tenham sido
diferentes.
Tempo para criao do modelo da empresa: como ser apresentado na

seo 7.4, a criao do modelo da empresa foi bastante demorada, sendo
que em mdia os sujeitos precisaram da 1 hora disponvel e o menor tempo
foi de 55 minutos. Ou seja, provvel que o tempo disponvel para essa
atividade tenha sido insuficiente.
Intervalo entre as atividades: os sujeitos que aplicaram as tcnicas

Transformao e Modelo da Empresa tiveram um intervalo de uma semana
39
Fui professor da disciplina "Anlise e Projeto Orientada a Objetos", a qual j havia terminado na
poca do experimento.
175
entre uma atividade e outra, enquanto que os demais sujeitos realizaram a
atividade em apenas 1 dia (em 1 hora). Isso permitiu aos sujeitos pensarem
sobre o exerccio e at mesmo conversar sobre o que foi feito. Porm, a
opo de deixar os sujeitos fazerem as duas atividades de uma vez causaria
a influncia de trs outras variveis independentes: a dificuldade de uso da
ferramenta, o cansao e a desmotivao por realizar uma atividade mais
demorada que a de outros sujeitos. Dessa forma, concluiu-se que o intervalo
entre as atividades menos prejudicial que essas outras influncias.
Metamodelos: os sujeitos usaram o metamodelo de casos de uso e uma

verso simplificada do metamodelo da empresa. O uso desses modelos
influenciou o resultado obtido, sendo possvel que eles no sejam adequados,
difceis de entender/criar ou que eles sejam apenas teis nos escopos
considerados.
Regras de transformao: a principal diferena dos tratamentos envolvendo

a tcnica Transformao e a tcnica Modelo da Empresa foi o emprego de
um modelo de caso de uso criado a partir das regras de transformao
discutidas na seo 6.4. Portanto, os resultados obtidos por esses sujeitos
so dependentes da correo dessas regras.
Para a validade de construo foram consideradas as seguintes ameaas:
Tempo necessrio: cada atividade do experimento foi feita em apenas 1

hora. Esse tempo no reflete adequadamente uma situao real, por mais
que existam restries de prazo em projetos. Apesar disso, essa limitao de
tempo foi definida ao considerar os experimentos similares, o que permite
futuras
comparaes.
Um
outro
motivo
para
essa
escolha
foi
impossibilidade de o experimento ter uma durao maior, j que ele teria um

impacto na disciplina.
Tamanho do projeto: o experimento foi limitado a 1 caso de uso, o que

tambm no reflete um projeto de desenvolvimento de software normal. Os
mesmos motivos para a ameaa "tempo necessrio" levaram deciso desse
tamanho (experimentos similares e impossibilidade de realizar experimentos
maiores).
No
uso
de
informao:
como
os
sujeitos
aplicando
tcnica
Transformao tambm receberam o modelo da empresa previamente criado,
176
possvel que eles tenham desprezado o modelo de casos de uso recebido.
Da mesma forma, possvel que os sujeitos que aplicaram a tcnica
Transformao e Modelo da Empresa tenham considerado apenas o
enunciado para criar os casos de uso.
Por fim, para a validade externa foram consideradas as seguintes ameaas
possibilidade de generalizao do experimento:
Tamanho e tempo: como apontado em (KITCHENHAM, 2007), existem

algumas tcnicas que no funcionam bem em grandes projetos, mas
funcionam bem em pequenos projetos ou vice-versa. Dessa forma,
possvel que os resultados obtidos sirvam apenas para projetos desse
tamanho e/ou dessa durao.
Escopo: por mais que tenham sido considerados 2 escopos, no possvel

generalizar as concluses para quaisquer sistemas de automao de
processos.
Alunos como sujeitos: foram usados alunos de ps-graduao que

possuem conhecimentos de Engenharia de Requisitos e da tcnica de caso
de uso, mas no so nem especialistas e nem novatos. Alm disso, os
sujeitos no foram escolhidos a partir de uma anlise de seu perfil em relao
aos usurios da tcnica proposta, sendo, portanto, um quasi-experimento.
7.3 Operao do experimento
Fase 1
1. Realizar
apresentao
sobre BPMN
Fase 4
9. Corrigir
casos de uso
2. Responder o
questionrio
inicial
3. Dividir sujeitos em
6 tratamentos
Fase 3
8. Responder
o questionrio
final
4. Produzir modelo da
empresa ou caso de
uso
Fase 2
7. Criar
casos de
uso
6. Transformar
modelo da
empresa
5. Representar
modelos da empresa
na ferramenta
Figura 7.2: As atividades realizadas no experimento, descritas usando BPMN (OMG, 2011a).
A execuo do experimento foi dividida em 4 fases, conforme apresentado

esquematicamente na Figura 7.2 atravs de um diagrama BPMN. Cada fase foi
realizada em dias diferentes. As atividades realizadas pelos sujeitos so
177
representadas em cinza, enquanto que as atividades realizadas pelo operador do
experimento so representadas em branco. Os detalhes dessas atividades so
apresentados a seguir:
1.
Os sujeitos assistem uma apresentao de 10 minutos sobre modelagem

de processo de negcio usando BPMN. O objetivo dessa apresentao
homogeneizar o conhecimento dos sujeitos.
2.
Os sujeitos respondem um questionrio a respeito das variveis

independentes randomizadas. Esse questionrio apresentado no
Apndice H.
3.
Dependendo das respostas dos questionrios, os sujeitos so divididos

entre os 6 tratamentos.
4.
Em um perodo mximo de 1 hora cada sujeito:

a. Recebe um documento com o exerccio, conforme apresentado no
Apndice I. O documento explica os requisitos considerando o
ambiente desejado para os sujeitos realizando a tcnica de criao de
casos de uso Diretamente, enquanto que para as demais tcnicas o
documento explica tambm o ambiente atual.
b. Produz um caso de uso, no caso dos sujeitos realizando a tcnica
Diretamente, ou um modelo da empresa as-is e to-be, no caso dos
sujeitos realizando a tcnica Modelo da Empresa e Transformao.
c. O tempo despendido por cada sujeito anotado.
5.
Os modelos de empresa so transcritos pelo operador do experimento

para a ferramenta. Preferiu-se deixar essa tarefa com o operador para
evitar que dificuldades do uso da ferramenta afetassem o resultado do
experimento. Dado o nmero de sujeitos, essa atividade no pde ser feita
no mesmo dia da atividade 4.
6.
Os modelos de empresa criados pelos sujeitos realizando os tratamentos

com a tcnica Transformao so transformados usando a ferramenta
apresentada na seo 6.5. Decidiu-se desconsiderar a regra RR8, uma
vez que ela gera um outro caso de uso. Com isso obtido apenas um
caso de uso.
7.
Os sujeitos realizando a tcnica Modelo da Empresa recebem o modelo da

empresa criado, representado atravs da ferramenta, e o enunciado
original, enquanto que os sujeitos realizando a tcnica Transformao
178
recebem o modelo da empresa criado (representado atravs da
ferramenta), o resultado da transformao e o enunciado original. Esses
sujeitos devem criar um caso de uso em no mximo 1 hora, tendo os seus
tempos
anotados.
Os
modelos
dos
documentos
entregues
so
apresentados no Apndice I.
8.
Ao
final,
os
sujeitos
realizando
experimento
com
tcnica
Transformao respondem um questionrio, avaliando qualitativamente a

atividade realizada. Esse questionrio apresentado no Apndice H.
9.
Os casos de uso so corrigidos pelo operador do experimento

considerando os critrios de qualidade de caso de uso definidos. Como
para alguns fatores necessrio um gabarito, usou-se os gabaritos
apresentados no Apndice J.
A operao do experimento foi testada com dois doutorandos em Engenharia de

Computao que no so alunos do curso de Tecnologia de Software. Eles
fizeram o experimento para os tratamentos com a tcnica Transformao, um para
cada projeto. No caso da Locadora, percebeu-se no teste que o enunciado
apresentava algumas dificuldades de interpretao, que ento foram corrigidas. Para
o caso da ATM percebeu-se uma dificuldade em representar na ferramenta um
processo de negcio que no seguia corretamente a notao BPMN. Por causa
disso planejou-se a atividade 1.
Apesar desses dois testes, durante a execuo do experimento foi necessria uma
mudana na atividade 3 (distribuio dos sujeitos nos 6 tratamentos). Por restries
de tempo na disciplina no foi possvel analisar os dados do questionrio inicial
antes da distribuio dos sujeitos entre os tratamentos. Com isso, a distribuio dos
sujeitos no foi completamente aleatria: eles foram distribudos em relao ao
projeto e criao de casos de uso ou modelos de empresa conforme a distribuio
deles na sala de aula. Com os dados da anlise do questionrio inicial, os sujeitos
que criaram modelos de empresa foram distribudos aleatoriamente entre as
tcnicas Modelo da Empresa e Transformao. Porm, 2 dos sujeitos no
conseguiram criar modelos de empresa no tempo determinado (um deles por chegar
atrasado e outro por, aparentemente, no ter entendido a tarefa), o que obrigou
desconsiderao desses dados na anlise. Como eles foram originalmente alocados
para um mesmo tratamento, decidiu-se randomizar novamente os sujeitos.
179
Um outro problema encontrado foi a ausncia de sujeitos na 1 ou na 3 fase do
experimento. Trs sujeitos faltaram 3 fase, sendo que apenas um deles havia feito
o experimento para a tcnica Diretamente (os outros dois foram para a tcnica
Transformao, mas para projetos diferentes). Dessa forma, os resultados da 1 fase
de apenas dois dos sujeitos que faltaram foram desconsiderados. Por outro lado, um
sujeito que faltou 1 fase estava disposio na aula em que foi realizada a 3
fase. Esse sujeito foi alocado para o tratamento Locadora e Diretamente, j que
esse tratamento tinha um sujeito a menos que para o tratamento ATM e
Diretamente. O nmero efetivo de sujeitos em cada um dos tratamentos
apresentado na Tabela 7.2.
Tabela 7.2: Nmero de sujeitos para cada um dos tratamentos.
Projeto
ATM
Locadora
Tcnicas de criao de caso de uso

Diretamente Modelo da Empresa Transformao
5
4
4
5
4
3
Em relao aos modelos de empresa, eles foram simplificados para apenas as

vises de processo, organizacional e de documentos. Essa simplificao considerou
o fato de as demais vises no serem usadas pelas regras de transformao e pela
limitao de tempo. Alm disso, os metamodelos organizacional e de documentos
foram simplificados a fim de tentar evitar que a dificuldade de entender o
metamodelo influenciasse o experimento. Para a viso organizacional o metamodelo
foi limitado aos participantes e sua lista de funes, representados textualmente;
para a viso de documentos pediu-se uma lista textual de documentos e de seus
respectivos campos.
Por fim, os sujeitos que realizaram na 1 fase do experimento a tcnica Diretamente
realizaram uma outra atividade durante a 3 fase: eles criaram casos de uso a partir
dos modelos de empresa criados pelos outros sujeitos (sem uma descrio dos
requisitos). Entretanto, como os resultados dessa parte do experimento no so
relevantes para este trabalho, eles no sero apresentados.
180
7.4 Anlise e interpretao dos dados
A seguir so apresentados os dados obtidos no experimento, detalhados no

Apndice K. Na Tabela 7.3 so apresentados a nota e os tempos para os escopos
ATM e Locadora. Nela possvel observar que a mdia dos tempos para a criao
do modelo da empresa foi de 1 hora em ambos os escopos (o que parece indicar
que o tempo disponvel foi insuficiente), enquanto que a mdia para a criao dos
casos de uso foi de 46 minutos, no escopo ATM, e 43 minutos, no escopo Locadora.
Em relao s notas, a mdia foi maior no escopo da Locadora.
Tabela 7.3: As notas e os tempos obtidos no experimento.
Escopo
ATM
Locadora
Tratamento
Aluno
Nota
Aluno 1
Aluno 2
Diretamente
Aluno 3
Aluno 4
Aluno 5
Aluno 6
Aluno 7
Modelo da Empresa
Aluno 8
Aluno 9
Aluno 10
Aluno 11
Transformao
Aluno 12
Aluno 13
Mdia
Aluno 14
Aluno 15
Diretamente
Aluno 16
Aluno 17
Aluno 18
Aluno 19
Aluno 20
Modelo da Empresa
Aluno 21
Aluno 22
Aluno 23
Transformao
Aluno 24
Aluno 25
Mdia
60,45
60,30
61,10
60,45
60,50
60,75
61,80
60,65
60,75
59,75
61,25
61,30
61,95
60,85
61,40
62,55
62,20
56,50
62,60
63,15
60,40
62,95
60,75
61,30
61,90
62,10
61,48
Tempo modelo
da empresa
01:04
00:59
00:55
00:59
01:07
00:58
00:58
01:06
01:00
01:04
00:58
00:58
00:58
01:03
00:55
01:04
01:00
Tempo caso
de uso
01:04
00:54
00:58
00:59
00:49
00:48
00:46
00:42
00:40
00:38
00:49
00:18
00:33
00:46
00:55
00:30
00:27
01:04
00:42
00:45
00:51
00:42
00:41
00:51
00:39
00:40
00:43
Uma comparao das notas para o escopo ATM apresentada na Figura 7.3
atravs de um grfico boxplot, (as notas esto no eixo vertical e as tcnicas no eixo
horizontal). Nesse grfico possvel observar que as notas do tratamento com a
tcnica Diretamente foram, de uma forma geral, menores que as notas dos demais
tratamentos.
As
maiores
notas
foram
as
obtidas
usando
tratamento
181
automaticamente, apesar de que nessa tcnica houve a maior variao nas notas.
Isso devido ao fato da menor e da maior nota do experimento para esse escopo
serem de sujeitos que realizaram esse tratamento. Em especial, a menor nota bem
inferior s demais notas ( 0,55 pontos menor que a segunda menor nota), o que
fica evidente no grfico. Essa nota se refere a um sujeito que chegou atrasado na 3
fase do experimento e entregou o caso de uso incompleto, apesar de ser o ltimo a
terminar o exerccio. Considerando a nota e o seu contexto, ela ser tratada como
um valor atpico e desconsiderada na anlise.
62,00
61,50
61,00
60,50
60,00
59,50
Diretamente
Modelo da Empresa Automaticamente
Figura 7.3: Grfico boxplot para as notas do escopo ATM.
O grfico de boxplot para o escopo Locadora apresentado Figura 7.4. Para esse
escopo no parece haver tanta diferena entre as tcnicas: as medianas das
distribuies so mais prximas (62,20, 61,85 e 61,90, respectivamente). Apesar
disso, h uma grande variao nas observaes usando as tcnicas Diretamente e
Modelo
da
Empresa,
enquanto
que
as
observaes
usando
tcnica
Automaticamente tem pequena variao. Entretanto, no possvel concluir que a

semelhana das observaes nesse caso seja evidncia de alguma vantagem da
tcnica usada, uma vez que ela pode ser causada pelo pequeno nmero de
observaes realizadas (apenas 3). Ao analisar o grfico possvel observar a
presena de um outro valor atpico na tcnica Diretamente. Esse valor 3,9 pontos
inferior ao segundo menor valor obtido. Um dos principais motivos dessa nota foi o
fato do caso de uso estar no nvel de subfunes ao invs de um caso de uso no
nvel das metas do usurio (o caso de uso detalhava demasiadamente as aes do
sistema). Dessa forma, essa observao ser desconsiderada na anlise dos dados.
182
64,00
63,00
62,00
61,00
60,00
59,00
58,00
57,00
56,00
Diretamente
Modelo da Empresa Automaticamente
Figura 7.4: Grfico boxplot para as notas do escopo Locadora.
Seguindo a estratgia de anlise dos dados apresentada na seo 7.2.4, a seguir

apresentada a interpretao dos dados para cada uma das hipteses experimentais.
Ao final tambm so apresentadas algumas anlises adicionais.
7.4.1 Hiptese HE1
A hiptese experimental HE1 trata da possibilidade de uso da transformao,

analisando se a qualidade do caso de uso obtido atravs da transformao maior
ou igual qualidade do caso de uso obtido atravs do emprego das outras tcnicas.
Usando o teste de Wilcoxon, ser analisado se a qualidade da transformao
menor (se no for menor, ento ela ser maior ou igual). As hipteses nulas HE1a0
(relativa tcnica Diretamente) e HE1b0 (relativa tcnica Modelo da Empresa)
sero
8!
rejeitadas
caso 8!
7(7 + : + 1) 8(7; :; ) ,
em
que
a soma dos postos associados s observaes da transformao, 7
o nmero de observaes para a tcnica Transformao, : o nmero de

observaes para a outra tcnica analisada (Diretamente ou Modelo da Empresa) e
8(7; :; ) o valor crtico para o teste usando um nvel de significncia
(que
aqui ser de 0,05).

Na Tabela 7.4 so apresentados os valores do teste, sendo que 8(3; 5; 0,05) = 20
e 8(3; 4; 0,05) = 17. Em nenhum caso o 8!
menor ou igual a 7(7 +
: + 1) 8(7; :; 0,05) e, portanto, no possvel rejeitar as hipteses nulas. Ou

seja, no possvel dizer que a tcnica Transformao leva a casos de uso com
qualidade inferior. No caso do escopo ATM os valores so consideravelmente
183
maiores aos valores de rejeio, enquanto que para o escopo Locadora os valores
so mais prximos. Em especial, para a tcnica Diretamente a diferena pequena.
Tabela 7.4: Valores para o teste da hiptese HE1.
Escopo
Elemento
Diretamente Modelo da Empresa
21
16
Wtransformao
ATM
m(m+n+1) - W(m; n; 0,05)
7
7
Wtransformao
8
12
Locadora
m(m+n+1) - W(m; n; 0,05)
7
7
Analisando tambm os resultados da tcnica Modelo da Empresa em relao

tcnica Diretamente, tem-se para o escopo ATM 8
$ %
1) 8(7; :; 0,05) = 13 e para o escopo Locadora 8
= 27 e 7(7 + : +
$ %
= 18 e
7(7 + : + 1) 8(7; :; 0,05) = 12. Ou seja, tambm no possvel afirmar que a

tcnica Modelo da Empresa leva a casos de uso com qualidade inferior aos criados
pela tcnica Diretamente.
7.4.2 Hiptese HE2
A hiptese experimental HE2 trata da vantagem de realizar a transformao,

testando se a qualidade do caso de uso obtido maior ao usar essa tcnica. De
forma similar hiptese experimental HE1, existem duas hipteses, HE2a e HE2b,
para as tcnicas Diretamente e Modelo da Empresa, respectivamente. Usando o
teste de Wilcoxon, nesse caso as hipteses nulas sero rejeitadas caso
8!
8(7; :; ), considerando
= 0,05. Os resultados desse teste so
apresentados na Tabela 7.5. A hiptese nula pode ser rejeitada apenas para o
escopo ATM e a tcnica Diretamente. Para a tcnica Modelo da Empresa para esse
mesmo escopo a diferena pequena, sendo quase possvel rejeitar a hiptese
nula. Em compensao, para o escopo da Locadora a diferena considervel.
Escopo
Elemento Diretamente Modelo da Empresa

Wtransformao
21
16
ATM
W(m; n; 0,05)
20
17
Wtransformao
8
12
Locadora
W(m; n; 0,05)
17
17
184
Ao analisar os resultados da tcnica Modelo da Empresa em relao tcnica
Diretamente,
tem-se
8(7; :; 0,05) = 27
para
para
escopo
Locadora
$ %
= 27
escopo
Locadora
$ %
= 18
8(7; :; 0,05) = 24. Ou seja, para o escopo da ATM possvel rejeitar a hiptese
nula (por pouco), mas no possvel rejeit-la para o escopo Locadora.
7.4.3 Hiptese HE3
Assim como a hiptese HE2, a hiptese HE3 tambm trata da vantagem do uso da
transformao, mas considerando o tempo. Nesse caso as hipteses nulas HE3a0 e
HE3b0 que analisam a transformao frente s tcnicas Diretamente e Modelo da
Empresa, respectivamente, sero rejeitadas caso 8!
1) 8(7; :; ) , considerando, novamente,
7(7 + : +
= 0,05 . O tempo total (soma dos
tempos para a criao dos modelos de empresa e de casos de uso, sendo que os
sujeitos aplicando a tcnica Diretamente criaram apenas o modelo de caso de uso) e
o tempo apenas para a criao do caso de uso so apresentados na Tabela 7.6.
Caso o tempo total seja considerado, no possvel rejeitar a hiptese nula para a
tcnica
Diretamente.
Na
realidade,
tempo
necessrio
para
tcnica
Transformao maior, j que ao usar o teste de Wilcoxon se obtm que

8!
8(7; :; 0,05), com 8(3; 5; 0,05) = 20, para o caso da ATM,
e 8(3; 4; 0,05) = 17, para o caso da Locadora. Em compensao, caso apenas o

tempo para a criao do caso de uso seja considerado, no caso da ATM possvel
rejeitar a hiptese nula. Ou seja, o tempo necessrio menor para a tcnica
Transformao (por pouco) para esse escopo.
Em relao ao teste, analisando as tcnicas Modelo da Empresa e Transformao,
no possvel afirmar que o tempo seja menor independente de qual tempo
considerado (total ou s da criao do caso de uso). Porm tambm no possvel
afirmar que o tempo seja maior, j que 8!
no maior ou igual a
8(3; 4; 0,05) = 17 ( o mesmo valor para o escopo ATM e Locadora, j que em

ambos os casos 7 = 3 e : = 4).
185
Diretamente Modelo da Empresa
Total UC Total
UC
WtempoTransformao
21
7
10
10
ATM
m(m+n+1) - W(m; n; 0,05)
7
7
7
7
WtempoTransformao
18
13
12
9
Locadora
m(m+n+1) - W(m; n; 0,05)
7
7
7
7
Escopo
Elemento
Na Tabela 7.7 so apresentados os valores para a anlise dos tempos obtidos ao

empregar a tcnica Modelo da Empresa em relao tcnica Diretamente. De forma
similar anlise entre as tcnicas Transformao e Diretamente, o tempo menor
apenas para o escopo ATM e considerando o tempo de criao do caso de uso.
Caso seja considerado o tempo total, ele ser maior, o que tambm acontece para o
escopo da Locadora. Por fim, no escopo da Locadora e considerando apenas o
tempo de criao do caso de uso, no possvel dizer que os tempos sejam
diferentes (um maior que o outro).
Tabela 7.7: Valores ao analisar os tempos ao empregar a tcnica Modelo da Empresa e Diretamente.
Escopo
Elemento
WtempoModeloDaEmpresa
4(4+5+1) - W(4; 5; 0,05)
W(4; 5; 0,05)
WtempoModeloDaEmpresa
Locadora 4(4+4+1) - W(4; 4; 0,05)
W(4; 4; 0,05)
ATM
Diretamente
Total UC
30
10
13
13
27
27
26
17
12
12
24
24
7.4.4 Questionrio final
As respostas dadas pelos sujeitos empregando a tcnica Transformao no

questionrio final so apresentadas na Figura 7.5. Nessa figura so apresentadas
apenas as porcentagens de cada uma das respostas, sendo que no Apndice K so
apresentadas as respostas efetivas. Assim como nas outras anlises, as respostas
dadas pelo sujeito que teve sua nota considerada como valor atpico foram
desconsideradas. Dessa maneira, as respostas consideram 6 sujeitos a menos da
pergunta 10 que no foi respondida por um dos sujeitos.
De uma forma geral, os sujeitos consideraram que o modelo da empresa to-be
auxilia a criao do caso de uso (83% responderam sim), enquanto que para o
186
modelo as-is no h um consenso. De qualquer forma, esses modelos no tinham
informao que atrapalhou a criao do caso de uso (100% responderam no).
1. Os modelos de empresa (representando o processo, os documentos e os participantes) ajudaram a
gerar o caso de uso?
(a) no (17%) (b) pouco (0%)
(c) mais ou menos (0%)
(d) razoavelmente (0%)
(e) sim (83%)
2. O modelo da empresa atual (sem o sistema) til para a criao do caso de uso?
(a) no (17%) (b) pouco (17%)
(c) mais ou menos (33%) (d) razoavelmente (0%)
(e) sim (33%)
3. O modelo da empresa com o sistema (desejado) til para a criao do caso de uso?
(a) no (17%) (b) pouco (0%)
(e) sim (66%)
4. Alguma informao dos modelos de empresa atrapalhou a criao do caso de uso?
(a) no (100%) (b) sim (0%)
5. Em um projeto real voc criaria os modelos de empresa antes de gerar o caso de uso?
(a) nunca (0%) (b) raramente (0%) (c) s vezes (17%)
(d) frequentemente (17%) (e) sempre (66%)
6. O caso de uso preliminar (entregue como anexo) ajudou a criar o caso de uso?
(a) no (17%) (b) pouco (0%)
(e) sim (50%)
7. O fluxo principal do caso de uso preliminar ajudou a definir o fluxo principal do caso de uso gerado?
(a) no (17%) (b) pouco (0%)
(e) sim (50%)
8. Os atores do caso de uso preliminar ajudaram a identificar os atores do caso de uso gerado?
(a) no (0%)
(b) pouco (17%)
(e) sim (83%)
9. Os fluxos alternativos do caso de uso preliminar ajudaram a definir os fluxos alternativos do caso de
uso gerado?
(a) no (33%) (b) pouco (0%)
(e) sim (50%)
10. As pr-condies do caso de uso preliminar ajudaram a identificar as pr-condies do caso de uso
gerado?
(a) no (40%) (b) pouco (0%)
(c) mais ou menos (20%) (d) razoavelmente (0%)
(e) sim (40%)
11. As ps-condies do caso de uso preliminar ajudaram a identificar as ps-condies do caso de uso
gerado?
(a) no (66%) (b) pouco (17%)
(e) sim (0%)
12. O caso de uso preliminar atrapalhou a criao do caso de uso?
(a) no (83%) (b) pouco (17%)
(e) sim (0%)
13. Voc acha que o emprego do caso de uso preliminar ajudou a obter um caso de uso de maior
qualidade?
(a) no (17%) (b) pouco (0%)
(e) sim (66%)
Figura 7.5: Respostas dos questionrios finais dos sujeitos que executaram um tratamento com a
tcnica de criao de caso de uso Transformao.
Em relao transformao, 100% responderam que o caso de uso preliminar no

atrapalhou a criao do caso de uso final (83% responderam no e 17%
responderam pouco). Mais que isso, 83% consideraram que o caso de uso gerado
pela transformao ajudou a criar os casos de uso (33% responderam
razoavelmente e 50% sim), e a mesma quantidade afirmou que o emprego desses
casos de uso ajudou a obter um caso de uso de maior qualidade (17% responderam
razoavelmente e 66% sim). Os casos de uso gerados contriburam para a
identificao dos atores (83% responderam sim), fluxo principal (83% responderam
razoavelmente e sim) e fluxo alternativo (67% responderam razoavelmente e sim).
Em compensao, 83% dos sujeitos responderam que o caso de uso gerado pela
ferramenta no ajudou a definir as ps-condies (66% responderam no e 17%
187
pouco) e no houve consenso se ele ajuda a definir as pr-condies. Essas
respostas negativas so esperadas, uma vez que as regras de transformao no
tratam desses dois elementos do modelo de caso de uso.
Como concluso da anlise dos questionrios, pode-se dizer que os sujeitos
consideraram til o caso de uso gerado pela transformao. Portanto, pode-se dizer
que qualitativamente os sujeitos consideraram que a transformao pode ser usada
e vantajosa.
7.4.5 Outras anlises
Alm dos testes de hipteses, duas outras anlises foram realizadas com os dados
obtidos. Primeiramente foi realizada uma anlise da dificuldade dos exerccios,
buscando concluir se um dos exerccios foi mais difcil que o outro. Para isso foram
consideradas as notas independentemente da tcnica usada. Como os tamanhos
das amostras so maiores que 8 (11 para Locadora e 12 para a ATM), usou-se uma
aproximao normal para o teste de Wilcoxon. De acordo com Devore (2003), a
aproximao normal pode ser feita atravs da seguinte frmula:
-=
8 7(7 + : + 1)2
B7:(7 + : + 1)12
Onde 8 a soma dos postos de Wilcoxon da primeira distribuio e 7 e : so o

nmero de observaes para a primeira e segunda distribuio, respectivamente. A
hiptese nula ser que as mdias so iguais, ou seja,
= 0, enquanto que a
hiptese alternativa que as mdias so diferentes, ou seja,
0. Caso
- 6. ou - 6. (em que 6. a varivel aleatria normal padro no nvel de

significncia
), a hiptese nula pode ser rejeitada. No caso da dificuldade dos
exerccios, ao considerar as notas da Locadora como primeira distribuio, se tem:

-=
176 11(11 + 12 + 1)2

B(11)(12)(11 + 12 + 1)12
= 2,71
Usando um nvel de significncia de 0,05, tem-se que 6. = 1,64. Como 2,71 1,64,
a hiptese nula rejeitada. Portanto, pode-se dizer que os exerccios no tm a
mesma dificuldade no caso, o exerccio do ATM mais difcil.
188
A outra anlise realizada tratou das regras de transformao usadas, sendo
apresentada na Tabela 7.8. As regras RS5, RS6, RS8 e RS11 e RS12 no so
apresentadas na tabela uma vez que, por questes de implementao, a ferramenta
no imprime quando elas so usadas. Alm disso, a regra RR7 no apresentada
na tabela por no ter sido implementada, enquanto que a RR8 no apresentada
por ter sido desconsiderada no experimento.
Tabela 7.8: Regras usadas por sujeito.
Escopo Sujeito RS1 RS2 RS3 RS4 RS7 RS9 RS10 RS13 RS14 RR1 RR2 RR3 RR4 RR5 RR6 Total
1
5
4
2
2
5
1
1
23
10 2
11 1
1
1
2
2
2
1
1
11
ATM
12 2
1
4
1
1
1
4
1
1
16
13 2
1
4
4
2
2
4
1
1
1
22
Mdia 1,8 1 3,5 2,8 1,3 0,5 1,75 3,5
0,75
1 0,3
18
23 1
1
3
5
2
2
3
1
18
24 1
1
3
7
3
15
Locadora
25 1
1
3
3
3
3
3
3
1
21
Mdia 1
1
3
5 1,7
1,67
3
1,3 0,3
18
De uma forma geral, as mesmas regras foram usadas nos dois escopos. Apenas
uma regra foi usada em apenas um escopo: a regra RS9 (que trata da identificao
de laos), usada em um dos exerccios do escopo ATM. Na mdia o mesmo nmero
de regras foi usado pelos dois escopos, sendo que houve uma maior variao no
escopo da ATM. Em especial, o exerccio que teve sua nota considerada como valor
atpico teve o maior uso de regras. Porm, como o nmero de sujeitos pequeno,
no parece ser adequado analisar a correlao das notas com o nmero de regras.
7.5 Discusso e concluses
O experimento teve como objetivo analisar a possibilidade de uso e as vantagens do

uso da transformao proposta por este trabalho. Para isso foram considerados dois
escopos diferentes (ATM e Locadora) e trs tcnicas para criao do caso de uso
(Diretamente, Modelo da Empresa e Transformao). As variveis dependentes
consideradas foram a qualidade dos casos de uso a qual foi avaliada considerando
os fatores propostos por (PHALP; VINCENT; COX, 2007a) o tempo necessrio e a
percepo subjetiva avaliada atravs de um questionrio.
189
Como resultado da anlise quantitativa dos dados, pode-se concluir que o uso da
transformao no diminui a qualidade dos casos de uso resultantes. Ou seja, podese dizer que ela pode ser usada na prtica. Porm no possvel dizer que o uso da
transformao vantajoso. Para o escopo ATM, o uso de modelos de empresa
resultou em casos de uso de maior qualidade, j que o emprego das tcnicas
Modelo da Empresa e Transformao levou a notas maiores do que as notas obtidas
atravs do emprego da tcnica Diretamente. Entretanto no possvel afirmar que a
transformao levou a uma qualidade maior, j que no houve diferena significativa
entre os resultados dessa tcnica e a tcnica Modelo da Empresa. Por outro lado, no
escopo Locadora no possvel afirmar que haja diferena entre as tcnicas
analisadas.
Em relao ao tempo, foi mais demorado empregar as tcnicas Modelo da Empresa
e Transformao do que empregar a tcnica Diretamente. Esse resultado
esperado, uma vez que necessrio criar um outro artefato: o modelo da empresa.
Caso seja considerado apenas o tempo para a criao do caso de uso, ento o
tempo necessrio no maior. Mais que isso, para o escopo da ATM ele menor
para as tcnicas Transformao e Modelo da Empresa.
Se por um lado os resultados quantitativos no indicam vantagens no uso da
transformao, qualitativamente os resultados foram positivos. A maioria dos sujeitos
considerou que os casos de uso gerados pela transformao no atrapalharam a
criao do caso de uso e, mais que isso, que o resultado da transformao ajudouos a gerar o caso de uso.
Como concluso, no possvel afirmar que a transformao de requisitos em
especificaes proposta traz vantagens para o engenheiro de requisitos, apesar de a
avaliao subjetiva ter sido positiva. Em compensao, tambm no possvel
afirmar que ela atrapalha a criao do caso de uso, o que positivo. Os resultados
obtidos (qualidade e tempo) foram similares aos obtidos pelos sujeitos que criaram o
caso de uso a partir do modelo da empresa. Talvez ao realizar o experimento com
um maior nmero de sujeitos e considerando um maior nmero de regras seja
possvel obter resultados mais positivos. De forma similar, talvez ao considerar
outras variveis dependentes seja possvel obter dados quantitativos que reflitam a
resposta positiva na avaliao subjetiva dos sujeitos. Alm disso, as vantagens do
190
uso de uma transformao e de um apoio ferramental talvez fiquem mais evidentes
durante a absoro de mudanas no modelo de requisitos, uma vez que os
requisitos que se mantm so automaticamente mapeados s especificaes e
parte dos que variam e os que so acrescentados podem ser detectados. Ou seja,
talvez seja necessrio um experimento diferente para avaliar essa possibilidade. Por
fim, o resultado das anlises da qualidade e do tempo parece indicar que existem
escopos em que o uso de modelos de empresa leva a melhores resultados casos
de uso de maior qualidade e menor tempo. Porm, isso pode ser devido a outros
fatores, como, por exemplo, o enunciado do experimento. Dessa maneira, cabe a
futuros experimentos analisar essa questo.
191
8 CONCLUSO
Este
trabalho
apresentou
uma
proposta
de
transformao
de
requisitos,
representados em um modelo da empresa do ponto de vista organizacional, em

especificaes, representadas em um modelo de casos de uso, usando conceitos de
Engenharia Dirigida por Modelos (MDE). Para isso, foram definidos metamodelos de
empresa e de casos de uso, juntamente com um conjunto de regras de
transformao que foram obtidas atravs da aplicao de um mtodo. Tambm foi
criada uma ferramenta que permite a execuo da transformao idealizada. Por
fim, foi realizado um experimento para analisar as possibilidades de uso e as
vantagens dessa transformao.
O resultado do experimento indicou que o uso da transformao no diminui a
qualidade dos casos de uso e tampouco aumenta o tempo de criao deles
(comparando com a situao em que um modelo da empresa criado). Alm disso,
a maioria dos sujeitos considerou que o caso de uso gerado pela transformao
ajudou-o a realizar a atividade proposta pelo experimento. Apesar desses resultados
positivos, o experimento no indicou um aumento da qualidade dos casos de uso ou
uma diminuio do tempo de criao deles ao aplicar a transformao. Como
concluso do experimento detalhada na seo 7.5 , pode-se dizer que possvel
usar a transformao na prtica, j que ela no afeta negativamente a criao dos
casos de uso. Entretanto no possvel afirmar que ela traz vantagens para o
engenheiro de requisitos, apesar da avaliao positiva dos sujeitos. Talvez com um
grupo maior de sujeitos, um nmero maior de regras de transformao, um projeto
maior ou um grupo menos experiente do que o que realizou o experimento, a
transformao apresente resultados mais positivos. Alm disso, talvez essa
transformao apresente mais vantagens durante a absoro de mudanas nos
requisitos, uma vez que ela permitiria observar com mais facilidade os impactos das
mudanas nas especificaes. Ou seja, outras anlises so necessrias. Ainda
assim, este trabalho confirmou a possibilidade de transformar requisitos em
especificaes: a ferramenta construda permite realizar essa transformao, mesmo
que de forma inicial e semiautomtica.
192
8.1 Contribuies
Este trabalho apresentou algumas contribuies para rea de Engenharia de

Requisitos e para a rea de Engenharia Dirigida por Modelos.
Na rea de Engenharia de Requisitos este trabalho avanou na discusso da
relao entre requisitos e especificaes. Mais que isso, foi proposta uma
transformao e um conjunto de regras para realizar o refinamento dos requisitos
em especificaes. Uma outra contribuio foi a discusso da relao entre o
contexto empresarial e os requisitos, sugerindo o uso em algumas situaes de
um modelo da empresa como um modelo dos requisitos. Relacionado a isso, uma
outra contribuio foi a proposta de um modelo da empresa do ponto de vista
organizacional a ser usado como modelo dos requisitos.
Em relao tcnica de casos de uso, este trabalho contribuiu ao discutir as
limitaes do emprego dos casos de uso conforme definido na UML como
especificaes. Alm disso, foram definidos critrios para avaliar a qualidade de um
caso de uso e se analisou os elementos mais comuns em propostas de guias e
metamodelos, propondo um metamodelo essencial de casos de uso.
Em relao rea de Engenharia Dirigida por Modelos, este trabalho contribuiu ao
discutir a relao entre os modelos do MDA e os requisitos, considerando o modelo
WRSPM. Uma outra contribuio foi a criao de uma ferramenta usando o padro
QVT e o EMF.
8.2 Trabalhos futuros
Existem alguns trabalhos futuros que podem ser realizados a partir desta pesquisa.
Dentre as possibilidades, destacam-se os seguintes trabalhos que se considera os
mais importantes para a continuidade da pesquisa, ressaltando a seo em que eles
foram sugeridos:
Aplicar o mtodo para obteno de regras de refinamento em outros projetos

(sugerido na seo 6.6);
Permitir a interveno do engenheiro de requisitos durante a transformao,
193
implementando corretamente as regras RR1, RR3, RR7 e RR8 (sugerido na
seo 6.6);
Definir como validar os modelos de empresa usados na transformao e os

modelos de caso de uso obtidos pela transformao (sugerido na seo 6.6);
Realizar o experimento em um nmero maior de sujeitos (sugerido na seo

7.5); e
Realizar um experimento para avaliar as vantagens do uso da transformao

e da ferramenta proposta no caso de mudanas nos requisitos (sugerido na
seo 7.5).
Alm desses trabalhos, a seguir so apresentados outros possveis trabalhos

futuros:
Definir um modelo da empresa do ponto de vista organizacional baseado na

fuso ou interseco dos metamodelos (sugerido na seo 6.2);
Analisar e alterar o metamodelo de empresa, considerando as necessidades

da transformao (sugerido nas sees 6.2.1 e 6.6);
Analisar o impacto das simplificaes realizadas nas vises motivacional e de

processos do metamodelo de empresa em relao capacidade de
representao dos requisitos e transformao (sugerido na seo 6.2.2);
Especializar o metamodelo de caso de uso ao considerar as necessidades de

sistemas de automao de processos (sugerido na seo 6.3.1);
Analisar se ao aplicar o mtodo para obteno de regras de refinamento em

vrios projetos as influncias dos sistemas e dos gabaritos usados so ainda
relevantes (sugerido na seo 6.4.1);
Analisar a eficcia do mtodo para obteno de regras de refinamento

(sugerido na seo 6.4.3);
Criar uma ferramenta para auxiliar a redao das regras de refinamento,

gerenciando-as e evidenciando seus relacionamentos (sugerido na seo
6.4.3);
Definir um conjunto bsico de teste para as regras de refinamento (sugerido

na seo 6.4.3);
Analisar a necessidade das relaes de incluso e extenso no metamodelo

de casos de uso (sugerido na seo 6.6);
194
Analisar se os casos de uso obtidos atravs das regras propostas levam a

uma decomposio funcional do caso de uso (sugerido na seo 6.6);
Analisar a correo e as vantagens de usar os metamodelos no contexto da

transformao (sugerido na seo 7.1);
Analisar a adequao das regras de transformao propostas (sugerido na

seo 7.1);
Definir um quadro de referncia que permita comparar casos de uso e outros

modelos de especificaes como, por exemplo, os modelos de metas usados
pelas abordagens Tropos e KAOS (sugerido na seo 7.1);
Analisar a influncia do escopo na qualidade dos casos de uso (sugerido na

seo 7.5);
Executar o experimento em sujeitos de diferentes perfis; e
Analisar a validade das outras trs hipteses consideradas.
8.3 Artigos publicados
Durante a realizao deste trabalho foram publicados os seguintes artigos:
SIQUEIRA, Fbio Levy; MUNIZ SILVA, Paulo Srgio. Transforming an

Enterprise Model into a Use Case Model Using Existing Heuristics. In:
Model-Driven Requirements Engineering Workshop (MoDRE), 2011.
SIQUEIRA, Fbio Levy; MUNIZ SILVA, Paulo Srgio. Using an Enterprise

Model as a Requirements Model in Process Automation Systems: A
Proposal. In: International Conference on Information Systems and
Technology Management (CONTECSI), 8., pp.3064-3088, 2011.
SIQUEIRA, Fbio Levy; MUNIZ SILVA, Paulo Srgio. An Essential Textual

Use Case Meta-model Based on an Analysis of Existing Proposals. In:
Workshop em Engenharia de Requisitos (WER), 2011.
SIQUEIRA, Fbio Levy; MUNIZ SILVA, Paulo Srgio. Mapping the WRSPM
Model to Model-Driven Architecture Models. In: International Conference
on Information Technology: New Generations (ITNG), 8., pp.750-753, 2011.
As propostas dos metamodelos de empresa e de casos de uso foram publicadas nos

artigos (2) e (3), respectivamente. A proposta da transformao e as regras de
transformao obtidas pela anlise dos trabalhos relacionados foram tratadas pelo
195
artigo (1). Por fim, o artigo (4) trata da relao do TS do MDA e o modelo de
referncia de requisitos usado (o WRSPM).
Outros artigos sobre o restante desse trabalho so planejados e esto sendo
redigidos, em especial alguns artigos tratando do experimento.
196
REFERNCIAS
ACHOUR, C. B.; ROLLAND, C.; MAIDEN, N. A. M.; SOUVEYET, C. Guiding use
case authoring: results of an empirical study. In: IEEE International Symposium
on Requirements Engineering, pp.36-43, 1999.
ADDISON, M. E. Fundamentos de Organizao e Mtodos. Traduo de Eduardo
de Almeida. Zahar editores, 1979.
ALEXANDER, I.; MAIDEN, N. Scenarios, Stories, Use Cases: Through the
Systems Development Life-Cycle. Wiley, 2004.
ANDA, B.; HANSEN, K.; SAND, G. An investigation of use case quality in a large
safety-critical software development project. Information and Software
Technology, v.51, i.12, pp.1699-1711, December 2009.
ANDA, B.; SJBERG, D. Towards an Inspection Technique for Use Case
Models. In: International Conference on Software Engineering and Knowledge
Engineering, pp.127-134, 2002.
ANDA, B.; SJBERG, D.; JRGENSEN, M. Quality and Understandability of Use
Case Models. In: European Conference on Object-Oriented Programming, 15.,
LNCS 2072, pp.402-428, 2001.
ANDERSON, R. G. Organisation and Methods. 2 ed. MacDonald and Evans,
1980.
ARMOUR, F. J.; KAISLER, S. H.; LIU, S. Y. A Big-Picture Look at Enterprise
Architectures. IT Professional, v.1, i.1, pp.35-42, January/February 1999.
ARMOUR, F.; MILLER, G. Advanced Use Case Modeling: Software Systems.
Addison-Wesley, 2001.
ATKISON, C.; KHNE, T. Model-Driven Development: A Metamodeling
Foundation. IEEE Software, v.20, n.5, pp.36-41, September/October 2003.
BARRETT, S.; SINNIG, D.; CHALIN, P.; BUTLER, G. Merging of Use Case Models:
Semantic Foundations. In: IEEE International Symposium on Theoretical Aspects of
Software Engineering, 3., pp.182-189, 2009.
BECK, K. Extreme Programming Explained: Embrace Change. Addison-Wesley,
1999.
197
BERNSTEIN, P. A. Applying Model Management to Classical Meta Data
Problems. In: Biennial Conference on Innovative Data Systems Research (CIDR),
1., 2003. Disponvel em: <http://www.cidrdb.org/cidr2003/>. Acesso em: 30 jul. 2011.
BZIVIN, J. On the unification power of models. Software Systems Model, v.4,
pp.171-188, 2005.
BZIVIN, J. Model Driven Engineering: An Emerging Technical Space. In:
Generative and Transformational Techniques in Software Engineering, LNCS 4143,
pp.36-64, 2006.
BZIVIN, J.; BARBERO, M.; JOUAULT, F. On the Applicability Scope of Model
Driven Engineering. In: Model-Based Methodologies for Pervasive and Embedded
Software, pp.3-7, 2007.
BZIVIN, J.; JOUAULT, F.; ROSENTHAL, P.; VALDURIEZ, P. Modeling in the
Large and Modeling in the Small. In: Working Conference on Model Driven
Architecture: Foundations and Applications, LNCS 3599, pp.33-46, 2005.
BITTNER, K. The Requirements Landscape. Ivar Jacobson International White
Paper. Jan. 2008. Disponvel em: <http://www.ivarjacobson.com>. Acesso em: 30 jul.
2011.
BITTNER, K.; SPENCE, I. Use Case Modeling. Addison-Wesley, 2002.
BLEISTEIN, S. J.; COX, K.; VERNER, J. Strategic Alignment in Requirements
Analysis for Organizational IT: an Integrated Approach. In: ACM Symposium on
Applied Computing, pp.1300-1307, 2005.
BLEISTEIN, S. J.; COX, K.; VERNER, J.; PHALP, K. T. B-SCP: A requirements
analysis framework for validating strategic alignment of organizational IT
based on strategy, context, and process. Information and Software Technology,
v.48, pp.846-868, 2006.
BOCK, C. UML 2 Activity and Action Models Part 2: Actions. Journal of Object
Technology, v.2, n.5, pp.41-56, 2003.
BOOCH, G.; BROWN, A.; IYENGAR, S.; RUMBAUGH, J.; SELIC, B. An MDA
Manifesto. MDA Journal, pp.2-9, 2004.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language
User Guide. 2a ed. Addison-Wesley, 2005.
BRASIL. Lei no10.406, de 10 de Janeiro de 2002. Disponvel em:
<http://www.planalto.gov.br/ccivil_03/leis/2002/l10406.htm>. Acesso em: 4 ago.
2011.
198
BRESCIANI, P.; PERINI, A.; GIORGINI, P.; GIUNCHIGLIA, F.; MYLOPOUYLOS, J.
Tropos: An Agent-Oriented Software Development Methodology. In:
Autonomous Agents and Multi-Agent Systems, v.8, pp.203-236, 2004.
BRUNET, G.; CHECHIK, M.; EASTERBROOK, S.; NEJATI, S.; NIU, N.;
SABETZADEH, M. A Manifesto for Model Merging. In: Workshop on Global
Integrated Model Management, pp.5-12, 2006.
BUBENKO JR., J. A. Challenges in Requirements Engineering. In: IEEE
International Symposium on Requirements Engineering, 2., p.160-162, 1995.
BUBENKO JR., J.; BRASH, D.; STIRNA, J. EKD User Guide. Version 1.1. 1998.
BUDINSKY, F.; STEINBERG, D.; MERKS, E.; ELLERSICK, R.; GROSE, T. J.
Eclipse Modeling Framework: A Developer's Guide. Addison-Wesley, 2003.
CABRAL, G.; SAMPAIO, A. Formal Specification Generation from Requirement
Documents. Electronic Notes in Theoretical Computer Science, v.195, pp.171-188,
2008.
CALDAS, M. P. O Triste Destino da rea de O&M I. Revista de Administrao de
Empresas, v.39, n.2, pp.6-17, Abr./Jun. 1999a.
CALDAS, M. P. O Triste Destino da rea de O&M II. Revista de Administrao
de Empresas, v.39, n.3, pp.6-16, Jul./Set. 1999b.
CASTRO, J.; KOLP, M.; MYLOPOULOS, J. A Requirements-Driven Development
Methodology. In: Conference on Advanced Information Systems, LNCS 2068,
pp.108-123, 2001.
CFA Conselho Federal de Administrao. Biblioteca Bsica para os Cursos em
Graduao
em
Administrao.
2
ed.
Disponvel
em:
<http://www.cfa.org.br/html/f_prof/bibl_b.html>. Acesso em: 30 jul. 2011.
CHAMPION, R. E. M.; MOORES, T. T. Exploiting an Enterprise Model during
Systems Requirements Capture and Analysis. In: International Conference on
Requirements Engineering, 2., pp.208-215, 1996.
CHASE, R. B.; JACOBS, F. R.; AQUILANO, N. J. Administrao da Produo para
a vantagem competitiva. 10 ed. Bookman, 2006.
CHIAVENATO, I. Administrao Teoria, Processo e Prtica. 3 ed. Makron
Books, 2000.
199
CHUNG, L.; SUPAKKUL, S. Representing NFRs and FRs: A goal-oriented and
Use case driven approach. In: Software Engineering Research and Applications,
LNCS 3647, pp.29-41, 2005.
CLARK, T.; SAMMUT, P.; WILLANS, J. Applied Metamodelling: A Foundation for
Language Driven Development. 2a ed. Ceteva, 2008a. Disponvel em:
<http://itcentre.tvu.ac.uk/~clark/>. Acesso em: 29 de jul. de 2011.
CLARK, T.; SAMMUT; P.; WILLANS, J. Superlanguages: Developing Languages
and
Applications
with
XMF.
Ceteva,
2008b.
Disponvel
em:
<http://itcentre.tvu.ac.uk/~clark/>. Acesso em: 29 de jul. de 2011.
CMMI PRODUCT TEAM. CMMI for Development, Version 1.3. CMU/SEI-2010-TR033, 2010.
COCKBURN, A. Writing Effective Use Cases. Addison-Wesley, 2000.
COOK, S. Domain-Specific Modeling and Model Driven Architecture. MDA
Journal, pp.2-10, 2004.
COOK, S.; JONES, G.; KENT, S.; WILLS, A. C. Domain-Specific Development
with Visual Studio DSL Tools. Addison-Wesley Professional, 2007.
COUTINHO, L. R. Interoperabilidade Organizacional em Sistemas Multiagentes
Abertos Baseada em Engenharia Dirigida por Modelos. 2009. 233p. Tese de
Doutorado Escola Politcnica, Universidade de So Paulo, 2009.
COX, K.; PHALP, K. Replicating the CREWS Use Case Authoring Guidelines
Experiment. Empirical Software Engineering, v.5, n.3, pp.245-267, 2000.
CRUZ, T. Sistemas, Mtodos e Processos: Administrando Organizaes por
Meio de Processos de Negcio. 2 ed. Atlas, 2005.
CURY, A. Organizao e Mtodos: Uma Viso Holstica. 8 ed. Atlas, 2007.
DAFT, R. L. Administrao. 6a ed. Thomson, 2005.
DARDENNE, A.; VAN LAMSWEERDE, A.; FICKAS, S. Goal-Directed
Requirements Acquisition. Science of Computer Programming, v.20, i.1-2, pp.3-50,
1993.
DAVENPORT, T. H. Reengenharia de Processos: Como inovar na empresa
atravs da tecnologia da informao. 5 ed. Campus, 1994.
DE LA VARA, J. L.; SANCHZ, J.; PASTOR, O. Business Process Modelling and
Purpose Analysis for Requirements Analysis of Information Systems. In:
200
International Conference on Advanced Information Systems Engineering, 20. LNCS
5074, pp.213-227, 2008.
DENNEY, R. Succeeding with Use Cases: Working Smart to Deliver Quality.
Addison Wesley, 2005.
DECREUS, K.; POELS, G. Putting Business into Business Process Models. In:
International Computer Software and Applications Conference, pp.1005-1010, 2008.
DECREUS, K.; SNOECK, M.; POELS, G. Practical Challenges for Methods
Transforming i* Goal Models into Business Process Models. In: IEEE
International Requirements Engineering Conference, 17., pp.15-23, 2009.
DELOR, E.; DARIMOND, R.; RIFAUT, A. Software Quality Starts with the
Modelling of Goal-Oriented Requirements. In: International Conference on
Software & Systems Engineering and their Applications, 16., 2003. Disponvel em:
<http://www.objectiver.com>. Acesso em: 30 jul. 2011.
DEVORE, J. L. Probability and Statistics for Engineering and the Sciences. 6a
ed. Duxbury Press, 2003.
DIAS, F.; MORGADO, G.; OSCAR, P.; SILVEIRA, D.; ALENCAR, A. J.; LIMA, P.;
SCHMITZ, E. Uma abordagem para a Transformao Automtica do Modelo de
Negcio em Modelo de Requisitos. In: Workshop em Engenharia de Requisitos,
2006.
DIETZ, J. L. G. Understanding and Modelling Business Processes with DEMO.
In: International Conference on Conceptual Modeling, 18., LNCS 1728, pp.188-202,
1999.
DIETZ, J. L. G. Deriving Use Cases from Business Process Models. In:
International Conference on Conceptual Modeling, 22., LNCS 2813, pp.131-143,
2003.
DIJKMAN, R. M.; JOOSTEN, S. M. M. An Algorithm to Derive Use Case Diagrams
from Business Process Models. In: The IASTED International Conference on
Software Engineering and Applications, 2002a.
DIJKMAN, R. M.; JOOSTEN, S. M. M. Deriving Use Case Diagrams from
Business Process Models. Technical Report TR-CTIT-02-08, Centre for Telematics
and Information Technology, University of Twente, 2002b. Disponvel em:
<http://doc.utwente.nl/37995/>. Acesso em: 30 jul. 2011.
DIJKSTRA, E. W. A constructive approach to the problem of program
correctness. BIT Numerical Mathematics, v.8, n.3, pp.174-186, 1968.
201
DOD Department of Defense. The DoDAF Architecture Framework Version
2.02, 2010. Disponvel em: <http://cio-nii.defense.gov/sites/dodaf20/>. Acesso em:
30 jul. 2011.
DURN, A.; BERNRDEZ, B.; GENERO, M.; PIATTINI, M. Empirically Driven Use
Case Metamodel Evolution. In: UML 2004 - The Unified Modelling Language, LNCS
3273, pp.1-11, 2004.
ESTRADA, H. MARTNEZ, A. PASTOR, O. Goal-Based Business Modeling
Oriented towards Late Requirements Generation. In: International Conference on
Conceptual Modeling, 22., LNCS 2813, pp.277-290, 2003.
FOX, M. S. Issues in Enterprise Modelling. In: International Conference on
Systems, Man and Cybernetics, pp.86-92, 1993.
FRANKEL, D. S.; HARMON, P.; MUKERJI, J.; ODELL, J.; OWEN M.; RIVITT, P.;
ROSEN, M.; SOLEY, R. M. The Zachman Framework and the OMG's Model
Driven Architecture. Business Process Trends. Whitepaper, September 2003.
GHERBI, T.; MESLATI, D.; BORNE, I. MDE between Promises and Challenges. In:
International Conference on Computer Modelling and Simulation, 11., pp.152-155,
2009.
GILB, T. Towards the Engineering of Requirements. Requirements Engineering,
v.2, pp.165-169, 1997.
GONZALEZ-PEREZ, C.; HENDERSON-SELLERS, B. Metamodelling for Software
Engineering. John Wiley & Sons, 2008.
GOTTESDIENER, E. Good Practices for Developing User Requirements.
CrossTalk. pp.13-17, march 2008.
GUNTER, C.; GUNTER, E.; JACKSON, M.; ZAVE, P. A Reference Model for
Requirements and Specifications. IEEE Software, v.17, n.3, pp.37-43, May/June
2000.
HAMMER, M.; CHAMPY, J. Reengenharia: Revolucionando a empresa em
funo dos clientes, da concorrncia e das grandes mudanas da gerncia.
Campus, 1994.
HAROLD; E. R.; MEANS, W. S. XML in a Nutshell. 3a ed. OReilly, 2004.
HARRINGTON, H. J. Aperfeioando processos empresariais: estratgia
revolucionria para o aperfeioamento da qualidade, da produtividade e da
competitividade. Makron Books, 1993.
202
HSIA, P.; DAVIS, A.; KUNG, D. Status Report: Requirements Engineering. IEEE
Software, v.10, n.6, pp.75-79, 1993.
IBM. Rational Software Architect Standard Edition. Version 7.5, 2008.
IBM. Rational Method Composer. Version 7.5, IBM, 2009.
IEEE. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard
Computer Glossaries. IEEE 610, 1990.
IEEE. IEEE Recommended Practice for Software Requirements Specifications.
IEEE 830, 1998.
IKV++ TECHNOLOGIES AG. Medini QVT. Verso 1.6.0.25263. 2008. Disponvel
em: <http://projects.ikv.de/qvt/>. Acesso em: 30 jul. 2011.
ISO International Organization for Standardization. Information processing -Documentation Symbols and Conventions for Data, Program and System
Flowcharts, Program Network Charts and System Resources Charts. ISO, 5807,
1985.
ISO International Organization for Standardization. Information Technology
Syntactic Metalanguage Extended BNF. ISO/IEC 14977, 1996.
ISO International Organization for Standardization. Software engineering
Product quality Part 1: Quality model. ISO/IEC 9126-1, 2001.
ISO International Organization for Standardization. Systems and software
engineering Recommended practice for architectural description of softwareintensive systems. ISO/IEC 42010, 2007.
ISO International Organization for Standardization. Systems and software
engineering System life cycle processes. ISO/IEC 15288, 2008.
ITU-T International Telecommunication Union - Telecommunication Standardization
Sector. User Requirements Notation (URN) Language requirements and
framework. ITU-T Recommendation Z.150, 2003.
JACKSON, M. Software Requirements & Specifications: a Lexicon of Practice,
Principles and Prejudices. Addison-Wesley, 1995.
JACKSON, M. The meaning of Requirements. Annals of Software Engineering, v.3,
pp.5-21, 1997.
203
JACKSON, M.; ZAVE, P. Deriving Specifications from Requirements: an
Example. In: International Conference on Software Engineering (ICSE), pp.15-24,
1995.
JACOBSON, I. Object-oriented software engineering: a use case driven
approach. Addison-Wesley, 1992.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development
Process. Addison-Wesley, 1999.
JARKE, M. Scenarios for Modeling. Communications of the ACM, v.42, n.1,
January 1999.
JARKE, M.; KURKI-SUONIO, R. Guest Editorial: Introduction to the Special
Issue. IEEE Transactions on Software Engineering, v.24, n.12, pp.1033-1035,
December 1998.
JIN, Z. Revisiting the meaning of Requirements. Journal of Computer Science and
Technology, v. 21, n.1, pp.32-40, jan. 2006.
JOHNSON, W. L. Deriving Specifications from Requirements. In: International
Conference on Software Engineering, pp.428-438, 1988.
JOUAULT, F.; KURTEV, I. Transforming Models with ATL. In: Satellite Events at
the MoDELS 2005 Conference, LNCS 3844, pp.128-138, 2006.
JURETA, I. J.; MYLOPOULOS, J.; FAULKNER, S. Revisiting the core Ontology
and Problem in Requirements Engineering. In: IEEE International Requirements
Engineering Conference, 16., pp.71-80, 2008.
KAVAKLI, V.; LOUCOPOULOS, P. Goal-Driven Business Process Analysis
Application in Electricity Deregulation. Information Systems, v.24, n.3, pp.187207, 1999.
KAVAKLI, E.; LOUCOPOULOS, P. Goal Modeling in Requirements Engineering:
Analysis and Critique of Current Methods. Information Modeling Methods and
Methodologies, pp.102-124, 2005.
KENT, S. Model Driven Engineering. In: Integrated Formal Methods, LNCS 2335,
pp.286-298, 2002.
KITCHENHAM, B. Empirical Paradigm - The Role of Experiments. In: International
Workshop Empirical Software Engineering Issues - Critical Assessment and Future
Directions, LNCS 4336, pp.25-32, 2007.
204
KLEPPE, A.; WARMER, J.; BAST, W. MDA Explained: The Model Driven
Architecture: Practice and Promise. Addison Wesley Professional, 2003.
KOLIADIS, G.; VRANESEVIC, A.; BHUIYAN, M.; KRISHNA, A.; GHOSE, A.
Combining i* and BPMN for Business Process Model Lifecycle Management. In:
Workshop on Grid and Peer-to-Peer Based Workflows, 2., LNCS 4103, pp.416-427,
2006.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and
Techniques. John Wiley & Sons, 1998.
KOUBARAKIS, M.; PLEXOUSAKIS, D. Business process modelling and design
a formal model and methodology. BT Technology Journal, v.17, n.4, pp.23-35,
1999.
KULAK, D.; GUINEY, E. Use Cases: Requirements in Context. 2a ed. AddisonWesley, 2003.
KURTEV, I.; BZIVIN, J.; AKSIT, M. Technological Spaces: an Initial Appraisal.
In: International Conference on Cooperative Information Systems (CoopIS), 10.,
Industrial track, 2002.
KWASNICKA, E. L. Introduo Administrao. 6a ed. Atlas, 2004.
LANKHORST, M. Introduction to Enterprise Architecture. In: Enterprise
Architecture at Work: Modelling, Communication and Analysis. 2a ed. Springer, 2009.
LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Iterative Development. 3a ed. Prentice Hall PTR,
2003.
LAUDON, K. C.; LAUDON, J. P. Sistemas de Informao Gerenciais. 7 ed.
Pearson Prentice Hall, 2007.
LEFFINGWELL, D.; WIDRIG, D. Managing Software Requirements: A Use Case
Approach. 2a ed. Addison-Wesley, 2003.
LERNER, W. Organizao, Sistemas e Mtodos: Soluo para Renovao e
Inovao Empresarial Participativa. 5 ed. Atlas, 1992.
LINDSTRM, A.; JOHNSON, P.; JOHANSSON, E.; EKSTEDT, M.; SIMONSSON, M.
A survey on CIO concerns-do enterprise architecture frameworks support
them? Information Systems Frontiers, v.8, n.2, pp.81-90, 2006.
205
LEI, M.; JIANG, W. C. Research on Activity Based Use Case Meta-Model. In:
International Conference on Advanced Computer Theory and Engineering, pp.843846, 2008.
LEIST, S.; ZELLNER, G. Evaluation of Current Architecture Frameworks. In:
ACM Symposium on Applied Computing, pp.1546-1553, 2006.
LLEWELLYN, N.; ARMISTEAD, C. Business Process Management: Exploring
Social Capital within Processes. In: Business Process Management, v.11, n.3,
pp.225-243, 2000.
LU, C.; SONG, I. A Comprehensive Aspect-Oriented Use Case Method for
Modeling Complex Business Requirements. In: Advances in Conceptual Modeling
Challenges and Opportunities, LNCS 5232, pp.133-143, 2008.
LUFTMAN, J. Assessing Business-IT Alignment Maturity. Comunications of the
Association for Information Systems, v.4, a.14, pp.1-49, 2000.
MAIDEN, N. User Requirements and System Requirements. IEEE Software, v.25,
n.2, pp.90-91, March/April 2008.
MARTNEZ, A.; PASTOR, O.; MYLOPOLOUS, J.; E GIORGINI, P. From Early to
Late Requirements: A Goal-Based Approach. In: Agent-Oriented Information
Systems, 8., LNAI 4898, pp.123-142, 2008.
MAXIMIANO, A. C. A. Introduo Administrao. 7a ed. Atlas, 2007.
MAYER, R. J.; MENZEL, C. P.; PAINTER, M. K.; DEWITTE, P. S.; BLINN, T.;
PERAKATH, B. Information Integration for Concurrent Engineering (IICE) IDEF3
Process Description Capture Method Report. Interim Technical Report AL-TR1995-XXXX, 1995. Disponvel em: <http://www.idef.com/>. Acesso em: 30 jul. 2011.
MELLOR, S. J.; CLARK, A. N.; FUTAGAMI, T. Guest Editors' Introduction: ModelDriven Development. IEEE Software, v.20, n.5, pp.14-18, September/October 2003.
MELLOR, S. J.; SCOTT, K.; UHL, A.; WEISE, D. MDA Distilled: Principles of
Model-Driven Architecture. Addison Wesley, 2004.
MENS, T.; GORP, P. V. A Taxonomy of Model Transformation. In: Proceedings of
the International Workshop on Graph and Model Transformation. Electronic Notes in
Theoretical Computer Science. v.152, pp.125-142, 2006.
MESERVY, T. O. FENSTERMACHER, K. D. MDA Transforming Software
Development: an MDA Road Map. IEEE Software, v.38, n.9, pp.52-58, Sept. 2005.
206
MEYER, B. Introduction to the Theory of Programming Languages. Prentice
Hall, 1990.
MILLER, J.; MUKERJI, J. (Eds). MDA Guide Version 1.0.1. omg/2003-06-01, 2003.
MOLINA, J. G.; ORTN, M. J.; MOROS, B.; NICOLS, J. TOVAL, A. Towards Use
Case and Conceptual Models through Business Modeling. In: International
Conference on Conceptual Modeling, 19., LNCS 1920, pp.281-294, 2000.
MYLOPOULOS, J.; CHUNG, L.; LIAO, S.; WANG, H.; YU, E. Exploring
Alternatives During Requirements Analysis. IEEE Software, v.18, n.1, pp.92-96,
Jan./Feb. 2001.
MYLOPOULOS, J.; KOLP, M.; CASTRO, J. UML for Agent-Oriented Software
Development: The Tropos Proposal. In: International Conference on The Unified
Modeling Language, Modeling Languages, Concepts, and Tools, 4., LNCS 2185,
pp.422-441, 2001.
NAKATANI, T.; URAI, T.; OHMURA, S.; TAMAI, T. A requirements description
metamodel for use cases. In: Asia-Pacific Software Engineering Conference, 8.,
pp.251-258, 2001.
NOETHER, G. E. Sample Size Determination for Some Common Nonparametric
Tests. Journal of the American Statistical Association, v.82, n.398, pp.645-647,
1987.
NUSEIBEH, B.; EASTERBROOK, S. Requirements Engineering: A Roadmap. In:
Conference on The Future of Software Engineering, pp.35-46, 2000.
OLIVEIRA, D. P. R. Sistemas, Organizao & Mtodos: Uma Abordagem
Gerencial. 5 ed. Atlas, 1994.
OMG Object Management Group. Meta Object
Specification. Version 2.0, formal/06-01-01, 2006a.
Facility
(MOF)
Core
OMG Object Management Group. Object Constraint Language. Version 2.0,

formal/06-05-01, 2006b.
OMG Object Management Group. MOF 2.0/XMI Mapping. Version 2.1.1,
formal/2007-12-01, 2007.
OMG Object Management Group. Business Motivation Model. Version 1.0,
formal/2008-08-02, 2008a.
OMG Object Management Group. Business Process Definition MetaModel Volume I: Common Infrastructure. Version 1.0, formal/2008-11-03, 2008b.
207
OMG Object Management Group. Business Process Definition MetaModel Volume II: Process Definitions. Version 1.0, formal/2008-11-04, 2008c.
OMG Object Management Group. Meta Object Facility (MOF) 2.0
Query/View/Transformation Specification. Version 1.1, Final Adopted
Specification, ptc/09-12-05, 2009.
OMG Object Management Group. Business Process Model and Notation
(BPMN). Version 2.0, formal/2011-01-03, 2011a.
OMG Object Management Group. OMG Unified Modeling Language (OMG
UML), Superstructure. Version 2.4, ptc/2010-11-14, 2011b.
OULD, M. A. Business Processes: Modelling and Analysis for Reengineering
and Improvement. Wiley, 1995.
PARSONS, T. Structure and Process in Modern Societies. Free Press, 1960.
PECE Programa de Educao Continuada da Escola Politcnica da Universidade
de
So
Paulo.
Tecnologia
de
Software.
2011.
Disponvel
em:
<http://www.pecepoli.org.br/PT/TSW/>. Acesso em: 30 jul. 2011.
PETTERSSON, F.; IVARSSON, M.; HMAN, P. Automotive use case standard for
embedded systems. In: Workshop on Software Engineering for Automotive
Systems, pp.1-6, 2005.
PFLEEGER, S. L. Experimental Design and Analysis in Software Engineering
Part 2: How to Set Up an Experiment. Software Engineering Notes, v.20, n.1,
pp.22-26, 1995.
PHALP, K. T.; VINCENT, J.; COX, K. Assessing the quality of use case
descriptions. Software Quality Journal, v.15, n.1, pp.69-97, 2007a.
PHALP, K. T.; VINCENT, J.; COX, K. Improving the Quality of Use Case
Descriptions: Empirical Assessment of Writing Guidelines. Software Quality
Journal, v.15, n.4, pp.383-399, 2007b.
POPPER, R. A Elaborao de Manuais na Empresa. Livraria Pioneira Editora,
1972.
POTTINGER, R.; BERNSTEIN, P. A. Merging Models Based on Given
Correspondences. In: International Conference on Very Large Data Bases, 29.,
pp.826-873, 2003.
RAHM, E.; BERNSTEIN, P. A. A Survey of Approaches to Automatic Schema
Matching. The VLDB Journal, v.10, n.4, pp.334-350, 2001.
208
RAMOS, I.; BERRY, D. M.; CARVALHO, J. A. Requirements engineering for
organizational transformation. Information and Software Technology, v.47, pp.479495, 2005.
RAMOS, R.; CASTRO, J.; ALENCAR, F.; ARAJO, J.; MOREIRA, A.; PENTEADO,
R. Quality Improvement for Use Case Model. In: Brazilian Symposium on Software
Engineering, 23., pp.187-195, 2009.
RESPECT-IT. A KAOS Tutorial. Version 1.0. 2007.
ROBERTSON, S.; ROBERTSON, J. C. Mastering the Requirements Process. 2a
ed. Addison-Wesley, 2006.
ROBINSON, W. N.; ELOFSON, G. Goal Directed Analysis with Use Cases.
Journal of Object Technology, v.3, n.5, pp.125-142, May-June 2004.
RODRGUEZ, A.; FERNNDEZ-MEDINA, E.; PIATTINI, M., Towards CIM to PIM
Transformation: From Secure Business Processes Defined in BPMN to UseCases. In: Business Process Management, LNCS 4714, pp.408-415, 2007.
ROLLAND, C. Capturing Systems Intentionally with Maps. Conceptual Modelling
in Information Systems Engineering. pp.141-158, 2007.
ROLLAND, C.; SALINESI, C. Modeling Goals and Reasoning with Them.
Engineering and Managing Software Requirements, pp.189-217, 2005.
ROLLAND, C.; ACHOUR, C. B.; CAUVET, C.; RALYT, J.; SUTCLIFFE, A.;
MAIDEN, N.; JARKE, M.; HAUMER, P.; POHL, K.; DUBOIS, E.; HEYMANS, P. A
Proposal for a Scenario Classification Framework. Requirements Engineering,
v.3, pp.23-47, 1998.
ROOD, M. A. Enterprise architecture: definition, content, and utility. In:
Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 3.,
pp.106-111, 1994.
ROSENBERG, D.; STEPHENS, M. Use Case Driven Object Modeling with UML:
Theory and Practice. Apress, 2007.
RUI, K.; BUTLER, G. Refactoring Use Case Models: The Metamodel. In:
Australasian Computer Science Conference, 26., pp.484-491, 2003.
SABETZADEH, M.; EASTERBROOK, S. View merging in the presence of
incompleteness and inconsistency. Requirements Engineering, v.11, n.3, pp.174193, 2006.
209
SANTANDER, V. F. A. Integrando Modelagem Organizacional com Modelagem
Funcional. 2002. 212p. Tese de Doutorado Centro de Informtica, Universidade
Federal de Pernambuco, 2002.
SANTANDER, V. F. A.; CASTRO, J. F. B. Deriving Use Cases from
Organizational Modeling. In: International Conference on Requirements
Engineering, 10., pp.32-39, 2002.
SCHNEIDER, G.; WINTERS, J. P. Applying Use Cases: A Practical Guide. 2a ed.
Addison-Wesley, 2001.
SCHENHERR, M. Towards a Common Terminology in the Discipline of
Enterprise Architecture. In: Workshop on Trends in Enterprise Architecture
Research, 3., LNCS 5472, pp.400-413, 2009.
SEIDEWITZ, E. What Models Mean. IEEE Software, v.20, n.5, pp.26-31, 2003.
SHAH, H.; KOURDI, M. E. Frameworks for Enterprise Architecture. IT
Professional, v.9, I.5, pp.36-41, September/October 2007.
SIKDAR, S.; DAS, O. Stakeholder Appropriate Requirements Development
Approach. In: International Advance Computing Conference, p.1670-1674, 2009.
SMIALEK, M.; BOJARSKI, J.; NOWAKOWSKI, W.; AMBROZIEWICZ, A.;
STRASZAK, T. Complementary Use Case Scenario Representations Based on
Domain Vocabularies. In: Model Driven Engineering Languages and Systems,
LNCS 4735, pp.544-588, 2007.
SOM, S. S. A Meta-Model for Textual Use Case Description. Journal of Object
Technology, v.8, n.7, pp.87-106, 2009.
SOMMERVILLE, I.; SAWYER, P. Requirements Engineering: A Good Practice
Guide. John Wiley & Sons, 1997.
SOWA, J. F.; ZACHMAN, J. A. Extending and Formalizing the Framework for
Information Systems Architecture. IBM Systems Journal, v.31, n.3, 1992.
STIRNA, J.; PERSSON, A. Ten Years Plus with EKD: Reflections from Using an
Enterprise Modeling Method in Practice. In: Conference on Advanced Information
Systems (CAiSE), 19., pp.97-106, 2007.
STOLFA, S., RADECK, M. The Business Modeling and Its Using for
Requirements Specification. In: Ph.D. Workshop of Faculty of Electrical
Engineering and Computer Science (VSB - Technical University of Ostrava), 2004.
210
SUBRAMANIAM, K.; FAR, B. H.; EBERLEIN, A. Automating the transition from
stakeholders' requests to use cases in OOAD. In: Canadian Conference on
Electrical and Computer Engineering, vol.1, pp.515-518, 2004.
SUSI, A.; PERINI, A.; MYLOPOLOUS, J.; GIORGINI, P. The Tropos Metamodel
and its Use. Informatica, v.29, pp.401-408, 2005.
THE ECLIPSE FOUNDATION. Eclipse SDK. Verso 3.6.2, 2011a. Acesso em: 14
de jun. de 2011.
THE ECLIPSE FOUNDATION. Eclipse documentation The Eclipse Modeling
Framework
(EMF)
Overview,
2011b.
Disponvel
em:
<http://help.eclipse.org/helios/>. Acesso em: 14 jun. 2011.
THE ECLIPSE FOUNDATION. Graphical Modeling Project (GMP), 2011c.
Disponvel em: <http://www.eclipse.org/modeling/gmp/>. Acesso em: 14 jun. 2011.
THE ECLIPSE FOUNDATION. Model Development Tools (MDT), 2011d.
Disponvel em: <http://www.eclipse.org/modeling/mdt/>. Acesso em: 14 jun. 2011.
THE ECLIPSE FOUNDATION. Model To Model (M2M), 2011e. Disponvel em:
<http://www.eclipse.org/m2m/>. Acesso em: 14 jun. 2011.
THE EXECUTIVE OFFICE OF THE PRESIDENT OF THE UNITED STATES. FEA
Consolidated Reference Model Document, Version 2.3. 2007. Disponvel em:
<http://www.whitehouse.gov/omb/e-gov/fea/>. Acesso em: 30 jul. 2011.
THE
OPEN
GROUP.
TOGAF
Version
9.
2009.
<http://www.opengroup.org/togaf/>. Acesso em: 30 jul. 2011.
Disponvel
em:
THEVENET, L.; SALINESI, C. Aligning IS to Organizations Strategy: The

INSTAL Method. In: Conference on Advanced Information Systems, LNCS 4495,
pp.203217, 2007.
TRNER, F.; IVARSSON, M.; PETTERSSON, F.; HMAN, P. An Empirical Quality
Assessment of Automotive Use Cases. In: IEEE International Conference on
Requirements Engineering, 14., pp.89-98, 2006.
VALDERAS, P.; FONS, J.; PELECHANO, V. From Web Requirements to
Navigational Design - A Transformational Approach. In: International Conference
on Web Engineering, 5., LNCS 3579, pp.506-511, 2005.
VAN LAMSWEERDE, A. Goal-Oriented Requirements Engineering: A Guided
Tour. In: IEEE International Symposium on Requirements Engineering, pp.249-262,
2001.
211
VAN LASWEERDE, A. Goal-Oriented Requirements Engineering: A Roundtrip
from Research to Practice. In: IEEE International Requirements Engineering
Conference, 12., pp.4-7, 2004.
VAN LAMSWEERDE, A. Requirements Engineering: From System Goals to UML
Models to Software Specifications. John Wiley & Sons, 2009.
VAN LAMSWEERDE, A.; LETIER, E. From Object Orientation to Goal
Orientation: A Paradigm Shift for Requirements Engineering. In: International
Workshop on Radical Innovations of Software and Systems Engineering in the
Future, 9., LNCS 2941, pp.325-340, 2004.
VERNADAT, F. B. Enterprise Modeling and Integration: Principles and
Applications. Chapamn & Hall, 1996.
W3C World Wide Web Consortium. XML Schema Part 0: Primer Second Edition.
2004. Disponvel em: <http://www.w3.org/TR/xmlschema-0/>. Acesso em: 30 jul.
2011.
W3C World Wide Web Consortium. Extensible Markup Language (XML) 1.1. 2a
ed. 2006. Disponvel em: <http://www.w3.org/TR/xml11/>. Acesso em: 30 jul. 2011.
W3C World Wide Web Consortium. XSL Transformations (XSLT). Verso 2.0.
2007. Disponvel em: <http://www.w3.org/TR/xslt20/>. Acesso em: 30 jul. 2011.
W3C World Wide Web Consortium. XML Essentials. W3C Website. 2010.
Disponvel em: <http://www.w3.org/standards/xml/core.html>. Acesso em: 30 jul.
2011.
WEIDENHAUPT, K.; POHL, K.; JARKE, M.; HAUMER, P. Scenarios in System
Development: Current Practice. IEEE Software, v.15, n.2, pp.34-45, march/april
1998.
WHITMAN, L.; HUFF, B. On the Use of Enterprise Models. The International
Journal of Flexible Manufacturing Systems, v.13, pp.195-208, 2001.
WHITMAN, L.; RAMACHANDRAN, K.; KETKAR, V. A. Taxonomy of a Living Model
of the Enterprise. In: Winter Simulation Conference, pp.848-855, 2001.
WIEGERS, K. Software Requirements. 2a ed. Microsoft Press, 2003.
WIRTH, N. Program development by stepwise refinement. Communications of the
ACM, v.14, n.4, pp.221-227, April 1971.
212
WOHLIN, C.; RUNESON, P.; HST, M. OHLSSON, M. C.; REGNELL, B.;
WESSLN, A. Experimentation in Software Engineering: An Introduction.
Kluwer Academic Publishers, 2000.
YAMAMOTO, S.; KAIYA, H.; COX, K.; BLEISTEIN, S. Goal Oriented Requirements
Enginering: Trends and Issues. IEICE Transactions on Information and Systems,
v.e89-d, n.11, pp.2701-2711, 2006.
YU, E. S. Modelling Strategic Relationships for Process Reengineering. 1995.
166p. Tese de Doutorado Department of Computer Science, University of Toronto,
1995.
YU, E.; MYLOPOULOS, J.; LESPERANCE, Y. AI Models for Business Process
Reengineering. IEEE Expert, pp.16-23, 1996.
YUE, T.; BRIAND, L. C.; LABICHE, Y. A Use Case Modeling Approach to
Facilitate the Transition towards Analysis Models: Concepts and Empirical
Evaluation. In: International Conference on Model Driven Engineering Languages
and Systems, 12., LNCS 5795, pp.484-498, 2009.
ZACHMAN, J. A. A Framework for Information Systems Architecture. IBM
Systems Journal, v.26, n.3, pp.267-292, 1987.
ZAVE, P. Classification of Research Efforts in Requirements Engineering. ACM
Computing Surveys, v.29, n.4, pp.315-321, 1997.
ZAVE, P.; JACKSON, M. Four Dark Corners of Requirements Engineering. ACM
Transactions on Software Engineering and Methodology, v.6, n.1, pp.1-30, jan. 1997.
ZELINKA, L.; VRANIC, V. A Configurable UML Based Use Case Modeling
Metamodel. In: IEEE Eastern European Conference on the Engineering of Computer
Based Systems, 1., pp.1-8, 2009.
213
GLOSSRIO
Ambiente
A parte do mundo em que o sistema ir interagir e na qual

os efeitos do sistema sero observados e avaliados
(JACKSON, 1997).
Caso de uso
"Uma especificao de um conjunto de aes executado

por um sistema, o qual gera um resultado observvel que ,
tipicamente, de valor para um ou mais atores ou outra parte
envolvida do sistema" (OMG, 2011b, p.612).
Conhecimento do domnio Afirmao sobre informaes conhecidas e assumidas

sobre o ambiente.
Diagrama
Uma representao grfica de um modelo ou de parte dele.
Empresa
Uma organizao que realiza atividade econmica para a

produo ou a circulao de bens ou de servios (BRASIL,
2002).
Engenharia de Requisitos a disciplina que cobre "todas as atividades envolvidas em

descobrir, documentar e manter um conjunto de requisitos
para
um
sistema
baseado
em
computador"
(SOMMERVILLE; SAWYER, 1997, p.5).

Engenharia de Requisitos a Engenharia de Requisitos usando metas GORE para
orientada por metas
realizar as suas atividades (VAN LAMSWEERDE, 2009).
Engenharia Dirigida por
um paradigma de desenvolvimento e manuteno de
Modelos
sistemas intensivos de software baseado no princpio de

que tudo um modelo (BZIVIN, 2005).
Especificao
Um tipo de requisito refinado ao remover todas as

caractersticas que impedem que ele seja implementado.
214
Especificao de
Documento que serve como uma declarao oficial para as
requisitos
partes
envolvidas
de
quais
so
as
especificaes
(SOMMERVILLE; SAWYER, 1997).

Espao tcnico
um "contexto de trabalho com um conjunto de conceitos

associados,
habilidades
corpo
de
necessrias
conhecimento,
e
possibilidades"
ferramentas,
(KURTEV;
BZIVIN; AKSIT, 2002, p.1).

Meta
uma afirmao sobre o estado ou condio de algo a ser

obtido ou mantido atravs de meios apropriados (OMG,
2008a).
Meta GORE
"Um objetivo que o sistema sob considerao deveria

atingir" (VAN LAMSWEERDE, 2001, p.250).
Metametamodelo
Modelo que define uma linguagem de metamodelagem.
Metamodelo
um modelo que define a linguagem de modelagem usada

por um modelo.
Modelo
Um conjunto de afirmaes sobre um determinado sistema

em geral (SEIDEWITZ, 2003).
Modelo as-is
Modelo que representa o sistema como ele atualmente.
Modelo to-be
Modelo que representa o sistema como ele ser ou como

se espera que ele fique.
Organizao
"Um sistema social que organizado para alcanar um tipo

particular de meta; o alcance dessa meta ao mesmo
tempo a realizao de um tipo de funo no interesse de
um sistema mais abrangente, a sociedade" (PARSONS,
1960, p.56).
215
Organizao e mtodos
rea da administrao tradicionalmente responsvel pela

institucionalizao da infraestrutura necessria para a
empresa atingir seus
objetivos
e pela definio e
redefinio dos processos e dos mtodos de trabalho

(CURY, 2007).
Projetor
Transformao de modelos entre diferentes Espaos

Tcnicos.
Refinamento
Processo que detalha requisitos em especificaes.
Requisito
(IEEE, 1990, p.172):

a) Uma condio ou capacidade necessria por um
usurio para resolver um problema ou atingir um
objetivo.
b) Uma condio ou capacidade que deve ser cumprida
ou possuda por um sistema ou componente do
sistema
para
satisfazer
um
contrato,
padro,
especificao, ou outros documentos formalmente

impostos.
Requisito no refinado
Requisitos no detalhados em especificao.
Semntica
Define o significado da linguagem (CLARK; SAMMUT;

WILLANS, 2008).
Sintaxe abstrata
Define os conceitos, as relaes entre eles e as regras de

formao que definem como eles podem ser combinados
(CLARK; SAMMUT; WILLANS, 2008).
Sintaxe concreta
A representao externa (ou notao) de uma linguagem

(MEYER, 1990).
Sistema
Uma
"combinao
de
elementos
que
interagem
organizados para atingir um ou mais propsitos declarados"

(ISO, 2008).
216
Sistema computacional
Sistemas contendo um ou mais computadores e o software

associado (IEEE, 1990).
Sistema de automao de So
processos
sistemas
computacionais
com
as
seguintes
caractersticas:
Automatizam processos de negcio, com foco no
fluxo de trabalho; e
So internos a uma empresa, mas podem possuir
algumas interfaces com outros participantes.

Tecnologia da Informao "todo software e todo hardware de que uma empresa
necessita para atingir seus objetivos organizacionais"
(LAUDON; LAUDON, 2007).
Transformao de
"o processo de converter um modelo em outro modelo do
modelos
mesmo sistema" (MILLER; MUKERJI, 2003, p.3.7).
217
APNDICE A ELEMENTOS DE REPRESENTAES DA EMPRESA

Na Tabela A.1 so apresentados os elementos propostos por (ADDISON, 1979),
(ANDERSON, 1980), (CRUZ, 2005), (CURY, 2007), (HARRINGTON, 1993),
(LERNER, 1991) e (OLIVEIRA, 1994) para descrio de uma empresa, sendo que
na coluna "total" apresentado o nmero de trabalhos que propem o elemento em
questo. Os elementos so organizados em um primeiro nvel pelo nome do
diagrama que ele faz parte e em nveis posteriores que denotam a especializao do
elemento. Alguns elementos no so descritos pelas referncias no contexto de uma
representao ou um diagrama especfico e por isso eles so descritos no final da
tabela.
Tabela A.1: Elementos propostos para a representao da empresa sob o ponto de vista
organizacional. As letras correspondem a: A (ADDISON, 1979), B (ANDERSON, 1980), C
(CRUZ, 2005), D (CURY, 2007), E (HARRINGTON, 1993), F (LERNER, 1991) e G
(OLIVEIRA, 1994).
Elemento
Organograma
Ttulo
Data
Autor
rgos / Cargo
Objetivo do cargo
Autoridade
Funes
Tarefas
Resultado esperado
Vinculao/relao
Relao hierrquica
Relao funcional ou de equipe
Comunicao
Tipo de ligao hierrquica
Nvel administrativo
Nome do dirigente
Efetivo de pessoal
Salrio
Esquema de bonificao
Grau de moral e cooperao
Quadro de pessoal
Fluxograma
Terminal
Documento
Emisso de documento
Aparecimento de documento
Alternativas
Mltiplas vias
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Total
X
X
X
X
X
X
X
X
6
2
2
1
6
2
3
5
3
1
5
5
2
2
1
2
1
2
1
1
1
1
6
3
6
2
3
1
3
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
218
Elemento
Jogos de documentos
Influncia em outras atividades
Temporariamente fora do procedimento
Quantidade indefinida de vias
Registro em livros ou fichrios
Cpia adicional
Uso alm do investigado
Inutilizar
Material
Dado
Origem do dado
Entrada
Sada
Evento
Nvel do evento
Operao
Numerao da atividade
Classificao
Conferncia
Verificao
Aplicao de carimbo
Operao do funcionrio
Operao de mquina
Operao de mquina de escrever
Leitura do documento
Operao no relevante para anlise
Mo
Transporte
Espera
Arquivo
Arquivo temporrio
Arquivo definitivo
Arquivo controlado
Procedimento
Ttulo
Propsito
Princpios que governam
Mquina
Equipamento
Formulrio
Tarefa
Sentido do fluxo
Sentido de consulta verbal
Volume de comunicao
Transmisso
Fluxo simultneo (de documentos)
Juno ou separao de documentos ou pessoas
Mais de 3 documentos envolvidos
Conector
Conector de rotina
Deciso
A
X
Total
1
2
1
1
1
1
1
2
1
1
1
2
2
1
1
7
1
1
5
1
1
1
1
1
2
2
1
4
6
5
2
3
1
2
1
1
1
1
1
1
1
7
1
1
1
1
2
1
3
1
5
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
219
Elemento
Cargo
Aparecimento de cargo
Notas explicativas
Tempo
de execuo
de ciclo
de uso da mquina
Arranjo fsico
rgos envolvidos
Planta
Tipo de mquina
Mquina
Tipo de equipamento
Equipamento
Tipo de mvel de escritrio
Mvel de escritrio
Padres de tamanho
Terminador
Atividade
Movimento das pessoas
Movimento de formulrios
Arquivos e manuais
Classificao
Codificao
Preparao de ndices ou referncias
Sistemas de arquivamento
Documento
Dados
Modelo do documento
Normas, polticas e diretrizes
Controles da alta direo
Objetivos
Metas e previses
Eficcia
Eficincia
Custo
Informes
Regras de comportamento disciplinar
Terminologia, definies e simbologia
X
X
X
X
X
X
X
X
Total
6
1
2
3
3
2
1
5
2
4
1
2
2
4
1
3
2
1
2
2
1
1
1
1
1
1
2
1
3
5
1
2
2
1
1
2
1
1
2
X
X
X
X
X
X
E
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Como discutido na seo 6.2, os elementos apresentados no possuem uma

nomenclatura e, em alguns casos, uma semntica consensual sendo assim
agrupados considerando a similaridade semntica e o nome mais comum ou mais
apropriado (ou seja, que evite conflitos de nomes e seja coerente com a
nomenclatura empregada pelo trabalho). Em relao ao primeiro nvel de
organizao dos elementos, em muitos casos existem diferentes tipos de diagramas
que representam essa informao, como, por exemplo, o funcionograma (CRUZ,
220
2005) (CURY, 2007) que permite representar estruturas hierrquicas similarmente
ao organograma e o diagrama de blocos (HARRINGTON, 1993) e o grfico das duas
mos (ADDISON, 1979) que representam informaes processuais assim como um
fluxograma. O contedo desses diagramas foi agrupado por similaridade na anlise
realizada, sendo apresentado na Tabela A.2 uma relao deles conforme a
nomenclatura empregada na Tabela A.1.
Tabela A.2: Diagramas e grficos propostos pelos trabalhos analisados, relacionados aos principais
diagramas propostos.
Trabalho
Processo
Layout
Organograma
(ADDISON, 1979)
Grfico de procedimentos/de
processos
Grfico de duas Mos
Grfico Modificado de Duas
Mos
Diagrama de fluxo
Grfico de
movimento pessoal e
formulrios
Grfico
Grfico X
organizacional
Mapas de
(vertical, horizontal, procedimento
concntrico e
radial)
(ANDERSON, 1980)
Grfico de fluxo do processo

Grfico de fluxo de
procedimentos
Grfico de fluxo do sistema
(estrutura e tcnica)
Grfico de estudo da
produo
Grfico de distribuio de
trabalho
Lista de atividades (mquina
e formulrio)
Grfico de mltiplas
atividades
Declarao de procedimento
(CRUZ, 2005)
Eventograma
Infograma
Fluxograma
(CURY, 2007)
Fluxograma vertical
Fluxograma administrativo
ou de rotinas de trabalho
Fluxograma global ou de
coluna
(OLIVEIRA, 1994)
Organograma
Funcionograma
Layout
Layout (pelo
processo e pelo
produto)
Organograma
Funcionograma
Fluxograma
geogrfico
Organograma
Fluxograma
Descrio narrativa
Layout
Organograma
Descrio das
tarefas
Harmonograma
Fluxograma vertical
Fluxograma parcial ou
descritivo
Fluxograma global ou de
coluna
Planta baixa
Organograma
Organograma
linearOrganograma
vertical
Diagrama de blocos
Fluxograma padro
(HARRINGTON, 1993)
Fluxograma funcional
Fluxo-cronograma
(LERNER, 1992)
Arranjo Fsico
Documento
Fluxograma
221
APNDICE B SINTAXE CONCRETA EM XML DO METAMODELO DE CASO DE USO

O XML Schema que define a sintaxe concreta em XML apresentado a seguir,
considerando as modificaes no metamodelo necessrias para a ferramenta,
discutidas na seo 6.5. Os termos so apresentados em ingls, assim como as
demais partes dos metamodelos. Alm disso, para diminuir o tamanho do XML
Schema, no sero apresentadas documentaes atravs de anotaes no modelo.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ucm="http://www.levysiqueira.com.br/UseCaseModel"
elementFormDefault="unqualified"
targetNamespace="http://www.levysiqueira.com.br/UseCaseModel">

<element name="useCaseModel">
<complexType>
<sequence>
<element name="actors">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="1" name="actor"
type="ucm:actorType"/>
</sequence>
</complexType>
</element>
<element maxOccurs="unbounded" minOccurs="1" name="useCase"
type="ucm:useCaseType">
<key name="KeyActorInStep">
<selector xpath="actors/actor"/>
<field xpath="@name"/>
</key>
<keyref name="ValidActorInBasicFlowAction"
refer="ucm:KeyActorInStep">
<selector xpath="basicFlow/action"/>
<field xpath="@actor"/>
</keyref>
<keyref name="ValidActorInAlternativeFlowAction"
refer="ucm:KeyActorInStep">
<selector xpath="alternativeFlow/action"/>
<field xpath="@actor"/>
</keyref>
</element>
</sequence>
<attribute name="subject" type="string" use="required"></attribute>
</complexType>
<key name="KeyActor">
<selector xpath="actors/actor"/>
</key>
<keyref name="ActorInActors" refer="ucm:KeyActor">
<selector xpath="useCase/actors/actor"/>
</keyref>
</element>
222

<complexType name="useCaseType">
<sequence>
<element name="description" type="string"></element>
<element name="actors">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="1" name="actor"
type="ucm:actorType"/></sequence>
</complexType>
</element>
<element maxOccurs="1" minOccurs="0" name="precondition"
nillable="true" type="string"></element>
<element maxOccurs="1" minOccurs="0" name="postcondition"
nillable="true" type="string"></element>
<element maxOccurs="1" minOccurs="1" name="basicFlow"
type="ucm:flowOfEvents"></element>
</sequence>
<attribute name="name" type="string" use="required"></attribute>
</complexType>
<complexType name="alternativeFlowType">
<complexContent>
<extension base="ucm:flowOfEvents">
<sequence>
<element maxOccurs="1" minOccurs="1" name="branchingStep">
<complexType>
<attribute name="step" type="ucm:stepNumberType"
use="required"></attribute>
</complexType>
</element>
<element maxOccurs="1" minOccurs="1" name="condition"
type="string"></element>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="actorType">
<attribute name="name" type="string" use="required"></attribute>
</complexType>
<complexType name="flowOfEvents">
<sequence>
<sequence>
<choice maxOccurs="unbounded" minOccurs="1">
<element name="action">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="number" type="ucm:stepNumberType"
use="required"></attribute>
<attribute name="actor" type="string" use="optional">
</attribute>
</extension>
</simpleContent>
</complexType>
<unique name="UniqueStepInFlowOfEvents">
<selector xpath="."/>
<field xpath="@number"/>
</unique>
223
</element>
<element name="if">
<complexType>
<complexContent>
<attribute name="condition" type="string" use="required">
</attribute>
</extension>
</complexContent>
</complexType>
</element>
<element name="loop">
<complexType>
<complexContent>
<attribute name="condition" type="string" use="required">
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</choice>
</sequence>
<element maxOccurs="unbounded" minOccurs="0" name="alternativeFlow"
type="ucm:alternativeFlowType"></element>
</sequence>
</complexType>
<simpleType name="stepNumberType">
<restriction base="string">
<pattern value="\d(\.([a-z]+|\d))*"/>
</restriction>
</simpleType>
</schema>
224
APNDICE C MODELO AS-IS E TO-BE DO EXEMPLO DA BIBLIOTECA

A seguir so apresentados os modelos as-is e to-be do exemplo de uma biblioteca,
representado usando os metamodelos apresentados no captulo 6 e criados usando
a ferramenta apresentada na seo 6.5. Os modelos so descritos em ingls.
ingls
C.1. Modelo as-is
Nas Figuras C.1, C.2, C.3, C.4 e C.5 so apresentados os processos da biblioteca
as-is de compra e registro de livro, devoluo de livro, emprstimo de livro, cadastro
de cliente e recebimento de multa, respectivamente.
Figura C.1: Processo as-is de compra e registro de livro.
Figura C.2: Processo as-is de devoluo de

d livro.
225
Figura C.3: Processo as-is de emprstimo de livro.
Figura C.4: Processo as-is de cadastro de cliente.
226
Figura C.5: Processo as-is de recebimento de multa.
A viso motivacional da empresa apresentada nas Figuras C.6, C.7 e C.8,

enquanto que a estrutura organizacional apresentada na Figura C.9. Por fim, os
artefatos usados esto representados na Figura C.10 e a viso de ambiente fsico da
biblioteca apresentada na Figura C.11.
Figura C.6:: Parte da viso motivacional

motivacional da biblioteca, apresentando as 3 metas definidas e os
elementos relacionados a elas.
227
Figura C.7:: Parte da viso motivacional da biblioteca, enfatizando a ttica de automatizar o

emprstimo, devoluo e cadastramento de livros.
Figura C.8:: Parte da viso motivacional da biblioteca as-is, apresentando as demais tticas e suas
regras de negcio e polticas de negcio relacionadas.
Figura C.9:: A viso organizacional da biblioteca as-is.
228
Figura C.10:: Os artefatos usados pela biblioteca as-is.
Figura C.11:: O layout das instalaes da biblioteca.
C.2. Modelo to-be
Os processos to-be da biblioteca so apresentados nas Figuras C.12, C.13, C.14,

C.15 e C.16.
229
Figura C.12: Processo to-be de compra e registro de livro.
Figura C.13: Processo to-be de emprstimo de livro.
230
Figura C.14: Processo to-be de devoluo de livro.
Figura C.15: Processo to-be de cadastro de cliente.
Figura C.16: Processo to-be de recebimento de multa.
231
Como no houve mudana nas vises motivacional, organizacional e de ambiente
fsico, elas no sero representadas. A outra viso que sofreu alteraes, alm da
processual, foi a viso de documentos que apresentada na Figura C.17.
Figura C.17:: Os artefatos usados pela biblioteca to-be.
232
APNDICE D MODELO DE CASO DE USO IDEAL PARA A BIBLIOTECA

A seguir apresentado o modelo de caso de uso ideal usando a sintaxe concreta
no XML, criado para a aplicao do mtodo proposto na seo 6.4.2. Assim como o
modelo da empresa as-is e to-be, este modelo ser apresentado em ingls.
UC 1: Book registration
Description:
This use case registers a book to be used in the library.
Actor:
Librarian
Precondition:
None
Basic Flow:
1. The system requests the following information:

Whether the book can be lent, name, authors, year, edition,
and number.
2. The librarian provides the information.

3. The system prints a book card with the following information:
Code, whether the book can be lent, name, authors, year,
edition, and number.
Alternative flow:
Step 3: The librarian does not provide some information.

3.a.1. The system presents an error message and ends the use case.
Post-condition:
The book is registered in the system.
UC 2: Book loan
Description:
This use case lends a book to a member.
Actor:
Attendant
Precondition:
None
Basic Flow:
1. The attendant informs the book code.

2. The system informs that the book can be lent and the following
information:
Name, author, year, edition, and number.
and requests the member's code.
3. The attendant provides the member's code.
4. The system confirms that the book is lent.
Alternative flow:
Step 2: The book cannot be lent.

2.a.1. The system informs the book cannot be lent and the following
information about the book:
Name, authors, year, edition, and number
and ends the use case.
Step 3: The attendant cancels.
3.a.1. The system confirms the cancellation and ends the use case.
Step 4: The member has already borrowed 3 books.
4.a.1. The system informs that the member has already borrowed 3
233
books and provides the following information of each one of the
borrowed books:
Borrowed date, code, authors, and year
Step 4: The member has a debt.
4.b.1. The system informs that the member has a debt and provides
the following information for each debt:
Borrowed date, return date, code, name, authors, year, and
fine
Step 4: the member has a book overdue.
4.c.1. The system informs that there are books overdue and presents
the following information for each book overdue:
Borrowed date, code, name, authors, and year
Post-condition:
Book is lent.
UC 3: Book return
Description:
This use case receives a book which was lent to a member.
Actor:
Attendant
Precondition:
None
Basic Flow:
1. The attendant provides the book code.

2. The system provides the following information:
Member's name, borrowed date, book name, authors, year,
edition, and number
and requests a confirmation.
3. The attendant confirms the return.
4. The system informs the book is returned.
Alternative flow:
Step 2: the book is overdue.

2.a.1. The system informs the book is overdue and presents the
following information:
Member's name, borrowed date, book name, authors, year,
edition, number, and fine.
and requests a confirmation.
2.a.2. The attendant confirms the return.
2.a.3. The system informs the book is returned and ends the use
case.
Step 3: The attendant cancels the return.
3.a.1. The system ends the use case.
Step 2.a.2: The attendant cancels the return.
2.a.2.a.1. The system ends the use case.
Post-condition:
Book is returned.
234
UC4: Member registration

Description:
This use case register a member to the library.
Actor:
Attendant
Precondition:
None
Basic Flow:
1. The attendant request a member registration.

2. The system requests the following information about the member:
Name, phone, driver's license, address, city, and photo.
3. The attendant provides the information about the member.
4. The system confirms the member registration and prints the
membership card.
Alternative flow:
Step 3: The attendant does not provide some information.

3.a.1. The system presents an error message and ends the use case.
Step 4: There is already a member with this driver's license.
4.a.1. The system informs that there is already a member with this
driver's license and presents the following information about this
member:
Code, name, phone, driver's license, address, city, and photo
Post-condition:
Member without debts.
UC5: Receive payment

Description:
This use case receives fines paid by a library member.
Actor:
Accountant
Precondition:
None
Basic Flow:
1. The accountant informs the member code.

2. The system presents the member's debts for each book:
Borrowed date, return date, name, authors, year, edition,
number, and fine.
and a total. The system requests a confirmation for the payment.
3. The accountant confirms the payment.
4. The system informs the payment is confirmed.
Alternative flow:
Step 2: The member has no debt.

2.a.1. The system informs the member has no debt and ends the use
case.
Step 3: The accountant cancels the payment.
3.a.1. The system informs the payment was cancelled and ends the
use case.
Post-condition:
Member without debts.
UC 6: Member management
Description:
This use case manages member information: list, edit, and cancel
235
membership.
Actor:
Attendant
Precondition:
None
Basic Flow:
1. The attendant requests a list of all members.

2. The system presents the list of all members, providing the following
information for each member:
Code, name, phone, driver's license, address, and city.
3. The attendant cancels.
Alternative flow:
Step 3: The attendant requests to edit a member.

3.a.1. The system requests the new information for the member:
Name, phone, address, and city.
3.a.2. The attendant provides the new information about the member.
3.a.3. The system confirms the change of the member's information
Step 3.a.2: The attendant cancels the edition.
3.a.2.a.1. The system ends the use case.
Step 3: The attendant requests to cancel a membership.
3.b.1. The system cancels the membership and ends the use case.
Post-condition:
None
UC 7: Book management
Description:
This use case manages book information: list, add, edit, and delete.
Actor:
User
Precondition:
None
Basic Flow:
1. The user requests a list of all books.

2. The system presents the list of all books, providing the following
information for each book:
Name, authors, year, edition, whether the book is lent, and
return date.
3. The user cancels.
Alternative flow:
Step 2: The user is an attendant.

2.a.1. The system presents the list of all books, providing the following
information for each book:
Name, authors, year, edition, whether the book can be lent,
whether the book is lent, return date, and member who
borrowed the book.
2.a.2. The user cancels.
2.a.3. The system ends the use case.
Step 2.a.2: The attendant requests to edit a book
2.a.2.a.1. The system requests the following information about the
book:
Whether the book can be lent, name, authors, year, edition.
2.a.2.a.2. The attendant provides the information about the book.
2.a.2.a.3. The system updates the information about the book and
236
ends the use case.
Step 2.a.2.a.1: The book is lent.
2.a.2.a.1.a.1. The system informs it is not possible to update the
information about the book while it is lent and ends the use case.
Step 2.a.2.a.2: The attendant cancels.
2.a.2.a.2.a.1.The system ends the use case.
Step 2.a.2: The attendant requests to cancel a book.
2.a.2.b.1. The system cancels the book.
Step 2.a.2.b.1. The book is lent.
2.a.2.b.1.a.1. The system informs it cannot cancel a book while it is
lent.
Post-condition:
None
237
APNDICE E RESULTADO DA TRANSFORMAO PARA O EXEMPLO DA

BIBLIOTECA USANDO AS REGRAS INICIAIS
A seguir apresentado o modelo de caso de uso obtido a partir das regras iniciais,
conforme discutido na seo 6.4.2. Esse modelo emprega a sintaxe concreta em
XML e foi obtido com o apoio da ferramenta descrita na seo 6.5.
<?xml version="1.0"?>
<ucm:useCaseModel xmlns:ucm="http://www.levysiqueira.com.br/UseCaseModel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.levysiqueira.com.br/UseCaseModel
UseCase.xsd"
subject="Library Automation Software">
<actors>
<actor name="Librarian" />
<actor name="Attendant" />
<actor name="Accountant" />
</actors>
<useCase name="Book registration">
<actors>
<actor name="Librarian" />
</actors>
<basicFlow>
<action number="1" actor="Librarian">Inform book's data</action>
<action number="2">Register book</action>
<loop condition="More books?">
<action number="3.a" actor="Librarian">Inform book's data</action>
<action number="3.b">Register book</action>
</loop>
</basicFlow>
</useCase>
<useCase name="Lend books">
<actors>
</actors>
<basicFlow>
<action number="1" actor="Attendant">Inform book code</action>
<action number="2">Obtain book data</action>
<if condition="Book can be lent?">
<if condition="Has membership card?">
<action number="3.a.1" actor="Attendant">Inform membership
code</action>
<action number="3.a.2">Inform if member can borrow the
book</action>
</if>
</if>
</basicFlow>
</useCase>
<useCase name="Receive returned books">
<actors>
</actors>
<basicFlow>
<action number="1" actor="Attendant">Inform devolution</action>
<action number="2">Analyze devolution</action>
</basicFlow>
</useCase>
238
<useCase name="Member registration">
<actors>
</actors>
<basicFlow>
<action number="1" actor="Attendant">Fill member info</action>
<action number="2">Register member</action>
</basicFlow>
</useCase>
<useCase name="Receive payment">
<actors>
<actor name="Accountant" />
</actors>
<basicFlow>
<action number="1" actor="Accountant">Inform membership code</action>
<action number="2">Present values to be paid</action>
<if condition="Paid?">
<action number="3.a" actor="Accountant">Inform ticket was
paid</action>
<action number="3.b">Confirm it was paid</action>
</if>
</basicFlow>
</useCase>
</ucm:useCaseModel>
239
APNDICE F FORMATO DO CASO DE USO CRUD DA REGRA RR8

A seguir apresentado o formato do caso de uso CRUD, da regra RR8 apresentada
na Tabela 6.12. As metaclasses do metamodelo da empresa so apresentadas em
itlico, enquanto que as metaclasses do metamodelo de caso de uso so
apresentadas sublinhadas. Metainformao apresentada entre "<" e ">".
Name: "Gerenciar <nome do Artifact>"
BasicFlow:
o
Step 1: "O <nome do Actor> solicita uma lista de <nome do Artifact>.".
Step 2: "O <nome do sistema> apresenta a seguinte informao para cada

<nome do Artifact>: <Fields selecionados>.".
Step 3: "O <nome do Actor> termina o caso de uso.".
AlternativeFlow:
o
Condition: "O <nome do Actor> solicita a criao de um <nome do Artifact>.".
BranchingStep: o Step 3 do BasicFlow.
Step 1: "O <nome do sistema> solicita as seguintes dados: <nome do

Artifact>.".
Step 2: "O <nome do Actor> informa os dados solicitados.".
Step 3: "O <nome do sistema> cria um novo <nome do Artifact>.".
AlternativeFlow:
o
Condition: "O <nome do Actor> solicita a edio de um <nome do Artifact>.".
Step 1: "O <nome do sistema> solicita as seguintes dados: <Fields

selecionados>.".
Step 2: "O <nome do Actor> informa os dados solicitados.".
Step 3: "O <nome do sistema> atualiza o <nome do Artifact>.".
AlternativeFlow:
o
Condition: "O <nome do Actor> solicita a remoo de um <nome do

Artifact>.".
Step 1: "O <nome do sistema> solicita uma confirmao para remover.".
Step 2: "O <nome do Actor> confirma a remoo.".
Step 3: "O <nome do sistema> remove o <nome do Artifact>.".
240
APNDICE G CRITRIOS PARA AVALIAO DE CASOS DE USO

Baseado nos fatores de qualidade propostos em (PHALP; VINCENT; COX, 2007),
na Tabela G.1 so apresentados os critrios objetivos para avaliao de cada um
desses fatores (os critrios para os fatores faixa e escopo exigem um gabarito).
Esses critrios foram usados para a avaliao dos casos de uso usados no
experimento descrito no captulo 7. Maiores detalhes sobre a criao desses
critrios so apresentados na seo 7.2.4.
Tabela G.1: Critrios para avaliao de casos de uso para cada um dos fatores propostos em
(PHALP; VINCENT; COX, 2007).
Fator
Faixa
Escopo
Ordem do texto
Dependncias
Critrio
Nota
Faltou nome do caso de uso
0,25
Nome do caso de uso impreciso
0,1
Faltou ator
0,25
Nome do ator impreciso/indefinido
0,1
Faltou passo
0,25
Agente invertido no passo
0,1
Passo est incompleto/impreciso
0,1
Faltou agente no passo
0,1
Faltou fluxo alternativo
0,25
Condio do fluxo alternativo est imprecisa
0,1
Passo junto com condio
0,1
Faltou ps-condio
0,25
Ps-condio imprecisa
0,1
Faltou pr-condio
0,25
Pr-condio imprecisa
0,1
Agente a mais
0,25
Passo com informao a mais
0,1
Passo a mais
0,1
Fluxo alternativo a mais
0,25
Pr-condio a mais
0,25
Ps-condio a mais
0,25
Ps-condio com informao a mais
0,1
Nome do caso de uso com informaes a mais
0,1
Passo fora de ordem
0,1
Passos seguidos de um agente
0,1
Fluxo no tem final
0,25
Final do fluxo inadequado
0,25
241
Fator
Critrio
Pr-condio muito restritiva
Resposta racional
Coerncia
Consistncia de abstrao
No considera o sistema
Sequncia
0,1
1
No est claro como informao obtida
0,25
Sentena no passo no repete substantivo ou frase

anterior
0,1
Detalhes de interface
0,1
Detalhes de implementao
0,1
Passo ou condio abstrata demais
0,25
Faltam detalhes na pr/ps-condio
0,25
Detalhes do negcio
0,1
Detalhes de outro agente
0,1
Fluxo bsico no considera o sistema
Variaes
Nota
Fluxo alternativo considera detalhes do negcio
0,5
Fluxo alternativo junto com o bsico
0,25
Passo do fluxo bsico como fluxo alternativo
0,5
Fluxo alternativo junto com outro fluxo alternativo
0,25
Numerao no em sequncia
0,1
Lao no diferenciado na numerao
0,25
Criao de subitem desnecessria
0,1
Criao de subitem errada
0,1
Faltou definir subitem (condio como ao)
0,25
Voz passiva
0,1
Futuro
0,1
Passado
0,1
Modais
0,1
Consistncia de gramtica Adjetivos
0,1
Advrbio
0,1
Pronomes
0,1
Sinnimos
0,1
Negativas
0,1
Separao
Viabilidade
Numerao
Existe seo em separado para fluxo alternativo
Alternativa invivel
0,5
Alternativa no faz sentido
0,5
Alternativa no detalhada
0,25
Passo do fluxo alternativo no segue numerao do

fluxo alternativo
0,1
Fluxo alternativo para passo incorreto
0,25
Ponto de ramificao no claro
0,25
242
APNDICE H QUESTIONRIOS APLICADOS NO EXPERIMENTO

A seguir so apresentadas as questes dos dois questionrios aplicados aos
sujeitos do experimento. O questionrio inicial foi aplicado antes da realizao do
experimento e forneceu dados para randomizar parte dos sujeitos. O questionrio
final foi usado para analisar qualitativamente a validade e a vantagem de usar a
transformao, conforme descrito na seo 7.2.
H.1. Questionrio Inicial
I - Engenharia de Requisitos
1. Com qual frequncia voc participa de atividades de Engenharia de Requisitos
(elicitao de requistos, anlise e negociao, documentao e verificao e
validao dos requisitos)?
(a) nunca
(b) raramente
(c) s vezes
(d) frequentemente
(e) sempre
2. Como voc avalia o seu conhecimento de Engenharia de Requisitos?

(a) nulo
(b) sofrvel
(c) razovel
(d) bom
(e) excelente
II Casos de Uso
3. Com qual frequncia voc redige e/ou l casos de uso?
(a) nunca
(b) raramente
(c) s vezes
(d) frequentemente
(e) sempre
4. Como voc avalia o seu conhecimento sobre casos de uso?

(a) nulo
(b) sofrvel
(c) razovel
(d) bom
(e) excelente
III Processo de negcio

5. Com qual frequncia voc redige e/ou l diagramas de processo de negcio?
(a) nunca
(b) raramente
(c) s vezes
(d) frequentemente
(e) sempre
6. Como voc avalia o seu conhecimento de BPMN (Business Process Modeling

Notation)?
(a) nulo
(b) sofrvel
(c) razovel
(d) bom
(e) excelente
IV Outras
7. Voc j trabalhou em um banco?
(a) nunca
(b) faz mais de 10 anos (c) faz entre 10 e 5 anos (d) faz menos de 5 anos (e) trabalho atualmente
8. Voc desenvolve ou j desenvolveu (mesmo que em um exerccio ou prova) um

software para uma ATM (Automated Teller Machine)?
(a) nunca (b) faz mais de 10 anos (c) faz entre 10 e 5 anos (d) faz menos de 5 anos (e) fao atualmente
243
9. Voc desenvolve ou j desenvolveu (mesmo que em um exerccio ou prova) um
software para uma locadora de filmes?
(a) nunca (b) faz mais de 10 anos (c) faz entre 10 e 5 anos (d) faz menos de 5 anos (e) fao atualmente
H.2. Questionrio final
I Modelo da empresa
1. Os modelos de empresa (representando o processo, os documentos e os
participantes) ajudaram a gerar o caso de uso?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
2. O modelo da empresa atual (sem o sistema) til para a criao do caso de

uso?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
3. O modelo da empresa com o sistema (desejado) til para a criao do caso de

uso?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
4. Alguma informao dos modelos de empresa atrapalhou a criao do caso de

uso?
(a) no
(b) sim
Se sim, quais?
5. Em um projeto real voc criaria os modelos de empresa antes de gerar o caso de

uso?
(a) nunca
(b) raramente
(c) s vezes
(d) frequentemente
(e) sempre
II Caso de uso
6. O caso de uso preliminar (entregue como anexo) ajudou a criar o caso de uso?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
7. O fluxo principal do caso de uso preliminar ajudou a definir o fluxo principal do

caso de uso gerado?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
8. Os atores do caso de uso preliminar ajudaram a identificar os atores do caso de

uso gerado?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
9. Os fluxos alternativos do caso de uso preliminar ajudaram a definir os fluxos

alternativos do caso de uso gerado?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
244
10. As pr-condies do caso de uso preliminar ajudaram a identificar as prcondies do caso de uso gerado?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
11. As ps-condies do caso de uso preliminar ajudaram a identificar as pscondies do caso de uso gerado?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
12. O caso de uso preliminar atrapalhou a criao do caso de uso?

(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
13. Voc acha que o emprego do caso de uso preliminar ajudou a obter um caso de
uso de maior qualidade?
(a) no
(b) pouco
(c) mais ou menos
(d) razoavelmente
(e) sim
245
APNDICE I ENUNCIADOS DOS EXERCCIOS USADOS NO EXPERIMENTO

Para cada escopo do projeto (ATM e Locadora) usado no experimento, existem dois
tipos de enunciados: para a criao do caso de uso e para a criao do modelo as-is
e to-be. Os sujeitos realizando o tratamento Diretamente apenas utilizam o
enunciado para criao do caso de uso, enquanto que os demais tratamentos usam
primeiramente, na fase 1, o enunciado para a criao do modelo as-is e to-be e
posteriormente, na fase 3, o enunciado para a criao do caso de uso. Uma vez que
a fase 1 do experimento igual para os sujeitos realizando a tcnica Modelo da
Empresa e Transformao, o enunciado deles igual. Em contraposio, o
enunciado para a criao do caso de uso apresenta um pargrafo a mais para as
tcnicas Modelo da Empresa e Transformao (nos tratamentos da tcnica
Diretamente no h o pargrafo). Dessa forma, o pargrafo para cada tratamento
apresentado usando [Modelo da Empresa] ou [Transformao].
Nas sees I.1, I.2, I.3, I.4 so apresentados cada um dos tipos de enunciados para
cada um dos escopos de projeto. Por fim, os enunciados de criao do modelo da
empresa as-is e to-be possuem uma legenda e observaes que so comuns para
os dois escopos. Essas informaes so apresentadas na seo I.5.
I.1.
Criao do caso de uso para a ATM
Um pequeno banco deseja construir uma ATM (Automated Teller Machine) que deve
automatizar parte de seus processos. Voc deve escrever o caso de uso para o
saque de dinheiro dessa nova mquina (apenas 1 caso de uso), representando
tanto os fluxos principais e alternativos. Considere como escopo desse caso de uso
a mquina como um todo, incluindo o hardware e o software por ela usado.
Um engenheiro de requisitos levantou alguns requisitos junto s partes envolvidas.
O sistema (a ATM) dever ter um servio de saque que atender a apenas ao
banco. Para sacar, o cliente dever inserir o seu carto e informar a senha. Caso o
carto e a senha sejam validados pelo banco (atravs de uma comunicao usando
a rede), o cliente dever ento informar o valor a ser sacado. Alm de entregar o
dinheiro, o sistema dever sempre imprimir um recibo para o cliente. Considere que
246
o sistema dever contatar via rede o banco para permitir ou no o saque do dinheiro
solicitado. Alm disso, o sistema dever bloquear o carto do cliente caso o cliente
informe a senha incorreta por 3 vezes consecutivas.
[Modelo da Empresa] Considerando esse contexto, criaram-se os modelos de
empresa apresentados em anexo, tratando do ambiente atual e do ambiente
desejado com o sistema. Use essas informaes para gerar o caso de uso.
[Transformao] Considerando esse contexto, criaram-se os modelos de empresa
apresentados em anexo, tratando do ambiente atual e do ambiente desejado com o
sistema. Uma ferramenta tambm gerou um caso de uso preliminar, apresentado no
outro anexo. Use essas informaes para gerar o caso de uso.
Para redigir o caso de uso, considere apenas os seguintes elementos do caso de
uso:
I.2.
Nome do caso de uso

Atores
Pr-condies
Fluxo bsico
Fluxos alternativos
Ps-condies
Criao do modelo as-is e to-be para a ATM
Um pequeno banco deseja construir uma ATM (Automated Teller Machine) que deve
automatizar parte de seus processos. Atualmente, sem a existncia da ATM, o
cliente deve ir para um dos caixas para sacar dinheiro. O caixa solicita o carto do
banco e um documento de identificao do cliente. Caso o carto no seja do banco,
ou a pessoa que deseja sacar no seja o titular do carto, o caixa deve avisar o
cliente que no pode realizar a operao, terminando o processo. Caso contrrio, o
caixa acessa o sistema bancrio e verifica se o carto vlido e se a conta est
ativa. O caixa ento pergunta para o cliente a quantia a ser sacada. O caixa verifica
em sua gaveta se h o dinheiro solicitado disponvel e, caso haja, informa ao
sistema a retirada do valor solicitado. Caso o sistema informe que no possvel
realizar o saque solicitado, o caixa avisa o cliente e termina o processo. Se for
possvel realizar o saque, o caixa ento imprime um recibo, informando o valor
247
sacado, o cdigo do caixa, o nmero da transao e a data do saque. O caixa ento
entrega o dinheiro e o recibo ao cliente, terminando o processo. Caso no haja
dinheiro suficiente na gaveta, o caixa deve informar ao cliente que no pode realizar
a transao e termina o processo.
Para a ATM, um engenheiro de requisitos levantou alguns requisitos junto s partes
envolvidas. O sistema (a ATM) dever ter um servio de saque que atender a
apenas ao banco. Para sacar, o cliente dever inserir o seu carto e informar a
senha. Caso o carto e a senha sejam validados pelo banco (atravs de uma
comunicao usando a rede), o cliente dever ento informar o valor a ser sacado.
Alm de entregar o dinheiro, o sistema dever sempre imprimir um recibo para o
cliente. Considere que o sistema dever contatar via rede o banco para permitir ou
no o saque do dinheiro solicitado. Alm disso, o sistema dever bloquear o carto
do cliente caso o cliente informe a senha incorreta por 3 vezes consecutivas.
Considerando esse contexto, voc deve representar as seguintes informaes da
empresa considerando apenas o processo de saque de dinheiro:
(1) A empresa envolvida no saque de dinheiro considerando o ambiente antes do
sistema:
a. Represente o processo de saque de dinheiro usando a notao BPMN.
b. Para cada participante do processo, descreva (textualmente) a sua
responsabilidade principal.
c. Represente textualmente o nome e o contedo (apenas os campos) dos
documentos em papel, cartes e recibos usados.
(2) A empresa envolvida no saque de dinheiro considerando o ambiente com o
sistema (siga o mesmo contexto da empresa antes do sistema):
a. Represente o processo de saque de dinheiro usando a notao BPMN.
248
I.3.
Criao do caso de uso para a locadora
Uma pequena locadora de filmes deseja construir um sistema que deve automatizar
parte de seus processos, incluindo o aluguel e a devoluo de filmes. Voc deve
escrever o caso de uso para o aluguel de filmes (apenas 1 caso de uso) desse
novo sistema, representando tanto os fluxos principais e alternativos.
Atualmente, sem a existncia do sistema, o atendente realiza todas as tarefas
manualmente. Um cliente que deseja alugar filmes informa ao atendente o seu nome
e o atendente obtm a ficha de registro do cliente. Essa ficha possui as seguintes
informaes: o nome do cliente, o endereo do cliente e, para cada filme alugado, o
nome do filme, se foi pago, a data de emprstimo, a data de devoluo e a data em
que ele foi devolvido. Caso o cliente no tenha uma ficha, ele no poder realizar o
aluguel. O atendente verifica nessa ficha se o cliente possui alguma pendncia e,
caso o cliente possua, ele no permite o aluguel dos filmes. No havendo
pendncias, para cada filme o atendente registra na ficha a data de emprstimo e o
cdigo do filme. O atendente tambm deve garantir que o cliente s tem 3 filmes
alugados por vez. Uma vez que todos os filmes foram registrados, o atendente ento
calcula o valor total e a data de devoluo. Havendo o pagamento, o atendente
confirma o pagamento na ficha de registro. Se o cliente desejar, ele pode pagar na
devoluo.
Para o novo sistema, um engenheiro de requisitos levantou alguns requisitos junto
s partes envolvidas. O sistema dever ter um servio de aluguel de filmes que
funcionar apenas para clientes cadastrados (que possuem um nmero de cliente) e
que no tenham pendncias. O atendente deve informar o cdigo de cada filme,
sendo que o sistema deve apresentar os dados do filme. Aps todos os filmes serem
informados, o sistema dever apresentar o valor total a ser pago e calcular a data de
devoluo dos filmes. Apesar de o sistema no ter funcionalidades de pagamento, o
sistema deve registrar que o pagamento foi efetuado, sendo assim necessria uma
confirmao do atendente. Uma outra restrio que o sistema s dever permitir o
aluguel de 3 filmes por cliente.
249
[Modelo da Empresa] Considerando esse contexto, criaram-se os modelos de
empresa apresentados em anexo, tratando do ambiente atual e do ambiente
desejado com o sistema. Use essas informaes para gerar o caso de uso.
[Transformao] Considerando esse contexto, criaram-se os modelos de empresa
apresentados em anexo, tratando do ambiente atual e do ambiente desejado com o
sistema. Uma ferramenta tambm gerou um caso de uso preliminar, apresentado no
outro anexo. Use essas informaes para gerar o caso de uso.
Para redigir o caso de uso, considere apenas os seguintes elementos do caso de
uso:
I.4.
Nome do caso de uso

Atores
Pr-condies
Fluxo bsico
Fluxos alternativos
Ps-condies
Criao do modelo as-is e to-be para a locadora
Uma pequena locadora de filmes deseja construir um sistema que deve automatizar
parte de seus processos, incluindo o aluguel e a devoluo de filmes. Atualmente,
sem a existncia do sistema, o atendente realiza todas as tarefas manualmente. Um
cliente que deseja alugar filmes informa ao atendente o seu nome e o atendente
obtm a ficha de registro do cliente. Essa ficha possui as seguintes informaes: o
nome do cliente, o endereo do cliente e, para cada filme alugado, o nome do filme,
se foi pago, a data de emprstimo, a data de devoluo e a data em que ele foi
devolvido. Caso o cliente no tenha uma ficha, ele no poder realizar o aluguel. O
atendente verifica nessa ficha se o cliente possui alguma pendncia e, caso o cliente
possua, ele no permite o aluguel dos filmes. No havendo pendncias, para cada
filme o atendente registra na ficha a data de emprstimo e o cdigo do filme. O
atendente tambm deve garantir que o cliente s tem 3 filmes alugados por vez.
Uma vez que todos os filmes foram registrados, o atendente ento calcula o valor
total e a data de devoluo. Havendo o pagamento, o atendente confirma o
pagamento na ficha de registro. Se o cliente desejar, ele pode pagar na devoluo.
250
Para o novo sistema, um engenheiro de requisitos levantou alguns requisitos junto
s partes envolvidas. O sistema dever ter um servio de aluguel de filmes que
funcionar apenas para clientes cadastrados (que possuem um nmero de cliente) e
que no tenham pendncias. O atendente deve informar o cdigo de cada filme,
sendo que o sistema deve apresentar os dados do filme. Aps todos os filmes serem
informados, o sistema dever apresentar o valor total a ser pago e calcular a data de
devoluo dos filmes. Apesar de o sistema no ter funcionalidades de pagamento, o
sistema deve registrar que o pagamento foi efetuado, sendo assim necessria uma
confirmao do atendente. Uma restrio que o sistema s dever permitir o
aluguel de 3 filmes por cliente.
Considerando esse contexto, voc deve representar as seguintes informaes da
empresa considerando apenas o processo de aluguel de filmes:
(1) A empresa envolvida no aluguel de filmes considerando o ambiente antes do
sistema:
a. Represente o processo de aluguel de filmes usando a notao BPMN.
(2) A empresa envolvida no aluguel de filmes considerando o ambiente com o
sistema (siga o mesmo contexto da empresa antes do sistema):
a. Represente o processo de aluguel de filmes usando a notao BPMN.
I.5.
Legenda
Para representar o processo de negcio, use a notao definida pelo BPMN:
251
Conceito
Representao (BPMN)
Evento inicial
Evento final
Atividade/Tarefa
Pontos de deciso (condio) indique a condio
Nome do
Partici pante
Sequncia entre atividades/tarefas

Participante
Mensagem entre atividades de participantes

diferentes
Artefato (documentos, cartes e recibos)
Uso do artefato
Observaes:
Represente
cada
pessoa/sistema
envolvido
no
processo
como
um
participante diferente.
No represente detalhes do funcionamento do sistema. Crie apenas 1

atividade no sistema por troca de mensagem com outro participante.
Se possvel e apropriado, use o mesmo nome para as atividades do processo

antes do sistema e com o sistema.
252
APNDICE J GABARITOS USADOS NO EXPERIMENTO

A seguir so apresentados os gabaritos dos casos de uso da locadora (seo J.1) e
da ATM (seo J.2), usados pelo experimento, seguindo a sintaxe concreta no
XML. Esses gabaritos so necessrios para alguns dos critrios de avaliao da
qualidade dos casos de uso.
J.1.
Alugar filme
Descrio:
Permite que o atendente alugue filmes para um cliente.
Atores:
Atendente
Pr-condio:
No h.
Fluxo bsico:
1. O Atendente informa o nmero do cliente.

2. Enquanto houver mais filmes e o nmero de filmes alugados for
menor que 3:
a. O Sistema solicita o cdigo do filme.
b. O Atendente informa o cdigo do filme.
c. O Sistema apresenta o nome do filme e o preo do aluguel.
3. O Atendente finaliza o aluguel.
4. O Sistema apresenta o valor total, a data de devoluo e solicita a
confirmao do pagamento.
5. O Atendente confirma o pagamento.
O Sistema confirma o aluguel.
Fluxo alternativo: Passo 2: O nmero do cliente invlido ou o cliente est inativo.

2.a.1. O sistema informa que o nmero do cliente invlido e
termina o caso de uso.
Passo 2: O cliente possui pendncias.
2.a.1. O sistema informa que no possvel alugar o filme e
Passo 2.c: O cdigo do filme invlido ou o filme no foi devolvido.
2.c.1.a. O sistema informa que no possvel alugar o filme e
retorna ao passo 2.a.
Passo 3: O Atendente cancela o aluguel.
3.a.1. O sistema confirma o cancelamento e termina o caso de
uso.
Passo 5: O Atendente no confirma o pagamento.
5.a.1. O sistema cancela o aluguel e termina o caso de uso.
Ps-condio:
J.2.
No h.
Sacar dinheiro
Descrio:
Permite que o cliente saque dinheiro no ATM.
Atores:
Cliente e banco
253
Pr-condio:
O sistema possui dinheiro a ser sacado.

O sistema possui papel para imprimir o recibo.
O sistema estar conectado rede.
Fluxo bsico:
1. O cliente solicita saque de dinheiro.

2. O sistema solicita o carto do cliente.
3. O cliente insere o carto.
4. O sistema solicita a senha.
5. O cliente informa a senha.
6. O sistema contata o banco e a informa o cdigo do carto e a senha.
7. O banco confirma a informao.
8. O sistema solicita o valor em dinheiro a ser sacado.
9. O cliente informa o valor.
10. O sistema solicita a retirada do valor informado ao banco.
11. O banco confirma a retirada do dinheiro.
12. O sistema disponibiliza o dinheiro e emite um recibo da transao
com as seguintes informaes:
a. Data do saque.
b. O cdigo de aprovao do banco.
O valor sacado.
Fluxo alternativo:
Ps-condio:
Passo 4: O carto est bloqueado.

4.a.1. O sistema informa que o carto est bloqueado e termina o
caso de uso.
Passo 4: O carto no do banco.
4.b.1. O sistema informa que o carto no do banco e termina o
caso de uso.
Passo 6: Problema de conexo com o banco.
6.a.1. O sistema informa que h um problema de conexo e
Passo 7: A senha informada incorreta.
7.a.1. O sistema solicita que a senha seja informada novamente,
voltando ao passo 4.
Passo 7.a.1: Problema na 3 tentativa de informar a senha (senha
incorreta).
7.a.1.a.1. O sistema bloqueia o carto e termina o caso de uso.
Passo 10: O ATM no possui o valor solicitado.
10.a.1. O sistema informa que no possui o valor solicitado e
pergunta por um novo valor, retornando ao passo 9.
Passo 11: O banco negou a retirada do dinheiro.
11.a.1. O sistema informa que o valor solicitado no pode ser
retirado e volta ao passo 9.
No h.
254
APNDICE K RESULTADOS DOS EXPERIMENTOS

Na Tabela K.1 so apresentadas as respostas do questionrio inicial para cada um
dos sujeitos. Os sujeitos 26, 27, 28 e 29 foram desconsiderados, seja porque
faltaram a uma fase do experimento (27 e 29) ou porque no conseguiram criar o
modelo da empresa no tempo determinado (26 e 28). Mais detalhes sobre isso so
apresentados na seo 7.3.
Tabela K.1: Respostas ao questionrio inicial.
Sujeito Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9
1
2
3
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Na Tabela K.2 so apresentadas as notas dos sujeitos do experimento para cada

um dos fatores de qualidade considerados: faixa, escopo, ordem do texto,
dependncias, resposta racional, coerncia, consistncia de abstrao, variaes,
sequncia, consistncia de gramtica, separao, viabilidade e numerao.
Locadora
ATM
Escopo
1
2
Diretamente
3
4
5
6
Modelo de
7
empresa
8
9
10
11
Transf.
12
13
Mdia
14
15
Diretamente
16
17
18
19
Modelo de
20
empresa
21
22
23
Transf.
24
25
Mdia
Tratamento Sujeito
Faixa
3,70
3,90
3,25
2,90
4,00
4,05
3,25
3,45
3,55
2,75
4,00
2,90
3,50
3,48
4,05
4,00
4,55
3,70
4,15
4,00
4,65
4,30
4,25
4,65
4,30
3,45
4,27
Convencimento
Esc. Ord. tex. Depen. Resp.

4,20
5,00
4,00
5,00
3,75
4,80
4,10
5,00
4,80
5,00
4,55
5,00
4,75
5,00
3,85
5,00
4,20
4,70
4,25
5,00
3,90
4,90
4,50
4,90
4,25
5,00
5,00
5,00
4,50
5,00
4,20
5,00
4,25
5,00
4,70
5,00
4,25
5,00
4,35
5,00
4,55
5,00
3,90
5,00
4,75
5,00
4,90
4,75
4,65
5,00
4,70
5,00
4,37
4,95
4,38
4,97
4,20
5,00
4,90
5,00
4,50
5,00
4,70
5,00
4,25
5,00
4,80
5,00
3,35
5,00
3,90
4,75
4,75
5,00
4,50
5,00
5,00
5,00
5,00
5,00
4,35
5,00
3,70
5,00
4,55
5,00
4,60
4,75
4,05
5,00
4,80
5,00
3,60
5,00
4,65
5,00
4,50
4,90
4,50
5,00
4,75
5,00
5,00
5,00
4,30
4,98
4,54
4,96
Cobertura
4,80
4,80
4,50
5,00
4,80
4,60
5,00
4,50
4,80
4,30
4,80
5,00
4,70
4,74
4,80
4,70
4,60
3,90
4,80
4,70
4,30
5,00
5,00
4,30
4,70
4,50
4,63
Coer.
Cons. de Cons. de estrut. Cons. de

abstr.
Variao Sequ. gram.
4,20
4,75
4,90
4,90
4,65
5,00
5,00
4,30
4,55
4,75
5,00
4,70
4,15
5,00
5,00
4,80
4,45
5,00
5,00
4,60
4,55
4,75
5,00
4,60
4,80
5,00
5,00
4,50
4,45
5,00
4,75
4,80
4,30
5,00
4,75
4,40
4,45
5,00
5,00
4,90
4,65
5,00
4,70
4,90
4,40
5,00
5,00
4,60
4,40
5,00
5,00
5,00
4,46
4,94
4,93
4,69
4,25
5,00
5,00
4,70
4,90
5,00
4,75
5,00
4,75
5,00
4,75
4,50
3,50
5,00
4,75
4,40
4,50
5,00
5,00
4,90
4,80
5,00
4,75
5,00
4,30
5,00
4,50
4,60
4,75
5,00
5,00
5,00
4,15
5,00
5,00
4,50
4,50
5,00
4,90
4,70
4,65
5,00
4,75
4,60
4,50
5,00
5,00
4,90
4,48
5,00
4,86
4,72
Sep.
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
5,00
Total
Viab. Num.
5,00 5,00 60,45
5,00 5,00 60,30
5,00 5,00 61,10
5,00 5,00 60,45
4,75 4,75 60,50
5,00 5,00 60,75
5,00 5,00 61,80
5,00 5,00 60,65
5,00 5,00 60,75
5,00 4,75 59,75
5,00 4,75 61,25
5,00 5,00 61,30
5,00 5,00 61,95
4,98 4,94 60,85
5,00 4,50 61,40
5,00 5,00 62,55
5,00 5,00 62,20
5,00 4,25 56,50
5,00 5,00 62,60
5,00 4,90 63,15
5,00 5,00 60,40
5,00 5,00 62,95
5,00 4,00 60,75
5,00 5,00 61,30
5,00 5,00 61,90
5,00 5,00 62,10
5,00 4,83 61,57
Cons. de alt.
255
Tabela K.2: Notas para cada um dos fatores de qualidade.
256
As respostas dadas no questionrio final pelos sujeitos dos tratamentos com a
tcnica transformao so apresentadas na Tabela K.3. Uma vez que a nota do
sujeito 10 foi considerada um valor atpico, as respostas dele foram evidenciadas e
desconsideradas na anlise realizada. Um outro detalhe que o sujeito 24 no
respondeu uma das questes, a Q10.
Tabela K.3: Respostas do questionrio final.
Escopo Sujeito
10
11
ATM
12
13
23
Locadora 24
25
Q1
e
e
e
e
a
e
e
Q2
e
c
e
e
a
c
b
Q3
e
d
e
e
a
e
e
Q4
a
a
a
a
a
a
a
Q5
c
d
e
e
c
e
e
Q6
e
d
e
d
a
e
e
Q7
e
d
e
d
a
e
e
Q8
e
e
e
e
b
e
e
Q9
e
e
e
d
a
a
e
Q10
d
e
e
c
a
Q11
b
d
b
a
a
a
a
a
Q12
a
a
b
a
a
a
a
Q13
e
d
e
e
a
e
e

Transformação de Um Modelo de Empresa em Um Modelo de Casos de Uso Seguindo Os Conceitos de Engenharia Dirigida Por Modelos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transformação de Um Modelo de Empresa em Um Modelo de Casos de Uso Seguindo Os Conceitos de Engenharia Dirigida Por Modelos

Uploaded by

Copyright:

Available Formats

FBIO LEVY SIQUEIRA

TRANSFORMAO DE UM MODELO DE EMPRESA EM UM

FBIO LEVY SIQUEIRA

TRANSFORMAO DE UM MODELO DE EMPRESA EM UM

Siqueira, Fbio Levy

LISTA DE ABREVIATURAS E SIGLAS

Atlas Transformation Language

Business Motivation Model

Business Process Definition Metamodel

Business Process Modeling Notation

Business Strategy, Context, and Process

Computation Independent Model

Document Type Definition

Enterprise Knowledge Development

Eclipse Modeling Framework

Graphical Modeling Framework

Knowledge Acquisition in Automated Specification ou Keep All Objectives

Arquitetura Dirigida por Modelos (Model Driven Architecture)

Engenharia Dirigida por Modelos (Model Driven Engineering)

Meta Object Facility

Organizao e Mtodos (ou Organizao, Sistemas e Mtodos)

Object Constraint Language

Platform Independent Model

Platform Specific Model

The Open Group Architecture Framework

Espao Tcnico (ou Espao Tecnolgico) (Technical Space)

Unified Modeling Language

World, Requirement, Specification, Platform e Machine

XML Metadata Interchange

Linguagem de Marcao Extensvel (Extensible Markup Language)

Extensible Stylesheet Language Transformations

REPRESENTAO DE UMA EMPRESA ......................................................................... 9

REQUISITO, ESPECIFICAO E SUAS REPRESENTAES ........................................... 18

ENGENHARIA DIRIGIDA POR MODELOS (MDE).......................................................... 56

MODELO DA EMPRESA E A TRANSFORMAO DE REQUISITOS EM ESPECIFICAES..... 69

TRANSFORMAO DO MODELO DA EMPRESA EM MODELO DE CASO DE USO ............. 100

CONCLUSO ....................................................................................................... 191

REFERNCIAS ........................................................................................................... 196

DA TRANSFORMAO PARA O EXEMPLO DA BIBLIOTECA

APNDICE F FORMATO DO CASO DE USO CRUD DA REGRA RR8 ............................ 239

Uma das principais responsabilidades da Engenharia de Requisitos levantar o que

Dada a importncia da obteno das especificaes a partir dos requisitos, o

Definir metamodelos de empresa e de casos de uso;

Propor regras para a transformao; e

Construir uma ferramenta.

Os metamodelos permitem descrever os modelos de entrada e de sada da

Existem diversos trabalhos que propem abordagens para a obteno das

especificaes. Trabalhos como (DIETZ, 2003), (DIJKMAN; JOOSTEN, 2002a),

transformaes de uma representao do ambiente atual em um modelo dos

A transformao de requisitos em especificaes proposta considera apenas os

Automatizam processos de negcio, com foco no fluxo de trabalho; e

So internos a uma empresa, mas podem possuir algumas interfaces com

Essas caractersticas permitem simplificar a transformao, seja ao facilitar a criao

1.5 Hipteses consideradas

A transformao de requisitos em especificaes proposta por este trabalho

Para atingir os objetivos propostos aplicou-se um mtodo hipottico-dedutivo,

Figura 1.1: Mtodo empregado para a realizao da tese.

A partir do objetivo, foram definidos os metamodelos que servem de base para a

1.7 Organizao do trabalho

Captulo 2 Representao de uma empresa: define o que empresa para

Captulo 3 Requisito, especificao e suas representaes: apresenta

Captulo 4 Engenharia dirigida por modelos (MDE): apresenta as linhas

Captulo 5 Modelo da empresa e a transformao de requisitos em