UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

PROGRAMA DE PS-GRADUAO EM INFORMTICA

UMA ABORDAGEM PARA IDENTIFICAO E REPRESENTAO DOS

INTERESSES TRANSVERSAIS NA ARQUITETURA EMPRESARIAL

Fabiana Jack Nogueira Santos

Orientadora
Flvia Maria Santoro
Co-orientadora
Claudia Cappelli

RIO DE JANEIRO, RJ BRASIL

JUNHO DE 2012

RIO DE JANEIRO, RJ BRASIL

JUNHO DE 2012

JUNHO DE 2012

S237

Santos, Fabiana Jack Nogueira.

Uma abordagem para identificao e representao dos interesses transversais na arquitetura empresarial / Fabiana Jack Nogueira Santos, 2012.
190f. ; 30 cm
Orientador: Flvia Maria Santoro.
Coorientador: Claudia Cappelli.
Dissertao (Mestrado em Informtica) Universidade Federal do
Estado do Rio de Janeiro, Rio de Janeiro, 2012.
1. Arquitetura empresarial. 2. Modularidade. 3. Interesses transversais.
4. Metodologia DEMO. 5. Abordagem orientada a aspecto. I. Santoro, Flvia Maria. II. Cappelli, Claudia. III. Universidade Federal do Estado do Rio
de Janeiro. Centro de Cincias Exatas e Tecnologia Curso de Mestrado em
Informtica. IV. Ttulo.
CDD 005.32

 minha me Maria Aparecida e ao meu marido Alexandre

por todo amor e apoio incondicionais.

AGRADECIMENTOS
Agradeo Deus por guiar todos os passos de minha vida, ench-la de oportunidades e
pessoas espetaculares e permitir que mais essa etapa fosse concluda. Agradeo ao pai que
tive e ME maravilhosa que tenho, a quem devo os mais sinceros agradecimentos por tudo
que sempre fez e faz por mim. O grande incentivador de toda essa jornada, meu marido e
companheiro que muito admiro Alexandre, no s incentivou, mas participou ativamente do
curso sempre que precisei. Alm disso, me ajuda a ver que a vida no perfeita, mas que
ainda assim podemos ser muito felizes. Obrigada por tudo!
Aventurar-me pelo mestrado s foi se tornando uma possibilidade para mim graas
muitas conversas com o Professor Sean Siqueira, a quem devo muita gratido por ter me
apresentado esse mundo, at ento, desconhecido. Ningum disse que seria fcil, mas cada
instante valeu muito a pena.
Agradeo imensamente minhas queridas orientadora e co-orientadora Flvia e Cludia,
pessoas pelas quais tenho muito carinho e admirao. Vocs foram minhas grandes guias,
foram mestras e muito pacientes nessa longa jornada, no tenho palavras para agradecer tudo
que vivi, aprendi e por ter conseguido, com a ajuda de vocs, concluir essa empreitada.
Agradeo ao NP2Tec por ter me aceitado como membro e me acolhido de braos
abertos. Aprendi muito com todos e tenho muito carinho por vocs. O mestrado e o NP2Tec
me trouxeram a oportunidade mpar de trabalhar com pesquisa e conhecer os professores Tas
Batista e Jlio Leite que me ensinam muito a cada contato. Agradeo imensamente a vocs
por tudo que aprendi.
Durando o curso estive com grandes pessoas que me acompanharam, algumas desde a
graduao, e sero eternamente amigas: Dbora, Priscila, Luiza, Mnica, Talita e Juliana
Frana. Agradeo tambm a todos os meus amigos e familiares que direta ou indiretamente
estiveram presentes nessa jornada ao meu lado.
Agradeo a todos os meus professores da graduao que me ensinaram muito e esto
sempre com uma palavra amiga quando os encontro pelos corredores, alguns estiveram
presentes no mestrado, outros no, mas todos vocs so especiais para mim: Fernanda,
Renata, Leila, Lo, Luiz Monte, Amncio, Mrcio e Tanaka. Obrigada a todos os meus
professores do mestrado que enriqueceram essa experincia. Agradeo tambm Erclia,
Alessandra, Douglas e todos da secretaria que muito me ajudam sempre quando necessrio.

SANTOS, Fabiana Jack Nogueira. Uma abordagem para identificao e representao dos
interesses transversais na Arquitetura Empresarial. UNIRIO, 2012. 180 pginas.
Dissertao de Mestrado. Departamento de Informtica Aplicada, UNIRIO.

RESUMO

O cenrio atual, no qual as organizaes esto inseridas, requer que mudanas sejam
realizadas rapidamente com baixo custo. Frente a este desafio, as organizaes precisam
conhecer a si mesmas, como John Zachman j observava em 1987 (ZACHMAN, 1987).
Conhecer a si mesma significa entender por que e como as atividades so realizadas, quais
informaes esto relacionadas a elas, quais sistemas as apoiam e qual tecnologia a suporta. A
literatura prope o estabelecimento do conceito de Arquitetura Empresarial para auxiliar as
organizaes a conhecerem a si mesmas. Atualmente existem diversos frameworks que
sugerem artefatos e prticas para o desenvolvimento e a manuteno das diversas
representaes que compem a Arquitetura Empresarial.
Porm ao se analisar as representaes sugeridas e suas formas de desenvolvimento e
manuteno na modelagem convencional da Arquitetura Empresarial propostas por estes
Frameworks, percebe-se a existncia de diversos interesses espalhados e entrelaados aos
interesses essenciais da organizao. Essa questo de baixa modularizao compromete o
reuso e dificulta tanto a manuteno quanto o entendimento das representaes da Arquitetura
Empresarial.
Para auxiliar na soluo de tal questo proposto um mtodo para identificar e representar os
interesses transversais na Arquitetura Empresarial. A soluo baseada na metodologia
DEMO e na abordagem orientada a aspectos. Para analisar o mtodo proposto foi realizado
um estudo de caso em uma empresa real.

Palavras-chave: Arquitetura Empresarial; Modularidade; Interesses Transversais; Aspectos

ABSTRACT

The current scenario where organizations are embedded requires changes to be performed
quickly with low costs.

In order to face this challenge, the organizations must know

themselves as John Zachman already observed in 1987 (ZACHMAN, 1987). Knowing itself
means understanding why and how the activities are performed, which information is related
to them, which systems endorses them and which technology support them. The literature
proposes the establishment of Enterprise Architecture concept to help organizations know
themselves. Currently there are many frameworks that suggest artifacts and practices to the
development and maintenance of the several representations that compose the Enterprise
Architecture.
However when analyzing the representations suggested and their development forms in
conventional modeling of the Enterprise Architecture proposed by these Frameworks, it is
possible to perceive the existence of several concerns scattered and tangled to the organization
essential concerns. This low modularity issue compromises reuse and makes it difficult both
to maintain and understand the Enterprise Architecture representations.
In order to solve this issue, we present a method to identify and represent the crosscutting
concerns at Enterprise Architecture level. The solution is based in the DEMO methodology
and in the aspect-oriented approach. To analyze the proposed method we have performed one
case study in a real world organization.

Keywords: Enterprise Architecture; Modularity; Crosscutting concerns; Aspects

NDICE
1.

2.

Introduo .......................................................................................................................... 1
1.1.

Motivao .................................................................................................................... 1

1.2.

Problema ...................................................................................................................... 2

1.3.

Enfoque de soluo ...................................................................................................... 3

1.4.

Escopo .......................................................................................................................... 4

1.5.

Estrutura do trabalho .................................................................................................... 5

Arquitetura Empresarial .................................................................................................. 6

2.1. Frameworks de Arquitetura Empresarial ..................................................................... 6
2.1.1. Framework de Zachman ....................................................................................... 7
2.1.2. FEAF .................................................................................................................... 8
2.1.3. TEAF .................................................................................................................... 9
2.1.4. DoDAF ............................................................................................................... 10
2.1.5. TOGAF ............................................................................................................... 11
2.1.6. FEA..................................................................................................................... 12
2.1.7. IEEE 1471-2000 ................................................................................................. 14
2.1.8. Comparao entre os frameworks ...................................................................... 15
2.2. Problemas encontrados na Arquitetura Empresarial .................................................. 18
2.2.1. Linguagens para modelagem da Arquitetura Empresarial ................................. 20
2.3. Ontologia Empresarial ............................................................................................... 28
2.3.1. Gerao das representaes da Ontologia Empresarial ...................................... 34
2.3.2. Exemplo .............................................................................................................. 37
2.4.

3.

Resumo ...................................................................................................................... 40

Orientao a Aspectos em Sistemas de Informao ..................................................... 41

3.1.

Conceitos gerais ......................................................................................................... 41

3.2.

Programao orientada a aspectos ............................................................................. 42

3.3.

Anlise de requisitos orientada a aspectos ................................................................. 43

3.4.

Modelagem de processos de negcios orientada a aspectos ...................................... 46

3.5.

Interesses transversais na Arquitetura Empresarial ................................................... 50

3.6.

Resumo ...................................................................................................................... 51

4. Mtodo para identificao e representao dos interesses transversais na

Arquitetura Empresarial ....................................................................................................... 53
4.1.

Objetivos .................................................................................................................... 53

4.2.

Premissas ................................................................................................................... 53

4.3.

Introduo ao mtodo ................................................................................................ 54

4.4. Fase Identificar .......................................................................................................... 56

4.4.1. EIA Obter representaes organizacionais ...................................................... 57
4.4.2. EIA - Definir os tipos de elementos bsicos de cada representao
organizacional ................................................................................................................... 57
4.4.3. EIA - Listar trechos que compem os elementos bsicos .................................. 58
4.4.4. EIA - Identificar transaes ontolgicas ............................................................ 64
4.4.5. EIA - Representar as transaes ontolgicas ...................................................... 64
4.4.6. EIA - Identificar os trechos que operacionalizam as transaes ontolgicas ..... 66
4.4.7. EIA - Descartar os trechos que no operacionalizam as transaes ontolgicas 68
4.4.8. EIA - Identificar os verbos utilizados ................................................................. 72
4.4.9. EIA - Identificar os verbos com significado semelhante .................................... 75
4.4.10. EIA - Calcular ocorrncia dos verbos................................................................. 76
4.4.11. EIA - Descartar verbos com apenas 1 ocorrncia............................................... 77
4.4.12. EIA - Identificar os trechos que compartilham mais de um verbo ..................... 81
4.4.13. EIA - Revisar lista de interesses transversais ..................................................... 81
4.4.14. EIA - Descartar trechos com verbos repetidos apenas na mesma representao
organizacional ................................................................................................................... 82
4.4.15. EIA - Nomear os interesses transversais identificados ....................................... 86
4.5. Fase Representar ........................................................................................................ 87
4.5.1. Passo a passo ...................................................................................................... 87
4.5.2. A Linguagem para especificao de interesses transversais na Arquitetura
Empresarial........................................................................................................................ 90
4.6.
5.

Resumo ...................................................................................................................... 96

Avaliao da proposta estudo de caso ........................................................................ 97

5.1.

Metodologia de pesquisa ........................................................................................... 97

5.2.

Caracterizao da Empresa ABCD ............................................................................ 98

5.3. Realizao do estudo de caso ..................................................................................... 98

5.3.1. Obter representaes organizacionais e identificar os tipos de elementos bsicos
de cada uma ....................................................................................................................... 99
5.3.2. Listar os trechos que compem os tipos de elementos bsicos ........................ 100
5.3.3. Identificar as transaes ontolgicas ................................................................ 104
5.3.4. Representar a essncia da organizao ............................................................. 105
5.3.5. Identificar os trechos que operacionalizam as transaes ontolgicas ............. 106
5.3.6. Descartar os trechos que operacionalizam as transaes ontolgicas .............. 107
5.3.7. Identificar os verbos utilizados ......................................................................... 111
5.3.8. Identificar os verbos semelhantes ..................................................................... 115
5.3.9. Calcular ocorrncia dos verbos ........................................................................ 115
5.3.10. Remover da lista os verbos com apenas 1 ocorrncia ...................................... 117
5.3.11. Identificar os trechos que compartilham mais de um verbo ............................. 121
5.3.12. Revisar lista ...................................................................................................... 123

5.3.13. Identificar verbos repetidos somente na mesma representao organizacional127

5.3.14. Nomear os interesses transversais identificados ............................................... 143
5.3.15. Criar o diagrama de interesses transversais ...................................................... 144
5.3.16. Especificar o relacionamento transversal para cada interesse transversal
identificado ...................................................................................................................... 144
5.3.17. Anlise dos resultados da aplicao do mtodo ............................................... 150
5.3.18. Respostas dos participantes .............................................................................. 151
5.4.
6.

Resumo .................................................................................................................... 157

Concluses ...................................................................................................................... 158

6.1.

Contribuies do trabalho ........................................................................................ 159

6.2.

Limitaes ................................................................................................................ 160

6.3.

Trabalhos futuros ..................................................................................................... 161

REFERNCIAS ................................................................................................................... 163

ANEXOS ............................................................................................................................... 170
I.

Convite para participar da pesquisa ............................................................................. 170

II. Apresentao do mtodo ............................................................................................. 171

III. Artefatos utilizados ...................................................................................................... 172
IV. Resultado ..................................................................................................................... 174
V. Roteiro da entrevista .................................................................................................... 174

LISTA DE FIGURAS
Figura 1 O Framework de Zachman 3.0 (ZACHMAN, 2011) ................................................................ 8
Figura 2 Componentes do planejamento da Arquitetura Empresarial traduzido de (FEAF, 1999) ........ 9
Figura 3 Recursos e produtos de trabalho do TEAF para direcionar, descrever e realizar a Arquitetura
Empresarial traduzido de (TEAF, 2000) ............................................................................................... 10
Figura 4 Pontos de vista arquiteturais do DoDAF v2.0 traduzido de (DoDAF, 2009) ......................... 11
Figura 5 Architecture Development Method TOGAF traduzido de (TOGAF, 2009)........................ 12
Figura 6 Modelos de referncia do FEA traduzido de (FEA Reference Models) ................................. 13
Figura 7 Modelo Conceitual do Framework IEEE 1471-2000 traduzido de (Hilliard, 2000)............... 14
Figura 8 Camada de negcio da situao atual da UME (University of Middle England).................... 21
Figura 9 Objetivo da camada de negcio .............................................................................................. 21
Figura 10 Como o aluno registrado .................................................................................................... 21
Figura 11 Camada de aplicao ............................................................................................................ 22
Figura 12 Refinamento da camada de negcio ..................................................................................... 22
Figura 13 TO-BE da UME .................................................................................................................... 23
Figura 14 Operaes includas no To-Be da Camada de Negcio ........................................................ 23
Figura 15 To-Be da Camada de Aplicao ........................................................................................... 23
Figura 16 Refinamento Camada de Aplicao ...................................................................................... 24
Figura 17 Definio dos fundos da instituio ...................................................................................... 24
Figura 18 Definio dos fundos da instituio ...................................................................................... 24
Figura 19 Diagrama de Contexto de Negcio do USCP ....................................................................... 26
Figura 20 Diagrama do Processo Pagamento por Perodo .................................................................... 27
Figura 21 Diagrama de caso de uso do BAP pessoal ............................................................................ 28
Figura 22 Transao .............................................................................................................................. 31
Figura 23 Padro Transao Bsico ...................................................................................................... 32
Figura 24 Bloco molecular .................................................................................................................... 33
Figura 25 Bloco atmico ....................................................................................................................... 33
Figura 26 Diagrama de Transao de Ator da DAE ............................................................................. 39

Figura 27 Meta-modelo para Integrao de Caractersticas Transversais durante a Definio de

Requisitos (SILVA, 2006)..................................................................................................................... 45
Figura 28 Processo de Gesto de Mudana (CAPPELLI, 2009)........................................................... 49
Figura 29 Processo de Gesto de Mudana com a composio de caractersticas transversais
(CAPPELLI, 2009) ............................................................................................................................... 49
Figura 30 Passo a passo do mtodo para Identificao e Representao dos Interesses Transversais na
Arquitetura Empresarial ........................................................................................................................ 56
Figura 31 Atividades da fase Identificar ............................................................................................... 59
Figura 32 Construction Model da EIA .................................................................................................. 65
Figura 33 Passo a passo da fase Representar ........................................................................................ 87
Figura 34 Exemplo de um diagrama para representar os Interesses Transversais ................................ 88
Figura 35 Interesses transversais na EIA .............................................................................................. 88
Figura 36 Definio do relacionamento transversal Elaborao ........................................................ 89
Figura 37 Componentes usados para representar interesses transversais em modelos da Arquitetura
Empresarial (adaptado de Cappelli (CAPPELLI, 2009) ....................................................................... 90
Figura 38 Sintaxe de LMAEOA (adaptado de Cappelli (Cappelli, 2009)) ........................................... 91
Figura 39 Modelo conceitual da linguagem de modelagem da Arquitetura Empresarial orientada a
aspectos (adaptado de Cappelli (CAPPELLI, 2009)) ............................................................................ 92
Figura 40 Instanciao da sintaxe de LMAEOA para Diagrama de processos de negcio .................. 93
Figura 41 Sintaxe do Relacionamento Transversal (adaptado de Cappelli (CAPPELLI, 2009)) ......... 94
Figura 42 Exemplo do Relacionamento Transversal do aspecto Log ................................................... 95
Figura 43 Construction Model da EIA ................................................................................................ 106
Figura 44 Interesses transversais da rea de informtica da empresa ABCD ..................................... 144
Figura 45 Definio do relacionamento transversal Elaborao ...................................................... 145
Figura 46 Definio do relacionamento transversal Realizao ...................................................... 145
Figura 47 Definio do relacionamento transversal Existncia ....................................................... 146
Figura 48 Definio do relacionamento transversal Definio ........................................................ 146
Figura 49 Definio do relacionamento transversal Mudana ......................................................... 146
Figura 50 Definio do relacionamento transversal Acesso ............................................................ 147
Figura 51 Definio do relacionamento transversal Gerenciamento ............................................... 147

Figura 52 Definio do relacionamento transversal Utilizao ....................................................... 148

Figura 53 Definio do relacionamento transversal Preparao ...................................................... 148
Figura 54 Definio do relacionamento transversal Permisso ....................................................... 149
Figura 55 Definio do relacionamento transversal Detalhamento ................................................. 149
Figura 56 Definio do relacionamento transversal Recuperao ................................................... 149
Figura 57 Definio do relacionamento transversal Contedo ........................................................ 150
Figura 58 Definio do relacionamento transversal Conselho ......................................................... 150
Figura 59 Definio do relacionamento transversal Parametrizao ............................................... 150
Figura 60 Passo a passo do mtodo para Identificar e Representar Interesses Transversais............... 173

LISTA DE TABELAS
Tabela 1 Comparao entre os frameworks traduzido de (TANG et al., 2004) .................................... 17
Tabela 2 Tipos de elementos bsicos das representaes organizacionais ............................................ 58
Tabela 3 Trechos das representaes organizacionais a serem analisados ............................................ 60
Tabela 4 Transaes ontolgicas da EIA .............................................................................................. 64
Tabela 5 Trechos das representaes organizacionais que operacionalizam as transaes ontolgicas
da EIA.................................................................................................................................................... 67
Tabela 6 Trechos Modelo de Processos de Negcio da EIA que no operacionalizam as transaes
ontolgicas............................................................................................................................................. 68
Tabela 7 Trechos PDI que no apoiam as transaes ontolgicas ........................................................ 69
Tabela 8 Trechos Manual do SIE que no apoiam as transaes ontolgicas ....................................... 70
Tabela 9 Verbos presentes nos trechos das representaes organizacionais ......................................... 73
Tabela 10 Nmero de ocorrncias dos verbos nos trechos das representaes organizacionais ........... 76
Tabela 11 Candidatos a interesse transversal presente nas representaes organizacionais ................. 77
Tabela 12 Candidatos a interesse transversal agrupados ....................................................................... 82
Tabela 13 Representaes organizacionais e seus respectivos tipos de elemento bsico...................... 99
Tabela 14 Todos os Trechos das representaes organizacionais ....................................................... 100
Tabela 15 Transaes ontolgicas de parte da empresa ABCD .......................................................... 104
Tabela 16 Trechos das representaes organizacionais que apoiam as transaes ontolgicas .......... 106
Tabela 17 Candidatos a interesse transversal ...................................................................................... 108
Tabela 18 Verbos dos candidatos a interesse transversal .................................................................... 111
Tabela 19 Nmero de ocorrncias dos verbos presentes nos trechos das representaes organizacionais
............................................................................................................................................................. 115
Tabela 20 Candidatos a interesse transversal presente nas representaes organizacionais ............... 117
Tabela 21 Anlise da predominncia dos verbos ................................................................................ 121
Tabela 22 Anlise da predominncia dos verbos ................................................................................ 123
Tabela 23 Candidatos a interesse transversal com verbos separados .................................................. 127
Tabela 24 Candidatos a interesse transversal agrupados por verbo..................................................... 133

Tabela 25 Interesses transversais agrupados por verbo foram removidos os verbos com ocorrncia
em apenas 1 tipo de seo ................................................................................................................... 139
Tabela 26 Definies ........................................................................................................................... 171

1. Introduo

Esta dissertao apresenta uma proposta para identificao e representao dos

interesses transversais na Arquitetura Empresarial (AE). Este captulo apresenta a motivao,
o problema, o enfoque de soluo, o escopo e a forma como o trabalho est organizado.

1.1. Motivao
O cenrio atual no qual as organizaes esto inseridas exige que as mudanas sejam
administradas de forma rpida e com o menor custo possvel. So consideradas mudanas
tanto alteraes para atingir novos objetivos quanto aquelas impostas por regulamentaes e
leis. Para isso, necessrio que as organizaes conheam a si mesmas como j previa John
Zachman em 1987 (ZACHMAN, 1987).
Conhecer a si mesma significa entender porque e como as atividades so realizadas,
quais so as informaes relacionadas a essas atividades, quais sistemas as apoiam e a
tecnologia que permite a operao da organizao. As atividades so realizadas pelas
organizaes e descrevem o seu funcionamento. Os sistemas e tecnologia apoiam a execuo
destas atividades. Todos estes elementos fazem parte das abordagens de Arquitetura
Empresarial propostas por diversos autores (ZACHMAN, 1997, LANKHORST et al., 2005,
TOGAF, 2009, BOTTO, 2004 ).
Segundo Lankhorst (2005) a Arquitetura Empresarial um conjunto coerente de
princpios, mtodos e modelos que so usados na concepo e na operao da estrutura
organizacional, dos processos de negcio, dos sistemas de informao e da infraestrutura de
uma organizao. Consideramos como Arquitetura Empresarial o conjunto de artefatos que
descrevem e representam as diversas perspectivas organizacionais de acordo com o
Framework de Zachman (ZACHMAN, 2008), que doravante chamaremos de Representaes
Organizacionais. Existem diversos frameworks propostos para apoiar a construo e a
manuteno das representaes que compem a Arquitetura Empresarial. A organizao da
Arquitetura Empresarial utiliza abstraes de alto nvel chamadas vises. Os frameworks
utilizam pontos de vista (viewpoints) para criar vises que representam diferentes perspectivas
1

da arquitetura (TANG et al., 2004). Pontos de vista comumente utilizados pelos frameworks
so: arquitetura de negcio, arquitetura de informao, arquitetura de sistema e arquitetura de
tecnologia.
Ao analisar as representaes da Arquitetura Empresarial de uma organizao,
percebe-se que existem interesses espalhados e entrelaados com outros interesses nas
diversas representaes. Essa baixa modularizao faz com que seja mais difcil incorporar
mudanas nas representaes e tambm denotam a ausncia de uma viso integrada de onde e
como esto operacionalizados os interesses que representam um mesmo conceito. Isso
compromete o reuso, a manuteno e o entendimento dos elementos da Arquitetura
Empresarial.

1.2. Problema
Existem diversas abordagens e frameworks que apoiam as iniciativas de estruturao
da Arquitetura Empresarial nas organizaes. Ao analisar algumas dessas abordagens,
percebe-se que o foco na representao do contedo de cada viso que compe a
Arquitetura Empresarial e no relacionamento entre as representaes. Nada se comenta sobre
partes que estejam espalhadas ou entrelaadas em diversas representaes, o que permite a
existncia de representaes contendo os mesmos elementos ou partes destes dentro de si.
Isso dificulta a anlise dos impactos causados por necessidade de atualizao ou remoo
destes elementos ou partes espalhadas ou entrelaadas em diversas representaes. Por
exemplo, se uma organizao precisa diminuir o tempo de realizao de seus processos pode
decidir automatizar todos os pontos dos processos onde h atividades de verificao. Mesmo
considerando que essa organizao j tenha uma abordagem estruturada da representao da
Arquitetura Empresarial, ainda assim ser demorado e custoso identificar todos os trechos de
todas as representaes da Arquitetura Empresarial onde existam elementos de verificao.
Neste caso, todos os processos devero ser analisados, pois possvel que as atividades de
verificao tenham nomes diferentes como analisar, examinar e averiguar, aumentando o
tempo gasto na anlise. Alm disso, ainda poder ser necessrio um levantamento de quais
das atividades de verificao j esto automatizadas para escolher a melhor forma de
implementao, o que far com que seja necessrio obter o cdigo de todas as
implementaes deste conceito e ento analis-los.

Os elementos espalhados e entrelaados com outros elementos presentes nas

representaes convencionais da Arquitetura Empresarial sero aqui denominados Interesses
Transversais (KICZALES et al., 1997). Neste trabalho a definio deste conceito, que ser
detalhada no Captulo 3, assume o interesse transversal como um elemento que se encontra
espalhado nas representaes da Arquitetura Empresarial e entrelaado com as representaes
da essncia da organizao.
Dessa forma, o problema a ser endereado nessa dissertao :

1.3. Enfoque de soluo

Este trabalho considera a hiptese de que possvel identificar e representar os
interesses transversais entrelaados e espalhados nas diversas representaes da Arquitetura
Empresarial. Para isso, ser desenvolvido um mtodo que permitir identificar e representar
os interesses transversais no nvel da Arquitetura Empresarial.
O mtodo para identificao e representao dos interesses transversais utiliza os
conceitos da orientao a aspectos (KICZALES et al., 1997). Nessa abordagem, um elemento
dito transversal quando afeta diversos outros elementos que implementam as
funcionalidades bsicas do sistema. Trazendo essa definio para a Arquitetura Empresarial,
teremos interesses transversais que afetam os elementos que representam a essncia da
organizao.
A essncia da organizao, segundo a Ontologia Empresarial (DIETZ, 2006), so os
atos realizados pelos papis de ator e os fatos resultantes de tais atos onde h produo de
algo novo ou tomada de deciso relacionada aos objetivos de negcio da organizao. Esses
atos so apoiados por outros atos e fatos onde h computao de informao ou manipulao
de dados que indicam como a realizao e implementao da essncia da organizao.
No mtodo proposto nessa dissertao, uma vez descoberta a essncia da organizao,
atravs da metodologia DEMO, possvel diferenci-la dos demais elementos que fazem
parte da organizao. Tais elementos podem ser interesses transversais ou simplesmente

outros elementos. Essas informaes so utilizadas na fase Identificao, onde so elencados

os interesses transversais.
Uma vez identificados, os interesses transversais sero representados utilizando as
ideias da orientao a aspectos na fase Representao do mtodo proposto. Nessa abordagem,
os elementos transversais so encapsulados no componente denominado Aspecto. Nesse
componente representado o cdigo do elemento transversal e em quais locais do cdigo ele
deve ser inserido e quando. No caso da Arquitetura Empresarial, as mesmas informaes
sero representadas.
A maioria dos trabalhos que lida com interesses transversais apresenta abordagens
para solucionar esse problema focadas um nico tipo de representao. Em Silva (2006)
proposta a orientao a aspectos no documento de requisitos de software, em Cappelli (2009)
proposta a orientao a aspectos no modelo de processos de negcio. Nesta dissertao, o
conceito de orientao a aspectos utilizado simultaneamente em diversos tipos de
representaes que compem a Arquitetura Empresarial, como modelos de processos de
negcio, casos de uso de um software, padro de desenvolvimento de um software, diagrama
de classes, modelo de objetivos, arquitetura de aplicaes etc.
Para avaliar a viabilidade do mtodo foram realizados dois estudos de caso. Um deles
na Escola de Informtica Aplicada da UNIRIO e o outro em uma empresa real. No estudo de
caso realizado em uma empresa real foi aplicado um questionrio para analisar o
entendimento de outras pessoas sobre a representao proposta. Todos os participantes atuam
na rea de informtica dessa empresa.
O mtodo para identificao e representao dos interesses transversais permitir aos
arquitetos aprimorar as representaes da organizao de forma modular, permitindo a
visualizao do que transversal essncia da organizao. Alm disso, ser possvel
visualizar de forma consolidada, atravs da representao proposta, os interesses transversais
que previamente apresentavam-se dispersos. Isso possibilita a anlise de impactos causados
por alteraes nos interesses transversais necessria aos gestores organizacionais e a
facilidade de manuteno e reuso dos interesses transversais.

1.4. Escopo

Nas abordagens de Arquitetura Empresarial existem a Arquitetura Atual, que indica a

situao atual da organizao, e a Arquitetura Futura, que indica como organizao deseja ser.
O escopo do mtodo a Arquitetura Atual que contm as representaes da organizao
como esto atualmente.

1.5. Estrutura do trabalho

No Captulo 2 apresentada a Arquitetura Empresarial, com a indicao e detalhes de
alguns de seus frameworks que auxiliam sua implantao, bem como as intenes das
organizaes com sua adoo e benefcios trazidos por ela. Ainda nesse captulo
apresentado o conceito de Ontologia Empresarial e a metodologia DEMO.
No Captulo 3 definido o conceito de interesses transversais acompanhado de uma
reviso da literatura com foco nas diversas fases do desenvolvimento de software e
componentes da Arquitetura Empresarial, como modelos de processos, que j incorporam a
orientao a aspectos como meio de contribuir para a melhoria da modularizao de suas
representaes. Tambm relatado o problema da modularizao dos interesses transversais
presentes na Arquitetura Empresarial e alguns trabalhos relacionados. O problema da
modularizao na Arquitetura Empresarial ilustrado atravs de exemplos para facilitar o
entendimento.
O Captulo 4 tem o intuito de detalhar o mtodo proposto para identificao e
representao dos interesses transversais na Arquitetura Empresarial, partindo de seu objetivo
geral at a descrio detalhada de suas fases com um exemplo.
No Captulo 5 apresentado um estudo de caso resultante da aplicao do mtodo
proposto. O estudo de caso foi realizado em uma empresa real, onde o mtodo foi aplicado
pela prpria autora a alguns artefatos da rea de informtica. Para analisar o resultado do
mtodo foram realizadas 2 entrevistas com funcionrios da rea de informtica dessa empresa.
A concluso deste trabalho, suas contribuies e trabalhos futuros so apresentados no
Captulo 6.

2. Arquitetura Empresarial

A Arquitetura Empresarial um conjunto coerente de princpios, mtodos e modelos

que so usados no projeto e realizao da estrutura, dos processos de negcio, dos sistemas de
informao e da infraestrutura de uma empresa (LANKHORST, 2009). De acordo com essa
definio, a Arquitetura Empresarial relaciona os elementos que compem os processos de
negcio, informaes, sistemas e infraestrutura que permitem o funcionamento das
organizaes.
Na literatura existem diversos frameworks que apoiam o desenvolvimento e a
manuteno das iniciativas de Arquitetura Empresarial nas organizaes, alguns deles so
apresentados na seo 2.1.
Na seo 2.2 so apresentados alguns problemas encontrados nos frameworks de
Arquitetura Empresarial, mas especificamente nas representaes geradas, onde h
espalhamento e entrelaamento dos interesses transversais que fazem parte das representaes
da Arquitetura Empresarial.
Na seo 2.3 apresentada a Ontologia Empresarial e a metodologia DEMO (DIETZ,
2006) que complementam a noo de Arquitetura Empresarial (DIETZ e HOOGERVORST,
2008). A metodologia DEMO define conceitualmente a Ontologia Empresarial como a
essncia de uma empresa independente de implementao (DIETZ e HOOGERVORST,
2008) possibilitando identificar e representar a essncia de uma organizao. A identificao
da essncia auxilia o mtodo proposto nessa dissertao ao explicitar o conceitos que no so
interesses transversais.

2.1. Frameworks de Arquitetura Empresarial

Os frameworks da Arquitetura Empresarial auxiliam na tarefa de descobrir quais
elementos devem ser utilizados para representar a organizao, mas no so suficientes para
garantir a qualidade destas representaes durante seu ciclo de vida. Para tal, devem ser
adotados mtodos que indiquem as relaes entre os diversos domnios, vises e camadas da

arquitetura e as modificaes que devem ocorrer de forma metdica entre elas

(LANKHORST et al., 2005).
Abaixo sero apresentados alguns frameworks de Arquitetura Empresarial, de forma
resumida. Alguns destes possuem tambm um mtodo associado. Nestes casos, sero
apresentados os frameworks com seus componentes e seus mtodos.
2.1.1. Framework de Zachman
O Framework de Zachman, proposto por John Zachman em 1987, influenciou diversos
modelos de arquitetura e a rea de Arquitetura Corporativa (BOTTO, 2004). Este framework,
representado na Figura 1, uma estrutura lgica para classificar e organizar as representaes
descritivas de uma organizao que so relevantes para os stakeholders, desde o nvel
gerencial at os desenvolvedores de software. Ele prov uma forma concisa de estruturar e
modelar a organizao e a arquitetura de sistemas, de informao e de tecnologia (TANG et
al., 2004).
As colunas da matriz indicam as perspectivas (O que? Como? Onde? Quem? Quando?
Por qu?) que devem ser respondidas considerando o nvel de abstrao (contextual,
conceitual, lgico, fsico, implementao e funcionamento) ou de forma semelhante,
considerando o papel de quem faz as perguntas (planejador, proprietrio, projetista, quem vai
construir, quem vai implementar e sub-contratados). As linhas e colunas da matriz se
interceptam para definir um elemento de projeto (design) da arquitetura em uma clula, que
um resultado de uma atividade arquitetural baseada em um aspecto de um sistema para um
grupo particular de pessoas (TANG et al., 2004).
As clulas da matriz relacionam-se da seguinte forma: as clulas das colunas
respondem s interrogativas do nvel mais abstrato at a representao detalhada e as linhas
compem as diversas perspectivas que determinada pessoa precisa saber sobre a organizao,
representam os tipos de vises da corporao (BOTTO, 2004). Este framework no possui um
mtodo associado publicado e as relaes entre as diferentes clulas tambm no so
especificadas formalmente (LANKHORST et al., 2005), nem as primitivas que aparecem na
matriz. Este framework principalmente direcionado pelos requisitos de negcio e possui
prescrio de documentao padronizada no contedo de suas clulas (MCCARTHY, 2006).
Alm disso, este framework tambm no prov suporte para os requisitos no funcionais, nem
para a evoluo da arquitetura (TANG et al., 2004).
7

Figura 1 O Framework de Zachman 3.0 (ZACHMAN, 2011)

2.1.2. FEAF
O FEAF (Federal Enterprise Architecture Framework) foi criado pelo Chief
Information Officer Council e descrito no documento A Practical Guide to Federal
Enterprise Architecture que aponta aspectos de governana e construo de frameworks de
arquitetura. Este documento define os termos importantes para a arquitetura, indica os
benefcios de seu uso, indica quais princpios governam a arquitetura e descreve o processo de
criao da arquitetura, composto pelas seguintes atividades: aprovao e suporte da rea
executiva, estabelecimento de estrutura de gerncia e controle, definio um processo de
abordagem da arquitetura, desenvolvimento da AE corrente, desenvolvimento da AE futura,
desenvolvimento de plano de prioridades, utilizao da AE e manuteno da AE.
Este framework tambm organiza a arquitetura em tipos, so eles: arquitetura de
negcios, arquitetura de dados, arquitetura de aplicaes e arquitetura de tecnologia. Ele
utiliza parte do Framework de Zachman, gerando uma matriz perspectivas x arquiteturas
8

(BOTTO, 2004) e composto pelas 3 primeiras colunas do Framework de Zachman,

orientada organizao como um todo, ao invs de ser orientado TI apenas
(URBACZEWSKI e MRDALJ, 2006).
Segundo Tang et al. (2004), este framework organizado em 4 nveis: nvel I o mais
alto e lida com architecture drivers ou estmulo externo e direcionamento estratgico da
arquitetura, ele facilita a transformao da arquitetura atual em futura atravs dos padres e
gesto do processo arquitetural; o nvel II prov maiores detalhes ao analisar os business
drivers e design drivers da arquitetura e resulta em na arquitetura de negcio e na arquitetura
de design futuras; o nvel III detalha ainda mais a arquitetura ao utilizar as vises de negcios,
dados, aplicaes e tecnologia para modelar a arquitetura futura; j o nvel IV utiliza uma
combinao do Framework de Zachman e do Spewaks Enterprise Architecture Planning
(EAP) para representar a arquitetura de dados, arquitetura de aplicao e arquitetura de
tecnologia. FEAF principalmente um framework de planejamento e no prov suporte para
requisitos no funcionais, exceto segurana (TANG et al., 2004). Os componentes de
planejamento do FEAF so apresentados na Figura 2.

Figura 2 Componentes do planejamento da Arquitetura Empresarial traduzido de

(FEAF, 1999)
2.1.3. TEAF
O TEAF (Treasury Enterprise Architecture Framework) um framework proposto
pelo Tesouro Federal Americano, influenciado pelo Framework de Zachman e pelo FEAF. Os
recursos e produtos de trabalho do TEAF so representados na Figura 3. Neste framework
temos as seguintes perspectivas: planejador, dono, designer e construtor. Para cada uma
dessas perspectivas temos as seguintes vises: viso funcional, viso da informao, viso
organizacional e viso de infra-estrutura. Neste framework, uma perspectiva um ponto de
vista de toda a arquitetura representado em uma entidade organizacional (BOTTO, 2004).
Este framework tambm possui uma matriz onde so indicados os principais produtos gerados
no desenvolvimento da arquitetura (documentao e modelagem). O TEAF permite a
9

flexibilidade de definir vises e perspectivas adicionais com foco nico em reas importantes
para determinados stakeholders (URBACZEWSKI e MRDALJ, 2006).

Figura 3 Recursos e produtos de trabalho do TEAF para direcionar, descrever e

realizar a Arquitetura Empresarial traduzido de (TEAF, 2000)
2.1.4. DoDAF
O DoDAF (Department of Defense Architecture Framework) um framework do
Departamento de Defesa para rgos militares e agncias relacionadas. Este framework foi
criado em 2003 para combinar o framework C4ISR (comando, controle, comunicao,
computadores e inteligncia) com os componentes do modelo FEAF (McCarthy, 2006). Este
framework utiliza o CADM (Core Architecture Data Model) para documentar a arquitetura.
Este modelo uma taxonomia padronizada que define vises e seus elementos em uma base
de dados. Este esquema dependente do domnio para o qual foi criado (operaes de defesa)
(TANG et al., 2004).
O framework possui os seguintes pontos de vista representadas na Figura 4: todas as
vises prov uma viso geral da arquitetura; operacional identifica quais necessidades
precisam ser cumpridas e quem as far; de sistemas relaciona sistemas e caractersticas com
necessidades operacionais; e de padres tcnicos prescreve padres e convenes. Para cada
um desses pontos de vista so listados os artefatos a serem gerados (BOTTO, 2004). A
documentao padronizada, com grande parte dos elementos utilizando UML para alcanar
10

esta padronizao (MCCARTHY, 2006). Este framework no prov capacidade de

modelagem para configurao de sistemas e apoia limitadamente a modelagem de requisitos
no funcionais (TANG et al., 2004).

Figura 4 Pontos de vista arquiteturais do DoDAF v2.0 traduzido de (DoDAF, 2009)

2.1.5. TOGAF
O The Open Group Architecture Framework (TOGAF, 2009) possui um mtodo
detalhado e um conjunto de ferramentas para apoi-lo no desenvolvimento da Arquitetura
Empresarial. Seu objetivo prover um framework para projeto (design), avaliao e
construo das arquiteturas (TANG et al., 2004). A primeira verso do TOGAF foi baseada
em outro framework para Arquitetura Empresarial chamado TAFIM (Technical Architecture
Framework for Information Management), este framework foi desenvolvido pelo
Departamento de Defesa dos Estados Unidos (DoD) para auxiliar o desenvolvimento de seus
sistemas.
O TOGAF formado por vrios componentes: Mtodo de Desenvolvimento
Arquitetural (Architecture Development Method) utilizado para desenvolvimento da
11

arquitetura empresarial; Universo da Arquitetura Empresarial (Enterprise Continuum) um

repositrio de ativos arquiteturais; Framework de Contedo Arquitetural (Architecture
Content Framework) modelo estrutural do contedo gerado pela arquitetura e Framework
de Funcionamento Arquitetural (Architecture Capability Framework) material de referncia
para o funcionamento da arquitetura.
O ciclo do desenvolvimento arquitetural apoiado pelo ADM apresentado na Figura
5. O TOGAF explica as regras para desenvolver bons princpios, ao invs de prover um
conjunto de princpios arquiteturais (URBACZEWSKI e MRDALJ, 2006). O ADM uma
metodologia para enderear a arquitetura tanto no nvel organizacional quanto ao nvel de
sistemas individuais e o Enterprise Continuum, com sua base de conhecimento, auxilia a
evoluo arquitetural (TANG et al., 2004).

Figura 5 Architecture Development Method TOGAF traduzido de (TOGAF, 2009)

2.1.6. FEA
Segundo Urbaczewski e Mrdalj (2006), O FEA (Federal Enterprise Architecture)
pode ser associado ao FEAF, pois ele fornece orientao s agncias federais em relao aos
frameworks e permite flexibilidade no uso de ferramentas, mtodos e produtos a serem
utilizados pelas agncias individualmente. Ele foi desenvolvido pelo OMB (Office of
Management and Budget) com o apoio do GSA (General Services Administration) e do CIO
12

(Federal Chief Information Officers) e construiu um modelo (blueprint) abrangente e voltado

para o negcio do governo federal norte americano (FEA Consolidated Reference Model,
2007).
O FEA composto por modelos de referncia inter-relacionados que facilitam anlises
atravs das agncias e permite a identificao de investimentos duplicados, gaps e
oportunidades de colaborao. Em conjunto, os modelos de referncia compem um
framework que descreve elementos importantes do FEA de forma comum e consistente. Desta
forma, os portflios de TI podem ser melhor gerenciados e alavancados atravs do governo
federal norte americano. Os modelos de referncia, representados na Figura 6, so: PRM
(Performance Reference Model), BRM (Business Reference Model), SRM (Service Reference
Model), TRM (Technical Reference Model) e DRM (Data Reference Model). O PRM um
framework para medio de performance que prov sadas comuns de medies atravs do
governo federal. O BRM prov um framework para facilitar a viso funcional das linhas de
negcio do governo federal, incluindo suas operaes internas e servios prestados aos
cidados de forma integrada, ou seja, independente das agncias ou escritrios que os
disponibilizam. O SRM um framework funcional, orientado a negcio que classifica os
componentes de servios de acordo com a forma com que apoiam o negcio e os objetivos de
performance. O DRM um framework flexvel e baseado em padres que permite o
compartilhamento de informaes e o reuso atravs do governo federal usando descrio
padro e descoberta de dados comuns e a promoo de prticas para gesto uniforme de
dados.

Figura 6 Modelos de referncia do FEA traduzido de (FEA Reference Models)

13

2.1.7. IEEE 1471-2000

Segundo Lankhorst et al. (2005), o padro IEEE 1471-2000 constri uma base terica
para definio, anlise e descrio das arquiteturas de sistemas, com foco em sistemas
apoiados por software. Este framework utiliza a metfora da arquitetura de construo civil
para descrever a arquitetura dos sistemas de software. Ele tambm no padroniza o processo
de desenvolvimento, nem recomenda linguagens de modelagem ou metodologias ou padro a
serem adotados. O framework IEEE 1471-2000 prov um conjunto de definies de termos
chave e um framework conceitual que explica a forma como os termos chave se relacionam
uns com os outros conforme representado na Figura 7, explica o papel dos stakeholders na
criao e uso da descrio arquitetural e prov diversos cenrios nos quais as atividades
arquiteturais podem ocorrer durante seu ciclo de vida. Este padro tambm disponibiliza seis
prticas de descrio arquitetural. Alm disso, ainda lista pontos de vista arquiteturais
relevantes e sua especificao (conceitos, linguagem, modelagem e mtodo de anlise).

Figura 7 Modelo Conceitual do Framework IEEE 1471-2000 traduzido de (Hilliard, 2000)

14

2.1.8. Comparao entre os frameworks

Na literatura existem diversos trabalhos de comparaes entre os frameworks
(URBACZEWSKI e MRDALJ, 2006; TANG et al., 2004; MCCARTHY, 2006). A seguir
alguns destes trabalhos sero apresentados.
Urbaczewski e Mrdalj (2006) apresentam uma comparao entre diversos frameworks
de Arquitetura Empresarial (Framework de Zachman, DoDAF, TEAF, FEAF e TOGAF) com
intuito de fornecer um guia para seleo de um framework que atenda determinados critrios.
Este artigo realiza uma comparao entre os frameworks com base em suas vises e aspectos,
pois eles se diferenciam com relao s necessidades dos stakeholders que endeream e s
questes que preocupam seu mundo (URBACZEWSKI e MRDALJ, 2006). Os autores
estudaram os frameworks e criaram um mtodo para compar-los com base nas perspectivas
dos stakeholders e abstraes. Com base nesta comparao foi feita uma anlise de qual
framework mais adequado s necessidades de um stakeholder em um determinado projeto.
Por haver muitos focos diferentes entre os frameworks listados, os autores optaram por
comparar os frameworks com base em suas vises, abstraes e cobertura do ciclo de vida do
desenvolvimento de sistemas.
Com relao s vises, o Framework de Zachman foi considerado o mais abrangente,
permitindo que as vises dos demais frameworks fossem mapeadas para sua terminologia.
Com base na comparao que realizaram entre diversos frameworks, os autores identificaram
determinadas vises e depois elaboraram uma tabela onde indicado qual framework
enderea qual viso, alguns endeream todas, como o caso do Framework de Zachman e
outros endeream apenas algumas. As seguintes vises foram identificadas pelos autores:
planner (representa os conceitos do produto), owner (representaes do que o proprietrio tem
em mente), designer (produto final do arquiteto com detalhes do plano), builder (define como
ser a construo), sub-contractor (partes das sub-sees do plano de construo) e user
(resultado fsico do produto final). Cada uma destas vises possui determinado nome nos
frameworks analisados e em alguns casos, a viso est representada em mais de um
componente do framework.
Com relao s abstraes tambm foi utilizado o Framework de Zachman e suas
interrogativas, para cada uma delas (O que? Como? Quem? Onde? Quando? Por qu?) foi
identificado nos frameworks o contedo correspondente, por exemplo, O que? no TEAF
representado pela Information View, j no FEAF representado pela Data Architecture,
15

no DoDAF representado pelo Data (mission) Logical Data Model, no Framework de

Zachman representado por Data e no TOGAF no foi identificada uma representao
adequada.
A anlise de cobertura do ciclo de desenvolvimento de software, composto pelas fases
planejamento, anlise, projeto (design), implementao e manuteno resultou na seguinte
concluso: a maioria dos frameworks no enderea a manuteno de sistemas; os frameworks
fornecem orientaes que posteriormente sero incorporadas s fases do desenvolvimento de
software e o forte dos frameworks o planejamento com foco em prover guias com intuito de
evitar que sistemas se tornem obsoletos antes mesmo de serem desenvolvidos.
Em (TANG et al., 2004) tambm realizada uma anlise dos frameworks de AE. Para
os autores, frameworks de arquitetura so mtodos usados na modelagem da arquitetura que
proveem uma abordagem sistemtica e estruturada para projeto de sistemas.
Tang et al. (2004) apresentam um modelo para entendimento dos frameworks de AE
atravs da anlise de objetivos (goals objetivos a serem alcanados com a construo da
arquitetura), entradas (inputs informaes que a modelagem da arquitetura considera) e
resultados (outcomes representa resultados e entregas da arquitetura). Alm disso, os autores
ainda caracterizaram e identificam as deficincias de 2 classes de frameworks: Software
Architecture Frameworks e Enterprise Architecture Frameworks. Os seguintes frameworks
foram analisados: Framework de Zachman, 4+1 View Model Architecture, FEAF, RM-ODP
(Reference Model for Open Distributed Computing), TOGAF e DoDAF. Os frameworks 4+ 1
View e RM-ODP possuem foco no desenvolvimento de arquiteturas de sistemas (TANG et
al., 2004). A inteno dos autores analisar e comparar as semelhanas e diferenas entre
estes frameworks.
Tang et al. (2004) prov maiores detalhes do que considera serem objetivos, entradas e
resultados dos frameworks e com base na definio destes conceitos, os autores apresentam a
anlise dos frameworks. Por exemplo, um dos objetivos considerados pelos autores
architecture definition and understanding. Cada um dos frameworks analisado para
verificar se atende este objetivo, representado pela letra Y na Tabela 1, sendo atendido
parcialmente pelo Framework de Zachman, representado pela letra P na Tabela 1 e pelo 1+4
View Model Architecture. Quando o framework analisado no atende a um dos requisitos, a
letra N indicada na clula correspondente. Este objetivo atendido por todos os demais
frameworks analisados. Em alguns casos, o objetivo, entrada e resultado no so atendidos
16

por nenhum dos frameworks (representado pela letra N na Tabela 1), conforme apresentado
na Tabela 1.
Tabela 1 Comparao entre os frameworks traduzido de (TANG et al., 2004)

A modelagem da arquitetura utiliza abstraes de alto nvel chamadas vises. Os

frameworks utilizam pontos de vista (viewpoints) para criar vises que representam diferentes
perspectivas do modelo de um sistema (TANG et al., 2004). Pontos de vista comumente
utilizados pelos frameworks so: arquitetura de negcio, arquitetura de informao,
arquitetura de software e arquitetura tcnica. O uso de diferentes frameworks para projetar
(design) um sistema pode gerar resultados semelhantes, porm diferentes, pois cada
framework possui diferentes pontos de vista (viewpoints) para a arquitetura. Por outro lado,
utilizar o mesmo framework para projetar sistemas com complexidade variada pode necessitar
diferentes tipos de entradas e produzir resultados diferentes (TANG et al., 2004).
Tang et al. (2004) apontam duas deficincias dos frameworks de Arquitetura
Empresarial: o nvel de detalhe dos modelos geralmente no especificado e a anlise
racional (rationale) da arquitetura no parte obrigatria dos modelos. A anlise racional da
arquitetura est relacionada a como e porque determinada decises foram tomadas, essa
informao proveniente do design rationale da arquitetura que documenta as razes de
projeto (design) com base em anlise e conflitos de escolha (tradeoffs) que envolvem
mltiplas dimenses de entradas (TANG et al., 2004).
17

O resultado destas deficincias que os modelos no podem ser verificados ou

rastreados. Os autores tambm indicam que no h uma fronteira clara entre atividades
arquiteturais e atividades de projeto (design). Para sanar este problema, os autores propem
que sejam analisados os riscos associados ao software a ser desenvolvido, se o risco for alto,
ento deve-se utilizar mais tempo na atividade arquitetural para definio do projeto (design)
do software, seno pode-se dar mais ateno na fase de projeto (design).
McCarthy (2006) discute a importncia da AE, descreve 3 dos frameworks mais
utilizados no mercado e apresenta as implicaes de se ter um nico framework integrado. Os
frameworks citados so FEAF, DoDAF, TOGAF, Framework de Zachman e E2AF (Extended
Enterprise Architecture Framework). O autor aponta os seguintes componentes essenciais a
AE, endereados diretamente ou indiretamente pelos frameworks: alinhamento, integrao,
criao de valor, gesto de mudana e complacncia (compliance). A anlise do autor
reconhece que existem mais semelhanas do que diferenas entre os frameworks. Cada
framework indica a necessidade de mapear os fluxos de informao, aplicaes e infraestrutura tcnica. Alm disso, prescrevem uma metodologia especfica para enderear os
requisitos de negcio, fluxos de informao e infraestrutura tcnica.

2.2. Problemas encontrados na Arquitetura Empresarial

Segundo Zachman (1997), o grande desafio das organizaes modernas a mudana.
Segundo o autor, no possvel mudar sem ter a representao do que se deseja mudar. Desta
forma, se faz necessria a criao das representaes da organizao que faro parte da
Arquitetura Empresarial. A Arquitetura Empresarial pode ser vista como um sistema de
sistemas (ARMOUR et al., 1999).
Kaisler et al. (2005) apontam os desafios enfrentados pelas organizaes que esto
desenvolvendo suas Arquiteturas Empresariais. Para tal, os autores basearam-se em sua
experincia na implantao de AEs e em discusses com outros arquitetos de sistemas. Para
os autores, tais desafios esto muito mais relacionados com questes polticas, de gesto de
projetos e problemas e fraquezas organizacionais do que com questes tcnicas, devido ao
fato da criao da Arquitetura Empresarial ser conceitual, assim mais difcil, tanto
qualitativamente quanto quantitativamente, medir e descrever os benefcios de sua criao.
Trs reas onde os problemas crticos no processo de gerar a AE ocorrem so: modelagem,
gesto e manuteno das arquiteturas (KAISLER et al., 2005).
18

A modelagem cria as representaes da Arquitetura Empresarial. Segundo Kaisler et

al. (2005), a modelagem deve ser feita em dois nveis, um onde so criadas as representao
de como a arquitetura e como deveria ser e um outro que permita aos stakeholders entender
os problemas e o impacto das decises. Vale ressaltar que diferentes stakeholders necessitam
diferentes perspectivas atravs das vises da Arquitetura Empresarial (Kaisler et al., 2005),
portanto no adianta gerar um modelo perfeito se no trar vantagem para os times envolvidos
no projeto (KAISLER et al., 2005). O problema a ser solucionado nessa dissertao encontrase nas representaes da Arquitetura Empresarial. A soluo proposta nessa dissertao
auxilia no entendimento do impacto das decises, mais especificamente das modificaes,
porque os interesses transversais sero explicitados e representados separadamente das demais
representaes da organizao, qualquer modificao naquele conceito que representa o
interesse transversal dever ser refletida em todos os lugares onde ele ocorre, isso
representado pelo relacionamento transversal.
Uma viso arquitetural um ponto de vista bem definido que descreve um conjunto
especfico de representaes. A maioria dos frameworks de AE reconhece a necessidade de
vises, porm tendem a discordar do que so essas vises e de quantas devem existir
(ARMOUR et al., 2003). Vises arquiteturais diversas auxiliam a gerir a complexidade, a
separao de interesses ou preocupaes e a enderear as diferentes existncias que
atravessam os elementos da arquitetura (ARMOUR et al., 1999). Cada viso composta por
elementos, relacionamentos e restries. As vises fornecem uma imagem de como sistemas
de informao individuais enquadram-se na estrutura maior que suporta as operaes
organizacionais (ARMOUR et al., 2003). Para Armour et al. (2003), as vises arquiteturais
dos frameworks focam em dados ou informao, funes ou processos, estruturas de trabalho
ou organizacional, infra-estrutura tcnica, segurana e aplicaes (ARMOUR et al., 2003).
Segundo Armour et al. (2003), os usurios possuem requisitos funcionais e no
funcionais que so transversais Arquitetura Empresarial, tornando necessria uma
coordenao e gesto mais prxima dos times e localidades. Desta forma, as vises devem
tambm representar os requisitos transversais de forma a auxiliar gesto dos mesmos. Com a
soluo do problema apresentado nessa dissertao, os requisitos podero ser mais facilmente
entendidos no nvel organizacional.
Nessa dissertao, tratado um problema de modelagem na Arquitetura Empresarial,
j que os interesses transversais so repetidos nos diversos artefatos utilizados para
19

representar a Arquitetura Empresarial de uma empresa. Alm de repetidos, esto espalhados e

entrelaados com outros interesses (CAPPELLI et al., 2010a).
2.2.1. Linguagens para modelagem da Arquitetura Empresarial
Clark et al. (2011) propem um framework de AE simples, que v a organizao como
um mecanismo que executado em termos de componentes de comunicao
hierarquicamente decompostos, chamado LEAP. Esta uma linguagem de modelagem da AE
precisa, pois suporta restries escritas em OCL (Object Constraint Language), possui
semntica de domnio e requer a modelagem dos relacionamentos entre diferentes vises. Esta
linguagem pode ser mapeada diretamente para outras tecnologias da AE. O LEAP baseado
em modelos e todos os seus componentes so modelados a partir da camada de negcio que
captura os conceitos de negcio e as restries relativas aos business drivers, diretivas e
processos. A camada de aplicao um refinamento da camada de negcio, ou seja, um
ponto de vista mais detalhado da mesma organizao, nesta camada so adicionados estrutura
organizacional e os processos de negcio associados s informaes presentes na camada de
negcio. A camada de tecnologia um refinamento da camada de aplicao, introduzindo
mais detalhes do mapeamento de componentes lgicos de negcio para sua realizao fsica
na forma de sistemas de TI. Os mapeamentos entre camadas so modelados de forma a
garantir que nenhuma informao ser perdida. O LEAP tambm permite que mudanas na
rea de negcio sejam modeladas, descrevendo em um modelo o estado atual e em outro o
estado futuro. O diferencial desta abordagem, segundo os autores, o requisito de modelar os
relacionamentos entre diferentes camadas e estados da organizao. Alm disso, de acordo
com os autores, esta abordagem tambm possui semntica associada e isso permite que os
modelos sejam verificados.
No ArchiMate, uma outra linguagem para modelagem da Arquitetura Empresarial,
existe um limite de camadas: negcio, aplicao e tecnologia, porm no LEAP os modelos
podem ser refinados inmeras vezes, aumentado cada vez mais o detalhamento dos
elementos. O mapeamento entre LEAP e ArchiMate simples, com base em um UML profile.
Em termos de mtodos da Arquitetura Empresarial, o LEAP pode ser usado para adicionar
preciso aos modelos do ArchiMate ou o ArchiMate pode ser usado para documentar os
modelos baseados no LEAP.
Clark et al. (2011) apresentam um estudo de caso para prover uma viso geral do
framework LEAP. Segundo os autores, este framework no requer uma notao especfica, no
20

estudo de caso a UML foi utilizada. O estudo de caso refere-se a uma instituio de ensino na
Inglaterra, nesta instituio os recursos utilizados para ensino e aprendizagem no esto
alinhados e alguns mdulos de cursos assumem que todos os alunos possuem notebooks, mas
este no o caso. Diante desta situao, a instituio decide adotar um esquema para
emprstimo de notebooks utilizando a AE com objetivo de determinar se a adoo deste novo
esquema est de acordo com suas metas e entender como esta nova arquitetura funcionar.
O primeiro passo na anlise da Arquitetura Empresarial entender o estado atual da
organizao, que neste estudo de caso refere-se descrio das estruturas de informao
relacionadas a aluno, ensino e aprendizagem. O resultado desta fase inicial apresentado na
Figura 8, onde o componente university o nico componente que define as estruturas de
informao e as operaes que sero afetadas pelo esquema de emprstimo de notebooks.
Este modelo descreve a camada de negcio conforme definido pelo ArchiMate.

Figura 8 Camada de negcio da situao atual da UME (University of Middle England)

Os objetivos da camada de negcio e as operaes so especificados utilizando-se
OCL, Os objetivos representados atravs de invariantes so apresentados na Figura 9 e uma
das operaes (como o aluno registrado) apresentada na Figura 10.

Figura 9 Objetivo da camada de negcio

Figura 10 Como o aluno registrado

21

O refinamento da Figura 8 gera a Figura 11, onde est representada a camada de

aplicao da UME. Neste refinamento, dois componentes so identificados: registry e
resource. O primeiro responsvel pela manuteno da base de dados dos alunos e seus
mdulos, j o segundo mantm a base de dados dos agendamentos das salas.

Figura 11 Camada de aplicao

No refinamento tem-se definido como cada operao da camada de negcio
implementada na camada de aplicao. Na Figura 12 apresentado o refinamento das
operaes da camada de negcio implementado por um nmero de operaes de coordenao
da camada de aplicao.

Figura 12 Refinamento da camada de negcio

Para realizar a verificao do refinamento deve haver a satisfao da condio de que
todos os modelos semnticos que satisfazem a camada de aplicao tambm satisfazem a
camada de negcio e vice-versa. O mesmo tambm deve ser vlido para as operaes.
Aps a criao da representao da situao atual so criadas as representaes de
como dever ser a organizao. Na Figura 13 apresentado o modelo To-Be da camada de
negcio, foram includos dois conceitos: Laptop e LaptopBooking. Novas operaes tambm
foram includas e esto representadas na Figura 14.
22

Figura 13 TO-BE da UME

Figura 14 Operaes includas no To-Be da Camada de Negcio

Com o refinamento da camada de negcio, obtm-se a camada de aplicao,
representada na Figura 15. Conforme realizado na camada de negcio, as novas operaes
tambm precisam ser definidas na camada de aplicao (Figura 16).

Figura 15 To-Be da Camada de Aplicao

23

Figura 16 Refinamento Camada de Aplicao

Depois da elaborao dos modelos possvel definir os objetivos de negcio. O LEAP
permite definir os objetivos de forma precisa e verificar se eles so satisfeitos pelos modelos
da arquitetura. Alm disso, por ser um modelo baseado em semntica possvel verificar se
os objetivos so inconsistentes.
A UME precisa garantir que todos os alunos possuam acesso aos laptops. Os laptops
so comprados no incio do ano letivo. Considerando que a renda da instituio proveniente
dos pagamentos dos alunos, os fundos da instituio podem ser expressos pela restrio
apresentada na Figura 17.

Figura 17 Definio dos fundos da instituio

As demais invariantes especificam o clculo do nmero mximo de salas e do nmero
mximo de alunos matriculados e as restries de que o fundo da instituio deve ser maior
que zero e o nmero de laptops deve ser igual ao nmero mximo de alunos matriculados em
determinado mdulo. Estas invariantes esto representadas na Figura 18.

Figura 18 Definio dos fundos da instituio

24

A UME possui os seguintes business drivers: seus fundos devem sempre ser positivos
e sua reputao deve melhorar ao disponibilizar laptops para aluguel para todos os alunos. Se
no houver um modelo preciso que expresse a relao entre ganhos e perdas, no ser
possvel verificar se as metas so atingveis. Deve-se verificar se existe algum caso em que o
resultado da relao entre as variveis envolvidas nos objetivos no satisfaz as condies, se
este caso for identificado a relao deve ser aprimorada de forma a garantir que o objetivo
ser atingido em todos os casos.
Armour et al. (2003) descrevem como utilizar modelos padro da UML para descrever
a viso arquitetural da informao e algumas extenses para enderear limitaes da UML.
Arquitetura define um conjunto de componentes e os relacionamentos entre eles, no caso da
Arquitetura Empresarial de Tecnologia da Informao, um dos componentes so os sistemas.
A criao de uma AE muito complexa, pois envolve mltiplas vises organizacionais, como
processos de negcio, estrutura organizacional, processos funcionais, requisitos de
informao e infra-estrutura tecnolgica. tambm importante manter atualizadas as
representaes e as vises geradas pela AE. Neste trabalho foram apresentadas extenses
desenvolvidas atravs do uso de stereotypes e tagged fields para permitir a representao das
diversas vises da Arquitetura Empresarial.
Os autores descrevem o estudo de caso baseado em seu trabalho desenvolvido no
USCP (United States Capitol Police). O USCP responsvel por diversos sistemas
administrativos que formam uma coleo heterognea de sistemas legados. A manuteno e
operao de tais sistemas difcil e cara. Estes sistemas legados no conseguem acompanhar
o ritmo dos processos de negcio do USCP. Devido a estes problemas, o USCP iniciou um
processo de modernizao dos sistemas de negcio. Esta modernizao far com que os
sistemas se tornem web, algumas aplicaes que possuem interface com sistemas externos
tambm tero seus links modernizados. Por ser um projeto grande e atingir toda a
organizao, o USCP determinou a criao de uma AE.
A viso de negcio da AE permite o entendimento de como a organizao funciona e
como alinhar sistemas de informao para dar suporte s operaes de negcio, os autores
selecionaram as seguintes tcnicas para modelar a viso de negcio: Enterprise Business
Context Diagrams (Figura 19) e Business Activity Diagrams (Figura 20).

25

Figura 19 Diagrama de Contexto de Negcio do USCP

Na Figura 20 so representadas as atividades do processo de pagamento por perodo e
quase todas as atividades possuem a indicao do caso de uso que prov detalhes funcionais
das atividades, esta informao, segundo os autores, relevante e maiores detalhes sero
disponibilizados na viso funcional.
A viso funcional descreve os sistemas de informao do negcio ou atividades que
capturam, manipulam ou gerenciam as informaes de negcio que apoiam as operaes da
organizao. nesta viso tambm que so representadas as dependncias lgicas e os
relacionamentos entre aplicaes e suas funes. A abordagem escolhida pelos autores para
representar esta viso a modelagem de casos de uso. Para cada uma dos BPA (Business
Application Packages) apresentado na viso de negcio ser gerado um modelo de caso de
uso. Na Figura 21 apresentado o diagrama de caso de uso do BAP Pessoal.

26

Figura 20 Diagrama do Processo Pagamento por Perodo

27

Outras vises arquiteturais so apresentadas de forma breve pelos autores, sendo elas:
viso da informao, viso de trabalho e viso de infra-estrutura tecnolgica.

Figura 21 Diagrama de caso de uso do BAP pessoal

2.3. Ontologia Empresarial

Segundo Dietz e Hoogervorst (2008), as cincias organizacionais tradicionais
conseguem ajudar muito pouco as organizaes a implementar suas estratgias de forma
efetiva e controlada, ou seja, as organizaes dificilmente conseguem obter sucesso a partir de
sua estratgia. Ainda segundo Dietz e Hoogervorst (2008), diversas fontes indicam que as
principais razes para esta falha a falta de coerncia e consistncia entre os diversos
componentes de uma empresa. Alm disso, operar de forma integrada tem se tornado cada vez
mais importante com a globalizao e evoluo das tecnologias de informao e
comunicao. Assim as empresas precisam cada vez mais ser geis, adaptativas e
transparentes (DIETZ e HOOGERVORST, 2008).
Os problemas citados acima so endereados tradicionalmente com a forma de pensar
denominada caixa-preta. Essa forma de pensar trata do conhecimento sobre funo e
comportamento das organizaes. De acordo com Dietz e Hoogervorst (2008), esse
28

conhecimento suficiente para gerir uma organizao, mas inadequado para alcanar as
metas estratgicas e para realizar modificaes na organizao. Para que as mudanas sejam
realizadas de forma controlada e sistemtica, o conhecimento caixa-branca se faz necessrio.
Esse conhecimento sobre a construo e operao das organizaes. O novo ponto de vista
para esse conhecimento que as organizaes so sistemas propositalmente projetados,
passam pelo processo de engenharia (engineered) e implementados. Segundo os autores, as
organizaes so artefatos projetados, como carros, sistemas de informao, entre outros. A
propriedade que distingue as organizaes dos demais que os elementos ativos so os seres
humanos, mais especificamente os seres humanos no seu papel de indivduos sociais ou
sujeitos (DIETZ e HOOGERVORST, 2008).
Dietz e Hoogervorst (2008) afirmam que de um lado existem as tecnologias que
habilitam as organizaes forma futura e de outro lado existe uma crescente introspeco
das cincias da computao que a noo central para entender o relacionamento entre
organizao e TI fazer parte e cumprir os compromissos. Esses compromissos ocorrem
atravs da inteno dos atos comunicativos. Aqui a inteno da comunicao colocada
acima de seu contedo. Exemplos de inteno so solicitar, prometer, afirmar e aceitar. Essa
mudana de ponto de vista explica e clarifica as noes de colaborao e cooperao,
autoridade e responsabilidade. Assim, segundo Dietz e Hoogervorst (2008), essa mudana de
ponto de vista marca a transio da engenharia de sistemas de informao para a era da
engenharia da organizao.
Segundo Dietz e Hoogervorst (2008), a premissa bsica para engenharia da
organizao que a organizao um sistema projetado e no algo que vai acontecendo de
qualquer forma. Para garantir que esse projeto seja realizado consistentemente e
coerentemente, de tal forma que o resultado seja um todo integrado, 2 noes so
indispensveis: arquitetura e ontologia .
Segundo Dietz (2006), um artefato algo projetado e construdo, diferentemente de
coisas que existem naturalmente. Arquitetura de um artefato, segundo ele, um conjunto de
princpios de design que guiam ou que guiaro seu projeto.
Ontologia de um sistema teoricamente definida como o entendimento de sua
construo e operao de forma independente de implementao. Praticamente o modelo de
construo de mais alto nvel de um sistema. O modelo de implementao o modelo de mais
baixo nvel. Comparado ao modelo de implementao, o modelo ontolgico oferece uma
29

reduo de complexidade de mais de 90%. Por exemplo, o modelo de implementao de um

sistema de informao o cdigo fonte em alguma linguagem de programao. O modelo de
implementao de uma organizao consiste das funes ou pacotes de tarefas que podem ser
atribudos a seres humanos com base em sua competncia. O modelo mais alto chamado
modelo ontolgico ou ontologia de um sistema, esse modelo completamente independente
de implementao, ele apenas mostra as caractersticas essenciais do sistema.
Essa noo de Ontologia Empresarial, segundo DIETZ e HOOGERVORST (2008),
difere das demais (GMEZ-PREZ, FERNNDEZ-LPEZ e CORCHO, 2004; GRUBER,
1995; GUARINO, 1998) em 2 aspectos: a noo de ontologia de sistema onde o foco
entender a essncia da construo e operao de sistemas complexos, mais especificamente de
organizaes, diferentemente das demais que adotam a noo de ontologia do mundo onde o
foco definir as entidades centrais do mundo em questo e seus relacionamentos de forma
mais clara e extensiva. Vale destacar que a noo de ontologia de sistema engloba a noo de
ontologia do mundo. A noo de ontologia de sistema baseada na teoria da operao de um
sistema, no caso dos autores, a base a teoria PSI (Performance in Social Interaction). Essa
teoria fornece uma modelagem ontolgica para organizaes que cobre questes estruturais,
de processos e de aes de forma que os modelos resultantes podem ser executados ou
simulados, essa a teoria de fundamentao apresentada por Dietz (2006) para construo da
ontologia empresarial. O segundo aspecto diz respeito incapacidade da noo comum de
ontologia empresarial em distinguir de forma precisa e clara entre os nveis de abstrao
ontolgico, infolgico e datalgico. Esses nveis de abstrao esto relacionados com 3
habilidades humanas que so exercidas tanto em atos de coordenao quanto em atos de
produo (DIETZ, 2006). Nos atos de coordenao, a habilidade forma refere-se a aspectos de
forma, a habilidade informa refere-se a aspectos de contedo e a habilidade performa referese a estar engajado em compromissos. Nos atos de produo, a habilidade forma refere-se
produo documental ou datalgica, a habilidade informa refere-se produo informacional
ou infolgica e a habilidade performa refere-se produo essencial de uma organizao
como, por exemplo, realizar novos fatos originais, esse tipo de produo chamada
ontolgica.
O objetivo da ontologia empresarial oferecer um novo entendimento das
organizaes de tal forma que uma pessoa possa ser capaz de olhar atravs de sua aparncia
confusa diretamente para sua essncia profunda (DIETZ e HOOGERVORST, 2008). DEMO
uma abordagem de ontologia empresarial baseada na teoria PSI. De acordo com a distino
30

dessa teoria entre funo e construo de um sistema, os servios coletivos que a empresa
prov ao seu ambiente so denominados como o negcio da organizao, eles representam a
perspectiva da funo. As atividades da empresa nas quais o negcio da organizao
realizado e entregue, incluindo os atores que realizam essas atividades so denominados
coletivamente a organizao da empresa, eles representam a perspectiva da construo.
De acordo com a teoria PSI, os sujeitos realizam atos de produo e atos de
coordenao (DIETZ, 2006). Ao realizar atos de produo, os sujeitos contribuem para
realizar os bens e servios que so entregues ao ambiente da organizao. Um ato de
produo pode ser material, como transporte ou fabricao ou imaterial como deciso,
julgamento e venda de bens. Ao realizar atos de coordenao os sujeitos estabelecem e
respeitam seus compromissos um para com o outro considerando a realizao dos atos de
produo. Exemplos de atos de coordenao so solicitar, prometer e rejeitar. O efeito de
realizar um ato de coordenao que tanto o realizador quanto o endereado do ato esto
envolvidos em compromissos com relao realizao do ato de produo correspondente.
Os atos de coordenao e produo ocorrem de acordo com um padro, denominado
transao, representado na Figura 22. Realizar atos de coordenao no significa
necessariamente comunicao oral ou escrita, em muitos casos isso ocorre tacitamente.

Figura 22 Transao
Uma transao envolve trs fases: fase de ordenao, fase de execuo e fase de
resultado. Na fase de ordenao, o iniciador e o executor negociam para chegar ao consenso
sobre o fato de produo que o executor realizar. Os principais atos de coordenao dessa
fase so solicitar e prometer. A fase de execuo onde o ato de produo realizado pelo
executor. Na fase de resultado, o iniciador e o executor negociam para alcanar consenso
sobre o fato de produo que foi realmente produzido (que pode ser diferente do que foi
solicitado). Os principais atos de coordenao dessa fase so afirmar e aceitar. Na Figura 22

31

representado o fluxo mais simples, porm sabe-se que pode haver excees. Os casos de
rejeitar e recusar so apresentados em Dietz (2006).
Os termos iniciador e executor substituem os termos cliente e produtor que so mais
comuns. Mais do que isso, eles fazem referncia a papis de ator ao invs de sujeitos. Os
papis de ator so definidos como a autoridade e responsabilidade para ser o executor de um
tipo de transao. Os papis de ator so cumpridos por sujeitos. Os sujeitos podem cumprir
diversos papis de ator. Em geral, papis de ator no so mapeados simplesmente para
unidades organizacionais ou funes (DIETZ, 2006). Um sujeito no cumprimento de seu
papel denominado ator.
Na Figura 23 apresentado o padro de transao bsico decomposto em atos de
produo e coordenao e fatos de produo e coordenao. Os atos de produo e
coordenao so as atividades realizadas pelos papis de ator no cumprimento de sua
responsabilidade e autoridade. Esses atos possuem resultados definitivos que so os fatos de
produo e coordenao respectivamente. Os quadrados representam os atos e os crculos
representam os fatos. Em cinza esto representados o ato de produo (quadrado) e o fato de
produo (losango).

Figura 23 Padro Transao Bsico

Na Figura 24 apresentado o padro de transao bsico condensado, onde os atos e
fatos so representados por smbolos compostos: quadrado e crculo para atos e fatos de
coordenao e quadrado e losango para atos e fatos de produo. Essa forma mais condensada
utilizada para denotar os blocos moleculares que compem a organizao. Essa
representao utilizada no Diagrama de Transao de Ator (DIETZ, 2006).

32

Figura 24 Bloco molecular

Na Figura 25 apresentado o padro de transao bsico resumido, onde os atos e
fatos que compem o padro de transao so condensados em um nico smbolo que
representa os tipos de transao. Essa notao utilizada no IAM (InterAction Model)
(DIETZ, 2006), onde temos os tomos que compem a organizao. Segundo relato do
prprio autor da metodologia, o CM (Construction Model) o nico modelo realmente
utilizado nos projetos reais (DIETZ et al., 2005).

Figura 25 Bloco atmico

Para entender a operao essencial da organizao necessrio conhecer a distino
entre 3 habilidades humanas que so exercidas tanto em atos de coordenao quanto em atos
de produo (DIETZ, 2006). Com relao coordenao, a habilidade forma refere-se a
aspectos de forma, a habilidade informa refere-se a aspectos de contedo e a habilidade
performa refere-se a estar engajado em compromissos. J na produo, a habilidade forma
refere-se produo documental ou datalgica, a habilidade informa refere-se produo
informacional ou infolgica e a habilidade performa refere-se produo essencial de uma
organizao como, por exemplo, realizar novos fatos originais, esse tipo de produo
chamada ontolgica.

33

A primeira abstrao feita pela teoria PSI para se chegar ao modelo ontolgico de uma
organizao considerar apenas a habilidade performa, tanto na coordenao quanto na
produo. A segunda abstrao consiste em aplicar o padro de transao universal conforme
representado na Figura 16. Em resumo, de acordo com a teoria PSI, performa a habilidade
humana essencial para fazer negcio de qualquer tipo considerando tanto coordenao quando
produo.
2.3.1. Gerao das representaes da Ontologia Empresarial
Em Dietz (2006) so descritos os passos para se obter uma base para gerar os modelos
da Ontologia Empresarial. Esses passos so listados abaixo:
1) A anlise performa/informa/forma: de acordo com o axioma da distino, cada trecho
de representao organizacional deve ser analisado para verificar se h criao de
conhecimento, como uma tomada de deciso ou a produo de coisa nova, que no
existia at ser elaborada. Os trechos que atendem a essas condies so a base para
gerao dos modelos da Ontologia Empresarial (DIETZ, 2006). Os trechos de
representao podem ser atividades de um modelo de processo, mtodos de uma
classe, frases de uma descrio etc.
2) A anlise coordenao/atores/produo: nesse passo, so identificados os atosC/resultados, atos-P/resultados e papis de ator referentes aos itens identificados no
passo 1 de acordo com o axioma da operao
3) A sntese do padro de transao: o padro de transao justaposto sobre os
resultados obtidos at ento, como um template, para reuni-los por tipo de transao.
Em seguida, para cada tipo de transao, o tipo de resultado formulado e a Tabela de
Resultado da Transao (TRT Transaction Result Table) pode ser elaborada.
4) A anlise da estrutura de resultado: todo tipo de transao na qual o ator do ambiente
o iniciador pode ser concebida como a entrega de um resultado final ao ambiente.
Geralmente, o executor interno desse tipo de transao o iniciador de um ou mais
outros tipos de transao. O resultado dessas transaes em cascata pode ser visto
como componentes do resultado final.
5) A sntese da construo: para cada tipo de transao, os papis de ator iniciadores e
executores so identificados, com base no axioma da transao. Esse o primeiro
passo na produo do Diagrama de Transao do Ator (ATD Actor Transaction
Diagram).
34

6) A sntese da organizao: uma escolha definitiva tem que ser feita sobre qual parte da
construo ser considerada como a organizao a ser estudada e qual parte ser seu
ambiente. O Diagrama de Transao do Ator pode ser finalizado. Segundo o Dietz
(2006) deve-se ter em mente que esse passo a passo um apoio e no um dogma.
Assim possvel executar os passos em ordem livre ou at mesmo pular um deles.

Ao concluir estes 6 passos, tem-se o IAM (InterAction Model). O IAM parte do CM

(Construction Model). Segundo Dietz (2006) o IAM o modelo ontolgico mais compacto
de uma empresa, juntamente com o Modelo de Interseo (InterSection Model). Mas mesmo
assim contem muita informao para aplicaes prticas teis (DIETZ, 2006 pgina 170). A
relevncia prtica do IAM, segundo Dietz (2006), que ele mostra a fronteira da organizao,
ou seja, os clientes e fornecedores e isso til para discusses de alinhamento estratgico.
Alm disso, o padro de transao facilita a ateno ao relacionamento com os clientes; as
unidades de competncia, responsabilidade e autoridade auxiliam na identificao e
classificao das funes organizacionais e por ser compacto possvel ter um mapa
organizacional visvel em papel A3 e gerencivel (DIETZ, 2006).
No mtodo de modelagem DEMO existem 4 modelos: o Modelo de Construo (CM
Construction Model), o Modelo de Processo (PM Process Model), o Modelo de Ao (AM Action Model) e o Modelo de Estado (SM - State Model). Juntos, esses modelos representam
o conhecimento ontolgico completo de uma organizao.
O CM especifica a construo da organizao, ele especifica os tipos de transao
identificados, os papis de ator associados a cada tipo de transao e as ligaes entre os
papis de ator e os bancos de informao (information bank representa o banco de produo
e o banco de coordenao onde devem ser armazenadas informaes necessrias para que os
papis de ator realizem seus atos). Esse o modelo mais conciso, ele composto de dois
modelos: o IAM InterAction Model e o ISM InterStriction Model. O IAM mostra a
execuo das transaes, ou seja, as influncias ativas entre os atores. J o ISM mostra as
influncias passivas entre os papis de ator, ou seja, os papis de ator tomam cincia dos fatos
existentes quando ativos. A representao do CM realizada atravs do Diagrama da
Construo Organizacional (OCD Organization Construction Diagram), ele composto
pelo Diagrama de Transao do Ator (ATD - Actor Transaction Diagram) e pelo Diagrama
de Banco do Ator (ABD - Actor Bank Diagram). A Tabela de Resultado da Transao
35

(Transaction Result Table) e a Tabela de Contedo do Banco (Bank Contents Table) tambm
fazem parte do OCD.
Cada tipo de transao do CM (Construction Model) representado segundo o padro
de transao no PM (Process Model). Alm disso, tambm so representadas as relaes
condicionais e causais entre as transaes. O PM o primeiro nvel de detalhe depois do CM.
A representao do PM realizada atravs do Diagrama de Estrutura de Processo (PSD
Process Structure Diagram) e da Tabela de Uso da Informao (IUT Information Use
Table).
O AM (Action Model) especifica as regras de ao a serem tomadas pelos papis de
ator para lidarem com sua agenda. Para cada tipo de agendum, o AM contem uma ou mais
regras de ao, elas so agrupadas por papel de ator. O AM o segundo nvel de
detalhamento do CM, isso significa que ele detalha os passos identificados no PM dos tipos
de transao identificados no CM. Considerando o nvel ontolgico, no h nada abaixo do
AM. O AM , segundo Dietz (2006), a base dos outros modelos, pois contem toda a
informao tambm presente nos demais (CM, PM e SM), mas de forma diferente e no to
facilmente acessvel. A representao do AM realizada atravs das Especificaes das
Regras de Ao (ARS Action Rule Diagram).
O SM (State Model) especifica as classes de objetos e os tipos de fatos, os tipos de
resultados e as regras de coexistncia ontolgica, ou seja, o espao de estado do mundo-P. O
SM diretamente baseado no AM, mas ao mesmo tempo ele o detalhamento de uma parte
do CM (os bancos de produo e coordenao). A representao do SM realizada atravs do
Diagrama de Fato do Objeto (OFD - Object Fact Diagram) e de uma Lista de Propriedades do
Objeto (OPL - Object Property List).
Assim, a sequencia de criao dos modelos : IAM, mais especificamente o ATD e a
TRT. Em seguida o PSD criado e ento o ARS. Depois disso, o SM pode ser elaborado
atravs do OFD e de uma Lista de Propriedades do Objeto (OPL - Object Property List). Em
seguida, j possvel completar o PM com a Tabela de Uso da Informao (IUT
Information Use Table). Por fim, o ISM produzido, ele consiste de um Diagrama de Banco
de Ator (ABD Actor Bank Diagram) e de uma Tabela de Contedo de Banco (BCT Bank
Contents Table). O ABD pode ser uma extenso do ATD.

36

Por ser o modelo mais conciso, na fase IDENTIFICAR do mtodo proposto nessa
dissertao ser utilizado o modelo CM composto pelo Diagrama de Transao do Ator (ATD
Actor Transaction Diagram) e pela Tabela de Resultado da Transao (TRT Transaction
Result Table) como em (DIETZ e HOOGERVORST, 2008). Nesse diagrama so
representados os atores e as transaes que fazem parte da essncia da organizao.
2.3.2. Exemplo
Em Dietz e Hoogervorst (2008) apresentado o caso de uma instituio de ensino,
descrito abaixo:
O Instituto de Tecnologia da Holanda (ITH) uma universidade de tecnologia,
composta de 15 escolas, em 7 faculdades nas quais so oferecidos programas de bacharelado e
mestrado em diversas reas tecnolgicas. Uma delas a escola de Arquitetura da Informao
(AI). Essa escola oferece um programa de mestrado de 2 anos com o mesmo nome.
Informaes gerais sobre o programa podem ser encontradas no site (pblico) da escola.
Embora a maioria dos estudantes que participam do programa IA tenham bacharelado em
cincia da computao ou em engenharia de sistemas, anlise de polticas e gesto (ESAPG)
do prprio HIT, tambm existem estudantes de outras universidades, a princpio de todo o
mundo, que participam do programa de mestrado AI. Na escola existe um Departamento de
Administrao Educacional (DAE) que lida com questes admissionais com relao ao
programa de mestrado. As atividades operacionais desse departamento sero descritas a
seguir.
A primeira coisa que os alunos tem que fazer se quiserem participar do programa AI
solicitar a admisso. Para isso eles precisam preencher o Formulrio de Admisso do
Programa, o qual pode ser baixado em pdf a partir do site da escola. A pessoa precisa
adicionar cpias do diploma de bacharelado que possua ou do diploma que considera como
alternativa (por exemplo, um diploma de mestrado). As solicitaes de admisso so
recolhidas e processadas pelo Escritrio de Admisso da DAE. As regras para admisso so:
- estudantes com bacharelado em cincia da computao do ITH ou de qualquer outra
universidade holandesa so diretamente aceitos;
- estudantes com bacharelado no ESAPG do ITH ou bacharelado em administrao de
negcio de uma universidade holandesa so diretamente aceitos;
37

- estudantes com bacharelado de uma universidade da lista negra, bem como

estudantes sem bacharelado ou equivalente no so admitidos.
Em caso de dvida, a solicitao de admisso direcionada ao Diretor do Programa do
IA para aprovao. Assim o Diretor do Programa decide os casos excepcionais. Com o passar
do tempo, isso pode levar adaptaes das regras de admisso aplicadas pelo Escritrio de
Admisso. Admisses aceitas so digitadas no Sistema de Administrao do Mestrado IA
(SAMIA). Uma confirmao da admisso enviada para o estudante por email, bem como
atravs de carta que entregue pelo servio postal pblico.
Aps ter sido admitido, os estudantes tem que se inscrever no curso que desejam
seguir por meio do Sistema WhiteBoard. O programa completo e o agendamento dos cursos
podem ser encontrados no site da escola. Inscries bem sucedidas so confirmadas aos
estudantes atravs de uma mensagem de email. O Sistema WhiteBoard tambm usado para
todo tipo de comunicao entre os instrutores dos cursos e os estudantes.
O agendamento de cursos tambm uma tarefa do DAE. Agendamento de cursos
significa que tem que ser encontrado um horrio vago e uma sala para o curso de tal forma
que no haja conflito entre aulas. Assim os estudantes podem sempre se inscrever nos cursos
que queiram. Um horrio de aula consiste de duas horas de aula consecutivas. Uma hora de
aula corresponde a 45 minutos, que tradicionalmente comea com 15 minutos de tempo livre.
Um dia de semana tem 8 horas aula, geralmente identificadas pelos nmeros de 1 a 8. Assim,
por exemplo, um horrio de aula sexta-feira quinta e sexta hora. O ano do curso dividido
em 4 perodos de 9 semanas. Aulas so dadas nas primeiras 7 semanas. A oitava semana
livre para estudo e a nona semana quando acontecem os exames. A disponibilidade de
professor no considerada enquanto o agendamento do curso feito, o que significa que
considerado que esto disponveis. Claro que conflitos de horrio para os professores so
evitados.
Exames so agendados para a manh (9h-12h) ou para a tarde (14h-17h) nos dias de
semana da nona semana de um perodo. Isso tambm tarefa do DAE. Os alunos precisam se
registrar explicitamente nos exames via EARS. O sistema produz uma lista de todos os alunos
registrados para um exame que enviada ao examinador (que geralmente o mesmo
professor do curso). Aps avaliar as respostas dos alunos, os examinadores escrevem as notas
na lista e envia de volta para o DAE. Esses dados so processados pelo EARS. Por questes
de segurana, os alunos no podem verificar suas notas on line. Ao invs disso, eles devem ir
38

ao DAE e pedir suas notas impressas. As notas por curso tambm so publicadas no Sistema
WhiteBoard. Elas podem ser acessadas pelos estudantes com base em suas informaes
pessoais cdigo de usurio e senha.
Se um aluno passou em todos os exames do AI, ele pode receber o diploma. Para obter
o diploma, ele deve preencher o Formulrio de Solicitao de Diploma que pode ser baixado
do site da escola. Esse formulrio deve ser enviado ao DAE que envia os mesmos para
Conselho de Diploma. Esse conselho formalmente decide sobre a emisso de diplomas. O
DAE registra essas decises.
Com base nesse caso, o Diagrama de Transao de Ator criado, representado na
Figura 26. As seguintes transaes ontolgicas foram identificadas: admisso ao programa,
aprovao da admisso, inscrio no curso, registro no exame, agendamento do exame, gesto
do exame, programao do curso e gesto do curso.

Figura 26 Diagrama de Transao de Ator da DAE

Vale destacar que transaes como avaliao de exames no responsabilidade do
DAE e, portanto, no foi includa no diagrama representa do na Figura 26. Segundo os
autores, o diagrama juntamente com a Tabela de Resultado das Transaes complemente
independente de implementao. Eles fornecem um relato compreensivo, coerente,
consistente e conciso da essncia das atividades operacionais do DAE. Eles no contm
qualquer ponto referente implementao, como documentos, formulrios e registros ou
qualquer canal de comunicao concreto como cartas ou email. Dietz e Hoogervorst (2008)
afirmam que escolher o meio mais apropriado de implementao uma questo de engenharia
39

(ou projeto detalhado) que guiado pela aplicao de princpios arquiteturais e o nvel
ontolgico de abstrao oferece a liberdade de projeto para isso (DIETZ e HOOGERVORST,
2008).

2.4. Resumo
Nesse captulo foram apresentados de forma resumida alguns frameworks de
Arquitetura Empresarial e alguns problemas da Arquitetura Empresarial. Nessa dissertao o
problema que iremos focar encontra-se na modelagem, mais especificamente nas
representaes geradas pelas organizaes para apresentar sua arquitetura.
Complementar noo de Arquitetura Empresarial a noo de Ontologia
Empresarial, tambm apresentada nesse captulo. Essa noo especialmente importante, pois
ser utilizada no mtodo proposto para resolver o problema do espalhamento e
entrelaamentos dos interesses transversais na Arquitetura Empresarial apresentado no
Captulo 1.

40

3. Orientao a Aspectos em Sistemas de Informao

Neste captulo so apresentados os conceitos gerais da orientao a aspectos, descrita

a abordagem orientada a aspectos em algumas fases do desenvolvimento de software e na
modelagem de processos. Tambm apresentado o problema de modularizao que essa
abordagem trata em cada um desses campos de conhecimento, incluindo a prpria Arquitetura
Empresarial. A definio de interesse transversal a ser utilizada no decorrer desse trabalho
tambm ser apresentada nesse Captulo.

3.1. Conceitos gerais

No paradigma orientado a aspectos (KICZALES et al., 1997) os Aspectos so
abstraes que permitem a modularizao dos interesses transversais que atravessam todas as
representaes da Arquitetura Empresarial. Nesse contexto, eles encapsulam conjuntos de
pontos de juno, adendos. Os pontos de juno so os pontos na representao
organizacional onde o Aspecto ser aplicado. Os conjuntos de juno so definidos pelo
Aspecto e so responsveis por detectar os pontos da representao em que o Aspecto dever
atuar. Os adendos representam o conceito existente no ponto de juno referenciado nos
conjuntos de juno
Esta abordagem trs os benefcios provenientes da modularizao, onde possvel
pensar sobre diferentes interesses ou preocupaes de forma isolada, tornando-os passveis de
remoo em cada tipo de representao, possibilitando o desenvolvimento de forma separada,
aumentando as possibilidades de reuso, permitindo que o design e a criao da representao
reflitam a forma como os analistas querem pensar sobre as representaes(KICZALES et al.,
1997; ELRAD et al., 2001) e diminuindo o custo de desenvolvimento, manuteno e evoluo
(RASHID et al., 2003).
O conceito de Aspectos tambm foi incorporado em outras fases do Desenvolvimento
de Software, gerando assim o DSOA (Desenvolvimento de Software Orientado a Aspectos).
Nesta abordagem, so definidas novas abstraes e mecanismos de composio entre as
representaes existentes e os Aspectos, que caracterizam os interesses transversais. Com
41

isso, a separao de interesses permeia todas as fases do Desenvolvimento de Software

(CAPPELLI et al. 2010a).
Na literatura, existem diversas abordagens para representar os artefatos gerados pelas
fases do Desenvolvimento de Sistemas de Informao (SI) de forma modularmente mais
adequada, refletindo os interesses transversais. As abordagens que endeream os interesses
transversais so denominadas Orientadas a Aspectos. Encontram-se abordagens Orientadas
a Aspectos na elicitao de requisitos que sero apresentados na seo 3.2. Tambm existem
abordagens para representao dos interesses transversais a partir dos processos de negcio
que daro origem ao software que os apoiar. Algumas dessas abordagens sero apresentadas
na seo 3.3.

3.2. Programao orientada a aspectos

A Orientao a Aspectos surgiu no nvel de programao (KICZALES et al., 1997).
Esta tcnica, denominada Programao Orientada a Aspectos (POA), foi proposta para
enderear o problema da transversalidade em partes do cdigo, cuja implementao gera o
espalhamento e a intruso no cdigo. Alguns exemplos de interesses transversais so
segurana, garantia de integridade de transaes, registro de operaes, desempenho,
autenticao etc. (TIRELO et al., 2004). Nem a modularizao proposta pelo paradigma da
Orientao a Objetos, nem pelo paradigma Procedural so capazes de resolver os problemas
gerados na implementao de tais requisitos (KICZALES et al., 1997).
Existem dois tipos de problemas em interesses transversais: entrelaamento e
espalhamento (TIRELO et al., 2004). O entrelaamento ocorre quando o cdigo de mais de
um interesse transversal est implementado em uma mesma regio do cdigo. J o
espalhamento quando um interesse transversal encontra-se implementado em diversos
trechos do cdigo (TIRELO et al., 2004). Estes problemas evidenciam a baixa modularidade
das abordagens Orientadas a Objeto e Procedural. O resultado desta baixa modularidade a
dificuldade em gerar, manter e evoluir o cdigo do sistema.
Na POA os requisitos funcionais do sistema so implementados atravs das Classes e
os requisitos transversais aos requisitos funcionais so implementados atravs de Aspectos.
Os Aspectos no tendem a ser unidade de decomposio funcional, mas sim propriedades

42

que afetam o desempenho ou a semntica dos componentes de forma sistmica (KICZALES

et al., 1997).
A POA possui as seguintes etapas: decomposio de requisitos, implementao de
requisitos e recomposio dos requisitos. Para que estas etapas sejam possveis a
implementao da POA possui uma Linguagem de Componentes, uma Linguagem de
Aspectos e um Combinador de Aspectos. A Linguagem de componentes permite que os
requisitos do negcio (funcionais) sejam implementados. A Linguagem de Aspectos permite
que os interesses transversais aos requisitos funcionais sejam implementados, fornecendo
meios para construo das estruturas que descrevem o comportamento e definem as situaes
em que o Aspecto ocorre. J o Combinador ou Compilador de Aspectos combina os Aspectos
com os programas escritos na Linguagem de Componentes, esta ao denominada weaving
ou costura (TIRELO et al., 2004).
No programao os Aspectos so abstraes que permitem a modularizao dos
interesses transversais que atravessam todo o cdigo de um sistema (TIRELO et al., 2004).
Eles encapsulam conjuntos de pontos de juno, adendos e declaraes inter-tipo. So capazes
de alterar a estrutura esttica (atravs das declaraes inter-tipo) e dinmica de um programa
(atravs da interceptao dos pontos de juno e da adio de seu comportamento antes,
durante ou depois do ponto, em tempo de execuo).
Os pontos de juno so os pontos na execuo de um programa onde o Aspecto ser
aplicado. Os conjuntos de juno so definidos pelo Aspecto e so responsveis por detectar
os pontos do programa que o Aspecto dever interceptar. Os adendos representam o cdigo
que ser executado no ponto de juno referenciado nos conjuntos de juno, ele pode
modificar a execuo do cdigo no ponto de juno, substituir ou apenas passar por ele. O
weaving ou costura a ao de juntar novamente os interesses transversais abstrados atravs
dos Aspectos ao cdigo do software, assim o software executado como antes da orientao a
aspectos, porm ele foi escrito de forma modularmente mais adequada.

3.3. Anlise de requisitos orientada a aspectos

Na Engenharia de Requisitos so encontradas abordagens orientadas a Aspectos
(SOUZA, 2004; RASHID et al., 2003; MOREIRA et al., 2005; YU et al., 2004; BRITO e

43

MOREIRA, 2006; SILVA, 2006; SILVA, 2007) j que so percebidas vantagens quando se
obtm a modularizao adequada j na elicitao dos requisitos.
Algumas vantagens so a facilidade no rastreamento entre documentos de requisitos,
arquitetura do software e cdigo do sistema e explicitao das caractersticas transversais que
ficariam escondidas na abordagem tradicional, permitindo que a implementao em
linguagens Orientadas a Aspectos seja mais natural (SILVA, 2006).
Souza (2004) cita algumas razes que levaram a Engenharia de Software a considerar
o paradigma da Orientao a Aspectos em estgios iniciais do desenvolvimento de software:
antecipar a identificao, modelagem dos Aspectos e o raciocnio sobre os componentes
afetados por um aspecto, e como a composio entre eles deve ser feita; permitir que a
compreenso do sistema seja feita atravs dos modelos gerados nas fases de anlise e projeto
ao invs da leitura do cdigo; e trazer os benefcios da orientao a aspectos a todas as fases
do desenvolvimento, no ficando exclusivamente relacionadas codificao.
Rashid et al. (2003) propem uma abordagem para compor e modularizar os requisitos
aspectuais, esta abordagem baseada na separao de requisitos aspectuais, requisitos no
aspectuais e regras de composio, esta separao realizada em mdulos que representam
abstraes coerentes e seguem determinados templates. As regras de composio especificam
como um requisito aspectual influencia o comportamento de um requisito no aspectual.
Moreira et al. (2005) propem um modelo para decompor requisitos de forma
uniforme, no considerando a natureza do requisito, se funcional ou no. Isso possibilita a
projeo de um conjunto de requisitos em outros requisitos, esta projeo especifica a
influncia de um interesse e possvel atravs de regras de composio.
Yu et al. (2004) tentam responder questo de como identificar os Aspectos em fases
preliminares do desenvolvimento de software. Para tal, os autores propem que os Aspectos
sejam descobertos durante a anlise de requisitos orientada a metas, para tornar esta proposta
possvel, apresentado um processo sistemtico para descobrir Aspectos a partir dos
relacionamentos entre metas funcionais (goals) e no funcionais (soft-goals).
Brito e Moreira (2006) apresentam uma abordagem integrada para suportar requisitos
aspectuais, incluindo um modelo de processo, um meta-modelo que define os interesses de
forma rigorosa e uma ferramenta para dar suporte especificao dos interesses e das regras
44

de composio. As atividades do processo so basicamente identificar os interesses,

especificar os interesses e compor os interesses.
Silva (2007) realiza uma comparao entre algumas abordagens para identificao dos
interesses transversais nas fases iniciais do desenvolvimento de software. Com base nesta
comparao, prope uma abordagem mais flexvel, permitindo o suporte adaptao em
projetos de desenvolvimento de software existentes e em novos. A abordagem proposta utiliza
LEL (Lxico Extendido da Linguagem) para facilitar a identificao e separao de interesses
nos projetos que utilizam a metodologia MDSODI (Methodology for Development of
Distributed Software).
Silva (2006) prope algumas atividades, que fazem parte de um meta-modelo para
integrao de caractersticas transversais. Este meta-modelo prov, alm de atividades,
mecanismos para facilitar a modularizao, rastreabilidade, modificao e reuso de
requisitos (SILVA, 2006). A descrio e composio das caractersticas transversais so
possveis atravs de um novo construto que pode ser utilizado em linguagens de requisitos
tradicionais denominado relacionamento transversal. Devido ao foco especfico em requisitos,
os modelos que a abordagem considera so todos do mesmo tipo e representam somente os
requisitos de software.
Esse meta-modelo apresentado por Silva (2006) representado na Figura 1
fundamentado nas ideias da programao orientada a aspectos, onde h a separao e
composio das caractersticas transversais. Alm destas, o meta-modelo ainda inclui a
visualizao, indicado como essencial pela autora, por auxiliar na anlise e especificao do
problema a ser resolvido pelo software.

Figura 27 Meta-modelo para Integrao de Caractersticas Transversais durante a Definio

de Requisitos (SILVA, 2006)

45

Na abordagem de Silva (2006) foi definida uma linguagem de modelagem de

requisitos orientada aspectos (LMROA) que estende as linguagens de modelagem de
requisitos ao incluir o relacionamento transversal. Alm de registrar a interao entre as
caractersticas, o relacionamento transversal indica como so as influncias ou modificaes
que umas causam s outras. A composio processa a especificao do relacionamento
transversal e propaga-as aos elementos descritos. J a visualizao permite que sejam geradas
diferentes vises do modelo integrado.
Ali e Kasirum (2011) propuseram uma abordagem para identificar interesses
transversais no documento de especificao de requisitos com base no processamento da
linguagem natural. Os autores propuseram um modelo e implementaram uma ferramenta para
automao da descoberta dos interesses transversais. De acordo com o modelo de Ali e
Kasirun (2011), depois de estruturar os requisitos, deve-se eliminar os requisitos redundantes
e estruturar os trechos elementares. O passo seguinte identificar os verbos de cada trecho e
realizar uma anlise semntica dos mesmos para garantir que verbos semelhantes no sejam
considerados distintos. Depois disso, deve-se calcular o nmero de ocorrncias dos verbos e
desconsiderar aqueles que possuem apenas uma ocorrncia. A justificativa que esses trechos
no possuem a caracterstica de espalhamento e, portanto, no so interesses transversais. Na
sequencia deve-se identificar os trechos que compartilham mais de um verbo e identificar o
verbo predominante de acordo com a estrutura lingustica da frase. Isso caracteriza a intruso
de um conceito. Essa abordagem ser adaptada e utilizada no mtodo proposto no Captulo 4.

3.4. Modelagem de processos de negcios orientada a aspectos

No nvel de processos de negcio, tambm so encontradas abordagens orientadas a
Aspectos (CAPPELLI et al., 2010b; CORREAL e CASSALLAS, 2007; PARK et al., 2007;
WADA et al., 2008; CHARFI et al., 2010; SHANKARDASS, 2009; WANG et al., 2007;
FRANCESCOMARINO e TONELLA, 2008; CAPPELLI, 2009). Cappelli et al. (2010b)
argumentam que os conceitos da orientao a Aspectos tambm se aplicam modelagem de
processos de negcio, melhorando a usabilidade e o entendimento do modelo, j que se utiliza
de conceitos que melhoram a modularidade em geral. Neste trabalho apresentada uma
proposta para modelagem de processos de negcio orientada a Aspectos, tal abordagem
suportada pela ferramenta CrossOryx (CAPPELLI et al., 2010b).

46

Cappelli et al. (2010b) listam algumas heursticas a serem utilizadas na identificao

dos interesses transversais em modelos de processos de negcio, so elas: se o conceito
repetido diversas vezes em diferentes locais; se conceitos com nomes distintos representam a
mesma situao; se o conceito representa uma deciso a ser tomada; se a ausncia do conceito
no interfere nos objetivos do processo; se o conceito genrico e pode ser reutilizado em
diferentes domnios e se o conceito muito independente dos demais.
Correal e Cassallas (2007) desenvolveram o AspectViewPoint, uma linguagem
aspectual especfica para domnios, neste caso, o domnio se refere modelagem de processos
de software. Esta linguagem cria modelos de pontos de vista utilizando vocabulrios baseados
em padres de controle de workflows. O objetivo dos autores diminuir a complexidade
existente na definio e melhoria de modelos de processos de software.
Park et al. (2007) afirmam que regras de negcio so interesses transversais que
devem ser distinguidos de instncias de processos de negcio. Ento propem um framework
de orientado a Aspectos baseado em regras. Neste framework, as regras de negcio aspectuais
podem ser efetivamente separadas e executadas. Com isso possvel alterar um regra de
negcio sem ter que parar todo o processo especificado utilizando BPEL (Business Process
Execution Language), permitindo que as empresas respondam s mudanas de forma mais
gil.
Wada et al. (2008) argumentam que em uma Arquitetura Orientada a Servios (SOA),
para conseguir o reuso de servios importante separar propriedades no funcionais (como
segurana) de suas propriedades funcionais. Ento propem uma linguagem orientada a
Aspectos para separao de propriedades funcionais e no funcionais em processos de
negcio, j que uma aplicao em SOA desenhada com um conjunto de servios
reutilizveis em um processo de negcio.
Charfi et al. (2010) propuseram o AO4BPMN como uma forma de modularizar os
interesses transversais nos processo de negcio. Os autores exemplificam interesses
transversais como complacncia (compliance), monitoramento e separao de funes, mas
no indicam como identificar esses interesses transversais nos processos. Eles apresentam
duas sintaxes, em uma delas os construtos grficos so propostos para representar os
interesses transversais; e, na outra, os interesses transversais podem ser representados
utilizando os elementos convencionais da BPMN.
47

Shankardass (2009) considera a representao dos interesses transversais para

execuo de processos integrada BPEL. O autor desenvolveu uma abordagem para tratar
interesses transversais no nvel de modelagem, transformao do modelo para cdigo e
execuo do cdigo em uma plataforma que permite a costura (weaving) dinmica dos
aspectos. Para tal, ele prope o AOBPMN que uma extenso do BPMN que integra os
aspectos no processo principal sem realizar a costura (weaving). De acordo com o autor, isso
permite o desacoplamento dos aspectos atravs do ciclo de vida do desenvolvimento de
software.
Wang et al. (2007) tambm confirmam que a composio e decomposio
convencionais dos processos de negcio no so suficientes para enderear a complexidade
dos interesses transversais. Para resolver esse problema, eles propuseram o COBPM (Concern
Oriented Business Process Modelling) onde o conceito de processo aspectual introduzido
modelagem de processos de negcio. Essa abordagem tem como objetivo permitir que
pessoas do negcio utilizem as ideias da AOP na modelagem de processos de negcio. Assim
eles propuseram uma ferramenta para apoiar sua abordagem e introduziram um mtodo que
inclui a definio dos interesses, identificao, extrao, montagem (assembling) e costura
(weaving).
Francescomarino e Tonella (2008) apresentaram uma linguagem de consulta visual
chamada BPMN VQL (BPMN Visual Query Language) para apoiar a navegao e explorao
dos interesses transversais relevantes em um domnio de negcio. Essa linguagem capaz de
quantificar os elementos do modelo de processos, identificar, localizar e apresentar os
interesses ao usurio destacando-os no modelo.
Cappelli (2009) prope o AO-BPM (Aspect-Oriented Business Process Modeling)
para permitir que interesses transversais como a transparncia possam ser adicionados aos
modelos de processos de negcio quando uma determinada caracterstica de qualidade deve
ser provida aos processos. Alm disso, Cappelli (2009) prope uma linguagem para
representar o relacionamento transversal na modelagem de processos de negcio.
Em Cappelli (2009) apresentado um exemplo de gesto de mudana no contexto de
desenvolvimento de software, cujo processo apresentado na Figura 28. Nesse processo, os
seguintes elementos esto repetidos: atividade Obter Formulrio de Solicitao de Mudana
e Enviar Solicitao de Mudana, o documento Formulrio de Solicitao de Mudanas e
os dados Dados de Requisio.
48

Figura 28 Processo de Gesto de Mudana (CAPPELLI, 2009)

Aps identificao, atravs de heursticas, dos elementos espalhados no modelo do
processo, aplicou-se a abordagem de Cappelli (2009) onde obteve-se o modelo representado
na Figura 29.

Figura 29 Processo de Gesto de Mudana com a composio de caractersticas transversais

(CAPPELLI, 2009)
Essa linguagem ser adaptada para a Arquitetura Empresarial, onde existem
representaes distintas para os diversos artefatos, e no apenas os modelos de processos de
negcio como era o caso em Cappelli (2009). Assim, ser possvel representar os interesses

49

transversais na Arquitetura Empresarial, para isso a linguagem apresentada em Cappelli

(2009) foi generalizada para permitir a criao de qualquer tipo de representao.

3.5. Interesses transversais na Arquitetura Empresarial

Na POA um requisito dito transversal quando afeta diversos outros requisitos que
implementam as funcionalidades bsicas do sistema. Podemos citar como exemplo os cdigos
referentes aos requisitos no funcionais de registro de operaes (logging) e autenticao de
servios que estaro presentes nas classes que implementam os requisitos funcionais, como
processamento de pagamentos e emisso de faturas, em um sistema de processamento de
cartes de crdito.
Na programao, dois interesses ou caractersticas so transversais quando os mtodos
referentes a estes se interceptam (ELRAD et al., 2001). Na modelagem de processos de
negcio, os interesses transversais so conceitos entrelaados com os conceitos bsicos do
processo e espalhados em diversas partes do modelo (CAPPELLI et al., 2010a).
Com foco na Engenharia de Requisitos, Silva (2006) afirma que os modelos gerados
para representar os sistemas so cada vez mais difceis de manipular devido, entre outros, ao
fato de que suas caractersticas so muito relacionadas umas s outras. Para a autora, os
mtodos convencionais de modelagem e programao no conseguem minimizar tal
acoplamento, pois focam apenas em uma dimenso das caractersticas do sistema. Desta
forma a transversalidade das caractersticas do sistema permanece, pois as caractersticas
continuam sendo fortemente relacionadas, entrelaadas e/ou sobrepostas, influenciando ou
restringindo umas s outras (SILVA, 2006).
Nos modelos processos de negcio, os interesses transversais so aqueles que no
podem ser efetivamente modularizadas utilizando as abstraes convencionais da Modelagem
de Processos de Negcio (CAPPELLI et al., 2010b). Exemplos de interesses transversais so
compliance, auditoria, monitoramento, contabilidade, faturamento, autorizao, privacidade e
separao de funes (CHARFI et al., 2010). Tais interesses podem ser separados no modelo,
reutilizados em outros modelos ou em diversos pontos do mesmo modelo, estando espalhados
e entrelaados aos demais interesses essenciais ao processo. Por exemplo, segundo Cappelli
(2009), a transparncia pode ser considerada um interesse transversal aos modelos de

50

processos de negcio organizacionais, pois no altera a essncia dos processos onde

includa.
Cappelli et al. (2010a) argumentam que no h tratamento para os interesses
transversais existentes nos nveis iniciais da definio dos Sistemas de Informao,
considerando, em especial, abordagens que utilizam a Arquitetura Empresarial. Segundo os
autores, os interesses transversais Arquitetura Empresarial deveriam ser explicitadas ao
invs de estarem repetidos e embutidos nos artefatos que representam SIs, considerando em
especial o Framework de Zachman. Como exemplo, podemos citar segurana, confiabilidade,
amigabilidade, adaptabilidade e usabilidade. Na Arquitetura Empresarial tanto interesses de
qualidade quanto interesses funcionais devem ser considerados.
Buckl et al. (2010) apontam 4 aspectos transversais modelagem de Arquiteturas
Empresariais, sendo eles: metas ou objetivos (goals), projetos, ciclos de vida e padres.
Segundo os autores, estes so considerados conceitos transversais, pois exercem influncia em
outros conceitos da Arquitetura Empresarial. Os autores tambm confirmam que os modelos
gerados para conceitualizao da Arquitetura Empresarial geralmente so descritos de
maneira similar orientada a objetos, utilizando-se de conceitos como classes, propriedades e
relacionamentos. Porm, segundo eles, aspectos relevantes gesto da Arquitetura
Empresarial como temporalidade, dependncia de propriedades e aspectos transversais so
negligenciados nessas abordagens.
Nessa dissertao trataremos dos aspectos transversais tais como os citados por Buckl
et al. (2010). Vale destacar que tais aspectos transversais, denominados nesse trabalho como
interesses transversais, so aqueles presentes nas representaes geradas pela Arquitetura
Empresarial e no aqueles relacionados gesto da Arquitetura Empresarial e seu ciclo de
vida.
Desta forma, nessa dissertao, so considerados interesses transversais os conceitos
que apoiam a essncia de uma organizao, ou seja, nos interesses essenciais da organizao.
Com essa definio, sabe-se que os interesses transversais no fazem parte da essncia das
organizaes, apenas apoiam ou exercem influncia sobre ela.

3.6. Resumo

51

Nesse captulo foram apresentados alguns trabalhos que utilizam a orientao a

aspectos para melhorar a modularizao de diversas fases do desenvolvimento de software e
da modelagem de processos, porm todos focam apenas em sua rea de conhecimento, ou
mais especificamente em uma ou duas clulas do Framework de Zachman, como o caso de
Silva (2007) em que temos requisitos e Arquitetura de Software e Shankardass (2009) onde
tem-se a modelagem, transformao do modelo para cdigo e execuo do cdigo.
Mesmo nessas abordagens onde mais de uma clula do Framework de Zachman
explorada, no h uma forma nica de representar os interesses transversais nessas diferentes
reas de conhecimento, mais especificamente representar a forma como so descritos e
implementados. A identificao dos interesses transversais na maioria dos casos realizada
atravs de heursticas e no h um mtodo para isso que incorpore mais de um tipo de
representao.
Assim pode-se concluir que o problema apresentado no Captulo 1 ainda no foi
tratado de forma integrada, como o caso se pensarmos no nvel da Arquitetura Empresarial.

52

4. Mtodo para identificao e representao dos interesses

transversais na Arquitetura Empresarial

Neste captulo apresentado o mtodo para identificao e representao dos

interesses transversais na Arquitetura Empresarial. O mtodo detalhado em duas fases e
cada fase em suas atividades para execuo. Antes disso so apresentados os objetivos e
premissas que se aplicam a esse mtodo.
Ao longo da apresentao das fases do mtodo,um exemplo utilizado como
ilustrao. Este exemplo foi criado a partir das representaes organizacionais da EIA
Escola de Informtica Aplicada da UNIRIO. A UNIRIO uma universidade federal
constituda de centros, departamentos e escolas. A EIA uma das escolas que compem o
CCET (Centro de Cincias Exatas e Tecnologia) da UNIRIO (Site UNIRIOTEC). Nessa
escola ministrado o curso de Bacharelado em Sistemas de Informao. Para elaborao do
exemplo foram utilizadas algumas representaes organizacionais disponveis no site da
UNIRIO e outras disponveis em trabalhos de concluso de curso dos alunos da graduao.

4.1. Objetivos
O objetivo geral do mtodo contribuir para melhorar a modularizao das
representaes da Arquitetura Empresarial. A Arquitetura Empresarial um campo de
conhecimento muito abrangente que engloba outros campos de conhecimento tais como
processo de negcio, informao, sistema e infraestrutura. Ao analisar os modelos gerados
para representar todas esses campos de conhecimento percebe-se modelos com muitos
elementos, complexos e com inmeros interesses espalhados e entrelaados. Assim, faz-se
necessrio, para reduzir o tamanho e consequentemente a complexidade, encontrar um
mecanismo que nos permita identificar e representar os interesses transversais.

4.2. Premissas

53

Uma das premissas do mtodo que a organizao onde o mtodo ser aplicado
possui representaes do seu funcionamento e que a partir da anlise de tais representaes
possvel identificar a essncia dessa organizao. Outra premissa que, mesmo uma
organizao que no possui uma abordagem formal de Arquitetura Empresarial adotada,
possui um ator que se enquadra do papel de Arquiteto e consequentemente possui os
conhecimentos necessrios para realizao do mtodo proposto.
O papel de Arquiteto responsvel pela realizao do mtodo. Esse papel, mesmo que
no exista formalmente na organizao, deve ser desempenhado por um agente (SANTOS et
al., 2012) que conhea as representaes organizacionais e que possa acess-las nos
repositrios que as armazenam. O papel de Arquiteto pertence a alguma rea da organizao
responsvel por gerenciar e controlar os repositrios das representaes organizacionais. Este
papel comumente executado pela rea de Arquitetura Empresarial da organizao.

4.3. Introduo ao mtodo

O mtodo para identificao e representao dos interesses transversais na Arquitetura
Empresarial contm 2 fases: Identificar e Representar.
Na fase Identificar, os interesses transversais presentes nas representaes
organizacionais so elencados. Para tal so utilizadas como entrada todas as representaes
organizacionais disponveis, com base nessas representaes aplicada parte da metodologia
DEMO (Dietz, 2006) descrita no Captulo 2, que preconiza a identificao da essncia da
organizao.
Nas representaes organizacionais encontram-se informaes sobre a organizao e
tambm os interesses transversais. Comparando as representaes organizacionais completas
com a representao da essncia proposta pela metodologia DEMO, so identificados, alm
de outros conceitos, os candidatos a interesse transversal. Aps a identificao do
espalhamento e entrelaamento dos verbos presentes nos trechos das representaes
organizacionais, ou seja, as aes da organizao e a descoberta de quais possuem aplicao a
nvel organizacional tem-se a lista dos interesses transversais existentes na organizao. A
sada dessa fase a lista dos interesses transversais e a identificao de quais trechos das
representaes organizacionais operacionalizam os interesses transversais.

54

Na fase Representar, a representao dos interesses transversais listados na fase

Identificar criada. Essa fase recebe como entrada a lista dos interesses transversais com a
indicao dos trechos das representaes organizacionais que os operacionalizam. A sada
dessa fase a representao dos interesses transversais com a indicao de onde esto
operacionalizados atravs do relacionamento transversal. Alm disso, o Diagrama dos
Interesses Transversais que um diagrama de classes da UML (OMG UML) criado.
Para identificar os interesses transversais e relacion-los s representaes que os
operacionalizam no h necessidade de remov-los de onde so operacionalizados.

Alm

disso, cada organizao possui formas particulares de representao dos artefatos que
compem sua arquitetura. Os interesses transversais na Arquitetura Empresarial podem
abranger mais de um tipo de artefato, ou seja, seu escopo organizacional ao invs de ser
focado em um nico tipo de artefato.

Se esse fosse o caso, bastaria utilizar uma das

abordagens citadas no Captulo 2 focadas em um nico tipo de representao organizacional.

Em uma abordagem convencional de Arquitetura Empresarial, as diversas
representaes so relacionadas. Por exemplo, uma provvel relao a ser documentada
entre os requisitos do documento de requisitos e o cdigo dos softwares que os implementam,
assim tem-se relacionamentos entre itens distintos (requisito e cdigo), no caso do mtodo
proposto nessa dissertao, o relacionamento transversal indica onde so as ocorrncias do
mesmo conceito. Isso o que diferencia nosso mtodo das abordagens convencionais focadas
em um nico tipo de representao e faz dele um complemento para melhoria das mesmas.
O mtodo proposto pode ser utilizado por qualquer organizao. Desde aquelas que
no possuem iniciativas de estruturao da Arquitetura Empresarial at aquelas que j tem
toda a sua Arquitetura Empresarial organizada. Isso se deve ao fato de que para execuo do
mtodo so necessrias apenas as representaes existentes na organizao, podendo estas j
serem parte de uma Arquitetura Empresarial estruturada ou no. Em geral, diversas
representaes j existem nas organizaes.
A Figura 30 apresenta o mtodo de forma resumida, essa figura caracterizada como
uma Rich Picture (AVISON, GOLDEN e SHAH, 1992), pois no foi encontrada nenhuma
notao que permitisse representar a riqueza de detalhes necessria, principalmente os
elementos que representam os componentes dos artefatos (crculo, retngulo, tringulo e
losango). As entradas da fase Identificar so representaes organizacionais (por exemplo,
ARTEFATO 1 e ARTEFATO 2). Aps a fase Identificar, a lista dos interesses transversais
55

(a1 e a2), a informao de quais artefatos os representam (ARTEFATO 1 e/ou ARTEFATO

2) e quais trechos dos artefatos os operacionalizam (retngulo, tringulo e losango) so
gerados. As formas dos interesses transversais so diferentes (retngulo, tringulo e losango),
pois em cada artefato ou at no mesmo artefato, os interesses transversais podem ser
representados de formas diferentes como eventos, atividades etc considerando o mesmo
artefato (modelo de processos de negcio) ou atividade e classe considerando artefatos
diferentes (modelo de processos de negcio e cdigo de software).
Na fase Representar, uma representao para os interesses transversais criada. Os
trechos das representaes organizacionais so agrupados de acordo com o tipo de interesse
transversal ao qual pertencem, e feita a indicao de onde so operacionalizados atravs do
relacionamento transversal. O mtodo prope a criao do Diagrama dos Interesses
Transversais para documentar quais so os tipos de interesses transversais que existem em
determinada organizao.

Figura 30 Passo a passo do mtodo para Identificao e Representao dos Interesses

Transversais na Arquitetura Empresarial
Na Seo 4.4 detalhada a fase Identificar e na Seo 4.5 detalhada a fase
Representar. Todos os modelos foram gerados utilizando a notao BPMN (White, 2004) e a
ferramenta BizAgi (BizAgi). Essa ferramenta foi escolhida por ser uma ferramenta gratuita.
Na Seo 4.6 apresentado o resumo do Captulo 4.

4.4. Fase Identificar

56

O objetivo da fase Identificar gerar a lista dos interesses transversais de

determinada organizao. As atividades da fase Identificar esto representadas na Figura 33,
elas so realizadas pelo Arquiteto.
O primeiro passo a obteno das representaes organizacionais que a organizao
possui. Para obter as representaes organizacionais, o Arquiteto dever consultar o
repositrio organizacional. Repositrio organizacional onde ficam armazenadas as
representaes da organizao que compem a Arquitetura Empresarial, caso haja ou que
representam os processos de negcio, as informaes, os sistemas e a infra-estrutura da
organizao. Se no houver um repositrio organizacional, o arquiteto dever consultar o
gestor de cada uma dessas reas organizacionais e descobrir onde esto armazenadas as
representaes organizacionais.
4.4.1. EIA Obter representaes organizacionais
O primeiro passo do mtodo obter as representaes organizacionais. No caso da
UNIRIO no h um repositrio com todas as representaes organizacionais. As
representaes organizacionais disponveis utilizadas nesse exemplo foram: O Plano de
Desenvolvimento Institucional (PDI) 2012-2016 da UNIRIO (site UNIRIO), o documento do
Modelo de Processos de Negcio da EIA (ENGIEL, 2009) e o Manual do SIE - Sistema de
Informaes para o Ensino (site UNIRIO).
Com base nas representaes organizacionais obtidas pelo Arquiteto, ele deve definir
quais so os tipos de elementos bsicos, ou seja, que correspondem ao propsito de cada
representao organizacional. Esses tipos so aqueles que explicam as partes mais
importantes da representao organizacional. Em um documento de requisitos, por exemplo,
pode-se ter introduo, definio dos requisitos e glossrio de termos. Nesse caso, o tipo de
elemento bsico a definio dos requisitos, os demais proveem mais detalhes sobre o
documento em si (introduo) ou sobre o tipo do elemento bsico (glossrio).
4.4.2. EIA - Definir os tipos de elementos bsicos de cada representao
organizacional
Ao analisar as representaes organizacionais disponveis, a
Tabela 2 apresenta os tipos de elementos bsicos a serem considerados em cada
representao organizacional.
57

Tabela 2 Tipos de elementos bsicos das representaes organizacionais

Representao organizacional
Modelo de Processos de Negcio - EIA

Tipo de Elemento bsico

EPC

PDI

Iniciativa estratgica

Manual do SIE

Funcionalidade

Uma vez definidos quais so os tipos de elementos bsicos de cada representao

organizacional, o Arquiteto deve listar todos os trechos elementares que compem o tipo de
elemento bsico e indicar o tipo do trecho elementar. No caso do documento de requisitos,
deve-se listar todos os requisitos e indicar o tipo requisito. Se fosse um documento com vrios
processos de negcio descritos, o tipo de elemento bsico seria processo, os trechos
elementares teriam os nomes dos elementos que compem os processos, como por exemplo,
os nomes das atividades e o tipo do trecho elementar seria atividade.
4.4.3. EIA - Listar trechos que compem os elementos bsicos
Nesse passo gerada a lista de todos os trechos elementares das representaes
organizacionais a serem analisados. Os trechos bsicos so o mnimo de contedo necessrio
para representar o que se deseja. Os tipos bsicos dependem da representao em questo,
uma vez que so conhecidos os modelos, sabe-se quais so os elementos bsicos e os trechos.
No exemplo da EIA, a lista representada na Tabela 3. Nessa lista no foram includos todos
os trechos de todos os tipos de elementos bsicos, foi feita uma seleo de alguns, o mais
diversificado possvel. O trecho elementar do PDI formado pelas iniciativas estratgicas que
detalham os objetivos estratgicos, neste caso foram listados tambm os objetivos estratgicos
apenas para facilitar o entendimento de como as iniciativas estratgicas estavam organizadas,
mas eles no sero analisados durante o mtodo.

58

Figura 31 Atividades da fase Identificar

59

Tabela 3 Trechos das representaes organizacionais a serem analisados

Representao
organizacional

Contedo do Tipo bsico

Modelo de Processos

Inscrever veterano em

de Negcio EIA

disciplina

Trecho elementar

Tipo do Trecho
elementar

Acessar portal do aluno

Atividade

Solicitar inscrio em disciplinas veterano

Atividade

Criticar solicitao de inscrio em disciplina

Atividade

Informar disponibilidade do relatrio de solicitao de

Atividade

inscrio em disciplina
Solicitar impresso da documentao de inscrio em

Atividade

disciplina
Emitir relatrio de solicitao de inscrio em disciplina e

Atividade

histrico
Agendar semana de confirmao de inscrio em disciplina

Atividade

Verificar relatrio de solicitao de inscrio em disciplina

Atividade

Realizar modificaes na solicitao

Atividade

Encaminhar relatrio de solicitao de inscrio em

Atividade

disciplina
Verificar modificaes na solicitao de inscrio em

Atividade

disciplina

Gerar grade horria

Discutir aes

Tratar solicitao de

Registrar modificaes na inscrio em disciplinas

Atividade

Confirmar inscrio em disciplinas

Atividade

Arquivar relatrio de inscrio em disciplinas

Atividade

Confeccionar proposta de grade horria

Atividade

Propor grade horria

Atividade

Pronunciar optativas

Atividade

Pronunciar matrias ofertadas da ps-graduao

Atividade

Pronunciar matrias ofertadas de outros departamentos

Atividade

Efetuar mudanas necessrias

Atividade

Solicitar mudanas

Atividade

Produzir minuta

Atividade

Discutir aes

Atividade

Verificar necessidade de realizao de pesquisa

Atividade

Elaborar pesquisa

Atividade

Enviar pesquisa

Atividade

Responder pesquisa

Atividade

Analisar resposta

Atividade

Solicitar diploma

Atividade

Montar processo

Atividade

Analisar processo

Atividade

Assinar processo

Atividade

Encaminhar processo

Atividade

diploma

Tratar solicitao de historio Solicitar histrico escolar

Atividade

escolar

60

Tratar solicitao de

Gerar histrico escolar

Atividade

Assinar histrico escolar

Atividade

Preencher solicitao de incluso/excluso de disciplina

Atividade

Encaminhar solicitao

Atividade

Analisar solicitao de incluso/excluso de disciplina

Atividade

Incluir alteraes

Atividade

Arquivar solicitao

Atividade

Agendar reunio

Atividade

Realizar reunio

Atividade

Elaborar ata

Atividade

Assinar ata

Atividade

incluso/excluso de
disciplinas

Tomar decises

PDI

Garantir a produo, difuso e preservao do saber em todos os campos do conhecimento

Objetivo estratgico

Fomentar a produo acadmica

Iniciativa estratgica

Produzir instrumentos de difuso da produo acadmica

Iniciativa estratgica

Apoiar a realizao de eventos de promoo e integrao da Iniciativa estratgica

produo acadmica em todas as reas do conhecimento
Promover a organizao e acesso produo cientfica da

Iniciativa estratgica

UNIRIO em meio digital de forma a elevar a sua

visibilidade e impacto
Formar cidados com conscincia humanista, crtica e reflexiva, comprometidos com a

Objetivo estratgico

sociedade e sua transformao, qualificados para o exerccio profissional

Fomentar aes voltadas para o incentivo de insero dos

Iniciativa estratgica

discentes no mundo do trabalho

Fomentar Programas de Nivelamento e Aprimoramento do

Iniciativa estratgica

processo de construo do conhecimento

Ampliar o preenchimento de vagas na graduao de modo a Iniciativa estratgica
consolidar os cursos existentes, em todas as modalidades
Gerir a implantao e a permanente atualizao de Projetos

Iniciativa estratgica

Poltico-Pedaggicos dos Cursos de Graduao

Aumentar a oferta de bolsas para discentes

Iniciativa estratgica

Fomentar aes visando formao e qualificao de

Iniciativa estratgica

professores para a Educao Bsica

Incentivar a Mobilidade Estudantil

Iniciativa estratgica

Fomentar a atuao acadmica no HUGG

Iniciativa estratgica

Melhorar os indicadores dos cursos de graduao

Iniciativa estratgica

Estender sociedade os benefcios da criao cultural, artstica, cientfica e tecnolgica

Objetivo estratgico

gerada na instituio
Dar visibilidade s aes da universidade

Iniciativa estratgica

Fomentar programas, projetos e cursos de extenso

Iniciativa estratgica

Criar fruns de discusso entre a universidade, a

Iniciativa estratgica

comunidade acadmica e a sociedade

Ampliar os servios oferecidos sociedade
Garantir a transparncia organizacional

Iniciativa estratgica
Objetivo estratgico

61

Desenvolver aes de Transparncia Organizacional e de

Iniciativa estratgica

estmulo ao Controle Social

Promover a transparncia das informaes institucionais

Iniciativa estratgica

para a sociedade
Construir polticas e prticas para comunicao

Iniciativa estratgica

organizacional
Manual do SIE

Oferta de disciplina

Clicar em Educao/ Controle Acadmico /Oferta de

Passo

Disciplina e clicar duas vezes em Oferta de Disciplina por

Curso
Na tela Oferta de Disciplinas por Curso, clicar em

Passo

Localizar na parte superior da janela

Digitar o Cdigo do curso ou Nome da Unidade e clicar em

Passo

Procurar
Se voc digitar a palavra curso, surgir a tela abaixo.

Passo

Clicar no curso desejado e em seguida clicar em Selecionar

Para cadastrar Turma:, clicar na flecha ao lado de Novo e

Passo

escolher Turma
Clique na lupa ao lado de Cdigo da Disciplina

Passo

Digite o cdigo da Disciplina, clique em Procurar, depois

Passo

em Selecionar

Ajuste de oferta de

Preencher os campos solicitados

Passo

Selecionar a disciplina desejada e clicar no cone Alterar

Passo

Efetuar as alteraes desejadas e clicar em Salvar

Passo

Clicar na flecha ao lado de Novo e selecionar Horrio ou

Passo

disciplina

clicar com o boto direito na disciplina selecionada e clicar

em Horrio
Ajuste de horrios

Tramitaes

Clicar duas vezes na disciplina

Passo

Clicar em Horrios

Passo

Clicar no cone Alterar

Passo

Efetuar as alteraes necessrias

Passo

Clicar no boto Salvar

Passo

Clicar no cone Tramitar

Passo

Na Guia Destino aparece o Departamento que receber o

Passo

processo. Na Guia Despacho digite o despacho necessrio e

na Guia Documento Vinculado voc pode anexar um
documento
Escolher o Fluxo. Escolher a opo: Envia para vinculao

Passo

de Docentes, Espao Fsico e Blocos

Clicar em OK

Passo

Na segunda folha da tela principal, Caixa Postal, podemos

Passo

visualizar todos os documentos que esto tramitando e

sobre os quais o usurio dever dar um parecer
Cadastro de nova turma

Clicar em Novo

Passo

Para cadastrar o docente, na tela inicial, v na opo

Passo

11.02.03.02 Oferta de Disciplina por Departamento

62

Localizar o curso e selecionar a disciplina desejada

Passo

Clicar com o boto direito em turma e escolher Docente.

Passo

Voc pode tambm clicar duas vezes na turma, clicar em

Docente, clicar na seta do boto Novo e clicar em Docente
Localize o docente clicando na lupa ao lado de matrcula.

Passo

Digitar a matrcula no campo Matrcula ou digitar parte do

nome no campo Nome do Docente.Clicar no boto Procurar
escolher o docente e clicar no boto Selecionar
Digitar o Encargo Didtico, isto , a quantidade de carga

Passo

horria semestral ou anual do docente na turma

No Papel do Docente escolher uma dentre as opes:

Passo

Coordenador (docente titular) da disciplina, Colaborador,

Substituto, Ministrante, Responsvel ou Titular
Para cadastrar o espao fsico, clicar com o boto direito

Passo

em turma e em seguida clicar com o boto esquerdo sobre

Espao Fsico
Selecionar o Dia da Semana, escolher o Espao Fsico

Passo

clicando no +

Lanamento de matrcula

Escolher o espao fsico e clicar no boto Adicionar

Passo

Na Tela Principal clicar em Educao / Controle

Passo

Acadmico / Matrcula / Matrcula por Aluno.

Na tela Matrcula por Aluno, clicar em Localizar

Passo

Digitar o cdigo do curso ou o Nome da Unidade e clicar

Passo

em OK.
Clicar na LUPA para encontrar a Matrcula do Aluno.

Passo

Digitar a matrcula e clicar em OK.

Passo

Clicar em Aluno/Procurar, escolher no nome do aluno

Passo

desejado e clicar em Selecionar. Neste caso aparecero

todos os alunos da UNIRIO.
Surgir a tela abaixo para verificar as disciplinas que o

Passo

aluno se matriculou, ou para realizar o ajuste de matrcula,

isto , cadastrar ou excluir disciplinas.
Excluso de matrcula

Na tela Matrcula por Aluno, clicar em Localizar

Passo

Digitar o cdigo do curso e clicar em OK

Passo

Clicar na lupa para encontrar a Matrcula do Aluno

Passo

Digitar a matrcula e clicar em OK

Passo

Selecionar a disciplina que desejar excluir e clicar no cone

Passo

Excluir

Com base no conhecimento do Arquiteto e nas prprias representaes

organizacionais, o Arquiteto dever identificar as transaes ontolgicas e aplicar a parte do
mtodo DEMO que diz respeito a gerar a representao mais concisa da essncia da
organizao, indicada no CM (Construction Model). Optou-se pelo CM por ser justamente o
63

modelo da metodologia DEMO mais conciso, que contm os elementos necessrios para
representar a essncia da organizao (as transaes ontolgicas).
Para

identificar

quais

so

as

transaes

ontolgicas

das

representaes

organizacionais, deve-se analisar os trechos que compem os tipos de elementos bsicos das
representaes organizacionais e buscar por atos onde haja tomada de deciso ou criao de
alguma coisa nova. Ao realizar atos de produo (transaes ontolgicas), os atores realizam a
misso da organizao ( Dietz e Habing, 2004). Um ato de produo pode ser material, como
fabricao ou transporte, ou imaterial, como decidir, julgar e diagnosticar (Dietz e Habing,
2004). Assim, nesse momento, o Arquiteto deve identificar as transaes ontolgicas da
organizao e represent-las.
4.4.4. EIA - Identificar transaes ontolgicas
O Modelo de Processos de Negcio contm a descrio do funcionamento da EIA,
esse o tipo de artefato que mais facilmente contribui para a elaborao da representao da
essncia da organizao seguindo a metodologia DEMO (Dietz, 2006).
As transaes ontolgicas identificadas nesse passo, a partir das representaes
organizacionais disponveis, esto listadas na Tabela 4. No Manual do SIE no foi
identificada nenhuma transao ontolgica.
Tabela 4 Transaes ontolgicas da EIA
Nome Transao ontolgica

Iniciador

Executor

Resultado

T01

Inscrio disciplina

Aluno

Atendente

Aluno A inscrito na disciplina B

T02

Aprovao Inscrio em disciplina

Atendente

Aprovador de inscrio

Inscrio do aluno A na disciplina B aprovada

T03

Alterao inscrio

Aluno

Atendente

Inscrio do aluno A na disciplina B alterada

T04

Aprovao alterao inscrio

Atendente

Aprovador de alterao

Alterao da inscrio do aluno A na disciplina

B aprovada

T05

Gesto grade

Gestor do curso Gestor do curso

Grade D gerida

T06

Montagem grade

Gestor do curso Planejador do curso

Grade D montada

4.4.5. EIA - Representar as transaes ontolgicas

O passo seguinte a elaborao da representao da essncia da organizao, para isso
foi utilizada a ferramenta Xemod (Xemod). Ao utilizar a metodologia DEMO, temos o
seguinte Construction Model da EIA representado na Figura 32.
64

Figura 32 Construction Model da EIA

Alguns elementos das representaes analisadas poderiam ser considerados transaes
ontolgicas, mas devido ao escopo, foram desconsiderados, como o processo Tratar
solicitao de diploma que foi considerado como responsabilidade do setor de diploma e no
da EIA. O processo de tomada de deciso, por pertencer ao Departamento de Informtica
Aplicada tambm foi desconsiderado. Assim na Figura 32 esto representadas as transaes
ontolgicas da EIA.
A transao ontolgica Realizao de inscrio denota o ato do aluno se inscrever em
disciplinas, por isso ele o iniciador. O executor o atendente que recebe essa inscrio. A
inscrio s poder ser efetivada aps a concluso da outra transao ontolgica Aprovao
de inscrio. Essa transao executada por algum com competncia para aprovar a
inscrio, esse papel representado pelo Aprovador de inscrio.
Raciocnio semelhante aplica-se Alterao de inscrio que s pode ser realizada
aps a concluso da Aprovao da alterao da inscrio. possvel que a transao
Alterao de inscrio seja realizada durante a transao de Realizao de inscrio, pois se o
responsvel pela aprovao decidir que a inscrio deve ter alguma disciplina includa ou
excluda, o mesmo deve ser feito, porm so transaes distintas. A transao Gesto da grade
auto-iniciada porque ocorre periodicamente e dispara a transao Montagem da grade
propriamente dita.
65

O passo seguinte a identificao de quais trechos que compem os tipos de

elementos bsicos das representaes organizacionais operacionalizam as transaes
ontolgicas. Esses trechos devem ser desconsiderados, pois no caracterizam um candidato a
interesse transversal. Essa atividade extremamente relevante para o mtodo, pois a
operacionalizao da essncia da organizao no considerada um interesse transversal,
assim eliminam-se das representaes organizacionais os trechos que no atendem aos
critrios que caracterizam um interesse transversal.
Uma vez identificados e desconsiderados os trechos que operacionalizam as transaes
ontolgicas, os trechos restantes so candidatos a operacionalizao de interesses transversais,
alm da operacionalizao das transaes infolgicas (computao da informao) ou
operacionalizaes das transaes datalgicas (manipulao de dados) que apoiam as
transaes ontolgicas (Dietz, 2006).
A identificao dos trechos que operacionalizam as transaes ontolgicas no
detalhada por Dietz (2006). Portanto, optou-se por associar as transaes ontolgicas aos
trechos onde no h transaes puramente infolgicas ou datalgicas ou onde h partes do
padro de transao. Por exemplo, a transao ontolgica de Aprovao de inscrio de
associao considerando como exemplo um clube de tnis cujos candidatos a membro devem
enviar suas informaes para anlise e posteriormente, de acordo com o resultado da anlise,
podero se tornar membros ou no (Dietz, 2006), deveria ser associada atividade Analisar
solicitao de associao, ao invs de ser associada atividade Arquivar solicitao de
associao, que puramente datalgica.
As representaes organizacionais que no possurem transaes ontolgicas
associadas tero todos os trechos considerados como candidatos a interesse transversal. Ao
final tem-se a lista de todos os candidatos a interesse transversal.
4.4.6. EIA - Identificar os trechos que operacionalizam as transaes ontolgicas
Com base no CM da EIA, sabe-se qual a essncia da EIA, desta forma sabe-se o que
no deve ser um interesse transversal, considerando a definio de interesse transversal
adotada nessa dissertao (Captulo 2). A partir desse conhecimento, devem ser analisadas as
representaes organizacionais disponveis e devem ser identificados quais trechos
operacionalizam as transaes ontolgicas.
66

Uma vez que foi especificado o tipo de trecho das representaes, devem ser listados
todos os trechos das representaes organizacionais que operacionalizam as transaes
ontolgicas. Esses trechos esto listados na Tabela 5.
Tabela 5 Trechos das representaes organizacionais que operacionalizam as transaes
ontolgicas da EIA
Representao

Seo

Trecho elementar

Tipo

organizacional

Transao
Ontolgica

Solicitar inscrio em disciplinas veterano

Atividade

T01

Inscrever em disciplina fora do prazo

Atividade

T01

Criticar solicitao de inscrio em disciplina

Atividade

T02

Realizar modificaes na solicitao

Atividade

T02, T03 e T04

Confirmar inscrio em disciplinas

Atividade

T02

Gerar grade horria

Produzir minuta

Atividade

T06

Tratar solicitao

Preencher solicitao de incluso/excluso de

de

disciplina

Atividade

T03

incluso/excluso

Analisar solicitao de incluso/excluso de

de disciplinas

disciplinas

Atividade

T04

Passo

T03

Passo

T03

Inscrever veterano
em disciplina
Modelo de Processos
de Negcio EIA

Lanamento de
matrcula
Manual do SIE

Surgir a tela abaixo para verificar as disciplinas que o

aluno se matriculou, ou para realizar o ajuste de
matrcula, isto , cadastrar ou excluir disciplinas.

Excluso de

Selecionar a disciplina que desejar excluir e clicar no

matrcula

cone Excluir

Os trechos Solicitar inscrio em disciplinas veterano e Inscrever em disciplina fora do

prazo so operacionalizaes da transao Inscrio em disciplinas, a diferena entre elas o
momento em que ocorrem, no prazo ou fora do prazo. Os trechos Criticar solicitao de
inscrio em disciplina, Realizar modificaes na solicitao e Confirmar inscrio em
disciplinas operacionalizam a transao Aprovao de inscrio. O segundo trecho
operacionalizao tambm das transaes Alteraes de inscrio e Aprovao de alterao
de inscrio. Isso ocorre porque durante a aprovao da inscrio o tutor pode perceber que
precisa alterar a inscrio e consequentemente aprovar a alterao. A transao Aprovao da
alterao da inscrio tambm operacionalizada pelo trecho Analisar solicitao de
incluso/excluso de disciplinas onde ocorre a deciso se a alterao ser aprovada ou no.
A reduo do total de trechos organizacionais (108) para os trechos que no
operacionalizam as transaes ontolgicas (10), no exemplo da EIA, relativamente pequena
67

(9,259%), porm importante para garantir que os interesses transversais identificados no so

essncia da organizao. Essa afirmao apoiada por uma das heursticas para identificao
dos interesses transversais nos processos de negcio. Essa heurstica diz que os interesses
transversais so representados por trechos opcionais, aqueles que sua remoo no impacta o
alcance do objetivo final, conforme exemplo apresentado em (Santos et al., 2011).
4.4.7. EIA - Descartar os trechos que no operacionalizam as transaes
ontolgicas
O passo seguinte listar todos os trechos das representaes organizacionais que no
operacionalizam as transaes ontolgicas, ou seja, so candidatos a interesse transversal. As
listas so apresentadas, divididas por representao organizacional, na Tabela 6, na Tabela 7 e
na Tabela 8.
Tabela 6 Trechos Modelo de Processos de Negcio da EIA que no operacionalizam as
transaes ontolgicas
Representao

Seo

Trecho elementar

Tipo

Modelo de

Inscrever veterano em

Acessar portal do aluno

Atividade

Processos de

disciplina

Informar disponibilidade do relatrio de solicitao de inscrio em

Atividade

Solicitar impresso da documentao de inscrio em disciplina

Atividade

Emitir relatrio de solicitao de inscrio em disciplina e histrico

Atividade

Agendar semana de confirmao de inscrio em disciplina

Atividade

Verificar relatrio de solicitao de inscrio em disciplina

Atividade

Encaminhar relatrio de solicitao de inscrio em disciplina

Atividade

Verificar modificaes na solicitao de inscrio em disciplina

Atividade

Registrar modificaes na inscrio em disciplinas

Atividade

Arquivar relatrio de inscrio em disciplinas

Atividade

10

Confeccionar proposta de grade horria

Atividade

11

Propor grade horria

Atividade

12

Pronunciar optativas

Atividade

13

Pronunciar matrias ofertadas da ps-graduao

Atividade

14

Pronunciar matrias ofertadas de outros departamentos

Atividade

15

Efetuar mudanas necessrias

Atividade

16

Solicitar mudanas

Atividade

17

Discutir aes

Atividade

18

Verificar necessidade de realizao de pesquisa

Atividade

19

Elaborar pesquisa

Atividade

20

Enviar pesquisa

Atividade

21

organizacional

Negcio EIA

disciplina

Gerar grade horria

Discutir aes

68

Responder pesquisa

Atividade

22

Analisar resposta

Atividade

23

Tratar solicitao de

Solicitar diploma

Atividade

24

diploma

Montar processo

Atividade

25

Analisar processo

Atividade

26

Assinar processo

Atividade

27

Encaminhar processo

Atividade

28

Tratar solicitao de

Solicitar histrico escolar

Atividade

29

historico escolar

Gerar histrico escolar

Atividade

30

Assinar histrico escolar

Atividade

31

Tratar solicitao de

Encaminhar solicitao

Atividade

32

incluso/excluso de

Incluir alteraes

Atividade

33

disciplinas

Arquivar solicitao

Atividade

34

Tomar decises

Agendar reunio

Atividade

35

Realizar reunio

Atividade

36

Elaborar ata

Atividade

37

Assinar ata

Atividade

38

Tabela 7 Trechos PDI que no apoiam as transaes ontolgicas

Representao Seo

Trecho elementar

Tipo

organizacional
PDI

Garantir a produo, difuso e

Objetivo estratgico

preservao do saber em todos os

campos do conhecimento
Fomentar a produo acadmica.

Iniciativa estratgica

39

Produzir instrumentos de difuso da produo

Iniciativa estratgica

40

Iniciativa estratgica

41

Iniciativa estratgica

42

acadmica
Apoiar a realizao de eventos de promoo e
integrao da produo acadmica em todas as
reas do conhecimento
Promover a organizao e acesso produo
cientfica da UNIRIO em meio digital de forma a
elevar a sua visibilidade e impacto
Formar cidados com conscincia

Objetivo estratgico

humanista, crtica e reflexiva,

comprometidos com a sociedade e
sua transformao, qualificados
para o exerccio profissional
Fomentar aes voltadas para o incentivo de

Iniciativa estratgica

43

Iniciativa estratgica

44

insero dos discentes no mundo do trabalho

Fomentar Programas de Nivelamento e
Aprimoramento do processo de construo do
conhecimento

69

Ampliar o preenchimento de vagas na graduao

Iniciativa estratgica

45

de modo a consolidar os cursos existentes, em

todas as modalidades
Gerir a implantao e a permanente atualizao de

46

Projetos Poltico-Pedaggicos dos Cursos de

Graduao
Aumentar a oferta de bolsas para discentes

Iniciativa estratgica

47

Fomentar aes visando formao e

Iniciativa estratgica

48

Incentivar a Mobilidade Estudantil

Iniciativa estratgica

49

Fomentar a atuao acadmica no HUGG

Iniciativa estratgica

50

Melhorar os indicadores dos cursos de graduao

Iniciativa estratgica

51

qualificao de professores para a Educao

Bsica

Estender sociedade os benefcios

Objetivo estratgico

da criao cultural, artstica,

cientfica e tecnolgica gerada na
instituio
Dar visibilidade s aes da universidade

Iniciativa estratgica

52

Fomentar programas, projetos e cursos de

Iniciativa estratgica

53

Iniciativa estratgica

54

Iniciativa estratgica

55

extenso
Criar fruns de discusso entre a universidade, a
comunidade acadmica e a sociedade
Ampliar os servios oferecidos sociedade
Garantir a transparncia

Objetivo estratgico

organizacional
Desenvolver aes de Transparncia

Iniciativa estratgica

56

Iniciativa estratgica

57

Iniciativa estratgica

58

Organizacional e de estmulo ao Controle Social

Promover a transparncia das informaes
institucionais para a sociedade
Construir polticas e prticas para comunicao
organizacional

Tabela 8 Trechos Manual do SIE que no apoiam as transaes ontolgicas

Representao

Seo

Trecho elementar

Tipo

Oferta de disciplina

Clicar em Educao/ Controle Acadmico /Oferta de Disciplina e

Passo

59

Passo

60

Digitar o Cdigo do curso ou Nome da Unidade e clicar em Procurar

Passo

61

Se voc digitar a palavra curso, surgir a tela abaixo. Clicar no

Passo

62

Passo

63

organizacional
Manual do SIE

clicar duas vezes em Oferta de Disciplina por Curso

Na tela Oferta de Disciplinas por Curso, clicar em Localizar na parte
superior da janela

curso desejado e em seguida clicar em Selecionar

Para cadastrar Turma:, clicar na flecha ao lado de Novo e escolher
Turma

70

Clique na lupa ao lado de Cdigo da Disciplina

Passo

64

Digite o cdigo da Disciplina, clique em Procurar, depois em

Passo

65

Preencher os campos solicitados

Passo

66

Ajuste de oferta de

Selecionar a disciplina desejada e clicar no cone Alterar

Passo

67

disciplina

Efetuar as alteraes desejadas e clicar em Salvar

Passo

68

Clicar na flecha ao lado de Novo e selecionar Horrio ou clicar com o

Passo

69

Clicar duas vezes na disciplina

Passo

70

Clicar em Horrios

Passo

71

Clicar no cone Alterar

Passo

72

Efetuar as alteraes necessrias

Passo

73

Clicar no boto Salvar

Passo

74

Clicar no cone Tramitar

Passo

75

Na Guia Destino aparece o Departamento que receber o processo. Na

Passo

76

Passo

77

Clicar em OK

Passo

78

Na segunda folha da tela principal, Caixa Postal, podemos visualizar

Passo

79

Clicar em Novo

Passo

80

Para cadastrar o docente, na tela inicial, v na opo 11.02.03.02

Passo

81

Localizar o curso e selecionar a disciplina desejada

Passo

82

Clicar com o boto direito em turma e escolher Docente. Voc pode

Passo

83

Passo

84

Passo

85

Passo

86

Passo

87

Selecionar o Dia da Semana, escolher o Espao Fsico clicando no + Passo

88

Escolher o espao fsico e clicar no boto Adicionar

Passo

89

Na Tela Principal clicar em Educao / Controle Acadmico /

Passo

90

Na tela Matrcula por Aluno, clicar em Localizar

Passo

91

Digitar o cdigo do curso ou o Nome da Unidade e clicar em OK.

Passo

92

Selecionar

boto direito na disciplina selecionada e clicar em Horrio

Ajuste de horrios

Tramitaes

Guia Despacho digite o despacho necessrio e na Guia Documento

Vinculado voc pode anexar um documento
Escolher o Fluxo. Escolher a opo: Envia para vinculao de
Docentes, Espao Fsico e Blocos

todos os documentos que esto tramitando e sobre os quais o usurio

dever dar um parecer
Cadastro de nova turma

Oferta de Disciplina por Departamento

tambm clicar duas vezes na turma, clicar em Docente, clicar na seta

do boto Novo e clicar em Docente
Localize o docente clicando na lupa ao lado de matrcula. Digitar a
matrcula no campo Matrcula ou digitar parte do nome no campo
Nome do Docente.Clicar no boto Procurar escolher o docente e clicar
no boto Selecionar
Digitar o Encargo Didtico, isto , a quantidade de carga horria
semestral ou anual do docente na turma
No Papel do Docente escolher uma dentre as opes: Coordenador
(docente titular) da disciplina, Colaborador, Substituto, Ministrante,
Responsvel ou Titular
Para cadastrar o espao fsico, clicar com o boto direito em turma e
em seguida clicar com o boto esquerdo sobre Espao Fsico

Lanamento de matrcula

Matrcula / Matrcula por Aluno.

71

Clicar na LUPA para encontrar a Matrcula do Aluno.

Passo

93

Digitar a matrcula e clicar em OK.

Passo

94

Clicar em Aluno/Procurar, escolher no nome do aluno desejado e

Passo

95

Na tela Matrcula por Aluno, clicar em Localizar

Passo

96

Digitar o cdigo do curso e clicar em OK

Passo

97

Clicar na lupa para encontrar a Matrcula do Aluno

Passo

98

Digitar a matrcula e clicar em OK

Passo

99

clicar em Selecionar. Neste caso aparecero todos os alunos da

UNIRIO.
Excluso de matrcula

Para saber quais trechos da lista de candidatos a interesse transversal realmente

operacionalizam interesses transversais, optou-se por adaptar uma abordagem da Engenharia
de Requisitos que identifica interesses transversais no documento de especificao de
requisitos com base no processamento da linguagem natural (Ali e Kasirum, 2011). Ali e
Kasirum (2011) propuseram um modelo e implementaram uma ferramenta para automao da
descoberta dos interesses transversais. A ferramenta chamada de 3CI. Nesse caso, um
documento de especificao de requisitos analisado com base apenas nos verbos utilizados
para descrev-los. No mtodo proposto nessa dissertao optou-se por considerar tambm os
verbos que indicam as aes realizadas pela organizao, porm nesse caso todas as
representaes organizacionais sero analisadas ao invs de analisar apenas um tipo de
representao.
O passo seguinte identificar os verbos que aparecem em cada trecho e aqueles que
possuem significado semelhante de forma a garantir que sinnimos no sejam considerados
distintos. Alguns trechos podem no trazer verbos escritos explicitamente, como o cdigo de
softwares por exemplo, nesse caso deve-se identificar o verbo que melhor representa aquele
trecho.
4.4.8. EIA - Identificar os verbos utilizados
O passo seguinte fazer um levantamento de todos os verbos utilizados na lista de
candidatos a interesse transversal. A Tabela 9 apresenta os verbos identificados em cada
trecho.

72

Tabela 9 Verbos presentes nos trechos das representaes organizacionais

#

Trecho elementar

Tipo

Verbo

Acessar portal do aluno

Atividade

acessar

Informar disponibilidade do relatrio de solicitao de inscrio em disciplina

Atividade

informar

Solicitar impresso da documentao de inscrio em disciplina

Atividade

solicitar

Emitir relatrio de solicitao de inscrio em disciplina e histrico

Atividade

emitir

Agendar semana de confirmao de inscrio em disciplina

Atividade

agendar

Verificar relatrio de solicitao de inscrio em disciplina

Atividade

verificar

Encaminhar relatrio de solicitao de inscrio em disciplina

Atividade

encaminhar

Verificar modificaes na solicitao de inscrio em disciplina

Atividade

verificar

Registrar modificaes na inscrio em disciplinas

Atividade

registrar

10 Arquivar relatrio de inscrio em disciplinas

Atividade

arquivar

11 Confeccionar proposta de grade horria

Atividade

confeccionar

12 Propor grade horria

Atividade

propor

13 Pronunciar optativas

Atividade

pronunciar

14 Pronunciar matrias ofertadas da ps-graduao

Atividade

pronunciar

15 Pronunciar matrias ofertadas de outros departamentos

Atividade

pronunciar

16 Efetuar mudanas necessrias

Atividade

efetuar

17 Solicitar mudanas

Atividade

solicitar

18 Discutir aes

Atividade

discutir

19 Verificar necessidade de realizao de pesquisa

Atividade

verificar

20 Elaborar pesquisa

Atividade

elaborar

21 Enviar pesquisa

Atividade

enviar

22 Responder pesquisa

Atividade

responder

23 Analisar resposta

Atividade

analisar

24 Solicitar diploma

Atividade

solicitar

25 Montar processo

Atividade

montar

26 Analisar processo

Atividade

analisar

27 Assinar processo

Atividade

assinar

28 Encaminhar processo

Atividade

encaminhar

29 Solicitar histrico escolar

Atividade

solicitar

30 Gerar histrico escolar

Atividade

gerar

31 Assinar histrico escolar

Atividade

assinar

32 Encaminhar solicitao

Atividade

encaminhar

33 Incluir alteraes

Atividade

incluir

34 Arquivar solicitao

Atividade

arquivar

35 Agendar reunio

Atividade

agendar

36 Realizar reunio

Atividade

realizar

37 Elaborar ata

Atividade

elaborar

38 Assinar ata

Iniciativa estratgica

assinar

39 Produzir instrumentos de difuso da produo acadmica

Iniciativa estratgica

produzir

Iniciativa estratgica

apoiar

40 Apoiar a realizao de eventos de promoo e integrao da produo acadmica

em todas as reas do conhecimento

73

41

Promover a organizao e acesso produo cientfica da UNIRIO em meio digital

de forma a elevar a sua visibilidade e impacto

Iniciativa estratgica

promover

Iniciativa estratgica

fomentar

Iniciativa estratgica

fomentar

Iniciativa estratgica

ampliar

Iniciativa estratgica

gerir

Iniciativa estratgica

aumentar

42 Fomentar aes voltadas para o incentivo de insero dos discentes no mundo do

trabalho
43 Fomentar Programas de Nivelamento e Aprimoramento do processo de construo
do conhecimento
44 Ampliar o preenchimento de vagas na graduao de modo a consolidar os cursos
existentes, em todas as modalidades
45 Gerir a implantao e a permanente atualizao de Projetos Poltico-Pedaggicos
dos Cursos de Graduao
46 Aumentar a oferta de bolsas para discentes
47 Fomentar aes visando formao e qualificao de professores para a
Iniciativa estratgica

fomentar

48 Incentivar a Mobilidade Estudantil

Educao Bsica

Iniciativa estratgica

incentivar

49 Fomentar a atuao acadmica no HUGG

Iniciativa estratgica

fomentar

50 Melhorar os indicadores dos cursos de graduao

Iniciativa estratgica

melhorar

51 Dar visibilidade s aes da universidade

Iniciativa estratgica

dar visibilidade

52 Fomentar programas, projetos e cursos de extenso

Iniciativa estratgica

fomentar

Iniciativa estratgica

criar

Iniciativa estratgica

ampliar

Iniciativa estratgica

desenvolver

56 Promover a transparncia das informaes institucionais para a sociedade

Iniciativa estratgica

promover

57 Construir polticas e prticas para comunicao organizacional

Iniciativa estratgica

construir

Passo

clicar, clicar

janela

Passo

clicar

Digitar o Cdigo do curso ou Nome da Unidade e clicar em Procurar

Passo

digitar, clicar

Passo

digitar, clicar, clicar

62 Para cadastrar Turma: clicar na flecha ao lado de Novo e escolher Turma

Passo

cadastrar, clicar, escolher

63 Clique na lupa ao lado de Cdigo da Disciplina

Passo

clicar

64 Digite o cdigo da Disciplina, clique em Procurar, depois em Selecionar

Passo

digitar, clicar, selecionar

65 Preencher os campos solicitados

Passo

preencher

66 Selecionar a disciplina desejada e clicar no cone Alterar

Passo

selecionar, clicar

67 Efetuar as alteraes desejadas e clicar em Salvar

Passo

efetuar, clicar

68 Clicar na flecha ao lado de Novo e selecionar Horrio

Passo

clicar, selecionar

69 Clicar duas vezes na disciplina

Passo

clicar

70 Clicar em Horrios

Passo

clicar

71 Clicar no cone Alterar

Passo

clicar

72 Efetuar as alteraes necessrias

Passo

efetuar

73 Clicar no boto Salvar

Passo

clicar

74 Clicar no cone Tramitar

Passo

clicar

53 Criar fruns de discusso entre a universidade, a comunidade acadmica e a

sociedade
54 Ampliar os servios oferecidos sociedade
55 Desenvolver aes de Transparncia Organizacional e de estmulo ao Controle
Social

58 Clicar em Educao/ Controle Acadmico /Oferta de Disciplina e clicar duas vezes

em Oferta de Disciplina por Curso
59 Na tela Oferta de Disciplinas por Curso, clicar em Localizar na parte superior da

60

61 Se voc digitar a palavra curso, surgir a tela abaixo. Clicar no curso desejado e
em seguida clicar em Selecionar

74

75 Na Guia Destino aparece o Departamento que receber o processo. Na Guia

Despacho digite o despacho necessrio e na Guia Documento Vinculado voc pode
anexar um documento

Passo

digitar, anexar

Passo

escolher

Passo

clicar

Passo

visualizar, dar parecer

Passo

clicar

Passo

cadastrar

Passo

localizar, selecionar

Passo

clicar, escolher

76 Escolher o Fluxo. Escolher a opo: Envia para vinculao de Docentes, Espao

Fsico e Blocos
77 Clicar em OK
78 Na segunda folha da tela principal, Caixa Postal, podemos visualizar todos os
documentos que esto tramitando e sobre os quais o usurio dever dar um parecer
79 Clicar em Novo
80 Para cadastrar o docente, na tela inicial, v na opo 11.02.03.02 Oferta de
Disciplina por Departamento
81 Localizar o curso e selecionar a disciplina desejada
82

Clicar com o boto direito em turma e escolher Docente

83 Localize o docente clicando na lupa ao lado de matrcula. Digitar a matrcula no

campo Matrcula. Clicar no boto Procurar escolher o docente e clicar no boto
Selecionar

localizar, digitar, clicar,

Passo

procurar, escolher, clicar

Passo

digitar

Passo

escolher

Passo

cadastrar, clicar, clicar

87 Selecionar o Dia da Semana, escolher o Espao Fsico clicando no +

Passo

selecionar, escolher

88 Escolher o espao fsico e clicar no boto Adicionar

Passo

escolher, clicar

Passo

clicar

90 Na tela Matrcula por Aluno, clicar em Localizar

Passo

clicar

91 Digitar o cdigo do curso ou o Nome da Unidade e clicar em OK.

Passo

digitar, clicar

92 Clicar na LUPA para encontrar a Matrcula do Aluno

Passo

digitar, clicar

93 Digitar a matrcula e clicar em OK

Passo

digitar, clicar

84 Digitar o Encargo Didtico, isto , a quantidade de carga horria semestral ou anual

do docente na turma
85 No Papel do Docente escolher uma dentre as opes: Coordenador (docente titular)
da disciplina, Colaborador, Substituto, Ministrante, Responsvel ou Titular
86 Para cadastrar o espao fsico, clicar com o boto direito em turma e em seguida
clicar com o boto esquerdo sobre Espao Fsico

89 Na Tela Principal clicar em Educao / Controle Acadmico / Matrcula / Matrcula

por Aluno

94 Clicar em Aluno/Procurar, escolher no nome do aluno desejado e clicar em

Selecionar

clicar, escolher,
Passo

selecionar

95 Na tela Matrcula por Aluno, clicar em Localizar

Passo

clicar

96 Digitar o cdigo do curso e clicar em OK

Passo

digitar, clicar

97 Clicar na lupa para encontrar a Matrcula do Aluno

Passo

clicar

98 Digitar a matrcula e clicar em OK

Passo

digitar, clicar

4.4.9. EIA - Identificar os verbos com significado semelhante

Em seguida deve-se realizar a anlise semntica dos verbos identificados para garantir
que verbos com significados semelhantes no sejam considerados verbos diferentes. Os
seguintes verbos identificados em cada candidato a interesse transversal possuem significado
semelhante e sero considerados sinnimos:
75

- confeccionar = elaborar = montar = gerar = produzir = construir = emitir = criar =

desenvolver;
- realizar = efetuar;
- selecionar = escolher;
- verificar = analisar;
- aumentar = ampliar;
- digitar = preencher;
Depois disso deve-se calcular o nmero de ocorrncias dos verbos nos trechos das
representaes organizacionais e remover da lista de candidatos a interesse transversal aqueles
que possuem verbos com apenas uma ocorrncia. A justificativa que esses trechos no
possuem a caracterstica de espalhamento e, portanto, no devem ser interesses transversais.
4.4.10. EIA - Calcular ocorrncia dos verbos
O passo seguinte calcular o nmero de ocorrncia de cada verbo. O resultado
apresentado na Tabela 10.
Tabela 10 Nmero de ocorrncias dos verbos nos trechos das representaes organizacionais
Verbo

Ocorrncia

acessar

informar

solicitar

confeccionar = elaborar = montar = gerar = produzir = construir = emitir = criar = desenvolver = realizar = efetuar

14

agendar

verificar = analisar

encaminhar

registrar = cadastrar

arquivar

propor

pronunciar

discutir

enviar

responder

assinar

incluir

76

apoiar

promover

fomentar

ampliar = aumentar

gerir

incentivar

melhorar

dar visibilidade

clicar

35

digitar = preencher

12

selecionar = escolher

15

anexar

dar parecer

visualizar

localizar

procurar

4.4.11. EIA - Descartar verbos com apenas 1 ocorrncia

Os verbos com apenas uma ocorrncia no indicam espalhamento, que uma
caracterstica do interesse transversal, dessa forma sero desconsiderados. O resultado dessa
atividade apresentado na Tabela 11 onde j foram includas as informaes de quais trechos
contm os verbos com mais de uma ocorrncia.
Tabela 11 Candidatos a interesse transversal presente nas representaes organizacionais
Seo

Trecho elementar

Tipo

Verbo

Inscrever veterano em

Solicitar impresso da documentao de inscrio em disciplina

Atividade

solicitar

disciplina

Emitir relatrio de solicitao de inscrio em disciplina e histrico

Atividade

emitir

Agendar semana de confirmao de inscrio em disciplina

Atividade

agendar

Verificar relatrio de solicitao de inscrio em disciplina

Atividade

verificar

Encaminhar relatrio de solicitao de inscrio em disciplina

Atividade

encaminhar

Verificar modificaes na solicitao de inscrio em disciplina

Atividade

verificar

Arquivar relatrio de inscrio em disciplinas

Atividade

arquivar

Confeccionar proposta de grade horria

Atividade

confeccionar

Pronunciar optativas

Atividade

pronunciar

Pronunciar matrias ofertadas da ps-graduao

Atividade

pronunciar

Pronunciar matrias ofertadas de outros departamentos

Atividade

pronunciar

Efetuar mudanas necessrias

Atividade

efetuar

Solicitar mudanas

Atividade

solicitar

Gerar grade horria

77

Discutir aes

Verificar necessidade de realizao de pesquisa

Atividade

verificar

Elaborar pesquisa

Atividade

elaborar

Analisar resposta

Atividade

analisar

Tratar solicitao de

Solicitar diploma

Atividade

solicitar

diploma

Montar processo

Atividade

montar

Analisar processo

Atividade

analisar

Assinar processo

Atividade

assinar

Encaminhar processo

Atividade

encaminhar

Tratar solicitao de

Solicitar histrico escolar

Atividade

solicitar

historico escolar

Gerar histrico escolar

Atividade

gerar

Assinar histrico escolar

Atividade

assinar

Tratar solicitao de

Encaminhar solicitao

Atividade

encaminhar

incluso/excluso de

Arquivar solicitao

Atividade

arquivar

Agendar reunio

Atividade

agendar

Realizar reunio

Atividade

realizar

Elaborar ata

Atividade

elaborar

Assinar ata

Atividade

assinar

Fomentar a produo acadmica.

Iniciativa

fomentar

disciplinas
Tomar decises

Garantir a produo, difuso

e preservao do saber em
todos os campos do

estratgica
Produzir instrumentos de difuso da produo acadmica

conhecimento

Iniciativa

Promover a organizao e acesso produo cientfica da UNIRIO em

Iniciativa

meio digital de forma a elevar a sua visibilidade e impacto

estratgica

Formar cidados com

Fomentar aes voltadas para o incentivo de insero dos discentes no

Iniciativa

conscincia humanista,

mundo do trabalho

estratgica

crtica e reflexiva,

Fomentar Programas de Nivelamento e Aprimoramento do processo de

Iniciativa

comprometidos com a

construo do conhecimento

estratgica

Ampliar o preenchimento de vagas na graduao de modo a consolidar

Iniciativa

os cursos existentes, em todas as modalidades

estratgica

Aumentar a oferta de bolsas para discentes

Iniciativa

sociedade e sua
transformao, qualificados
para o exerccio profissional

produzir

estratgica
promover

fomentar

fomentar

ampliar

aumentar

estratgica
Fomentar aes visando formao e qualificao de professores para

Iniciativa

a Educao Bsica

estratgica

Fomentar a atuao acadmica no HUGG

Iniciativa

fomentar

fomentar

estratgica
Estender sociedade os

Fomentar programas, projetos e cursos de extenso

benefcios da criao

Iniciativa

fomentar

estratgica

cultural, artstica, cientfica

Criar fruns de discusso entre a universidade, a comunidade acadmica

Iniciativa

e tecnolgica gerada na

e a sociedade

estratgica

instituio

Ampliar os servios oferecidos sociedade

Iniciativa

criar

ampliar

estratgica
Garantir a transparncia

Desenvolver aes de Transparncia Organizacional e de estmulo ao

Iniciativa

organizacional

Controle Social

estratgica

desenvolver

78

Promover a transparncia das informaes institucionais para a

Iniciativa

sociedade

estratgica

Construir polticas e prticas para comunicao organizacional

Iniciativa

promover

construir

estratgica
Oferta de disciplina

Clicar em Educao/ Controle Acadmico /Oferta de Disciplina e clicar

Passo

clicar e clicar

Passo

clicar

Digitar o Cdigo do curso ou Nome da Unidade e clicar em Procurar

Passo

digitar e clicar

Se voc digitar a palavra curso, surgir a tela abaixo. Clicar no curso

Passo

digitar e clicar e

duas vezes em Oferta de Disciplina por Curso

Na tela Oferta de Disciplinas por Curso, clicar em Localizar na parte
superior da janela

desejado e em seguida clicar em Selecionar

Para cadastrar Turma:, clicar na flecha ao lado de Novo e escolher

clicar
Passo

Turma

cadastrar e clicar e
escolher

Clique na lupa ao lado de Cdigo da Disciplina

Passo

clicar

Digite o cdigo da Disciplina, clique em Procurar, depois em Selecionar

Passo

digitar e clicar e
selecionar

Ajuste de oferta de
disciplina

Ajuste de horrios

Tramitaes

Preencher os campos solicitados

Passo

preencher

Selecionar a disciplina desejada e clicar no cone Alterar

Passo

selecionar e clicar

Efetuar as alteraes desejadas e clicar em Salvar

Passo

efetuar e clicar

Clicar na flecha ao lado de Novo e selecionar Horrio

Passo

clicar e selecionar

Clicar duas vezes na disciplina

Passo

clicar

Clicar em Horrios

Passo

clicar

Clicar no cone Alterar

Passo

clicar

Efetuar as alteraes necessrias

Passo

efetuar

Clicar no boto Salvar

Passo

clicar

Clicar no cone Tramitar

Passo

clicar

Na Guia Destino aparece o Departamento que receber o processo. Na

Passo

digitar e anexar

Passo

escolher

Clicar em OK

Passo

clicar

Clicar em Novo

Passo

visualizar e dar

Guia Despacho digite o despacho necessrio e na Guia Documento

Vinculado voc pode anexar um documento
Escolher o Fluxo. Escolher a opo: Envia para vinculao de Docentes,
Espao Fsico e Blocos

Cadastro de nova turma

parecer
Para cadastrar o docente, na tela inicial, v na opo 11.02.03.02 Oferta

Passo

clicar

Localizar o curso e selecionar a disciplina desejada

Passo

cadastrar

Clicar com o boto direito em turma e escolher Docente.

Passo

localizar e

Localize o docente clicando na lupa ao lado de matrcula. Digitar a

Passo

clicar e escolher

Passo

localizar, digitar,

de Disciplina por Departamento

selecionar

matrcula no campo Matrcula. Clicar no boto Procurar escolher o

docente e clicar no boto Selecionar
Digitar o Encargo Didtico, isto , a quantidade de carga horria
semestral ou anual do docente na turma

clicar, procurar,
escolher e clicar

79

No Papel do Docente escolher uma dentre as opes: Coordenador

Passo

digitar

Passo

escolher

Passo

cadastrar, clicar e

(docente titular) da disciplina, Colaborador, Substituto, Ministrante,

Responsvel ou Titular
Para cadastrar o espao fsico, clicar com o boto direito em turma e em
seguida clicar com o boto esquerdo sobre Espao Fsico
Selecionar o Dia da Semana, escolher o Espao Fsico clicando no +

clicar

Lanamento de matrcula

Escolher o espao fsico e clicar no boto Adicionar

Passo

selecionar e escolher

Na Tela Principal clicar em Educao / Controle Acadmico / Matrcula

Passo

escolher e clicar

Na tela Matrcula por Aluno, clicar em Localizar

Passo

clicar

Digitar o cdigo do curso ou o Nome da Unidade e clicar em OK.

Passo

clicar

Clicar na LUPA para encontrar a Matrcula do Aluno

Passo

digitar e clicar

Digitar a matrcula e clicar em OK.

Passo

digitar e clicar

Clicar em Aluno/Procurar, escolher no nome do aluno desejado e clicar

Passo

digitar e clicar

Passo

clicar e escolher e

/ Matrcula por Aluno.

em Selecionar.
Excluso de matrcula

Na tela Matrcula por Aluno, clicar em Localizar

selecionar
Digitar o cdigo do curso e clicar em OK

Passo

clicar

Clicar na lupa para encontrar a Matrcula do Aluno

Passo

digitar e clicar

Digitar a matrcula e clicar em OK

Passo

digitar e clicar

Na sequncia devem ser identificados os trechos que compartilham mais de um verbo,

e identificado o verbo predominante, se houver, de acordo com a estrutura lingustica da frase.
Se no houver predominncia, tem-se caracterizado a entrelaamento de um conceito.
A identificao da predominncia tambm apresentada por Ali e Kasirum (2011).
Segundo os autores temos 3 tipos de sintaxe:
1) Frase Nominal Frase Verbal 1-para-Frase Verbal 2-Conjuno-Frase Verbal 3
a. Essa morfologia mostra que FV2 disparada por FV1 e FV3
b. Exemplo: os estudantes podem entrar para assistir ao vdeo se foram
registrados
2) Frase Nominal-Frase Verbal 1-Conjuno-Frase Verbal 2
a. Essa morfologia mostra que FV1 disparado por FV2
b. Exemplo: usurios devem ser alertados quando receberem um novo email
80

3) Frase Nominal-Frase Verbal 1-e-Frase Verbal 2

a. Exemplo: professores deveriam poder ver as informaes dos estudantes e
moderar discusses
Com base nas sintaxes identificadas, as seguintes regras podem ser usadas para um
interesse emaranhado, no caso do mtodo proposto, em um trecho de representao
organizacional compartilhado por mais de um verbo:
- regra 1: na sintaxe 1, FV2 disparada por FV1 e FV3, neste caso o verbo dominante
FV2;
- regra 2: na sintaxe 2, FV1 disparada por FV2, neste caso FV1 dominante;
- regra 3: na sintaxe 3, o peso dos 2 verbos igual, dessa forma no h verbo
dominante.
4.4.12. EIA - Identificar os trechos que compartilham mais de um verbo
O prximo passo identificar os trechos das representaes organizacionais que
compartilham mais de um verbo. No exemplo da EIA no foram encontrados trechos que
atendam esse critrio, exceto no caso do Manual do SIE, porm, pela observao do contedo
entende-se que falha na estruturao do documento como o caso no passo Digitar a
matrcula e clicar em OK. Esse trecho descreve dois passos juntos e, portanto, os verbos
possuem o mesmo peso. Uma possibilidade para melhorar a estruturao do documento seria
ter cada um dos verbos em um passo.
Aps identificao dos verbos dominantes em cada trecho, deve-se revisar a lista de
interesses transversais, especialmente para verificar se algum verbo que foi considerado como
no dominante deve ser removido.
4.4.13. EIA - Revisar lista de interesses transversais
Como no foram identificados trechos com mais de um verbo, esse passo no foi
realizado no caso da EIA.
O passo seguinte listar os trechos candidatos a interesse transversal organizados por
verbo e analisar quais destes verbos aparecem repetidos apenas na mesma representao
81

organizacional. Isso pode ser considerado como um interesse transversal daquele tipo
representao e no da Arquitetura como um todo que o que prope o mtodo, eles fazem
parte das representaes, mas no esto espalhados pela Arquitetura, esto espalhados apenas
na mesma representao e nesse caso pode-se utilizar uma abordagem orientada a aspectos
especfica para essa representao. Verbos especficos de determinados tipos de
representao, como clicar e fomentar podem ser desconsiderados e removidos da lista de
candidatos a interesse transversal, que nesse momento passa a ser a lista dos interesses
transversais identificados no nvel da Arquitetura Empresarial de uma organizao.
4.4.14. EIA - Descartar trechos com verbos repetidos apenas na mesma
representao organizacional
O agrupamento dos trechos das representaes organizacionais por verbo
apresentado na Tabela 12. Nas linhas 5 e 6, por exemplo, os verbos considerados do mesmo
grupo (emitir e confeccionar) esto agrupados em tom de cinza. Assim os agrupamentos
foram apresentados em cinza e branco intercalados.
Tabela 12 Candidatos a interesse transversal agrupados
Contedo elemento
bsico

Trecho elementar

Tipo

Verbo

Inscrever veterano em
disciplina

Solicitar impresso da documentao de inscrio em disciplina

Atividade

solicitar

Gerar grade horria

Tratar solicitao de
diploma
Tratar solicitao de
histrico escolar
Inscrever veterano em
disciplina

Solicitar mudanas
Solicitar diploma

Atividade
Atividade

solicitar
solicitar

Solicitar histrico escolar

Atividade

solicitar

Emitir relatrio de solicitao de inscrio em disciplina e histrico

Atividade

emitir

Gerar grade horria

Gerar grade horria
Discutir aes
Tratar solicitao de
diploma
Tratar solicitao de
historio escolar
Tomar decises

Confeccionar proposta de grade horria

Efetuar mudanas necessrias
Elaborar pesquisa
Montar processo

Atividade
Atividade
Atividade
Atividade

confeccionar
efetuar
elaborar
montar

Gerar histrico escolar

Atividade

gerar

Realizar reunio

Atividade

realizar

Tomar decises
Garantir a produo,
difuso e preservao
do saber em todos os
campos do
conhecimento

Elaborar ata
Produzir instrumentos de difuso da produo acadmica

Atividade
Iniciativa
estratgica

elaborar
produzir

Estender sociedade os
benefcios da criao
cultural, artstica,
cientfica e tecnolgica
gerada na instituio

Criar fruns de discusso entre a universidade, a comunidade acadmica e

a sociedade

Iniciativa
estratgica

criar

82

Garantir a transparncia
organizacional

Desenvolver aes de Transparncia Organizacional e de estmulo ao

Controle Social

Iniciativa
estratgica

desenvolver

Estender sociedade os
benefcios da criao
cultural, artstica,
cientfica e tecnolgica
gerada na instituio

Construir polticas e prticas para comunicao organizacional

Iniciativa
estratgica

construir

Ajuste de oferta de
disciplina

Efetuar as alteraes desejadas e clicar em Salvar

Passo

efetuar

Ajuste de horrios

Efetuar as alteraes necessrias

Passo

efetuar

Inscrever veterano em
disciplina
Tomar decises
Inscrever veterano em
disciplina

Agendar semana de confirmao de inscrio em disciplina

Atividade

agendar

Agendar reunio
Verificar relatrio de solicitao de inscrio em disciplina

Atividade
Atividade

agendar
verificar

Inscrever veterano em
disciplina
Discutir aes

Verificar modificaes na solicitao de inscrio em disciplina

Atividade

verificar

Verificar necessidade de realizao de pesquisa

Atividade

verificar

Discutir aes
Tratar solicitao de
diploma

Analisar resposta
Analisar processo

Atividade
Atividade

analisar
analisar

Inscrever veterano em
disciplina

Encaminhar relatrio de solicitao de inscrio em disciplina

Atividade

encaminhar

Tratar solicitao de
diploma
Tratar solicitao de
incluso/excluso de
disciplinas
Inscrever veterano em
disciplina

Encaminhar processo

Atividade

encaminhar

Encaminhar solicitao

Atividade

encaminhar

Arquivar relatrio de inscrio em disciplinas

Atividade

arquivar

Tratar solicitao de
incluso/excluso de
disciplinas
Gerar grade horria

Arquivar solicitao

Atividade

arquivar

Pronunciar optativas

Atividade

pronunciar

Gerar grade horria

Pronunciar matrias ofertadas da ps-graduao

Atividade

pronunciar

Gerar grade horria

Pronunciar matrias ofertadas de outros departamentos

Atividade

pronunciar

Tratar solicitao de
diploma
Tratar solicitao de
historio escolar

Assinar processo

Atividade

assinar

Assinar histrico escolar

Atividade

assinar

Tomar decises

Assinar ata

Atividade

assinar

Garantir a produo,
difuso e preservao
do saber em todos os
campos do
conhecimento

Fomentar a produo acadmica

Iniciativa
estratgica

fomentar

Formar cidados com

conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional

Fomentar aes voltadas para o incentivo de insero dos discentes no

mundo do trabalho

Iniciativa
estratgica

fomentar

Formar cidados com

conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional

Fomentar Programas de Nivelamento e Aprimoramento do processo de

construo do conhecimento

Iniciativa
estratgica

fomentar

83

Formar cidados com

conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional

Fomentar aes visando formao e qualificao de professores para a

Educao Bsica

Iniciativa
estratgica

fomentar

Formar cidados com

conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional

Fomentar a atuao acadmica no HUGG

Iniciativa
estratgica

fomentar

Estender sociedade os
benefcios da criao
cultural, artstica,
cientfica e tecnolgica
gerada na instituio
Garantir a produo,
difuso e preservao
do saber em todos os
campos do
conhecimento

Fomentar programas, projetos e cursos de extenso

Iniciativa
estratgica

fomentar

Promover a organizao e acesso produo cientfica da UNIRIO em

meio digital de forma a elevar a sua visibilidade e impacto

Iniciativa
estratgica

promover

Promover a transparncia das informaes institucionais para a sociedade

Iniciativa
estratgica

promover

Formar cidados com

conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional
Formar cidados com
conscincia humanista,
crtica e reflexiva,
comprometidos com a
sociedade e sua
transformao,
qualificados para o
exerccio profissional

Ampliar o preenchimento de vagas na graduao de modo a consolidar os

cursos existentes, em todas as modalidades

Iniciativa
estratgica

ampliar

Aumentar a oferta de bolsas para discentes

Iniciativa
estratgica

aumentar

Estender sociedade os
benefcios da criao
cultural, artstica,
cientfica e tecnolgica
gerada na instituio
Oferta de disciplina

Ampliar os servios oferecidos sociedade

Iniciativa
estratgica

ampliar

Clicar em Educao/ Controle Acadmico /Oferta de Disciplina e clicar

duas vezes em Oferta de Disciplina por Curso

Passo

clicar

Oferta de disciplina

Na tela Oferta de Disciplinas por Curso, clicar em Localizar na parte

superior da janela
Digitar o Cdigo do curso ou Nome da Unidade e clicar em Procurar

Passo

clicar

Passo

clicar

Oferta de disciplina

Se voc digitar a palavra curso, surgir a tela abaixo. Clicar no curso

desejado e em seguida clicar em Selecionar

Passo

clicar

Oferta de disciplina

Para cadastrar Turma:, clicar na flecha ao lado de Novo e escolher Turma

Passo

clicar

Oferta de disciplina

Clique na lupa ao lado de Cdigo da Disciplina

Passo

clicar

Ajuste de oferta de
disciplina
Ajuste de oferta de
disciplina

Selecionar a disciplina desejada e clicar no cone Alterar

Passo

clicar

Efetuar as alteraes desejadas e clicar em Salvar

Passo

clicar

Garantir a transparncia
organizacional

Oferta de disciplina

84

Ajuste de oferta de
disciplina

Clicar na flecha ao lado de Novo e selecionar Horrio

Passo

clicar

Ajuste de horrios
Ajuste de horrios
Ajuste de horrios

Clicar duas vezes na disciplina

Clicar em Horrios
Clicar no cone Alterar

Passo
Passo
Passo

clicar
clicar
clicar

Ajuste de horrios
Tramitaes
Tramitaes

Clicar no boto Salvar

Clicar no cone Tramitar
Clicar em OK

Passo
Passo
Passo

clicar
clicar
clicar

Cadastro de nova turma

Clicar em Novo

Passo

clicar

Cadastro de nova turma

Cadastro de nova turma

Clicar com o boto direito em turma e escolher Docente.

Passo
Localize o docente clicando na lupa ao lado de matrcula. Digitar a
Passo
matrcula no campo Matrcula. Clicar no boto Procurar escolher o docente
e clicar no boto Selecionar

clicar
clicar

Cadastro de nova turma

Para cadastrar o espao fsico, clicar com o boto direito em turma e em

seguida clicar com o boto esquerdo sobre Espao Fsico

Passo

clicar

Cadastro de nova turma

Escolher o espao fsico e clicar no boto Adicionar

Passo

clicar

Lanamento de
matrcula
Lanamento de
matrcula

Na Tela Principal clicar em Educao / Controle Acadmico / Matrcula /

Matrcula por Aluno.
Na tela Matrcula por Aluno, clicar em Localizar

Passo

clicar

Passo

clicar

Lanamento de
matrcula
Lanamento de
matrcula
Lanamento de
matrcula
Lanamento de
matrcula
Excluso de matrcula

Digitar o cdigo do curso ou o Nome da Unidade e clicar em OK.

Passo

clicar

Clicar na LUPA para encontrar a Matrcula do Aluno

Passo

clicar

Digitar a matrcula e clicar em OK.

Passo

clicar

Clicar em Aluno/Procurar, escolher no nome do aluno desejado e clicar em Passo

Selecionar.
Digitar o cdigo do curso e clicar em OK
Passo

clicar

Excluso de matrcula

Clicar na lupa para encontrar a Matrcula do Aluno

Passo

clicar

Excluso de matrcula

Digitar a matrcula e clicar em OK

Passo

clicar

Oferta de disciplina

Digitar o Cdigo do curso ou Nome da Unidade e clicar em Procurar

Passo

digitar

Oferta de disciplina

Se voc digitar a palavra curso, surgir a tela abaixo. Clicar no curso

desejado e em seguida clicar em Selecionar

Passo

digitar

Oferta de disciplina

Digite o cdigo da Disciplina, clique em Procurar, depois em Selecionar

Passo

digitar

Tramitaes

Na Guia Destino aparece o Departamento que receber o processo. Na

Passo
Guia Despacho digite o despacho necessrio e na Guia Documento
Vinculado voc pode anexar um documento
Localize o docente clicando na lupa ao lado de matrcula. Digitar a
Passo
matrcula no campo Matrcula. Clicar no boto Procurar escolher o docente
e clicar no boto Selecionar
Digitar o Encargo Didtico, isto , a quantidade de carga horria semestral Passo
ou anual do docente na turma

digitar

Lanamento de
matrcula
Lanamento de
matrcula

Digitar o cdigo do curso ou o Nome da Unidade e clicar em OK.

Passo

digitar

Digitar a matrcula e clicar em OK.

Passo

digitar

Excluso de matrcula

Digitar o cdigo do curso e clicar em OK

Passo

digitar

Excluso de matrcula
Oferta de disciplina

Digitar a matrcula e clicar em OK

Preencher os campos solicitados

Passo
Passo

digitar
preencher

Oferta de disciplina

Digite o cdigo da Disciplina, clique em Procurar, depois em Selecionar

Passo

selecionar

Ajuste de oferta de
disciplina

Selecionar a disciplina desejada e clicar no cone Alterar

Passo

selecionar

Ajuste de oferta de
disciplina

Clicar na flecha ao lado de Novo e selecionar Horrio

Passo

selecionar

Tramitaes

Escolher o Fluxo. Escolher a opo: Envia para vinculao de Docentes,

Espao Fsico e Blocos

Passo

escolher

Cadastro de nova turma

Localizar o curso e selecionar a disciplina desejada

Passo

selecionar

Cadastro de nova turma

Cadastro de nova turma

clicar

digitar

digitar

85

Cadastro de nova turma

selecionar

Cadastro de nova turma

Localize o docente clicando na lupa ao lado de matrcula. Digitar a

Passo
matrcula no campo Matrcula. Clicar no boto Procurar escolher o docente
e clicar no boto Selecionar
No Papel do Docente escolher uma dentre as opes: Coordenador
Passo
(docente titular) da disciplina, Colaborador, Substituto, Ministrante,
Responsvel ou Titular
Selecionar o Dia da Semana, escolher o Espao Fsico clicando no +
Passo

Cadastro de nova turma

Selecionar o Dia da Semana, escolher o Espao Fsico clicando no +

Passo

escolher

Cadastro de nova turma

Escolher o espao fsico e clicar no boto Adicionar

Passo

escolher

Lanamento de
matrcula
Lanamento de
matrcula

Clicar em Aluno/Procurar, escolher no nome do aluno desejado e clicar em Passo

Selecionar.
Clicar em Aluno/Procurar, escolher no nome do aluno desejado e clicar em Passo
Selecionar.

escolher

Cadastro de nova turma

Para cadastrar o docente, na tela inicial, v na opo 11.02.03.02 Oferta de

Disciplina por Departamento
Para cadastrar o espao fsico, clicar com o boto direito em turma e em
seguida clicar com o boto esquerdo sobre Espao Fsico

Passo

cadastrar

Passo

cadastrar

Oferta de disciplina

Para cadastrar Turma:, clicar na flecha ao lado de Novo e escolher Turma

Passo

cadastrar

Cadastro de nova turma

Localizar o curso e selecionar a disciplina desejada

Passo

localizar

Cadastro de nova turma

Localize o docente clicando na lupa ao lado de matrcula. Digitar a

Passo
matrcula no campo Matrcula. Clicar no boto Procurar escolher o docente
e clicar no boto Selecionar
Na tela Matrcula por Aluno, clicar em Localizar
Passo

localizar

Cadastro de nova turma

Cadastro de nova turma

Excluso de matrcula

escolher

selecionar

selecionar

localizar

A anlise da Tabela 12 permite-nos afirmar que a maioria dos agrupamentos contm

trechos da mesma representao organizacional exceto os trechos do verbo elaborar. A
explicao para esse fato simples, j que cada representao organizacional tem seu
propsito muito claro: os processos de negcio descrevem atividades realizadas pelos
funcionrios da organizao, j o planejamento estratgico trata de planos e ambies da
organizao e o manual apresenta o passo a passo a ser seguido.
Por fim, deve-se nomear os interesses transversais listados. Essa nomeao deve
consistir principalmente em substantivar os verbos listados para que as aes reflitam
conceitos. Assim os verbos analisar e verificar, por exemplo, podem ser nomeados de
verificao. Para isso, deve-se analisar no s os verbos semelhantes que esto agrupados e
identificar um nome que reflita todos, mas tambm o real significado do verbo no trecho.
Existem casos em que a palavra foi utilizada com outro significado, como prever a
funcionalidade x que na verdade no significa adivinhar ou profetizar e sim disponibilizar.
4.4.15. EIA - Nomear os interesses transversais identificados
O seguinte interesse transversal foi identificado no nvel da Arquitetura Empresarial
da EIA: elaborao.

86

4.5. Fase Representar

Na fase Representar, a representao dos interesses transversais listados na fase
Identificar criada. Essa fase recebe como entrada a lista dos interesses transversais com a
indicao dos trechos das representaes organizacionais que os operacionalizam. A sada
dessa fase a representao dos interesses transversais com a indicao de onde esto
relacionados, ou seja, o relacionamento transversal, e o Diagrama dos Interesses Transversais.
As atividades a serem realizadas para gerar a representao dos interesses transversais
so descritas em mais detalhes na Seo 4.5.1 e a linguagem proposta para representao dos
interesses transversais na Arquitetura Empresarial detalhada a partir da Seo 4.5.2.
4.5.1. Passo a passo
A primeira atividade da fase Representar criar o modelo que representa os
interesses transversais no nvel da Arquitetura Empresarial, ou seja, o Diagrama dos
Interesses Transversais. Alm disso, deve-se especificar o relacionamento transversal de cada
trecho da lista de interesses transversais gerada pela fase Identificar. Essas atividades esto
representadas na Figura 33.

Figura 33 Passo a passo da fase Representar

Essa dissertao prope uma representao dos interesses transversais na Arquitetura
Empresarial utilizando um diagrama de classes da UML, o diagrama de classes foi escolhido
por permitir a representao de conceitos e os relacionamentos existentes entre eles. Um
exemplo para ilustrar o contedo do diagrama encontra-se na Figura 34. Nesse diagrama temse o Interesse Transversal como classe pai e os seguintes interesses transversais como filhos:
Log, Transparncia, Auditoria e Persistncia. Isso significa que os filhos so um tipo de
87

interesse transversal especfico e cada um dos tipos se aplica a representaes organizacionais

diferentes que so onde eles ocorrem. Ao instanciar a sintaxe representada na Figura 38,
teremos tipos de interesses transversais distintos, justificando os diferentes interesses
transversais filhos. O diagrama de interesses transversais no representa instncias de
interesse transversal e sim tipos de interesses transversais que existem em determinada
organizao.

Figura 34 Exemplo de um diagrama para representar os Interesses Transversais

4.5.1.1 EIA - Criar o diagrama de interesses transversais
A atividade seguinte elaborar o Diagrama dos Interesses Transversais. O Diagrama
dos Interesses Transversais da EIA representado na Figura 35.

Figura 35 Interesses transversais na EIA

Com o modelo do interesse transversal criado e a especificao de todos os seus
relacionamentos transversais, tem-se os interesses transversais relacionados s representaes
de uma organizao.
4.5.1.2 EIA Especificar o relacionamento transversal para cada interesse
transversal identificado
88

A fase Representar inclui a especificao dos relacionamentos transversais dos

interesses transversais identificados relacionados s representaes organizacionais que os
contm. A especificao do relacionamento transversal do interesse transversal Elaborao
apresentada na Figura 36. Na declarao de transversalidade do aspecto Elaborao so
indicados todos os trechos onde ocorre o conceito Elaborao, por exemplo, depois da
atividade Solicitar impresso da documentao para inscrio em disciplina no trecho
Inscrever veterano em disciplina dentro do artefato Modelo de Processos de Negcio da EIA.
Em todos os pontos descritos na declarao de transversalidade ocorre a ao de incluir
(INCLUDE) o aspecto Elaborao.

Figura 36 Definio do relacionamento transversal Elaborao

Essas representaes fazem parte da Arquitetura Empresarial da organizao, assim os
interesses transversais so explicitados no nvel da Arquitetura Empresarial. Alm disso,
pode-se afirmar que so esses os interesses transversais presentes na operacionalizao da
organizao. Os interesses transversais no aparecem na representao da essncia da
organizao justamente por possurem carter de apoio, ou seja, apoiam a essncia da
organizao. Mesmo nos casos em que as transaes ontolgicas contenham os verbos com
89

sentido semelhante aos identificados nos interesses transversais, ter significado mais
especfico.
4.5.2. A Linguagem para especificao de interesses transversais na Arquitetura
Empresarial
Para a fase Representar, proposta uma linguagem chamada LMAEOA (Linguagem
de Modelagem da Arquitetura Empresarial Orientada a Aspectos) que permitir representar os
interesses transversais em qualquer representao da Arquitetura Empresarial. Essa linguagem
composta pelos seguintes itens representados na Figura 37:
Elementos dos tipos de modelos que faro parte da linguagem - qualquer
linguagem de modelagem da Arquitetura Empresarial que permita a criao
dos artefatos propostos por Zachman (Zachman, 2008) para representar a
Arquitetura de uma empresa. Cada tipo de modelo constitudo por elementos
prprios. Por exemplo, os elementos de um modelo de processos de negcio
so atividades, atores, eventos, raias; os elementos de um manual de usurio
so os passos de uma funcionalidade.;
Elementos do modelo ncleo representados pelo relacionamento transversal;
O modelo de pontos de juno ou joinpoints que representa o conjunto de
elementos dos tipos de modelos que podem ser afetados por um
relacionamento transversal

Figura 37 Componentes usados para representar interesses transversais em modelos da

Arquitetura Empresarial (adaptado de Cappelli (CAPPELLI, 2009)
90

Essa linguagem, representada na Figura 37, juntamente com o modelo representado na

Figura 39 formam a infra-estrutura necessria para a representao dos interesses transversais
na Arquitetura Empresarial.
Na Figura 38 apresentada a sintaxe da LMAEOA cujos detalhes so apresentados a
partir da Seo 4.5.2.1. Na Figura 39 representado o modelo conceitual dessa linguagem
onde esto representados os elementos que fazem parte de cada um dos componentes da
LMAEOA. No modelo conceitual optou-se por deixar os termos em ingls para facilitar a
associao aos conceitos conforme apresentados no Captulo 3.

Figura 38 Sintaxe de LMAEOA (adaptado de Cappelli (Cappelli, 2009))

A Figura 39 uma adaptao do modelo da linguagem de modelagem de processos
orientada a aspectos proposta por Cappelli (2009). A adaptao realizada foi alterar a
cardinalidade entre as entidades LMAEOA e model. No caso de Cappelli (2009), a linguagem
era composta de apenas 1 modelo, no caso da LMAEOA possvel ter diversos tipos de
modelos e pelo menos 1.
A partir da Seo 4.5.2.1 so apresentados com maiores detalhes cada um dos
componentes da LMAEOA.

91

Figura 39 Modelo conceitual da linguagem de modelagem da Arquitetura Empresarial

orientada a aspectos (adaptado de Cappelli (CAPPELLI, 2009))
4.5.2.1. Modelo de Componentes
No modelo conceitual da LMAEOA (Figura 39), o modelo de componentes representa
uma linguagem de modelagem da Arquitetura Empresarial descrita por modelos que possuem
um tipo e um identificador, dependendo do tipo, o modelo poder ter componentes e/ou
relacionamentos, assim possvel representar tanto listas quanto modelos mais complexos
(linhas 2, 3 e 4 da Figura 38).
Os elementos Componentset e relationship so elementos a serem instanciados (linhas
5, 6, 7 e 8 da Figura 38) de acordo com o modelo da Arquitetura Empresarial a ser
considerado. Componentset possui um tipo e um identificador. Com essa linguagem
possvel representar tanto os modelos convencionais da Arquitetura Empresarial,
considerando o Framework de Zachman, como lista de conceitos do negcio, lista de
processos de negcio, modelos de processos de negcio, arquitetura da aplicao, arquitetura
de rede, cdigo fonte etc. quanto os modelos a serem utilizados para representar os interesses
transversais (Figura 34). Na Figura 40 apresentada uma instanciao modelo conceitual da
LMAEOA para o modelo de processos de negcio. Nesse exemplo o tipo de modelo
92

Diagrama de Processos de Negcio, os tipos de componentes so atividade, evento, ator etc.

(elementos que compem o diagrama), os relacionamentos so o relacionamento transversal e
os relacionamentos convencionais (sequencia, mensagem e associao) e os possveis
joinpoints so atividade e evento, ou seja, os elementos que podem ser interceptados por um
aspecto.

Figura 40 Instanciao da sintaxe de LMAEOA para Diagrama de processos de negcio

4.5.2.2. Modelo de Joinpoints
Os joinpoints so elementos do modelo de componentes que podem ser afetados por
aspectos, como classe, atividade, dado, mtodo etc. Em linguagens de implementao, eles
podem ser estticos ou dinmicos: um joinpoint esttico uma localizao na estrutura de um
elemento, j um joinpoint dinmico uma localizao na execuo de um programa. Como na
Arquitetura Empresarial possvel tanto modelos quanto cdigo de implementaes, as duas
alternativas so possveis.
Na Figura 38 o construto joinpoint (linha 7) no tem valor definido porque depende do
modelo de componentes a ser considerado. O modelo de joinpoints ser composto pelos
elementos da linguagem sobre os quais podero incidir os aspectos, ou seja, os elementos dos
diversos tipos de modelos a serem criados para representar a arquitetura empresarial,
considerando o Framework de Zachman, os artefatos podem ser lista de conceitos do negcio,
lista de processos de negcio, modelos de processos de negcio, arquitetura da aplicao,
arquitetura de rede, cdigo fonte etc. Os respectivos possveis elementos sero item da lista,
atividade, componente, n, mtodo etc. No exemplo da Figura 40, os jointpoints so atividade
e evento, no caso do Diagrama de Processos de Negcio.
4.5.2.3Modelo Ncleo
93

O relacionamento transversal um tipo de relacionamento a ser adicionado ao modelo

de componentes (linha 8 da Figura 38), ele j existia na proposta de Cappelli (2009), e no caso
dessa dissertao ele apenas mais genrico para permitir a representao de qualquer tipo de
ponto de juno. Este relacionamento herda as informaes de origem e destino. Dentro das
linguagens de modelagem da Arquitetura Empresarial, os elementos modelados tm um tipo
(classe, atividade, dado, mtodo etc.) e pertencem a determinado modelo, que tambm deve
ser indicado. O label do relacionamento no deve ser fixo, ele deve ter um nome que o
relacione sua origem, ele colocado como uma varivel a ser especificada no momento da
criao do relacionamento transversal. Uma regra para nome-lo poderia ser sempre colocar
os trs primeiros caracteres do interesse transversal (Cappelli, 2009).
As primitivas definem como o pointcut ser afetado ( Silva e Leite, 2005). Elas
dependem do tipo de representao em questo:
Nos modelos, a inteno desta abordagem representar os interesses
transversais, sem que sejam feitas modificaes, a primitiva include faz parte
do modelo ncleo.
J nos casos de cdigo de programas, as demais primitivas add - adiciona um
conjunto de elementos ao local especificado; include - adiciona um conjunto
de elementos como sub-elementos do elemento especificado; exclude exclui um conjunto de elementos da sub-rvore especificada; e substitute substitui elementos da sub-rvore especificada so consideradas ( Silva e Leite,
2005). Na Figura 41 apresentada a sintaxe do relacionamento transversal da
LMAEOA.

Figura 41 Sintaxe do Relacionamento Transversal (adaptado de Cappelli (CAPPELLI, 2009))

94

Nas Sees 4.5.2.3.1 e 4.5.2.3.2, so apresentados o pointcut e advice, utilizados como

construtos do relacionamento transversal. Assim como em Cappelli (2009), os nomes pointcut
e advice foram mantidos para auxiliar a associao com os elementos de desenho e
implementao, porm a semntica foi adaptada para a modelagem da Arquitetura
Empresarial.
Na Figura 42, apresentado um exemplo de relacionamento transversal considerando
o aspecto LOG e os artefatos onde ele deve atuar so cdigo fonte do sistema de informao
do departamento de logstica, modelo de processo de negcio Receber mercadoria e diagrama
de caso de uso Registrar bens a receber. Foram sublinhados os nomes que indicam o tipo de
componente do artefato considerado. Isso possvel, pois no modelo conceitual da LMAEOA
todo componente possui um tipo (mtodo) e um identificador (registrarBensAReceber) e
parte de um modelo, que possui tipo (classe) e identificador (Recebimento do sistema de
informao do departamento de logstica).

Figura 42 Exemplo do Relacionamento Transversal do aspecto Log

4.5.2.3.1. Pointcut
Pointcuts indicam os elementos afetados por um interesse transversal. Cada pointcut
definido por um nome e uma expresso (linhas 4 e 5 da Figura 41). Expresses consistem em
sentenas que usam operandos, operadores e primitivas. Os operandos so elementos cujos
tipos esto associados aos joinpoints (linha 6, 7, 8 e 9). Os operadores so utilizados para
agrupar um ou mais joinpoints, so eles NOT, AND e OR. As primitivas definem uma ao a
ser realizada no pointcut (linha 12). No caso de modelos que sejam diagramas ou texto, existe
somente a primitiva include que adiciona um ou mais elementos ao local especificado, as
demais primitivas devem ser utilizadas caso o tipo de modelo a ser considerado seja cdigo

95

fonte de programas. No exemplo do aspecto Log, os pointcuts so os elementos

registrarBensAReceber, Registrar bens a receber e fluxo principal.
4.5.2.3.2. Advice
Um advice define quais elementos do modelo de origem espalham-se ou entrelaam-se
nos pointcuts. Ele registra o conjunto de elementos que representa um comportamento ou
estrutura que se repete. Cada advice formado por um tipo (after, before e around) que indica
a maneira como ele afeta os pointcuts; uma expresso de pointcuts indica quais so os
pointcuts em que o advice ser aplicado; e o corpo define o conjunto de elementos que se
espalha ou se entrelaa nos pointcuts. No exemplo da Figura 42, o advice representado pelos
construtos onde e ao que indicam que o aspecto Log deve ser includo antes do mtodo
RegistrarBensAReceber na classe Recebimento, antes da atividade Registrar bens a receber
no modelo de processos Receber mercadoria e antes do fluxo principal do caso de uso
Registrar bens a receber.

4.6. Resumo
Nesse captulo foram apresentadas em detalhe as duas fases que compem o mtodo
para identificao e representao dos interesses transversais na Arquitetura Empresarial:
Identificar e Representar.
No Captulo 5 ser apresentado o estudo de caso realizado em uma empresa real.
Neste estudo de caso, para analisar o resultado obtido, foi aplicado um questionrio.

96

5. Avaliao da proposta estudo de caso

Neste Captulo apresentado o estudo de caso realizado em uma empresa real que ser
denominada ficticiamente de ABCD. Aps aplicao do mtodo, com o resultado gerado, foi
aplicado um questionrio a alguns funcionrios dessa empresa para a anlise do resultado
final. O principal objetivo do estudo de caso avaliar se mtodo proposto resolve o problema
dos interesses transversais espalhados e entrelaados nas representaes da Arquitetura
Empresarial.

5.1. Metodologia de pesquisa

O estudo de caso auxilia na validao do que foi feito na pesquisa (Yin, 1984). Esse
foi o mecanismo escolhido nessa dissertao para verificar a hiptese de que possvel
identificar e representar os interesses transversais existentes na Arquitetura Empresarial de
uma organizao. Para isso, foi realizado um estudo de caso na empresa ABCD que ser
apresentado nesse captulo. Na primeira etapa, o mtodo proposto foi executado pela autora
do mtodo com os artefatos de uma empresa real. Na segunda etapa, com base nos resultados
obtidos, foram realizadas entrevistas com dois funcionrios da empresa ABCD que conhecem
as representaes utilizadas no mtodo e a empresa para coletar suas impresses sobre os
interesses transversais identificados.
Uma vez que o mtodo foi executado, o resultado foi analisado de acordo com
respostas das entrevistas realizadas. Se as respostas estiverem de acordo com o funcionamento
do mtodo, ento pode-se afirmar que h indcios de que o mtodo resolve o problema. Para
no influenciar os participantes, o mtodo foi apresentado, de forma oral e grfica,
resumidamente, pois deseja-se descobrir se o mtodo identifica e representa os interesses
transversais da Arquitetura da empresa ABCD. Para tal, os participantes precisam entender o
que interesse transversal, conhecer as representaes organizacionais utilizadas e a sada
gerada pelo mtodo. As perguntas utilizadas na entrevista so apresentadas no Anexo V, as
respostas dos participantes na Seo 5.3.18 e a anlise das respostas na Seo 5.3.18.1.
97

5.2. Caracterizao da Empresa ABCD

A empresa onde foi realizado o estudo de caso uma empresa brasileira que atua na
comercializao de combustvel. Por questes de sigilo, o nome da empresa omitido, bem
como o nome de seus funcionrios e outras empresas que compem o grupo. Tais nomes
aparecem no contedo das representaes organizacionais utilizadas e foram substitudos por
conjuntos de letras como xxx e yyy.
Foram disponibilizadas pela rea de informtica da empresa ABCD algumas
representaes organizacionais. No entanto, devido limitao de tempo na pesquisa, apenas
algumas foram selecionadas para aplicao do mtodo. As seguintes representaes
organizacionais foram utilizadas no estudo de caso: plano de desenvolvimento do software do
Sistema de Proposta de Negociao (PNE), arquitetura do software PNE, iterao 1 do
desenvolvimento do PNE, iterao 6 do desenvolvimento do PNE, especificao do servio
Voucher B2C e padres de desenvolvimento Ensemble. Essas representaes foram
escolhidas para abranger o maior nmero possvel e maior diversidade. Estavam disponveis
diversos documentos das iteraes, por exemplo, porm muito semelhantes, por isso foram
escolhidos aqueles que descreviam a iterao 1 e a iterao 6 do software PNE. O plano de
desenvolvimento foi escolhido por conter informaes distintas dos documentos escolhidos
previamente e ainda sim fazer referncia ao mesmo software. Os documento dos padres de
desenvolvimento foi escolhido por ser totalmente diferente dos demais e conter informaes
de um padro a ser adotado. O documento de especificao do servio Voucher B2C possui
contedo distinto dos demais.

5.3. Realizao do estudo de caso

O estudo de caso procedeu da seguinte forma: a empresa foi convidada a participar do
estudo de caso e concluiu que no haveria recursos disponveis para executar o mtodo por
conta prpria, assim concordou em fornecer alguns artefatos para que o mtodo pudesse ser
realizado. A prpria autora do mtodo realizou o estudo de caso. Para isso foi necessrio
analisar os artefatos disponibilizados e escolher aqueles que apresentavam contedo mais
diversificado. Uma vez definidos quais seriam os artefatos e quais sees seriam
consideradas, o mtodo foi realizado. Com o resultado em mos a empresa foi novamente
98

contatada e 2 recursos puderam participar da entrevista, cada um no momento mais adequado

s suas agendas. Com as respostas a autora do mtodo pode analisar os resultados com base
na viso de outras pessoas alheias execuo e a todos os detalhes do mtodo e com pessoas
que conhecem a organizao mais que a prpria autora.
5.3.1. Obter representaes organizacionais e identificar os tipos de elementos
bsicos de cada uma
O primeiro passo do mtodo obter as representaes organizacionais. As
representaes organizacionais e os respectivos tipos de elementos bsicos a serem analisados
so listados na Tabela 13. O Plano de Desenvolvimento de Software referente ao software
PNE descreve a abordagem para o desenvolvimento do software e seu gerenciamento. O
Documento da Arquitetura do Software descreve a viso geral da arquitetura do software. O
documento da Iterao 1 do desenvolvimento do software apresenta o detalhamento da fase de
iniciao do projeto onde o escopo definido. O documento da Iterao 6 do
desenvolvimento do software PNE apresenta o detalhamento da fase de construo. O
documento Especificao de VoucherB2C descreve a especificao do servio de Voucher. O
documento de Padres de Desenvolvimento Ensemble descreve as regras que se aplicam ao
desenvolvimento utilizando Ensemble.
Tabela 13 Representaes organizacionais e seus respectivos tipos de elemento bsico
Representao organizacional

Verso

Tipo de elemento bsico

PN2-PlanoDesenvSoftware

1.1

Objetivo das iteraes

PN2-DocArqSoftware

1.2

Meta e restries da Arquitetura

PN2-Iterao-1

1.1

Plano objetivo

1.1

Plano cronograma

PN2-Iterao-6

1.1

Caso de uso

Especificao de VoucherB2C

1.0

Capacidade

Padres de Desenvolvimento Ensemble

1.3

Padro de desenvolvimento

O documento PN2-Iterao-1 e o documento PN2-Iterao-6, mesmo referindo-se ao

mesmo contedo que a iterao, possui elementos bsicos distintos, isso ocorreu para que
fossem analisados o maior nmero possvel de representaes e contedos. Algumas
representaes organizacionais tiveram considerados como relevantes no os trechos que
representam o contedo mais importante, mas outros tipos de contedo para diversificar o
99

contedo a ser analisado. Por exemplo, no documento que contm o Plano de

Desenvolvimento do Software, foi considerada relevante a seo que descreve os objetivos
das iteraes ao invs de ser considerada a seo que contm o planejamento do projeto em si.
O planejamento do projeto considerado como seo relevante do documento Iterao 1.
5.3.2. Listar os trechos que compem os tipos de elementos bsicos
Nesse passo so listados os trechos que compem os elementos bsicos de cada
representao organizacional. O resultado dessa atividade apresentado na Tabela 14.
Tabela 14 Todos os Trechos das representaes organizacionais
Representao

Contedo do

organizacional

elemento bsico

Trecho elementar

elementar

Plano de

Objetivos da

Iterao-1: Requisitos - Levantar as necessidades, definir as

desenvolvimento

iterao

funcionalidades, Modelo de Caso de Uso, RMPLAN e SDP

do PNE

Tipo de trecho

Iterao 2 - Analisar, projetar e implementar funcionalidades

Descrio de iterao

Descrio de iterao

significativas para a arquitetura. Objetivo Elaborao TIR/PNE

recebendo informaes do servidor WAS
Iterao 3 - Aumentar o nmero de funcionalidades significativas,

Descrio de iterao

correes e ajustes da iterao anterior. Objetivo: Elaborao TIR/PNE,

transmitindo informaes ao servidor WAS
Iterao 4 - Incluindo o "workflow"

Descrio de iterao

Iterao 5 - Implementar a release que incluir o uso parcial do

Descrio de iterao

Gerenciador de Propostas, TIR.

Iterao 6 - Elaborao quase completa envolvendo Gerenciador de

Descrio de iterao

Propostas. TIR e PNE com o envio para o servidor WAS

Iterao 7 - produto completo - Sistema completo para homologao e

Descrio de iterao

testes.
Iterao 8 - correo dos defeitos das releases anteriores, estratgia de

Descrio de iterao

treinamento e suporte, estratgia de implantao, carga inicial de

informaes, rotinas de backup, recuperao e contingncia
Arquitetura de

Metas e

software

restries da

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do

xxx

Arquitetura

O sistema dever prever a utilizao de um banco de dados nico,

Metas e restries

Metas e restries

disponibilizado para as duas empresas. A verso do banco de dados ser

o Oracle 9i ou superior. Far uso de BLOB's
Dever permitir que os assessores comerciais possam trabalhar sem

Metas e restries

estarem o tempo todo conectado rede interna da Cia

Todos os usurios da yyy acessaro o sistema na companhia via rede

Metas e restries

interna de transmisso de dados entre as 2 empresas (j existente)

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

O controle de acesso ao sistema se dar atravs do Notes quando se

Metas e restries

tratar de acesso pela web ou fluxo de aprovao

100

Para autenticao dos usurios dever utilizar o servidor LDAP nas

Metas e restries

aplicaes de Elaborao (VB)

Prever a exportao de informaes para o MS Excel

Metas e restries

O sistema operacional a ser utilizado nos notebooks ou desktop o

Metas e restries

Microsoft Windows 98 ou superior. O Browser a ser o Internet

Explorer 5.5 ou superior
A aplicao dever estar em funcionamento no horrio normal de

Metas e restries

expediente da empresa, de 6:00 s 22:00h, de segunda sexta-feira

O sistema dever prever a interface possibilitando o envio de

Metas e restries

informaes de propostas transacionadas no dia para o ERP da

companhia a exemplo do que j ocorre atualmente. Em princpio no
estaremos alterando esta interface
O sistema far uso de XML para armazenar informaes de troca entre

Metas e restries

os servidores e a aplicao cliente

Iterao 1

Plano

Utilizao de fluxo de aprovao no Notes

Metas e restries

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

O objetivo principal da iterao de se coletar requisitos para o novo

Objetivo

sistema, bem como os riscos para o projeto. Em outras palavras iremos

avaliar o escopo e risco do projeto
Estaremos iniciando o projeto em 25/04/2005 com um workshop de

Objetivo

requisitos envolvendo pessoas da rea de mercado urbano, rodovia e

consumo da companhia e yyy com a rea de informtica das 2
empresas. O workshop ter durao de 2 dias e esperamos mapear as
principais funcionalidades para o novo sistema, j com os critrios de
prioridade definidos pelo prprio usurio
Na semana seguinte estaremos realizando o workshop de casos de uso,

Objetivo

visando mapear os processos (principais cenrios de uso) do novo

sistema. Para atingir este objetivo, esperamos contar com a presena de
assessores comerciais de cada um dos mercados (urbano, rodovia e
consumo). Novamente estaremos reunindo as 2 empresas
Montagem dos artefatos de requisitos (documento de viso,

Objetivo

especificao suplementar, glossrio, modelo de caso de uso e definio

de casos de uso), artefatos de Gerncia de Projeto tais como Plano de
Iterao-2, Plano de Desenvolvimento, Lista de Riscos e cronograma
para a segunda iterao
Priorizar os casos de uso que sero objetos de estudo nesta iterao e

Objetivo

iniciar o seu detalhamento

Criao e montagem do ambiente de trabalho, tais como VOB no

Objetivo

clearcase, adoo de padres de desenvolvimento e outras diretrizes

Ainda com relao ao ambiente, preparar os ambientes de

Objetivo

desenvolvimento, ferramentas utilizadas, etc.

Definio da Equipe, propostas de contrao de recursos especializados

Objetivo

na plataforma selecionada (que deve ser Java, notes e Microsoft)

Criao de prottipos de telas e navegao para homologao pelos

Objetivo

usurios

101

Neste projeto estaremos testando o uso da ferramenta ClearQuest, para

Objetivo

gerncia de mudanas cuja finalidade ter um processo padro de

controle de mudanas documentado, assegurando a consistncia das
mudanas e que os envolvidos tenham conhecimento das modificaes e
do impacto no custo e programao gerada por elas
J nesta iterao, estaremos iniciando os testes com o produto "LEI",

Objetivo

que um software que permite ao Notes acessar diretamente o Banco de

Dados Oracle e tambm fazer acesso servidores de aplicao J2EE,
acessando componentes EJB (Enterprise Java Bean). No h uma
obrigatoriedade no uso desta ferramenta, caso no seja homologada
tempo. Poderemos optar pela forma antiga, como utilizada no sistema
PLC Proposta de Limite de Crdito
Com relao a utilizao da Infra-estrutura da companhia pela yyy creio

Objetivo

no haver maiores problemas, pois todos os testes j foram efetuados por

ocasio do desenvolvimento do projeto GPV Gesto de Ponto de
Vendas. Estes testes envolveram pessoal de infra-estrutura das 2
empresas, e foram realizados com sucesso no que se refere ao acesso aos
nossos servidores de aplicao, servidores de dados e autenticao.
Como para este novo projeto os servidores sero os mesmos creio no
haver necessidade de novos testes
Cronograma

Sistema pn2 - iterao 1

Tarefa

Gerenciamento de projeto

Tarefa

Conceber novo projeto

Tarefa

Avaliar escopo e risco do projeto

Tarefa

Elaborar plano de desenvolvimento

Tarefa

Gerenciar iterao

Tarefa

Monitorar e controlar o projeto

Tarefa

Reavaliar escopo e risco do projeto

Tarefa

Planejar prxima iterao

Tarefa

Refinar o plano de desenvolvimento de software

Tarefa

Requisitos

Tarefa

Workshop de Requisitos

Tarefa

Analisar o problema

Tarefa

Compreender necessidades dos envolvidos

Tarefa

Workshop casos de uso

Tarefa

Definir o sistema

Tarefa

Gerenciar o escopo do sistema

Tarefa

Gerenciar requisitos variveis

Tarefa

Anlise e design

Tarefa

Realizar sntese arquitetural

Tarefa

Ambiente

Tarefa

Preparar ambiente para o projeto

Tarefa

Preparar ambiente para iterao 1

Tarefa

Preparar diretrizes para a iterao

Tarefa

Ambiente de suporte e iterao

Tarefa

Gerncia de configurao

Tarefa

Criar ambiente de configurao Projeto

Tarefa

102

Especificao de

Capacidades

VoucherB2C

Gerenciar baseline e releases

Tarefa

Gerenciar solicitaes de mudanas

Tarefa

Monitorar e relatar statis de configurao

Tarefa

Gera e grava o voucher com o status de no disponvel para o uso

Capacidade

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

Muda o status do voucher para disponvel

Capacidade

Muda o status do voucher para reservado, mas necessitando de

Capacidade

confirmao para ser consumido

Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

Volta o status do voucher para disponvel, se estiver com o status de

Capacidade

reservado
Recupera todos os voucher com status de disponvel e no disponvel

Capacidade

para o vigente para um CPF ou CNPJ

Padro

Geral

desenvolvimento

Todos os componentes de um servio (BS, BP e BO) devem ter request

Padro

e response prprios, mesmo quando no h diferena entre eles

Antes do inicio de cada desenvolvimento, devemos criar um projeto para Padro
incluir os objetos criados e alterados
Quando houver uma propriedade no request ou no response que seu

Padro

contedo seja uma senha, a mesma deve ser private. Com isso a senha
no ser exposta no Trace do Ensemble
Business Service

Um BS no pode conter lgica do servio, no mximo uma

Padro

transformao de dados. Mas essa pratica, sempre que possvel, deve ser
evitada. (Dificulta a legibilidade do Trace do Ensemble)
Um mtodo do BS s pode chamar um nico BP

Padro

Um BS no pode chamar direto um BO

Padro

Um BS deve usar uma classe DTL para chamar o BP

Padro

Um BS no pode acessar um sistema ou dado externo. Com exceo de

Padro

SQL Inbound Adapter

Quando o BS for um WebService, tipar ao mximo possvel as

Padro

propriedades do Request e Response (Ex: obrigatrio, enumerar, valores

permitidos, tamanho etc)
Quando o BS for um WebService e houver muitas propriedades e

Padro

hierarquias no request ou response, definir uma nica propriedade

string/stream e criar o XSD de request e de response
Business Process Toda lgica da integrao deve ficar no BP
Quando um BP precisar acessar dados externos ao Ensemble, deve ser

Padro
Padro

chamado um BO para recuperar esses dados

Quando um BP chamar um BO ou devolver informaes para o BS,

Padro

deve ser feito atravs de um DTL

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro

Padro

devem ser tratados para no haver exception no tratada

Business
Operations

Quando um WSDL for importado o Business Operation deve ser criado

Padro webclient

pelo Wizard
Criar Classe Serial

Padro webclient

Manter o mesmo pacote das classes Proxy para as classes Business

Padro webclient

Operation, Request e Response. S acrescentando um nvel no pacote

com operation, request e response respectivamente

103

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

Quando for necessrio fazer modificaes na classe do Business

Padro webclient

Operation, criar uma classe herdado da classe criada pelo wizard e nessa
sim fazer as modificaes
Sempre parametrizar a url do destino na production

Padro webclient

O BO de SQLGateway deve ter uma atividade bem definida. (Ex:

Padro sqlgateway

Recuperar Saldo, gravar pedido, receber equipamento)

Prioridade no uso do SQLGateway - usar procedure ou funes originais

Padro sqlgateway

do sistema chamado
prioridade no uso do SQLGateway - utilizar Views originais ou criar

Padro sqlgateway

uma para acessar sistema externo

prioridade no uso do SQLGateway - colocar os comandos DMLs diretos

Padro sqlgateway

no BO
prioridade no uso do SQLGateway - criar procedures ou funes no

Padro sqlgateway

sitema externo para o mesmo ser acessado

A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e

Padro sqlgateway

procedures

5.3.3. Identificar as transaes ontolgicas

Nesse passo, todas as representaes organizacionais devem ser utilizadas. As
representaes organizacionais referem-se especificao do software PNE (Proposta de
Negociao Eletrnica um sistema interno da empresa utilizado em negociaes para
novas aquisies, asseguramentos entre outros (Glossrio do software)), especificao do
servio VoucherB2C e ao detalhamento dos padres de desenvolvimento utilizando o
determinada ferramenta. Assim as seguintes transaes ontolgicas de parte da organizao
so listadas na Tabela 15.
Tabela 15 Transaes ontolgicas de parte da empresa ABCD
Nome

Transao ontolgica

Iniciador

Executor

Resultado

T01

Identificao requisitos

Cliente

Analisador de requisitos

Requisito A foi identificado

T02

Implementao requisito

Analisador requisitos

Programador

Requisito A foi implementado

T03

Identificao riscos

Cliente

Analisador de riscos

Risco B foi identificado

T04

Avaliao escopo

Cliente

Analisador de escopo

Escopo C foi avaliado

T05

Criao voucher

Cliente

Criador de voucher

Voucher D criado

As seguintes explicaes se fazem necessrias para o entendimento das transaes

ontolgicas descritas na Tabela 15:

104

1)

Identificao de requisitos foi considerada uma transao ontolgica, pois a

rea de informtica responsvel por realizar a implementao de software e,
portanto, o produto dessa rea o cdigo do software. Para que o cdigo seja
gerado necessrio decidir o que requisito e se ser implementado e o que
no requisito;

2)

Implementao de requisitos foi considerada uma transao ontolgica, pois o

resultado dessa transao a gerao do produto fim da rea de informtica;

3)

Identificao de riscos foi considerado uma transao ontolgica devido ao fato

de que deve-se decidir o que considerado risco ou no no desenvolvimento
do produto;

4)

Avaliao de escopo foi considerado uma transao ontolgica porque

subjetivamente deve-se decidir o que est no escopo do desenvolvimento do
produto e o que no est;

5)

Criao de voucher foi considerado uma transao ontolgica, pois o resultado

a criao de um novo produto, assim como no item 2;

5.3.4. Representar a essncia da organizao

O passo seguinte a elaborao da representao da essncia da organizao, para isso
foi utilizada a ferramenta Xemod (Xemod). Essa ferramenta foi escolhida por ser a nica
ferramenta que permite a representao da essncia da organizao conforme proposta por
Dietz (2006).. A partir das representaes organizacionais e das transaes ontolgicas
identificadas na Seo 5.2.3 temos o seguinte Construction Model representado na Figura 43.
Todas as transaes ontolgicas so iniciadas pelo Cliente que representa a pessoa
interessada em cada uma das transaes ontolgicas. A nica exceo a transao
Implementao de requisitos, cujo iniciador o Analisador de requisitos. Essa transao
ontolgica depende da realizao da transao ontolgica Identificao de requisitos para que
possa ser realizada.

105

Figura 43 Construction Model da EIA

5.3.5. Identificar os trechos que operacionalizam as transaes ontolgicas
Com base no CM representado na Figura 43, sabe-se qual a essncia da parte da
empresa analisada, desta forma sabemos o que no deve ser um interesse transversal,
considerando a definio de interesse transversais adotada nessa dissertao (Captulo 3). A
partir desse conhecimento, devem ser analisadas as representaes organizacionais
disponveis e identificados quais trechos operacionalizam as transaes ontolgicas. Os
trechos que operacionalizam as transaes ontolgicas so apresentados na Tabela 16.
Tabela 16 Trechos das representaes organizacionais que apoiam as transaes ontolgicas
Representao

Contedo

organizacional

elemento

Trecho elementar

Tipo de trecho

Transao

elementar

ontolgica

Descrio de iterao

T01

Iterao 2 - Analisar, projetar e implementar funcionalidades Descrio de iterao

T02

bsico
Plano de

Objetivos das

Iterao-1: Requisitos - Levantar as necessidades, definir as

desenvolvimento

iterao

funcionalidades, Modelo de Caso de Uso, RMPLAN e SDP.

do PNE

significativas para a arquitetura. Objetivo Elaborao

TIR/PNE recebendo informaes do servidor WAS.
Iterao 3 - Aumentar o nmero de funcionalidades

Descrio de iterao

T02

Descrio de iterao

T02

significativas, correes e ajustes da iterao anterior.

Objetivo: Elaborao TIR/PNE, transmitindo informaes
ao servidor WAS
Iterao 4 - Incluindo o "workflow"

106

Iterao 5 - Implementar a release que incluir o uso parcial

Descrio de iterao

T02

Descrio de iterao

T02

Descrio de iterao

T02

Objetivo

T02 e T03

Avaliar escopo e risco do projeto

Tarefa

T03 e T04

Reavaliar escopo e risco do projeto

Tarefa

T03 e T04

Requisitos

Tarefa

T01

Workshop de Requisitos

Tarefa

T01

Analisar o problema

Tarefa

T01

Compreender necessidades dos envolvidos

Tarefa

T01

Workshop casos de uso

Tarefa

T01

Definir o sistema

Tarefa

T01

Gerenciar o escopo do sistema

Tarefa

T04

Gerenciar requisitos variveis

Tarefa

T01

Anlise e design

Tarefa

T02

Realizar sntese arquitetural

Tarefa

T02

Gera e grava o voucher com o status de no disponvel para

Capacidade

T05

do Gerenciador de Propostas, TIR.

Iterao 6 - Elaborao quase completa envolvendo
Gerenciador de Propostas. TIR e PNE com o envio para o
servidor WAS
Iterao 7 - produto completo - Sistema completo para
homologao e testes.
Arquitetura de

Metas e

software

restries da
Arquitetura

Iterao 1

Plano

O objetivo principal da iterao de se coletar requisitos

para o novo sistema, bem como os riscos para o projeto. Em
outras palavras iremos avaliar o escopo e risco do projeto

Especificao de
VoucherB2C

Capacidades

o uso

Na Tabela 16, so representados os trechos e as transaes ontolgicas associadas. Em

algumas transaes ontolgicas, mais de um trecho considerado como operacionalizao da
mesma. Alguns trechos representam o mesmo contedo de diferentes formas. Foi
considerado, por exemplo, aumentar o nmero de funcionalidades como implementar o
software. Outros trechos, como gerenciar o escopo do projeto, foi considerado como parte da
transao de anlise do escopo e associada transao ontolgica T04.
5.3.6. Descartar os trechos que operacionalizam as transaes ontolgicas
O passo seguinte listar todos os trechos das representaes organizacionais que no
operacionalizam as transaes ontolgicas, ou seja, so candidatos a interesse transversal. A
lista apresentada Tabela 17.

107

Tabela 17 Candidatos a interesse transversal

Representao

Contedo

organizacional

elemento

Trecho elementar

Tipo trecho
elementar

bsico
Plano de

Objetivos das

desenvolvimento

iterao

do PNE

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de

Descrio de

treinamento e suporte, estratgia de implantao, carga inicial de informaes,

iterao

rotinas de backup, recuperao e contingncia

Arquitetura de

Metas e

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do xxx

Metas e restries

software

restries da

O sistema dever prever a utilizao de um banco de dados nico,

Metas e restries

Arquitetura

disponibilizado para as duas empresas. A verso do banco de dados ser o Oracle

9i ou superior. Far uso de BLOB's
Dever permitir que os assessores comerciais possam trabalhar sem estarem o

Metas e restries

tempo todo conectado rede interna da Cia

Todos os usurios da yyy acessaro o sistema na companhia via rede interna de

Metas e restries

transmisso de dados entre as 2 empresas (j existente)

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

O controle de acesso ao sistema se dar atravs do Notes quando se tratar de

Metas e restries

acesso pela web ou fluxo de aprovao

Para autenticao dos usurios dever utilizar o servidor LDAP nas aplicaes de

Metas e restries

Elaborao (VB)
Prever a exportao de informaes para o MS Excel

Metas e restries

O sistema operacional a ser utilizado nos notebooks ou desktop o Microsoft

Metas e restries

Windows 98 ou superior. O Browser a ser o Internet Explorer 5.5 ou superior

A aplicao dever estar em funcionamento no horrio normal de expediente da

Metas e restries

empresa, de 6:00 s 22:00h, de segunda sexta-feira

O sistema dever prever a interface possibilitando o envio de informaes de

Metas e restries

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

ocorre atualmente. Em princpio no estaremos alterando esta interface
O sistema far uso de XML para armazenar informaes de troca entre os

Metas e restries

servidores e a aplicao cliente

Iterao 1

Plano

Utilizao de fluxo de aprovao no Notes

Metas e restries

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

Objetivo

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da

companhia e yyy com a rea de informtica das 2 empresas. O workshop ter
durao de 2 dias e esperamos mapear as principais funcionalidades para o novo
sistema, j com os critrios de prioridade definidos pelo prprio usurio
Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir

este objetivo, esperamos contar com a presena de assessores comerciais de cada
um dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo
as 2 empresas
Montagem dos artefatos de requisitos (documento de viso, especificao

Objetivo

suplementar, glossrio, modelo de caso de uso e definio de casos de uso),

artefatos de Gerncia de Projeto tais como Plano de Iterao-2, Plano de
Desenvolvimento, Lista de Riscos e cronograma para a segunda iterao

108

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o

Objetivo

seu detalhamento
Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

Objetivo

adoo de padres de desenvolvimento e outras diretrizes

Ainda com relao ao ambiente, preparar os ambientes de desenvolvimento,

Objetivo

ferramentas utilizadas, etc.

Definio da Equipe, propostas de contrao de recursos especializados na

Objetivo

plataforma selecionada (que deve ser Java, notes e Microsoft)

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

Neste projeto estaremos testando o uso da ferramenta ClearQuest, para gerncia

Objetivo

de mudanas cuja finalidade ter um processo padro de controle de mudanas

documentado, assegurando a consistncia das mudanas e que os envolvidos
tenham conhecimento das modificaes e do impacto no custo e programao
gerada por elas
J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

tambm fazer acesso servidores de aplicao J2EE, acessando componentes
EJB (Enterprise Java Bean). No h uma obrigatoriedade no uso desta
ferramenta, caso no seja homologada tempo. Poderemos optar pela forma
antiga, como utilizada no sistema PLC Proposta de Limite de Crdito
Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no

Objetivo

haver maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes
Cronograma

Especificao de
VoucherB2C

Capacidades

Sistema pn2 - iterao 1

Tarefa

Gerenciamento de projeto

Tarefa

Conceber novo projeto

Tarefa

Elaborar plano de desenvolvimento

Tarefa

Gerenciar iterao

Tarefa

Monitorar e controlar o projeto

Tarefa

Planejar prxima iterao

Tarefa

Refinar o plano de desenvolvimento de software

Tarefa

Ambiente

Tarefa

Preparar ambiente para o projeto

Tarefa

Preparar ambiente para iterao 1

Tarefa

Preparar diretrizes para a iterao

Tarefa

Ambiente de suporte e iterao

Tarefa

Gerncia de configurao

Tarefa

Criar ambiente de configurao Projeto

Tarefa

Gerenciar baseline e releases

Tarefa

Gerenciar solicitaes de mudanas

Tarefa

Monitorar e relatar statis de configurao

Tarefa

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

Muda o status do voucher para disponvel

Capacidade

109

Muda o status do voucher para reservado, mas necessitando de confirmao para

Capacidade

ser consumido
Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

Volta o status do voucher para disponvel, se estiver com o status de reservado

Capacidade

Recupera todos os voucher com status de disponvel e no disponvel para o

Capacidade

vigente para um CPF ou CNPJ

Padro

Geral

desenvolvimento

Todos os componentes de um servio (BS, BP e BO) devem ter request e

Padro

response prprios, mesmo quando no h diferena entre eles

Antes do inicio de cada desenvolvimento, devemos criar um projeto para incluir

Padro

os objetos criados e alterados

Quando houver uma propriedade no request ou no response que seu contedo

Padro

seja uma senha, a mesma deve ser private. Com isso a senha no ser exposta no
Trace do Ensemble
Business

Um BS no pode conter lgica do servio, no mximo uma transformao de

Service

dados. Mas essa pratica, sempre que possvel, deve ser evitada. (Dificulta a

Padro

legibilidade do Trace do Ensemble)

Um mtodo do BS s pode chamar um nico BP

Padro

Um BS no pode chamar direto um BO

Padro

Um BS deve usar uma classe DTL para chamar o BP

Padro

Um BS no pode acessar um sistema ou dado externo. Com exceo de SQL

Padro

Inbound Adapter
Quando o BS for um WebService, tipar ao mximo possvel as propriedades do

Padro

Request e Response (Ex: obrigatrio, enumerar, valores permitidos, tamanho etc)

Quando o BS for um WebService e houver muitas propriedades e hierarquias no

Padro

request ou response, definir uma nica propriedade string/stream e criar o XSD

de request e de response
Business

Toda lgica da integrao deve ficar no BP

Padro

Process

Quando um BP precisar acessar dados externos ao Ensemble, deve ser chamado

Padro

um BO para recuperar esses dados

Quando um BP chamar um BO ou devolver informaes para o BS, deve ser

Padro

feito atravs de um DTL

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem

Padro

ser tratados para no haver exception no tratada

Business
Operations

Quando um WSDL for importado o Business Operation deve ser criado pelo

Padro webclient

Wizard
Criar Classe Serial

Padro webclient

Manter o mesmo pacote das classes Proxy para as classes Business Operation,

Padro webclient

Request e Response. S acrescentando um nvel no pacote com operation,

request e response respectivamente
Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

uma classe herdado da classe criada pelo wizard e nessa sim fazer as
modificaes
Sempre parametrizar a url do destino na production

Padro webclient

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Padro sqlgateway

Saldo, gravar pedido, receber equipamento)

110

Prioridade no uso do SQLGateway - usar procedure ou funes originais do

Padro sqlgateway

sistema chamado
prioridade no uso do SQLGateway - utilizar Views originais ou criar uma para

Padro sqlgateway

acessar sistema externo

prioridade no uso do SQLGateway - colocar os comandos DMLs diretos no BO

Padro sqlgateway

prioridade no uso do SQLGateway - criar procedures ou funes no sitema

Padro sqlgateway

externo para o mesmo ser acessado

A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e

Padro sqlgateway

procedures

5.3.7. Identificar os verbos utilizados

O passo seguinte fazer um levantamento de todos os verbos utilizados nos trechos
elementares das representaes organizacionais. A Tabela 18 apresenta os verbos
identificados em cada trecho.
Tabela 18 Verbos dos candidatos a interesse transversal
#

Trecho elementar

Tipo trecho

Verbo

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de

Descrio de

corrigir, elaborar, elaborar,

treinamento e suporte, estratgia de implantao, carga inicial de informaes,

iterao

realizar, realizar, realizar e

elementar

rotinas de backup, recuperao e contingncia

realizar

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do xxx

Metas e restries

prever

O sistema dever prever a utilizao de um banco de dados nico,

Metas e restries

prever, disponibilizar,

disponibilizado para as duas empresas. A verso do banco de dados ser o Oracle

utilizar

9i ou superior. Far uso de BLOB's

4

Dever permitir que os assessores comerciais possam trabalhar sem estarem o

Metas e restries

permitir

Metas e restries

acessar

tempo todo conectado rede interna da Cia

5

Todos os usurios da yyy acessaro o sistema na companhia via rede interna de

transmisso de dados entre as 2 empresas (j existente)

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

empregar

O controle de acesso ao sistema se dar atravs do Notes quando se tratar de

Metas e restries

acontecer

Metas e restries

utilizar

Metas e restries

prever, exportar

Metas e restries

utilizar

Metas e restries

funcionar

Metas e restries

prever, possibilitar, enviar

acesso pela web ou fluxo de aprovao

8

Para autenticao dos usurios dever utilizar o servidor LDAP nas aplicaes de
Elaborao (VB)

Prever a exportao de informaes para o MS Excel

10 O sistema operacional a ser utilizado nos notebooks ou desktop o Microsoft

Windows 98 ou superior. O Browser a ser o Internet Explorer 5.5 ou superior
11 A aplicao dever estar em funcionamento no horrio normal de expediente da
empresa, de 6:00 s 22:00h, de segunda sexta-feira
12 O sistema dever prever a interface possibilitando o envio de informaes de
propostas transacionadas no dia para o ERP da companhia a exemplo do que j
ocorre atualmente. Em princpio no estaremos alterando esta interface

111

13 O sistema far uso de XML para armazenar informaes de troca entre os

Metas e restries

utilizar

14 Utilizao de fluxo de aprovao no Notes

Metas e restries

utilizar

15 Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

16 Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

Objetivo

iniciar, envolver, durar,

servidores e a aplicao cliente

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da

definir

companhia e yyy com a rea de informtica das 2 empresas. O workshop ter

durao de 2 dias e esperamos mapear as principais funcionalidades para o novo
sistema, j com os critrios de prioridade definidos pelo prprio usurio
17 Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir

realizar, mapear, atingir,

reunir

este objetivo, esperamos contar com a presena de assessores comerciais de cada

um dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo
as 2 empresas
18 Montagem dos artefatos de requisitos (documento de viso, especificao

Objetivo

montar

Objetivo

priorizar, iniciar, detalhar

Objetivo

criar, montar, adotar

Objetivo

preparar

Objetivo

definir

23 Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

criar, homologar

24 Neste projeto estaremos testando o uso da ferramenta ClearQuest, para gerncia

Objetivo

testar, gerenciar,

suplementar, glossrio, modelo de caso de uso e definio de casos de uso),

artefatos de Gerncia de Projeto tais como Plano de Iterao-2, Plano de
Desenvolvimento, Lista de Riscos e cronograma para a segunda iterao
19 Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o
seu detalhamento
20 Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,
adoo de padres de desenvolvimento e outras diretrizes
21 Ainda com relao ao ambiente, preparar os ambientes de desenvolvimento,
ferramentas utilizadas, etc.
22 Definio da Equipe, propostas de contrao de recursos especializados na
plataforma selecionada (que deve ser Java, notes e Microsoft)

de mudanas cuja finalidade ter um processo padro de controle de mudanas

documentar, assegurar,

documentado, assegurando a consistncia das mudanas e que os envolvidos

conhecer

tenham conhecimento das modificaes e do impacto no custo e programao

gerada por elas
25 J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

iniciar, permitir, acessar,

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

acessar, acessa, homologar,

tambm fazer acesso servidores de aplicao J2EE, acessando componentes

optar

EJB (Enterprise Java Bean). No h uma obrigatoriedade no uso desta

ferramenta, caso no seja homologada tempo. Poderemos optar pela forma
antiga, como utilizada no sistema PLC Proposta de Limite de Crdito
26 Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no

Objetivo

efetuar, envolver, realizar

haver maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes
27 Sistema pn2 - iterao 1

Tarefa

28 Gerenciamento de projeto

Tarefa

gerenciar

112

29 Conceber novo projeto

Tarefa

conceber

30 Elaborar plano de desenvolvimento

Tarefa

elaborar

31 Gerenciar iterao

Tarefa

gerenciar

32 Monitorar e controlar o projeto

Tarefa

monitorar e controlar

33 Planejar prxima iterao

Tarefa

planejar

34 Refinar o plano de desenvolvimento de software

Tarefa

refinar

35 Ambiente

Tarefa

36 Preparar ambiente para o projeto

Tarefa

preparar

37 Preparar ambiente para iterao 1

Tarefa

preparar

38 Preparar diretrizes para a iterao

Tarefa

preparar

39 Ambiente de suporte e iterao

Tarefa

40 Gerncia de configurao

Tarefa

gerenciar

41 Criar ambiente de configurao Projeto

Tarefa

criar

42 Gerenciar baseline e releases

Tarefa

gerenciar

43 Gerenciar solicitaes de mudanas

Tarefa

gerenciar

44 Monitorar e relatar statis de configurao

Tarefa

monitorar e relatar

45 Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar, utilizar

46 Muda o status do voucher para disponvel

Capacidade

mudar

47 Muda o status do voucher para reservado, mas necessitando de confirmao para

Capacidade

mudar, confirmar

48 Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

mudar, reservar

49 Volta o status do voucher para disponvel, se estiver com o status de reservado

Capacidade

mudar, voltar

50 Recupera todos os voucher com status de disponvel e no disponvel para o

Capacidade

recuperar

Padro

ter

Padro

criar, incluir, criar, alterar

Padro

ser, expor

Padro

conter, transformar, evitar

55 Um mtodo do BS s pode chamar um nico BP

Padro

chamar

56 Um BS no pode chamar direto um BO

Padro

chamar

57 Um BS deve usar uma classe DTL para chamar o BP

Padro

usar, chamar

58 Um BS no pode acessar um sistema ou dado externo. Com exceo de SQL

Padro

acessar

Padro

tipar

Padro

definir

61 Toda lgica da integrao deve ficar no BP

Padro

ficar

62 Quando um BP precisar acessar dados externos ao Ensemble, deve ser chamado

Padro

acessar, recuperar

ser consumido

vigente para um CPF ou CNPJ

51 Todos os componentes de um servio (BS, BP e BO) devem ter request e
response prprios, mesmo quando no h diferena entre eles
52 Antes do inicio de cada desenvolvimento, devemos criar um projeto para incluir
os objetos criados e alterados
53 Quando houver uma propriedade no request ou no response que seu contedo
seja uma senha, a mesma deve ser private. Com isso a senha no ser exposta no
Trace do Ensemble
54 Um BS no pode conter lgica do servio, no mximo uma transformao de
dados. Mas essa pratica, sempre que possvel, deve ser evitada. (Dificulta a
legibilidade do Trace do Ensemble)

Inbound Adapter
59 Quando o BS for um WebService, tipar ao mximo possvel as propriedades do
Request e Response (Ex: obrigatrio, enumerar, valores permitidos, tamanho etc)
60 Quando o BS for um WebService e houver muitas propriedades e hierarquias no
request ou response, definir uma nica propriedade string/stream e criar o XSD
de request e de response

um BO para recuperar esses dados

113

63 Quando um BP chamar um BO ou devolver informaes para o BS, deve ser

Padro

chamar, devolver

Padro

ser, tratar

Padro webclient

importar, criar

66 Criar Classe Serial

Padro webclient

criar

67 Manter o mesmo pacote das classes Proxy para as classes Business Operation,

Padro webclient

manter, acrescentar

68 Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

evitar, mudar

69 Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

modificar, criar, modificar

70 Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

71 O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Padro sqlgateway

ter, recuperar, gravar,

feito atravs de um DTL

64 Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem
ser tratados para no haver exception no tratada
65 Quando um WSDL for importado o Business Operation deve ser criado pelo
Wizard

Request e Response. S acrescentando um nvel no pacote com operation,

request e response respectivamente

uma classe herdado da classe criada pelo wizard e nessa sim fazer as
modificaes

Saldo, gravar pedido, receber equipamento)

72 Prioridade no uso do SQLGateway - usar procedure ou funes originais do

receber
Padro sqlgateway

usar, chamar

Padro sqlgateway

utilizar, criar, acessar

74 prioridade no uso do SQLGateway - colocar os comandos DMLs diretos no BO

Padro sqlgateway

colocar

75 prioridade no uso do SQLGateway - criar procedures ou funes no sitema

Padro sqlgateway

criar, acessar

Padro sqlgateway

usar

sistema chamado
73 prioridade no uso do SQLGateway - utilizar Views originais ou criar uma para
acessar sistema externo

externo para o mesmo ser acessado

76 A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e
procedures

Em alguns trechos, no foi encontrado verbo, mas ao comparar o contedo do trecho

elementar com os demais, percebe-se que deveria haver um verbo, nesses casos optou-se por
transformar o nome contido no trecho em verbo. Em outros casos no havia o verbo referente
ao contedo, nesses casos o verbo foi introduzido, como no item nmero 1 (estratgia de
treinamento e suporte) onde faltava o verbo elaborar. Outro caso onde houve interveno do
executor do mtodo nos casos em que h conjuno verbal e ser considerado apenas o
verbo principal (dever permitir permitir). Outro caso, no item 7, diz que o acesso se dar
atravs do Notes, esse verbo foi substitudo por acontecer. Nos itens 27 e 35 no havia um
item como os demais da seo e no foi possvel identificar o verbo, por isso ficaram vazios.
Acredita-se que isso se deve ausncia de padro para elaborao do artefato.

114

5.3.8. Identificar os verbos semelhantes

Em seguida deve-se realizar a anlise semntica dos verbos identificados para garantir
que verbos com significados semelhantes no sejam considerados verbos diferentes. Os
verbos duplicados devem ser desconsiderados. Os seguintes verbos possuem significado
semelhante, e foram considerados sinnimos:
usar = utilizar = adotar = empregar;
acessar = chamar;
criar = elaborar = conceber;
colocar = parametrizar;
ter = conter;
modificar = mudar = transformar = alterar;
acrescentar = incluir;
gerenciar = controlar;
refinar = detalhar;
efetuar = realizar;
permitir = possibilitar = prever;
5.3.9. Calcular ocorrncia dos verbos
O passo seguinte calcular a frequncia de ocorrncia de cada verbo. O resultado
apresentado na Tabela 19.
Tabela 19 Nmero de ocorrncias dos verbos presentes nos trechos das representaes
organizacionais
Verbo

Ocorrncias

usar = adotar=utilizar = empregar

14

acessar = chamar

13

conceber = criar = elaborar

14

115

colocar = parametrizar

ter = conter

recuperar

gravar

receber

modificar = mudar = transformar = alterar

11

evitar

manter

acrescentar = incluir

importar

ser

tratar

haver

devolver

ficar

definir

tipar

expor

reservar

confirmar

relatar

monitorar

gerenciar = controlar

preparar

refinar = detalhar

planejar

efetuar = realizar

envolver

iniciar

possibilitar = permitir = prever

optar
homologar

testar

documentar

assegurar

conhecer

montar

priorizar

mapear

atingir

reunir

durar

enviar

funcionar

exportar

116

disponibilizar

corrigir

5.3.10. Remover da lista os verbos com apenas 1 ocorrncia

Em seguida devem ser relacionados os verbos identificados com os trechos nos quais
eles so citados. Os verbos com apenas uma ocorrncia no indicam espalhamento, que uma
caracterstica do interesse transversal, dessa forma sero desconsiderados. A Tabela 20
contm a lista atual dos candidatos a interesse transversal.
Nos trechos compostos por mais de um verbo, foram removidas da coluna de verbos
aqueles que tiveram apenas 1 ocorrncia, os demais foram mantidos.
Tabela 20 Candidatos a interesse transversal presente nas representaes organizacionais
Contedo

Trecho elementar

elemento

Tipo trecho

Verbo

elementar

bsico
Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia
iterao

Descrio de iterao

de treinamento e suporte, estratgia de implantao, carga inicial

elaborar, elaborar, realizar,

realizar, realizar e realizar

de informaes, rotinas de backup, recuperao e contingncia

Metas e

Prever a utilizao do sistema pela yyy outra distribuidora do

restries da

Grupo do xxx

Arquitetura

O sistema dever prever a utilizao de um banco de dados nico,

Metas e restries

prever

Metas e restries

prever, utilizar

disponibilizado para as duas empresas. A verso do banco de dados

ser o Oracle 9i ou superior. Far uso de BLOB's
Dever permitir que os assessores comerciais possam trabalhar sem Metas e restries

permitir

estarem o tempo todo conectado rede interna da Cia

Todos os usurios da yyy acessaro o sistema na companhia via

Metas e restries

acessar

Metas e restries

empregar

rede interna de transmisso de dados entre as 2 empresas (j

existente)
A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

O controle de acesso ao sistema se dar atravs do Notes quando se Metas e restries

utilizar

tratar de acesso pela web ou fluxo de aprovao

Para autenticao dos usurios dever utilizar o servidor LDAP nas

Metas e restries

utilizar

Prever a exportao de informaes para o MS Excel

Metas e restries

prever

O sistema operacional a ser utilizado nos notebooks ou desktop o

Metas e restries

utilizar

Metas e restries

prever, possibilitar

aplicaes de Elaborao (VB)

Microsoft Windows 98 ou superior. O Browser a ser o Internet

Explorer 5.5 ou superior
O sistema dever prever a interface possibilitando o envio de
informaes de propostas transacionadas no dia para o ERP da
companhia a exemplo do que j ocorre atualmente. Em princpio

117

no estaremos alterando esta interface

O sistema far uso de XML para armazenar informaes de troca

Metas e restries

utilizar

Utilizao de fluxo de aprovao no Notes

Metas e restries

utilizar

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

Estaremos iniciando o projeto em 25/04/2005 com um workshop

Objetivo

iniciar, envolver, mapear,

entre os servidores e a aplicao cliente

Plano

de requisitos envolvendo pessoas da rea de mercado urbano,

priorizar, definir

rodovia e consumo da companhia e yyy com a rea de informtica

das 2 empresas. O workshop ter durao de 2 dias e esperamos
mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio
Na semana seguinte estaremos realizando o workshop de casos de

Objetivo

realizar, mapear

Objetivo

montar

uso, visando mapear os processos (principais cenrios de uso) do

novo sistema. Para atingir este objetivo, esperamos contar com a
presena de assessores comerciais de cada um dos mercados
(urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas
Montagem dos artefatos de requisitos (documento de viso,
especificao suplementar, glossrio, modelo de caso de uso e
definio de casos de uso), artefatos de Gerncia de Projeto tais
como Plano de Iterao-2, Plano de Desenvolvimento, Lista de
Riscos e cronograma para a segunda iterao
Priorizar os casos de uso que sero objetos de estudo nesta iterao Objetivo

priorizar, iniciar, detalhar

e iniciar o seu detalhamento

Criao e montagem do ambiente de trabalho, tais como VOB no

Objetivo

criar, montar, adotar

Objetivo

preparar

Objetivo

definir

clearcase, adoo de padres de desenvolvimento e outras

diretrizes
Ainda com relao ao ambiente, preparar os ambientes de
desenvolvimento, ferramentas utilizadas, etc.
Definio da Equipe, propostas de contrao de recursos
especializados na plataforma selecionada (que deve ser Java, notes
e Microsoft)
Criao de prottipos de telas e navegao para homologao pelos Objetivo

criar, homologar

usurios
Neste projeto estaremos testando o uso da ferramenta ClearQuest,

Objetivo

gerenciar

para gerncia de mudanas cuja finalidade ter um processo

padro de controle de mudanas documentado, assegurando a
consistncia das mudanas e que os envolvidos tenham
conhecimento das modificaes e do impacto no custo e
programao gerada por elas

118

J nesta iterao, estaremos iniciando os testes com o produto

Objetivo

"LEI", que um software que permite ao Notes acessar

iniciar, permitir, acessar,

acessar, acessar, homologar

diretamente o Banco de Dados Oracle e tambm fazer acesso

servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta
ferramenta, caso no seja homologada tempo. Poderemos optar
pela forma antiga, como utilizada no sistema PLC Proposta de
Limite de Crdito
Com relao a utilizao da Infra-estrutura da companhia pela yyy

Objetivo

creio no haver maiores problemas, pois todos os testes j foram

haver, efetuar, envolver,

realizar

efetuados por ocasio do desenvolvimento do projeto GPV

Gesto de Ponto de Vendas. Estes testes envolveram pessoal de
infra-estrutura das 2 empresas, e foram realizados com sucesso no
que se refere ao acesso aos nossos servidores de aplicao,
servidores de dados e autenticao. Como para este novo projeto os
servidores sero os mesmos creio no haver necessidade de novos
testes
Cronograma

Capacidades

Sistema pn2 - iterao 1

Tarefa

Gerenciamento de projeto

Tarefa

gerenciar

Conceber novo projeto

Tarefa

conceber

Elaborar plano de desenvolvimento

Tarefa

elaborar

Gerenciar iterao

Tarefa

gerenciar

Monitorar e controlar o projeto

Tarefa

monitorar e controlar

Refinar o plano de desenvolvimento de software

Tarefa

refinar

Ambiente

Tarefa

Preparar ambiente para o projeto

Tarefa

preparar

Preparar ambiente para iterao 1

Tarefa

preparar

Preparar diretrizes para a iterao

Tarefa

preparar

Ambiente de suporte e iterao

Tarefa

Gerncia de configurao

Tarefa

gerenciar

Criar ambiente de configurao Projeto

Tarefa

criar

Gerenciar baseline e releases

Tarefa

gerenciar

Gerenciar solicitaes de mudanas

Tarefa

gerenciar

Monitorar e relatar statis de configurao

Tarefa

monitorar

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar, utilizar

Muda o status do voucher para disponvel

Capacidade

mudar

Muda o status do voucher para reservado, mas necessitando de

Capacidade

mudar

Capacidade

mudar

Capacidade

mudar

Capacidade

recuperar

Padro

ter

confirmao para ser consumido

Muda o status do voucher para usado, se estiver no status de
reservado
Volta o status do voucher para disponvel, se estiver com o status
de reservado
Recupera todos os voucher com status de disponvel e no
disponvel para o vigente para um CPF ou CNPJ
Geral

Todos os componentes de um servio (BS, BP e BO) devem ter

request e response prprios, mesmo quando no h diferena entre
eles

119

Antes do inicio de cada desenvolvimento, devemos criar um

Padro

criar, incluir, criar, alterar

projeto para incluir os objetos criados e alterados

Quando houver uma propriedade no request ou no response que seu Padro

ser

contedo seja uma senha, a mesma deve ser private. Com isso a
senha no ser exposta no Trace do Ensemble
Business

Um BS no pode conter lgica do servio, no mximo uma

Padro

conter, transformar, evitar

Service

transformao de dados. Mas essa pratica, sempre que possvel,

Um mtodo do BS s pode chamar um nico BP

Padro

chamar

Um BS no pode chamar direto um BO

Padro

chamar

Um BS deve usar uma classe DTL para chamar o BP

Padro

usar, chamar

Um BS no pode acessar um sistema ou dado externo. Com

Padro

acessar

Padro

definir

Padro

acessar, recuperar

Padro

chamar

Padro

ser, tratar, haver, tratar

Padro webclient

criar

Criar Classe Serial

Padro webclient

criar

Manter o mesmo pacote das classes Proxy para as classes Business

Padro webclient

acrescentar

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

evitar, mudar

Quando for necessrio fazer modificaes na classe do Business

Padro webclient

modificar, criar, modificar

Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

O BO de SQLGateway deve ter uma atividade bem definida. (Ex:

Padro sqlgateway

ter, recuperar

Padro sqlgateway

usar, chamar

Padro sqlgateway

utilizar, criar, acessar

Padro sqlgateway

colocar

deve ser evitada. (Dificulta a legibilidade do Trace do Ensemble)

exceo de SQL Inbound Adapter

Quando o BS for um WebService e houver muitas propriedades e
hierarquias no request ou response, definir uma nica propriedade
string/stream e criar o XSD de request e de response
Business

Quando um BP precisar acessar dados externos ao Ensemble, deve

Process

ser chamado um BO para recuperar esses dados

Quando um BP chamar um BO ou devolver informaes para o
BS, deve ser feito atravs de um DTL
Toda chamada a BOs deve ser dentro de um Scope e no catchall
os erro devem ser tratados para no haver exception no tratada

Business
Operations

Quando um WSDL for importado o Business Operation deve ser

criado pelo Wizard

Operation, Request e Response. S acrescentando um nvel no

pacote com operation, request e response respectivamente

Operation, criar uma classe herdado da classe criada pelo wizard e

nessa sim fazer as modificaes

Recuperar Saldo, gravar pedido, receber equipamento)

Prioridade no uso do SQLGateway - usar procedure ou funes
originais do sistema chamado
prioridade no uso do SQLGateway - utilizar Views originais ou
criar uma para acessar sistema externo
prioridade no uso do SQLGateway - colocar os comandos DMLs
diretos no BO
prioridade no uso do SQLGateway - criar procedures ou funes no Padro sqlgateway

criar, acessar

sitema externo para o mesmo ser acessado

A partir da verso 2010.2 no usar mais vinculao de Tabelas,

Padro sqlgateway

usar

Views e procedures

120

5.3.11. Identificar os trechos que compartilham mais de um verbo

O prximo passo identificar os trechos das representaes organizacionais que
compartilham mais de um verbo. Nesse segundo estudo de caso existem diversos trechos
contendo mais de um verbo. Na Tabela 21 apresentada a lista e resultado da anlise dos
mesmos. Alguns verbos foram descartados por no serem os verbos dominantes dos trechos
de acordo com as regras apresentadas no Captulo 4. Um exemplo o verbo prever nos
trechos: O sistema dever prever a utilizao... e O sistema dever prever a interface....
Tabela 21 Anlise da predominncia dos verbos
Contedo

Trecho elementar

elemento

Tipo trecho

Verbo

Resultado anlise

elementar

bsico
Objetivos das Iterao 8 - correo dos defeitos das releases
iterao

anteriores, estratgia de treinamento e suporte,

Descrio de

elaborar, elaborar, Todos os verbos so

iterao

realizar, realizar,

predominantes, pois fazem

realizar e realizar

parte de uma lista de itens

prever, utilizar

Os dois verbos podem ser

estratgia de implantao, carga inicial de

informaes, rotinas de backup, recuperao e
contingncia
Metas e

O sistema dever prever a utilizao de um banco de

Metas e

restries da

dados nico, disponibilizado para as duas empresas.

restries

Arquitetura

A verso do banco de dados ser o Oracle 9i ou

substitudos apenas pela

verbo utilizar

superior. Far uso de BLOB's

O sistema dever prever a interface possibilitando o

Metas e

prever,

Os dois verbos podem ser

envio de informaes de propostas transacionadas no

restries

possibilitar

substitudos apenas pela

dia para o ERP da companhia a exemplo do que j

verbo possibilitar

ocorre atualmente. Em princpio no estaremos

alterando esta interface
Plano

Estaremos iniciando o projeto em 25/04/2005 com

iniciar, envolver,

Todos os verbos so

um workshop de requisitos envolvendo pessoas da

Objetivo

mapear, priorizar,

considerados predominantes

rea de mercado urbano, rodovia e consumo da

definir

companhia e yyy com a rea de informtica das 2

empresas. O workshop ter durao de 2 dias e
esperamos mapear as principais funcionalidades para
o novo sistema, j com os critrios de prioridade
definidos pelo prprio usurio
Na semana seguinte estaremos realizando o

Objetivo

realizar, mapear

Ambos os verbos sero

workshop de casos de uso, visando mapear os

considerados, no havendo

processos (principais cenrios de uso) do novo

predominncia de apenas 1

sistema. Para atingir este objetivo, esperamos contar

deles

com a presena de assessores comerciais de cada um

dos mercados (urbano, rodovia e consumo).
Novamente estaremos reunindo as 2 empresas

121

Priorizar os casos de uso que sero objetos de estudo

Objetivo

nesta iterao e iniciar o seu detalhamento

priorizar, iniciar,

Os 3 verbos sero

detalhar

considerados, no havendo
predominncia de apenas 1
deles

Criao e montagem do ambiente de trabalho, tais

Objetivo

como VOB no clearcase, adoo de padres de

criar, montar,

Os 3 verbos sero

adotar

considerados, no havendo

desenvolvimento e outras diretrizes

predominncia de apenas 1
deles

Criao de prottipos de telas e navegao para

Objetivo

criar, homologar

homologao pelos usurios

Todos os verbos so
predominantes, pois fazem
parte de uma lista de itens

J nesta iterao, estaremos iniciando os testes com o

iniciar, permitir,

Todos os verbos so

produto "LEI", que um software que permite ao

Objetivo

acessar, acessar,

predominantes, pois fazem

Notes acessar diretamente o Banco de Dados Oracle

acessar,

parte de uma lista de itens

e tambm fazer acesso servidores de aplicao

homologar

J2EE, acessando componentes EJB (Enterprise Java

Bean). No h uma obrigatoriedade no uso desta
ferramenta, caso no seja homologada tempo.
Poderemos optar pela forma antiga, como utilizada
no sistema PLC Proposta de Limite de Crdito
Com relao a utilizao da Infra-estrutura da

Objetivo

companhia pela yyy creio no haver maiores

haver, efetuar,

Regra 2 - haver e regra 3 -

envolver, realizar

envolver e realizar

monitorar e

regra 3 - monitorar e

controlar

controlar

criar, incluir,

Regra 2 - criar

problemas, pois todos os testes j foram efetuados

por ocasio do desenvolvimento do projeto GPV
Gesto de Ponto de Vendas. Estes testes envolveram
pessoal de infra-estrutura das 2 empresas, e foram
realizados com sucesso no que se refere ao acesso
aos nossos servidores de aplicao, servidores de
dados e autenticao. Como para este novo projeto os
servidores sero os mesmos creio no haver
necessidade de novos testes
Cronograma

Geral

Monitorar e controlar o projeto

Antes do inicio de cada desenvolvimento, devemos

Tarefa

Padro

criar um projeto para incluir os objetos criados e

criar, alterar

alterados
Business

Um BS no pode conter lgica do servio, no

Service

mximo uma transformao de dados. Mas essa

Padro

conter,
transformar,

pratica, sempre que possvel, deve ser evitada.

evitar

Regra 2 - conter

(Dificulta a legibilidade do Trace do Ensemble)

Business

Quando um BP precisar acessar dados externos ao

Process

Ensemble, deve ser chamado um BO para recuperar

Padro

acessar, recuperar

regra 1 - verbo
predominante recuperar

esses dados
Toda chamada a BOs deve ser dentro de um Scope e

Padro

no catchall os erro devem ser tratados para no haver

ser, tratar, haver,

Haver, tratada e ser - regras

tratar

1e3

evitar, mudar

Ambos verbos so

exception no tratada
Business

Evitar ao mximo mudar as classes criadas pelo

Padro

122

Operations

Wizard

webclient

predominantes

Quando for necessrio fazer modificaes na classe

Padro

modificar, criar,

regra 2 - verbos dominantes

do Business Operation, criar uma classe herdado da

webclient

modificar

criar e modificar

O BO de SQLGateway deve ter uma atividade bem

Padro

ter, recuperar

regra 3 - verbos ter e

definida. (Ex: Recuperar Saldo, gravar pedido,

sqlgateway

classe criada pelo wizard e nessa sim fazer as

modificaes

recuperar

receber equipamento)
Prioridade no uso do SQLGateway - usar procedure

Padro

usar, chamar

regra 2 - verbo dominantes

ou funes originais do sistema chamado

sqlgateway

prioridade no uso do SQLGateway - utilizar Views

Padro

utilizar, criar,

regra 1 - verbo dominante

originais ou criar uma para acessar sistema externo

sqlgateway

acessar

acessar

prioridade no uso do SQLGateway - criar procedures

Padro

criar, acessar

regra 1 - verbo dominante

ou funes no sitema externo para o mesmo ser

sqlgateway

usar

acessar

acessado

5.3.12. Revisar lista

Na Tabela 22 apresentada a lista de candidatos a interesse transversal com a
respectiva lista de verbos dos trechos atualizada. Nessa atividade alguns verbos deixaram de
ter pelo menos 2 ocorrncias como tratar, evitar e acrescentar/incluir.
Tabela 22 Anlise da predominncia dos verbos
Contedo

Trecho elementar

elemento

Tipo trecho

Verbo

elementar

bsico
Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia
iterao

Descrio de iterao

de treinamento e suporte, estratgia de implantao, carga inicial

elaborar, elaborar, realizar,

realizar, realizar e realizar

de informaes, rotinas de backup, recuperao e contingncia

Metas e

Prever a utilizao do sistema pela yyy outra distribuidora do

restries da

Grupo do xxx

Arquitetura

O sistema dever prever a utilizao de um banco de dados nico,

Metas e restries

prever

Metas e restries

prever, utilizar

disponibilizado para as duas empresas. A verso do banco de dados

ser o Oracle 9i ou superior. Far uso de BLOB's
Dever permitir que os assessores comerciais possam trabalhar sem Metas e restries

permitir

estarem o tempo todo conectado rede interna da Cia

Todos os usurios da yyy acessaro o sistema na companhia via

Metas e restries

acessar

Metas e restries

empregar

rede interna de transmisso de dados entre as 2 empresas (j

existente)
A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

O controle de acesso ao sistema se dar atravs do Notes quando se Metas e restries

utilizar

tratar de acesso pela web ou fluxo de aprovao

Para autenticao dos usurios dever utilizar o servidor LDAP nas

Metas e restries

utilizar

123

aplicaes de Elaborao (VB)

Prever a exportao de informaes para o MS Excel

Metas e restries

prever

O sistema operacional a ser utilizado nos notebooks ou desktop o

Metas e restries

utilizar

Metas e restries

prever, possibilitar

Metas e restries

utilizar

Utilizao de fluxo de aprovao no Notes

Metas e restries

utilizar

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

Estaremos iniciando o projeto em 25/04/2005 com um workshop

Objetivo

iniciar, envolver, mapear,

Microsoft Windows 98 ou superior. O Browser a ser o Internet

Explorer 5.5 ou superior
O sistema dever prever a interface possibilitando o envio de
informaes de propostas transacionadas no dia para o ERP da
companhia a exemplo do que j ocorre atualmente. Em princpio
no estaremos alterando esta interface
O sistema far uso de XML para armazenar informaes de troca
entre os servidores e a aplicao cliente

Plano

de requisitos envolvendo pessoas da rea de mercado urbano,

priorizar, definir

rodovia e consumo da companhia e yyy com a rea de informtica

das 2 empresas. O workshop ter durao de 2 dias e esperamos
mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio
Na semana seguinte estaremos realizando o workshop de casos de

Objetivo

realizar, mapear

Objetivo

montar

uso, visando mapear os processos (principais cenrios de uso) do

novo sistema. Para atingir este objetivo, esperamos contar com a
presena de assessores comerciais de cada um dos mercados
(urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas
Montagem dos artefatos de requisitos (documento de viso,
especificao suplementar, glossrio, modelo de caso de uso e
definio de casos de uso), artefatos de Gerncia de Projeto tais
como Plano de Iterao-2, Plano de Desenvolvimento, Lista de
Riscos e cronograma para a segunda iterao
Priorizar os casos de uso que sero objetos de estudo nesta iterao Objetivo

priorizar, iniciar, detalhar

e iniciar o seu detalhamento

Criao e montagem do ambiente de trabalho, tais como VOB no

Objetivo

criar, montar, adotar

Objetivo

preparar

Objetivo

definir

clearcase, adoo de padres de desenvolvimento e outras

diretrizes
Ainda com relao ao ambiente, preparar os ambientes de
desenvolvimento, ferramentas utilizadas, etc.
Definio da Equipe, propostas de contrao de recursos
especializados na plataforma selecionada (que deve ser Java, notes
e Microsoft)
Criao de prottipos de telas e navegao para homologao pelos Objetivo

criar, homologar

usurios

124

Neste projeto estaremos testando o uso da ferramenta ClearQuest,

Objetivo

gerenciar

Objetivo

iniciar, permitir, acessar,

para gerncia de mudanas cuja finalidade ter um processo

padro de controle de mudanas documentado, assegurando a
consistncia das mudanas e que os envolvidos tenham
conhecimento das modificaes e do impacto no custo e
programao gerada por elas
J nesta iterao, estaremos iniciando os testes com o produto
"LEI", que um software que permite ao Notes acessar

acessar, acessar, homologar

diretamente o Banco de Dados Oracle e tambm fazer acesso

servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta
ferramenta, caso no seja homologada tempo. Poderemos optar
pela forma antiga, como utilizada no sistema PLC Proposta de
Limite de Crdito
Com relao a utilizao da Infra-estrutura da companhia pela yyy

Objetivo

haver envolver, realizar

creio no haver maiores problemas, pois todos os testes j foram

efetuados por ocasio do desenvolvimento do projeto GPV
Gesto de Ponto de Vendas. Estes testes envolveram pessoal de
infra-estrutura das 2 empresas, e foram realizados com sucesso no
que se refere ao acesso aos nossos servidores de aplicao,
servidores de dados e autenticao. Como para este novo projeto os
servidores sero os mesmos creio no haver necessidade de novos
testes
Cronograma

Capacidades

Sistema pn2 - iterao 1

Tarefa

Gerenciamento de projeto

Tarefa

gerenciar

Conceber novo projeto

Tarefa

conceber

Elaborar plano de desenvolvimento

Tarefa

elaborar

Gerenciar iterao

Tarefa

gerenciar

Monitorar e controlar o projeto

Tarefa

monitorar e controlar

Refinar o plano de desenvolvimento de software

Tarefa

refinar

Ambiente

Tarefa

Preparar ambiente para o projeto

Tarefa

preparar

Preparar ambiente para iterao 1

Tarefa

preparar

Preparar diretrizes para a iterao

Tarefa

preparar

Ambiente de suporte e iterao

Tarefa

Gerncia de configurao

Tarefa

gerenciar

Criar ambiente de configurao Projeto

Tarefa

criar

Gerenciar baseline e releases

Tarefa

gerenciar

Gerenciar solicitaes de mudanas

Tarefa

gerenciar

Monitorar e relatar statis de configurao

Tarefa

monitorar

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar, utilizar

Muda o status do voucher para disponvel

Capacidade

mudar

Muda o status do voucher para reservado, mas necessitando de

Capacidade

mudar

Capacidade

mudar

Capacidade

mudar

confirmao para ser consumido

Muda o status do voucher para usado, se estiver no status de
reservado
Volta o status do voucher para disponvel, se estiver com o status

125

de reservado
Recupera todos os voucher com status de disponvel e no

Capacidade

recuperar

Padro

ter

Padro

criar

disponvel para o vigente para um CPF ou CNPJ

Geral

Todos os componentes de um servio (BS, BP e BO) devem ter

request e response prprios, mesmo quando no h diferena entre
eles
Antes do inicio de cada desenvolvimento, devemos criar um
projeto para incluir os objetos criados e alterados

Quando houver uma propriedade no request ou no response que seu Padro

ser

contedo seja uma senha, a mesma deve ser private. Com isso a
senha no ser exposta no Trace do Ensemble
Business

Um BS no pode conter lgica do servio, no mximo uma

Service

transformao de dados. Mas essa pratica, sempre que possvel,

Padro

conter

Um mtodo do BS s pode chamar um nico BP

Padro

chamar

Um BS no pode chamar direto um BO

Padro

chamar

Um BS deve usar uma classe DTL para chamar o BP

Padro

usar, chamar

Um BS no pode acessar um sistema ou dado externo. Com

Padro

acessar

Padro

definir

Padro

recuperar

Padro

chamar

Padro

haver, tratar, ser

Padro webclient

criar

Criar Classe Serial

Padro webclient

criar

Manter o mesmo pacote das classes Proxy para as classes Business

Padro webclient

acrescentar

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

evitar, mudar

Quando for necessrio fazer modificaes na classe do Business

Padro webclient

criar, modificar

Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

O BO de SQLGateway deve ter uma atividade bem definida. (Ex:

Padro sqlgateway

ter, recuperar

Padro sqlgateway

usar

Padro sqlgateway

acessar

Padro sqlgateway

colocar

deve ser evitada. (Dificulta a legibilidade do Trace do Ensemble)

exceo de SQL Inbound Adapter

Quando o BS for um WebService e houver muitas propriedades e
hierarquias no request ou response, definir uma nica propriedade
string/stream e criar o XSD de request e de response
Business

Quando um BP precisar acessar dados externos ao Ensemble, deve

Process

ser chamado um BO para recuperar esses dados

Quando um BP chamar um BO ou devolver informaes para o
BS, deve ser feito atravs de um DTL
Toda chamada a BOs deve ser dentro de um Scope e no catchall
os erro devem ser tratados para no haver exception no tratada

Business
Operations

Quando um WSDL for importado o Business Operation deve ser

criado pelo Wizard

Operation, Request e Response. S acrescentando um nvel no

pacote com operation, request e response respectivamente

Operation, criar uma classe herdado da classe criada pelo wizard e

nessa sim fazer as modificaes

Recuperar Saldo, gravar pedido, receber equipamento)

Prioridade no uso do SQLGateway - usar procedure ou funes
originais do sistema chamado
prioridade no uso do SQLGateway - utilizar Views originais ou
criar uma para acessar sistema externo
prioridade no uso do SQLGateway - colocar os comandos DMLs
diretos no BO

126

prioridade no uso do SQLGateway - criar procedures ou funes no Padro sqlgateway

acessar

sitema externo para o mesmo ser acessado

A partir da verso 2010.2 no usar mais vinculao de Tabelas,

Padro sqlgateway

usar

Views e procedures

5.3.13. Identificar verbos repetidos somente na mesma representao

organizacional
O passo seguinte identificar os verbos repetidos somente na mesma representao
organizacional, isso no caracteriza um interesse transversal organizacional. Para isso foi
necessrio separar os verbos diferentes que ocorrem no mesmo trecho. Por exemplo, no trecho
referente Iterao 8 da seo Objetivos das iteraes havia apenas 1 linha com 6 verbos,
optou-se por criar 6 linhas e 1 verbo em cada linha para o mesmo trecho. O resultado
apresentado na Tabela 23.
Tabela 23 Candidatos a interesse transversal com verbos separados
Contedo do

Trecho elementar

elemento bsico

Tipo trecho

Verbo

elementar

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

Descrio de iterao

elaborar

Descrio de iterao

elaborar

Descrio de iterao

realizar

Descrio de iterao

realizar

Descrio de iterao

realizar

Descrio de iterao

realizar

backup, recuperao e contingncia

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento

iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Cronograma

Elaborar plano de desenvolvimento

Tarefa

elaborar

Plano

Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

realizar

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir este
objetivo, esperamos contar com a presena de assessores comerciais de cada um
dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas

127

Plano

Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

mapear

Objetivo

haver

Objetivo

envolver

Objetivo

realizar

Objetivo

iniciar

Objetivo

envolver

Objetivo

mapear

Objetivo

priorizar

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir este
objetivo, esperamos contar com a presena de assessores comerciais de cada um
dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas
Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

128

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

Objetivo

definir

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do xxx

Metas e restries

prever

Metas e restries

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

Metas e restries

prever

da Arquitetura

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior.

Metas e restries

utilizar

Metas e restries

permitir

Metas e restries

acessar

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia

e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio
Metas e restries
da Arquitetura

Far uso de BLOB's

Metas e restries

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

da Arquitetura

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior.

Far uso de BLOB's

Metas e restries

Dever permitir que os assessores comerciais possam trabalhar sem estarem o

da Arquitetura

tempo todo conectado rede interna da Cia

Metas e restries

Todos os usurios da yyy acessaro o sistema na companhia via rede interna de

da Arquitetura

transmisso de dados entre as 2 empresas (j existente)

Metas e restries

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

empregar

Metas e restries

O controle de acesso ao sistema se dar atravs do Notes quando se tratar de

Metas e restries

utilizar

da Arquitetura

acesso pela web ou fluxo de aprovao

Metas e restries

Para autenticao dos usurios dever utilizar o servidor LDAP nas aplicaes de

Metas e restries

utilizar

da Arquitetura

Elaborao (VB)

Metas e restries

Prever a exportao de informaes para o MS Excel

Metas e restries

prever

Metas e restries

O sistema operacional a ser utilizado nos notebooks ou desktop o Microsoft

Metas e restries

utilizar

da Arquitetura

Windows 98 ou superior. O Browser a ser o Internet Explorer 5.5 ou superior

Metas e restries

O sistema dever prever a interface possibilitando o envio de informaes de

Metas e restries

prever

da Arquitetura

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

Metas e restries

possibilitar

Metas e restries

utilizar

da Arquitetura

da Arquitetura

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e restries

O sistema dever prever a interface possibilitando o envio de informaes de

da Arquitetura

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e restries

O sistema far uso de XML para armazenar informaes de troca entre os

da Arquitetura

servidores e a aplicao cliente

Metas e restries

Utilizao de fluxo de aprovao no Notes

Metas e restries

utilizar

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

Montagem dos artefatos de requisitos (documento de viso, especificao

Objetivo

montar

Objetivo

priorizar

Objetivo

iniciar

da Arquitetura
Metas e restries
da Arquitetura
Plano

suplementar, glossrio, modelo de caso de uso e definio de casos de uso),

artefatos de Gerncia de Projeto tais como Plano de Iterao-2, Plano de
Desenvolvimento, Lista de Riscos e cronograma para a segunda iterao
Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu
detalhamento

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu
detalhamento

129

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu

Objetivo

detalhar

Objetivo

criar

Objetivo

montar

Objetivo

adotar

Objetivo

preparar

Objetivo

definir

detalhamento
Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

adoo de padres de desenvolvimento e outras diretrizes

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

adoo de padres de desenvolvimento e outras diretrizes

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

adoo de padres de desenvolvimento e outras diretrizes

Plano

Ainda com relao ao ambiente, preparar os ambientes de desenvolvimento,

ferramentas utilizadas, etc.

Plano

Definio da Equipe, propostas de contrao de recursos especializados na

plataforma selecionada (que deve ser Java, notes e Microsoft)

Plano

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

criar

Plano

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

homologar

Plano

Neste projeto estaremos testando o uso da ferramenta ClearQuest, para gerncia de

Objetivo

gerenciar

Objetivo

iniciar

Objetivo

permitir

Objetivo

acessar

Objetivo

acessar

mudanas cuja finalidade ter um processo padro de controle de mudanas

documentado, assegurando a consistncia das mudanas e que os envolvidos
tenham conhecimento das modificaes e do impacto no custo e programao
gerada por elas
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

130

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

acessar

Objetivo

homologar

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Cronograma

Sistema pn2 - iterao 1

Tarefa

Cronograma

Gerenciamento de projeto

Tarefa

gerenciar

Cronograma

Conceber novo projeto

Tarefa

conceber

Cronograma

Gerenciar iterao

Tarefa

gerenciar

Cronograma

Monitorar e controlar o projeto

Tarefa

monitorar

Cronograma

Monitorar e controlar o projeto

Tarefa

controlar

Cronograma

Refinar o plano de desenvolvimento de software

Tarefa

refinar

Cronograma

Preparar ambiente para o projeto

Tarefa

preparar

Cronograma

Preparar ambiente para iterao 1

Tarefa

preparar

Cronograma

Preparar diretrizes para a iterao

Tarefa

preparar

Cronograma

Gerncia de configurao

Tarefa

gerenciar

Cronograma

Criar ambiente de configurao Projeto

Tarefa

criar

Cronograma

Gerenciar baseline e releases

Tarefa

gerenciar

Cronograma

Gerenciar solicitaes de mudanas

Tarefa

gerenciar

Cronograma

Monitorar e relatar statis de configurao

Tarefa

monitorar

Capacidades

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar

Capacidades

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

utilizar

Capacidades

Muda o status do voucher para disponvel

Capacidade

mudar

Capacidades

Muda o status do voucher para reservado, mas necessitando de confirmao para

Capacidade

mudar

ser consumido
Capacidades

Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

mudar

Capacidades

Volta o status do voucher para disponvel, se estiver com o status de reservado

Capacidade

mudar

Capacidades

Recupera todos os voucher com status de disponvel e no disponvel para o

Capacidade

recuperar

Padro

ter

Padro

criar

Padro

ser

Padro

conter

Padro

chamar

vigente para um CPF ou CNPJ

Geral

Todos os componentes de um servio (BS, BP e BO) devem ter request e response

prprios, mesmo quando no h diferena entre eles

Geral

Antes do inicio de cada desenvolvimento, devemos criar um projeto para incluir os

objetos criados e alterados

Geral

Quando houver uma propriedade no request ou no response que seu contedo seja
uma senha, a mesma deve ser private. Com isso a senha no ser exposta no Trace
do Ensemble

Business Service

Um BS no pode conter lgica do servio, no mximo uma transformao de

dados. Mas essa pratica, sempre que possvel, deve ser evitada. (Dificulta a
legibilidade do Trace do Ensemble)

Business Service

Um mtodo do BS s pode chamar um nico BP

131

Business Service

Um BS no pode chamar direto um BO

Padro

chamar

Business Service

Um BS deve usar uma classe DTL para chamar o BP

Padro

usar

Business Service

Um BS deve usar uma classe DTL para chamar o BP

Padro

chamar

Business Service

Um BS no pode acessar um sistema ou dado externo. Com exceo de SQL

Padro

acessar

Padro

definir

Padro

recuperar

Padro

chamar

Padro

haver

Padro

tratar

Padro

ser

Padro webclient

criar

Inbound Adapter
Business Service

Quando o BS for um WebService e houver muitas propriedades e hierarquias no

request ou response, definir uma nica propriedade string/stream e criar o XSD de
request e de response

Business Process

Quando um BP precisar acessar dados externos ao Ensemble, deve ser chamado

um BO para recuperar esses dados

Business Process

Quando um BP chamar um BO ou devolver informaes para o BS, deve ser feito

atravs de um DTL

Business Process

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem
ser tratados para no haver exception no tratada

Business Process

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem
ser tratados para no haver exception no tratada

Business Process

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem
ser tratados para no haver exception no tratada

Business

Quando um WSDL for importado o Business Operation deve ser criado pelo

Operations

Wizard

Business

Criar Classe Serial

Padro webclient

criar

Business

Manter o mesmo pacote das classes Proxy para as classes Business Operation,

Padro webclient

acrescentar

Operations

Request e Response. S acrescentando um nvel no pacote com operation,

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

evitar

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

mudar

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

criar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

modificar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Business

Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Padro sqlgateway

ter

Operations

Saldo, gravar pedido, receber equipamento)

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Padro sqlgateway

recuperar

Operations

Saldo, gravar pedido, receber equipamento)

Business

Prioridade no uso do SQLGateway - usar procedure ou funes originais do

Padro sqlgateway

usar

Operations

sistema chamado

Business

prioridade no uso do SQLGateway - utilizar Views originais ou criar uma para

Padro sqlgateway

acessar

Operations

acessar sistema externo

Business

prioridade no uso do SQLGateway - colocar os comandos DMLs diretos no BO

Padro sqlgateway

colocar

Business

prioridade no uso do SQLGateway - criar procedures ou funes no sitema externo Padro sqlgateway

acessar

Operations

para o mesmo ser acessado

Operations

request e response respectivamente

Business
Operations
Business
Operations

Operations

Operations

132

Business

A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e

Operations

procedures

Padro sqlgateway

usar

Em seguida os trechos foram agrupados por verbos para que fosse identificado se
aquele verbo est repetido somente na mesma representao. O resultado apresentado na
Tabela 24.
Tabela 24 Candidatos a interesse transversal agrupados por verbo
Contedo

Trecho elementar

Tipo trecho elementar

Verbo

Descrio de iterao

elaborar

Descrio de iterao

elaborar

elemento
bsico
Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Cronograma

Elaborar plano de desenvolvimento

Tarefa

elaborar

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

Objetivo

criar

adoo de padres de desenvolvimento e outras diretrizes

Plano

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

criar

Cronograma

Criar ambiente de configurao Projeto

Tarefa

criar

Geral

Antes do inicio de cada desenvolvimento, devemos criar um projeto para incluir os Padro

criar

objetos criados e alterados

Business

Quando um WSDL for importado o Business Operation deve ser criado pelo

Operations

Wizard

Padro webclient

criar

Business

Criar Classe Serial

Padro webclient

criar

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

criar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Cronograma

Conceber novo projeto

Tarefa

conceber

Descrio de iterao

realizar

Descrio de iterao

realizar

Descrio de iterao

realizar

Descrio de iterao

realizar

Operations

Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento
iterao

e suporte, estratgia de implantao, carga inicial de informaes, rotinas de

backup, recuperao e contingncia

133

Plano

Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

realizar

Objetivo

realizar

Objetivo

mapear

Objetivo

mapear

Objetivo

haver

Padro

haver

Objetivo

envolver

Objetivo

envolver

Objetivo

iniciar

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir este
objetivo, esperamos contar com a presena de assessores comerciais de cada um
dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas
Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Plano

Na semana seguinte estaremos realizando o workshop de casos de uso, visando

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir este
objetivo, esperamos contar com a presena de assessores comerciais de cada um
dos mercados (urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Business

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem

Process

ser tratados para no haver exception no tratada

Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores
de dados e autenticao. Como para este novo projeto os servidores sero os
mesmos creio no haver necessidade de novos testes

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

134

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu

Objetivo

iniciar

Objetivo

iniciar

Objetivo

priorizar

Objetivo

priorizar

Objetivo

definir

Objetivo

definir

Padro

definir

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Utilizao de fluxo de aprovao no Notes

Metas e restries

utilizar

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

utilizar

detalhamento
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu
detalhamento

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia
e yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2
dias e esperamos mapear as principais funcionalidades para o novo sistema, j com
os critrios de prioridade definidos pelo prprio usurio

Plano

Definio da Equipe, propostas de contrao de recursos especializados na

plataforma selecionada (que deve ser Java, notes e Microsoft)

Business

Quando o BS for um WebService e houver muitas propriedades e hierarquias no

Service

request ou response, definir uma nica propriedade string/stream e criar o XSD de

request e de response

Metas e

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

restries da

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior.

Arquitetura

Far uso de BLOB's

Metas e

O controle de acesso ao sistema se dar atravs do Notes quando se tratar de

restries da

acesso pela web ou fluxo de aprovao

Arquitetura
Metas e

Para autenticao dos usurios dever utilizar o servidor LDAP nas aplicaes de

restries da

Elaborao (VB)

Arquitetura
Metas e

O sistema operacional a ser utilizado nos notebooks ou desktop o Microsoft

restries da

Windows 98 ou superior. O Browser a ser o Internet Explorer 5.5 ou superior

Arquitetura
Metas e

O sistema far uso de XML para armazenar informaes de troca entre os

restries da

servidores e a aplicao cliente

Arquitetura
Metas e
restries da
Arquitetura
Metas e
restries da
Arquitetura
Capacidades

135

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

Objetivo

adotar

Um BS deve usar uma classe DTL para chamar o BP

Padro

usar

Business

Prioridade no uso do SQLGateway - usar procedure ou funes originais do

Padro sqlgateway

usar

Operations

sistema chamado

Business

A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e

Padro sqlgateway

usar

Operations

procedures

Metas e

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

empregar

Metas e

Dever permitir que os assessores comerciais possam trabalhar sem estarem o

Metas e restries

permitir

restries da

tempo todo conectado rede interna da Cia

Objetivo

permitir

Metas e restries

possibilitar

adoo de padres de desenvolvimento e outras diretrizes

Business
Service

restries da
Arquitetura

Arquitetura
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Metas e

O sistema dever prever a interface possibilitando o envio de informaes de

restries da

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

Arquitetura

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do xxx

Metas e restries

prever

Metas e

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

Metas e restries

prever

restries da

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior.

Arquitetura

Far uso de BLOB's

Metas e

Prever a exportao de informaes para o MS Excel

Metas e restries

prever

Metas e

O sistema dever prever a interface possibilitando o envio de informaes de

Metas e restries

prever

restries da

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

Arquitetura

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e

Todos os usurios da yyy acessaro o sistema na companhia via rede interna de

Metas e restries

acessar

restries da

transmisso de dados entre as 2 empresas (j existente)

Objetivo

acessar

restries da
Arquitetura

restries da
Arquitetura

Arquitetura
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

136

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

acessar

Objetivo

acessar

Padro

acessar

Padro sqlgateway

acessar

acessar

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

Business

Um BS no pode acessar um sistema ou dado externo. Com exceo de SQL

Service

Inbound Adapter

Business

prioridade no uso do SQLGateway - utilizar Views originais ou criar uma para

Operations

acessar sistema externo

Business

prioridade no uso do SQLGateway - criar procedures ou funes no sitema externo Padro sqlgateway

Operations

para o mesmo ser acessado

Business

Um mtodo do BS s pode chamar um nico BP

Padro

chamar

Um BS no pode chamar direto um BO

Padro

chamar

Um BS deve usar uma classe DTL para chamar o BP

Padro

chamar

Business

Quando um BP chamar um BO ou devolver informaes para o BS, deve ser feito

Padro

chamar

Process

atravs de um DTL

Plano

Montagem dos artefatos de requisitos (documento de viso, especificao

Objetivo

montar

Objetivo

montar

Objetivo

detalhar

Service
Business
Service
Business
Service

suplementar, glossrio, modelo de caso de uso e definio de casos de uso),

artefatos de Gerncia de Projeto tais como Plano de Iterao-2, Plano de
Desenvolvimento, Lista de Riscos e cronograma para a segunda iterao
Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase,

adoo de padres de desenvolvimento e outras diretrizes

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu
detalhamento

Cronograma

Refinar o plano de desenvolvimento de software

Tarefa

refinar

Plano

Ainda com relao ao ambiente, preparar os ambientes de desenvolvimento,

Objetivo

preparar

ferramentas utilizadas, etc.

Cronograma

Preparar ambiente para o projeto

Tarefa

preparar

Cronograma

Preparar ambiente para iterao 1

Tarefa

preparar

Cronograma

Preparar diretrizes para a iterao

Tarefa

preparar

Plano

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

homologar

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

homologar

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como
utilizada no sistema PLC Proposta de Limite de Crdito

137

Plano

Neste projeto estaremos testando o uso da ferramenta ClearQuest, para gerncia de

Objetivo

gerenciar

mudanas cuja finalidade ter um processo padro de controle de mudanas

documentado, assegurando a consistncia das mudanas e que os envolvidos
tenham conhecimento das modificaes e do impacto no custo e programao
gerada por elas
Cronograma

Gerenciamento de projeto

Tarefa

gerenciar

Cronograma

Gerenciar iterao

Tarefa

gerenciar

Cronograma

Gerncia de configurao

Tarefa

gerenciar

Cronograma

Gerenciar baseline e releases

Tarefa

gerenciar

Cronograma

Gerenciar solicitaes de mudanas

Tarefa

gerenciar

Cronograma

Monitorar e controlar o projeto

Tarefa

controlar

Cronograma

Monitorar e controlar o projeto

Tarefa

monitorar

Cronograma

Monitorar e relatar statis de configurao

Tarefa

monitorar

Capacidades

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar

Capacidades

Muda o status do voucher para disponvel

Capacidade

mudar

Capacidades

Muda o status do voucher para reservado, mas necessitando de confirmao para

Capacidade

mudar

ser consumido
Capacidades

Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

mudar

Capacidades

Volta o status do voucher para disponvel, se estiver com o status de reservado

Capacidade

mudar

Business

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

mudar

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

modificar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Capacidades

Recupera todos os voucher com status de disponvel e no disponvel para o

Capacidade

recuperar

Padro

recuperar

Padro sqlgateway

recuperar

Padro

ter

Padro sqlgateway

ter

Padro

conter

Padro

ser

Padro

ser

Operations

vigente para um CPF ou CNPJ

Business

Quando um BP precisar acessar dados externos ao Ensemble, deve ser chamado

Process

um BO para recuperar esses dados

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Operations

Saldo, gravar pedido, receber equipamento)

Geral

Todos os componentes de um servio (BS, BP e BO) devem ter request e response

prprios, mesmo quando no h diferena entre eles

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar

Operations

Saldo, gravar pedido, receber equipamento)

Business

Um BS no pode conter lgica do servio, no mximo uma transformao de

Service

dados. Mas essa pratica, sempre que possvel, deve ser evitada. (Dificulta a
legibilidade do Trace do Ensemble)

Geral

Quando houver uma propriedade no request ou no response que seu contedo seja
uma senha, a mesma deve ser private. Com isso a senha no ser exposta no Trace
do Ensemble

Business

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem

Process

ser tratados para no haver exception no tratada

Business

prioridade no uso do SQLGateway - colocar os comandos DMLs diretos no BO

Padro sqlgateway

colocar

Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

Operations
Business
Operations

138

Nesse passo, verbos que aparecem apenas em uma representao organizacional foram
descartados. Como exemplo pode-se utilizar o verbo monitorar que aparece apenas na seo
Cronograma, esse verbo ser removido da lista que conter os interesses transversais
representada na Tabela 25. O mesmo vale para os verbos mapear, envolver, iniciar, priorizar,
montar e homologar da seo Plano.
Tabela 25 Interesses transversais agrupados por verbo foram removidos os verbos com
ocorrncia em apenas 1 tipo de seo
Contedo

Trecho elementar

elemento

Tipo trecho

Verbo

elementar

bsico
Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e
iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

Descrio de

elaborar

iterao

recuperao e contingncia
Objetivos das Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e
iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

Descrio de

elaborar

iterao

recuperao e contingncia
Cronograma

Elaborar plano de desenvolvimento

Tarefa

elaborar

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase, adoo

Objetivo

criar

de padres de desenvolvimento e outras diretrizes

Plano

Criao de prottipos de telas e navegao para homologao pelos usurios

Objetivo

criar

Cronograma

Criar ambiente de configurao Projeto

Tarefa

criar

Geral

Antes do inicio de cada desenvolvimento, devemos criar um projeto para incluir os

Padro

criar

Quando um WSDL for importado o Business Operation deve ser criado pelo Wizard

Padro webclient

criar

Criar Classe Serial

Padro webclient

criar

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

criar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Cronograma

Conceber novo projeto

Tarefa

conceber

Objetivos da

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e

Descrio de

realizar

iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

iterao

objetos criados e alterados

Business
Operations
Business
Operations

recuperao e contingncia
Objetivos da

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e

Descrio de

iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

iterao

realizar

recuperao e contingncia
Objetivos da

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e

Descrio de

iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

iterao

realizar

recuperao e contingncia
Objetivos da

Iterao 8 - correo dos defeitos das releases anteriores, estratgia de treinamento e

Descrio de

iterao

suporte, estratgia de implantao, carga inicial de informaes, rotinas de backup,

iterao

realizar

recuperao e contingncia

139

Plano

Na semana seguinte estaremos realizando o workshop de casos de uso, visando

Objetivo

realizar

Objetivo

realizar

Objetivo

haver

Padro

haver

Objetivo

definir

Objetivo

definir

Padro

definir

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

Metas e restries

utilizar

mapear os processos (principais cenrios de uso) do novo sistema. Para atingir este
objetivo, esperamos contar com a presena de assessores comerciais de cada um dos
mercados (urbano, rodovia e consumo). Novamente estaremos reunindo as 2
empresas
Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores de
dados e autenticao. Como para este novo projeto os servidores sero os mesmos
creio no haver necessidade de novos testes

Plano

Com relao a utilizao da Infra-estrutura da companhia pela yyy creio no haver

maiores problemas, pois todos os testes j foram efetuados por ocasio do
desenvolvimento do projeto GPV Gesto de Ponto de Vendas. Estes testes
envolveram pessoal de infra-estrutura das 2 empresas, e foram realizados com
sucesso no que se refere ao acesso aos nossos servidores de aplicao, servidores de
dados e autenticao. Como para este novo projeto os servidores sero os mesmos
creio no haver necessidade de novos testes

Business

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem ser

Process

tratados para no haver exception no tratada

Plano

Estaremos iniciando o projeto em 25/04/2005 com um workshop de requisitos

envolvendo pessoas da rea de mercado urbano, rodovia e consumo da companhia e
yyy com a rea de informtica das 2 empresas. O workshop ter durao de 2 dias e
esperamos mapear as principais funcionalidades para o novo sistema, j com os
critrios de prioridade definidos pelo prprio usurio

Plano

Definio da Equipe, propostas de contrao de recursos especializados na

plataforma selecionada (que deve ser Java, notes e Microsoft)

Business

Quando o BS for um WebService e houver muitas propriedades e hierarquias no

Service

request ou response, definir uma nica propriedade string/stream e criar o XSD de

request e de response

Metas e

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

restries da

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior. Far

Arquitetura

uso de BLOB's

Metas e

O controle de acesso ao sistema se dar atravs do Notes quando se tratar de acesso

restries da

pela web ou fluxo de aprovao

Arquitetura
Metas e

Para autenticao dos usurios dever utilizar o servidor LDAP nas aplicaes de

restries da

Elaborao (VB)

Arquitetura
Metas e

O sistema operacional a ser utilizado nos notebooks ou desktop o Microsoft

restries da

Windows 98 ou superior. O Browser a ser o Internet Explorer 5.5 ou superior

Arquitetura
Metas e

O sistema far uso de XML para armazenar informaes de troca entre os servidores

restries da

e a aplicao cliente

Arquitetura
Metas e

Utilizao de fluxo de aprovao no Notes

140

restries da
Arquitetura
Metas e

Utilizao da API Java para acesso do servidor Java ao Notes

Metas e restries

utilizar

Capacidades

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

utilizar

Plano

Criao e montagem do ambiente de trabalho, tais como VOB no clearcase, adoo

Objetivo

adotar

Um BS deve usar uma classe DTL para chamar o BP

Padro

usar

Business

Prioridade no uso do SQLGateway - usar procedure ou funes originais do sistema

Padro sqlgateway

usar

Operations

chamado

Business

A partir da verso 2010.2 no usar mais vinculao de Tabelas, Views e procedures

Padro sqlgateway

usar

A tecnologia a empregar ser o Visual Basic, J2EE, Ltus Notes

Metas e restries

empregar

Metas e

Dever permitir que os assessores comerciais possam trabalhar sem estarem o tempo

Metas e restries

permitir

restries da

todo conectado rede interna da Cia

Objetivo

permitir

Metas e restries

possibilitar

restries da
Arquitetura

de padres de desenvolvimento e outras diretrizes

Business
Service

Operations
Metas e
restries da
Arquitetura

Arquitetura
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como utilizada
no sistema PLC Proposta de Limite de Crdito

Metas e

O sistema dever prever a interface possibilitando o envio de informaes de

restries da

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

Arquitetura

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e

Prever a utilizao do sistema pela yyy outra distribuidora do Grupo do xxx

Metas e restries

prever

Metas e

O sistema dever prever a utilizao de um banco de dados nico, disponibilizado

Metas e restries

prever

restries da

para as duas empresas. A verso do banco de dados ser o Oracle 9i ou superior. Far

Arquitetura

uso de BLOB's

Metas e

Prever a exportao de informaes para o MS Excel

Metas e restries

prever

Metas e

O sistema dever prever a interface possibilitando o envio de informaes de

Metas e restries

prever

restries da

propostas transacionadas no dia para o ERP da companhia a exemplo do que j

Arquitetura

ocorre atualmente. Em princpio no estaremos alterando esta interface

Metas e

Todos os usurios da yyy acessaro o sistema na companhia via rede interna de

Metas e restries

acessar

restries da

transmisso de dados entre as 2 empresas (j existente)

restries da
Arquitetura

restries da
Arquitetura

Arquitetura

141

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

Objetivo

acessar

Objetivo

acessar

Objetivo

acessar

Padro

acessar

Padro sqlgateway

acessar

Padro sqlgateway

acessar

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e

tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como utilizada
no sistema PLC Proposta de Limite de Crdito
Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como utilizada
no sistema PLC Proposta de Limite de Crdito

Plano

J nesta iterao, estaremos iniciando os testes com o produto "LEI", que um

software que permite ao Notes acessar diretamente o Banco de Dados Oracle e
tambm fazer acesso servidores de aplicao J2EE, acessando componentes EJB
(Enterprise Java Bean). No h uma obrigatoriedade no uso desta ferramenta, caso
no seja homologada tempo. Poderemos optar pela forma antiga, como utilizada
no sistema PLC Proposta de Limite de Crdito

Business

Um BS no pode acessar um sistema ou dado externo. Com exceo de SQL

Service

Inbound Adapter

Business

prioridade no uso do SQLGateway - utilizar Views originais ou criar uma para

Operations

acessar sistema externo

Business

prioridade no uso do SQLGateway - criar procedures ou funes no sitema externo

Operations

para o mesmo ser acessado

Business

Um mtodo do BS s pode chamar um nico BP

Padro

chamar

Um BS no pode chamar direto um BO

Padro

chamar

Um BS deve usar uma classe DTL para chamar o BP

Padro

chamar

Business

Quando um BP chamar um BO ou devolver informaes para o BS, deve ser feito

Padro

chamar

Process

atravs de um DTL

Plano

Priorizar os casos de uso que sero objetos de estudo nesta iterao e iniciar o seu

Objetivo

detalhar

Service
Business
Service
Business
Service

detalhamento
Cronograma

Refinar o plano de desenvolvimento de software

Tarefa

refinar

Plano

Ainda com relao ao ambiente, preparar os ambientes de desenvolvimento,

Objetivo

preparar

ferramentas utilizadas, etc.

Cronograma

Preparar ambiente para o projeto

Tarefa

preparar

Cronograma

Preparar ambiente para iterao 1

Tarefa

preparar

Cronograma

Preparar diretrizes para a iterao

Tarefa

preparar

Plano

Neste projeto estaremos testando o uso da ferramenta ClearQuest, para gerncia de

Objetivo

gerenciar

mudanas cuja finalidade ter um processo padro de controle de mudanas

documentado, assegurando a consistncia das mudanas e que os envolvidos tenham
conhecimento das modificaes e do impacto no custo e programao gerada por
elas
Cronograma

Gerenciamento de projeto

Tarefa

gerenciar

Cronograma

Gerenciar iterao

Tarefa

gerenciar

142

Cronograma

Gerncia de configurao

Tarefa

gerenciar

Cronograma

Gerenciar baseline e releases

Tarefa

gerenciar

Cronograma

Gerenciar solicitaes de mudanas

Tarefa

gerenciar

Cronograma

Monitorar e controlar o projeto

Tarefa

controlar

Capacidades

Muda o voucher para deletado caso ele no tenha sido utilizado

Capacidade

mudar

Capacidades

Muda o status do voucher para disponvel

Capacidade

mudar

Capacidades

Muda o status do voucher para reservado, mas necessitando de confirmao para ser

Capacidade

mudar

consumido
Capacidades

Muda o status do voucher para usado, se estiver no status de reservado

Capacidade

mudar

Capacidades

Volta o status do voucher para disponvel, se estiver com o status de reservado

Capacidade

mudar

Business

Evitar ao mximo mudar as classes criadas pelo Wizard

Padro webclient

mudar

Business

Quando for necessrio fazer modificaes na classe do Business Operation, criar

Padro webclient

modificar

Operations

uma classe herdado da classe criada pelo wizard e nessa sim fazer as modificaes

Capacidades

Recupera todos os voucher com status de disponvel e no disponvel para o vigente

Capacidade

recuperar

Padro

recuperar

Padro sqlgateway

recuperar

Padro

ter

Padro sqlgateway

ter

Padro

conter

Padro

deve ser

Padro

deve ser

Operations

para um CPF ou CNPJ

Business

Quando um BP precisar acessar dados externos ao Ensemble, deve ser chamado um

Process

BO para recuperar esses dados

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar Saldo,

Operations

gravar pedido, receber equipamento)

Geral

Todos os componentes de um servio (BS, BP e BO) devem ter request e response

prprios, mesmo quando no h diferena entre eles

Business

O BO de SQLGateway deve ter uma atividade bem definida. (Ex: Recuperar Saldo,

Operations

gravar pedido, receber equipamento)

Business

Um BS no pode conter lgica do servio, no mximo uma transformao de dados.

Service

Mas essa pratica, sempre que possvel, deve ser evitada. (Dificulta a legibilidade do
Trace do Ensemble)

Geral

Quando houver uma propriedade no request ou no response que seu contedo seja
uma senha, a mesma deve ser private. Com isso a senha no ser exposta no Trace do
Ensemble

Business

Toda chamada a BOs deve ser dentro de um Scope e no catchall os erro devem ser

Process

tratados para no haver exception no tratada

Business

prioridade no uso do SQLGateway - colocar os comandos DMLs diretos no BO

Padro sqlgateway

colocar

Sempre parametrizar a url do destino na production

Padro webclient

parametrizar

Operations
Business
Operations

5.3.14. Nomear os interesses transversais identificados

Mesmo nesse caso reduzido como resultado do mtodo, os seguintes interesses
transversais foram identificados no nvel da Arquitetura Empresarial no escopo analisado da
empresa ABCD, eles so genricos, apoiam a essncia da organizao e podem ser
reutilizados em outros domnios: elaborao; realizao; existncia; definio; utilizao;
permisso; acesso; detalhamento; preparao; gerenciamento; mudana; recuperao;
contedo; conselho; parametrizao.
143

5.3.15. Criar o diagrama de interesses transversais

Alm disso, ainda deve ser elaborado o diagrama dos interesses transversais. O
diagrama dos interesses transversais de parte da empresa ABCD representado na Figura 44.

Figura 44 Interesses transversais da rea de informtica da empresa ABCD

5.3.16. Especificar o relacionamento transversal para cada interesse transversal
identificado
A fase Representar inclui a especificao dos relacionamentos transversais dos
interesses transversais identificados relacionados s representaes organizacionais que os
contm. A especificao do relacionamento transversal do interesse transversal Elaborao
apresentada na Figura 45, do interesse transversal Realizao apresentada na Figura 46, do
interesse transversal Existncia na Figura 47, do interesse transversal Definio na Figura 48,
do interesse transversal Mudana na Figura 49, do interesse transversal Acesso na Figura 50,
do interesse transversal Gerenciamento na Figura 51, do interesse transversal Utilizao na
Figura 52, do interesse transversal Preparao na Figura 53, do interesse transversal
Permisso na Figura 54, do interesse transversal Detalhamento na Figura 55, do interesse
transversal Recuperao na Figura 56, do interesse transversal Contedo na Figura 57, do
interesse transversal Conselho na Figura 58 e do interesse transversal Parametrizao na
Figura 59.

144

Figura 45 Definio do relacionamento transversal Elaborao

Figura 46 Definio do relacionamento transversal Realizao

145

Figura 47 Definio do relacionamento transversal Existncia

Figura 48 Definio do relacionamento transversal Definio

Figura 49 Definio do relacionamento transversal Mudana

146

Figura 50 Definio do relacionamento transversal Acesso

Figura 51 Definio do relacionamento transversal Gerenciamento

147

Figura 52 Definio do relacionamento transversal Utilizao

Figura 53 Definio do relacionamento transversal Preparao

148

Figura 54 Definio do relacionamento transversal Permisso

Figura 55 Definio do relacionamento transversal Detalhamento

Figura 56 Definio do relacionamento transversal Recuperao

149

Figura 57 Definio do relacionamento transversal Contedo

Figura 58 Definio do relacionamento transversal Conselho

Figura 59 Definio do relacionamento transversal Parametrizao

5.3.17. Anlise dos resultados da aplicao do mtodo
A reduo do total de trechos organizacionais (97) para os trechos que no
operacionalizam as transaes ontolgicas (76) um pouco maior que no exemplo da EIA
(21,649%). Acredita-se que uma explicao aceitvel que os artefatos, no caso da empresa
ABCD so mais relacionados, ou seja, representam aes onde h produo de coisa nova ou
tomada de deciso que o que considerado transao ontolgica de acordo com a Ontologia
Empresarial apresentada no Captulo 3.
150

Alguns trechos representados na Tabela 14, que contm todos os trechos a serem
analisados ficaram muito grandes, principalmente das representaes que contm texto, por
exemplo padro de desenvolvimento. Assim esses tipos de trechos poderiam ser sub-divididos
em frase e essa poderia ser a unidade de anlise. Outra possvel concluso que a falta de
estruturao ou padro do documento gerou itens com contedo to grande no caso do
documento Iterao 1 plano onde mesmo a unidade de anlise parecendo adequada ainda
estava com contedo muito grande.
Com as representaes organizacionais disponveis no possvel identificar todas as
transaes ontolgicas da organizao, pois eles representam apenas parte da organizao.
Assim, a essncia identificada atravs da aplicao do mtodo se refere apenas s
representaes organizacionais consideradas.
O passo onde deve-se nomear os interesses transversais identificados atravs da
substantivao dos verbos pode gerar nomes estranhos para os interesses transversais
apresentados na literatura, como Contedo e Existncia. Esses nomes vieram de trechos onde
so informados itens que existem ou no no contexto considerado, assim o nome que
substantiva esse verbo existncia, mas existncia um nome muito genrico para um
interesse transversal e como tal no denota de forma clara um conceito espalhado e
entrelaado com os demais conceitos da Arquitetura Empresarial.
Os verbos se referem a aes a serem realizadas, essas aes utilizam determinados
conceitos. O foco nos verbos dificulta a nomeao dos interesses transversais relacionados aos
verbos, ou seja, os nomes gerados no denotam facilmente um interesse transversal, mas ao
realizar o mtodo percebe-se que os verbos tambm se encontram espalhados e entrelaados
com outros nas representaes da Arquitetura Empresarial. A continuao desse trabalho deve
complementar essa viso das aes.
5.3.18. Respostas dos participantes
A entrevista foi realizada com duas pessoas da rea de informtica da empresa ABCD.
Um dos participantes tem o perfil a, com tempo de permanncia na empresa de pelo menos 11
anos na mesma rea, com responsabilidade de definio de solues e coordenao da equipe
de desenvolvimento SOA. O outro participante tem o perfil b com tempo de permanncia na
empresa de 6 anos, sendo que esteve em reas diferentes, no incio na rea de infra-estrutura e
151

atualmente na rea de desenvolvimento de servios, responsvel pela definio dos servios,

sendo um dos recursos da equipe de desenvolvimento de servios.
Respostas do perfil a:
1)

Considerando os artefatos analisados, possvel identificar algum conceito

espalhado nas representaes organizacionais que no esteja presente no
diagrama apresentado na Figura 44?

R: No sei.
2)

Quais dos conceitos apresentados na Figura 44 so interesses transversais na

Arquitetura Empresarial? Por que?

R: Permisso existem diversos tipos de permisso, permisso de acesso ao dado,

permisso de acesso ao prdio, permisso de tirar frias.
Conselho no faz sentido nenhum.
Mudana faz sentido tudo tem mudana escopo sistema, legislao sistema,
mudana servidor, mudana estado ativo de TI, gerncia de mudana.
Elaborao tambm faz sentido.
No vejo diferena entre elaborao e realizao.
Conceitos muito genricos.
Utilizao faz sentido.
3)

Voc considera que os trechos elementares apresentados nas letras a, b e c

podem indicar um conceito transversal? Voc consegue identificar alguma
relao entre eles?
a) Iterao 2 - Analisar, projetar e implementar funcionalidades
significativas para a arquitetura. Objetivo Elaborao TIR/PNE recebendo
informaes do servidor WAS
b) Iterao 4 - Incluindo o "workflow"
152

c) Iterao 7 - produto completo - Sistema completo para homologao e

testes
R: Considerando a definio de interesse transversal, esses itens fazem parte da
essncia e no so transversais. A princpio pensou-se

que eles poderiam ser

transversais e estar espalhados em toda a organizao, porm os artefatos utilizados

retratam uma rea de TI cuja essncia est relacionada ao desenvolvimento de
software ciclo de vida de um software.
A letra b no faz parte do ciclo de desenvolvimento.
4)

O conceito Priorizao est repetido no mesmo artefato, ele pode ser

considerado um interesse transversal da Arquitetura Empresarial?

R: Sim. possvel priorizar inmeras coisas em uma rea de TI.

5)

Considerando os trechos representados nas letras a, b e c, possvel afirmar

que eles esto espalhados na Arquitetura Empresarial?
a) Workshop de Requisitos
b) Volta o status do voucher para disponvel, se estiver com o status de
reservado
c) Toda lgica da integrao deve ficar no BP

R: No.
Respostas do perfil b:
1)

Considerando os artefatos analisados, possvel identificar algum conceito

espalhado nas representaes organizacionais que no esteja presente no
diagrama apresentado na Figura 44?

R: Analisei os conceitos apresentados no diagrama e consegui identificar sinnimos

para os conceitos que pensei como sendo transversais. Por exemplo, quando penso em
requerimento ele pode estar associado a detalhamento, permisso com autenticao,
autorizao e acesso, configurao e parametrizao.
153

2)

Quais dos conceitos apresentados na Figura 44 so interesses transversais na

Arquitetura Empresarial? Por que?

R: Todos so interesses transversais, pois representam assuntos que vo se repetir em

outras reas da empresa.
3)

Voc considera que os trechos elementares apresentados nas letras a, b e c

podem indicar um conceito transversal? Voc consegue identificar alguma
relao entre eles?
a) Iterao 2 - Analisar, projetar e implementar funcionalidades
significativas para a arquitetura. Objetivo Elaborao TIR/PNE recebendo
informaes do servidor WAS
b) Iterao 4 - Incluindo o "workflow"
c) Iterao 7 - produto completo - Sistema completo para homologao e
testes

R: No consegui extrair nada que se repita a partir da anlise da letra b. A e c iro se

repetir em vrias reas, esto relacionadas uma a outra, uma implementar e a outra
homologar.
4)

O conceito Priorizao est repetido no mesmo artefato, ele pode ser

considerado um interesse transversal da Arquitetura Empresarial?

R: Sim.
5)

Considerando os trechos representados nas letras a, b e c, possvel afirmar

que eles esto espalhados na Arquitetura Empresarial?
a) Workshop de Requisitos
b) Volta o status do voucher para disponvel, se estiver com o status de
reservado
c) Toda lgica da integrao deve ficar no BP

R: No, no encontrei nenhum conceito que vai se repetir.

154

5.2.18.1.

Anlises das respostas dos participantes

Ao analisar as respostas dos participantes, tem-se o seguinte:

1)

Considerando os artefatos analisados, possvel identificar algum conceito

espalhado nas representaes organizacionais que no esteja presente no
diagrama apresentado na Figura 44?

A pergunta original exigia que os participantes conhecessem cada trecho dos artefatos
analisados e tomaria deles muito tempo. O primeiro participante no sabia dizer, j o segundo,
como a explicao verbal foi alterada, ele conseguiu pensar em conceitos que poderiam ser
equivalentes aos apresentados no diagrama. Assim na segunda entrevista, a explicao da
pergunta foi feita de forma que a resposta pudesse ser baseada no conhecimento prvio da
pessoa. Como em nenhum dos casos foi citado interesse transversal que no estivesse no
diagrama, especialmente no segundo caso, em que o participante conseguir associar os
conceitos apresentados no diagrama da Figura 44 com os conceitos que ele prprio conseguia
pensar, pode-se concluir que existe pequena probabilidade de que os interesses transversais
identificados pelo mtodo so os interesses transversais da rea da organizao considerada.
2)

Quais dos conceitos apresentados na Figura 44 so interesses transversais na

Arquitetura Empresarial? Por que?

Ao analisar as respostas, percebe-se que os conceitos apresentados na Figura 44

podero existir em nvel organizacional em diversas representaes. Alguns possuem nomes
no apropriados aparentemente, como apontado por um dos participantes e pelo anlise do
mtodo apresentada na Seo 5.2.17. Assim pode-se concluir que o mtodo possibilita a
identificao de alguns interesses transversais na Arquitetura Empresarial.
3)

Voc considera que os trechos elementares apresentados nas letras a, b e c

podem indicar um conceito transversal? Voc consegue identificar alguma
relao entre eles?

Nessa questo desejava-se avaliar se os participantes entenderam o conceito de

interesses transversais que apoiam a essncia. Aqui, em um primeiro momento, houve
consenso, ambos pensaram nas letras a e c como sendo transversais, porm o perfil a, ao ser
lembrado sobre a essncia, concluiu que esses trechos no seriam transversais e sim
155

essenciais. O perfil b ao ser lembrado sobre a essncia continuou com a opinio de que so
transversais. O item b no fez sentido para nenhum dos entrevistados. Assim pode-se afirmar
que a identificao da essncia da organizao (Dietz, 2006) no uma tarefa trivial e no
facilmente relacionada ao conceito de interesse transversal, uma vez que os participantes no
associaram, em um primeiro momento, esses trechos essncia. Outra concluso que o fato
de alguns trechos das representaes utilizadas no seguirem um padro traz consequncias
negativas para a aplicao do mtodo. Antes de aplic-lo essas inconsistncias poderiam ser
revistas.
a) Iterao 2 - Analisar, projetar e implementar funcionalidades significativas
para a arquitetura. Objetivo Elaborao TIR/PNE recebendo informaes do
servidor WAS
b) Iterao 4 - Incluindo o "workflow"
c) Iterao 7 - produto completo - Sistema completo para homologao e
testes
4)

O conceito Priorizao est repetido no mesmo artefato, ele pode ser

considerado um interesse transversal da Arquitetura Empresarial?

Nessa questo, tambm houve consenso entre os participantes, uma vez que ambos
afirmaram que a priorizao se trata de um interesse transversal. Porm h repetio apenas
na mesma representao, ou seja, no um interesse transversal na Arquitetura Empresarial.
Assim h indcios de que o mtodo no identificou todos os interesses transversais . Vale
destacar que o julgamento dos participantes era com base em sua opinio e conhecimento
prvio, sendo que em alguns momentos as definies interesse transversal e essncia da
organizao foram deixadas de lado.
5)

Considerando os trechos representados nas letras a, b e c, possvel afirmar

que eles esto espalhados na Arquitetura Empresarial?

Nessa questo, nenhum dos perfis conseguiu identificar conceitos espalhados na

Arquitetura. A letra a se refere um trecho considerado como parte de transao ontolgica,
assim no um interesse transversal. A letra b foi associada ao conceito de mudana que um
conceito transversal. Ao explicar essa associao ao perfil a, o mesmo concluiu que se trata de
156

um interesse transversal. A letra c realmente no um interesse transversal. Assim pode-se

concluir que difcil para uma pessoa que no realizou o mtodo associar um verbo
apresentado no diagrama de interesses transversais (volta o status) a um conceito (mudana) e
ento concluir que o conceito transversal.
a) Workshop de Requisitos
b) Volta o status do voucher para disponvel, se estiver com o status de
reservado
c) Toda lgica da integrao deve ficar no BP

5.4. Resumo
Nesse Captulo foi apresentado o estudo de caso realizado na empresa ABCD e as
respostas dos participantes a este estudo de caso. Tambm foram citadas anlises dos
resultados, problemas e dificuldades encontrados durante a realizao do mtodo. A entrevista
foi realizada com 2 funcionrios da rea de informtica da empresa ABCD que conhecem as
representaes organizacionais utilizadas e a empresa. O principal objetivo da entrevista foi
analisar se o resultado obtido pela realizao do mtodo foi coerente. A partir da anlise das
respostas dos participantes do estudo de caso percebe-se que h indcios de que o mtodo
proposto pode resolver o problema apresentado no Captulo 1.

157

6. Concluses

Esta dissertao apresentou uma proposta para resolver os problemas de espalhamento

e entrelaamento dos interesses transversais nas representaes que compem a Arquitetura
Empresarial. Esses problemas evidenciam a baixa modularizao das representaes
comumente criadas durante o desenvolvimento e manuteno da Arquitetura Empresarial nas
organizaes.
Para resolver esse problema da baixa modularizao foi proposto o uso da abordagem
orientada a aspectos, adaptada da rea de programao. Nessa abordagem o Aspecto
utilizado para encapsular o requisito transversal e especificar onde ele deve atuar. No caso
dessa dissertao, o Aspecto utilizado para encapsular os interesses transversais e tambm
indicar onde ele deve atuar, atravs da especificao do relacionamento transversal. Alm
disso, foi necessrio adaptar a definio de interesse transversal na Arquitetura Empresarial a
partir da proposta da rea de programao e descobrir um mecanismo que permitisse ao
arquiteto descobrir a essncia da organizao.
O mtodo proposto para solucionar o problema da baixa modularizao nas
representaes da Arquitetura Empresarial considera como entrada qualquer representao da
organizao, a partir da identificada a essncia da organizao e todos os trechos das
representaes organizacionais que operacionalizam essa essncia no so considerados
candidatos a interesse transversal. Nos demais trechos, atravs de processamento da
linguagem natural e contagem da ocorrncia dos verbos presentes nos trechos so
identificados os conceitos repetidos e espalhados nas representaes. Uma vez identificados
os interesses transversais, eles so nomeados, representados atravs do diagrama de interesses
transversais e tem especificados todos os lugares onde ocorrem atravs do relacionamento
transversal.
O mtodo DEMO, utilizado para explicitar a essncia das organizaes, acrescenta um
nvel a mais de dificuldade ao mtodo proposto nesta dissertao. Isso se deve ao fato de que
existe toda uma fundamentao terica apresentada por Dietz (2006) para explicar porque a
158

tomada de deciso e criao de coisa nova so consideradas essncia da organizao. Alm do

livro, existem diversos artigos explicando e utilizando parte da metodologia. No foi
encontrado nenhum trabalho que explicasse exatamente como identificar as transaes
ontolgicas, mais especificamente o que e o que no considerado transao ontolgica.
Optou-se, nessa dissertao, por considerar o artigo que apresenta o caso de uma universidade
(Dietz e Hoogervorst, 2008), onde as transaes ontolgicas so listadas de acordo com o
escopo e as responsabilidades e fica mais claro que algumas no so transaes ontolgicas
do departamento considerado. Alm disso, como pode ser que nas representaes
organizacionais no haja representao explcita das transaes ontolgicas, utilizou-se todo
conhecimento adquirido para afirmar que os trechos onde no h transaes infolgicas ou
datalgicas puras podem ser considerados implementao das transaes ontolgicas.
Para verificao do mtodo foi realizado um estudo de caso apresentado no Captulo 5,
onde possvel concluir que h alguns indcios de que o mtodo proposto pode resolver o
problema do espalhamento e entrelaamento dos interesses transversais na Arquitetura
Empresarial, pois ao final da realizao do mtodo tem-se a representao dos interesses
transversais existentes no escopo considerado e a especificao de todos os lugares em que
ocorrem. Alm disso, com as respostas ao questionrio apresentadas na Seo 5.2.20.6 podese concluir que h indcios de que o mtodo identifica pelo menos um interesse transversal e
que a mais de um dos interesses transversais identificados existe no nvel organizacional.
Para a representao dos aspectos foi proposto o Diagrama de Interesses Transversais
e uma linguagem, adaptada de Cappelli (2009) que permite a representao de qualquer
artefato utilizado na Arquitetura Empresarial e o relacionamento transversal.

6.1. Contribuies do trabalho

A primeira contribuio dessa dissertao a definio de interesse transversal na
Arquitetura Empresarial. Foram encontrados trabalhos que indicam o problema dos interesses
transversais na Arquitetura Empresarial, mas na maioria dos casos eles so explicados atravs
de exemplos (CAPPELLI et al., 2010a e SABINE et al, 2010) e no por definio.
Outra contribuio a proposta para melhoria na modularizao das representaes da
Arquitetura Empresarial. A Arquitetura Empresarial auxilia as organizaes a conhecerem a si
159

mesmas e reagir de forma mais eficiente s mudanas, porm no torna possvel identificar
todas as partes dos artefatos onde determinado interesse transversal encontra-se
implementado.
A principal contribuio deste trabalho o mtodo para identificao e representao
proposto para resolver o problema do espalhamento e entrelaamento dos interesses
transversais. Como o mtodo utiliza em parte a metodologia DEMO, outra contribuio a
induo ao conhecimento e representao da essncia da organizao (aplicao da Ontologia
Empresarial), ou seja, o funcionamento independente de realizao e implementao e
consequentemente mais estvel da organizao.
Mais uma contribuio dessa trabalho a integrao, com adaptaes, de diversas
solues j existentes na literatura para compor o mtodo. A metodologia DEMO foi utilizada
para identificar a essncia independente de implementao da organizao, uma abordagem
da engenharia de requisitos para identificao de interesses transversais com base no
processamento da linguagem natural e a orientao a aspectos como forma de representar os
interesses transversais identificados.
Os resultados obtidos tanto na elaborao do exemplo da EIA, quanto no estudo de
caso realizado na empresa ABCD so mais uma contribuio ao permitir que outros trabalhos
possam ser elaborados e guiados pelos resultados deste.

6.2. Limitaes
Uma das limitaes do mtodo proposto quantidade de trechos das representaes
organizacionais a serem analisados. Por considerar como entrada toda e qualquer
representao organizacional, o nmero de trechos a serem analisados pode ser grande e a
consequncia a necessidade de muito tempo para a realizao do mtodo.
Devido limitao citada acima, foi necessrio delimitar o escopo do estudo dentro
das organizaes analisadas no estudo de caso e no exemplo, bem como os trechos das
representaes organizacionais a serem analisadas. Com base na anlise dos artefatos, a
prpria autora selecionou os trechos. Assim no possvel afirmar que todos os interesses
transversais das organizaes analisadas foram identificados e representados, nem que a
essncia representada utilizando a metodologia DEMO a essncia da organizao como um
160

todo. Pode-se afirmar que foi identificada a essncia da organizao e que os interesses
transversais do escopo considerado foram identificados.
Outra limitao est relacionada ao executor do mtodo no estudo de caso. Como no
foi possvel encontrar um empresa com disponibilidade no prazo existente para aplicar o
mtodo por conta prpria em suas representaes, o estudo de caso considerou representaes
de uma empresa real, porm teve sua realizao apoiada pela prpria autora.
Alguns passos do mtodo ainda so subjetivos e dependem do conhecimento do
domnio. Como a identificao do propsito da representao organizacional para que as
partes irrelevantes fossem descartadas e a anlise da lista de interesses transversais para
descobrir quais deles fazem sentido no nvel organizacional e os verbos que so
caractersticos de apenas uma representao organizacional, so exemplos desta subjetividade.
Outra limitao o uso do conhecimento comum e conhecimento do domnio para encontrar
verbos semelhantes, com nomes distintos, porm representando o mesmo conceito.

6.3. Trabalhos futuros

A anlise dos trechos das representaes organizacionais com candidatos a interesse
transversal tambm pode considerar substantivos, alm dos verbos. Isso resultaria na
Arquitetura Empresarial organizada por assuntos de uma forma mais ampla, ao invs de
assuntos relacionados apenas s aes da empresa. Outra extenso possvel deste trabalho a
gerao dos demais modelos propostos pela metodologia DEMO onde h representao dos
atos e fatos e das informaes que precisam ser sabidas para que os papis de ator possam
realizar suas transaes ontolgicas. So esses modelos, que representam as informaes
ontolgicas, que sero comparados com as representaes organizacionais, pois eles
representam a essncia informao organizacional. Assim pode-se estender o mtodo para
anlise de modelos de dados, como os diagramas de classe por exemplo.
Um dos trabalhos a serem realizados para dar continuidade a essa dissertao a
automatizao do mtodo. Acredita-se que principalmente a descoberta da essncia utilizando
como base nos objetivos da organizao, a descoberta do que no essncia e principalmente
a linguagem de representao especificada no Captulo 4 podem ser automatizados.

161

Outra possibilidade ter como entrada representaes organizacionais com os trechos

realmente relevantes j definidos. Para isso possvel utilizar um template que especifique
quais so os trechos e o contedo da representao. A explorao desse item contribui
tambm para a automao do mtodo.
Para auxiliar a automatizao do mtodo, ser necessrio utilizar um dicionrio para
encontrar os verbos sinnimos, assim essa atividade deixa de passar pela subjetividade do
executor. Vale destacar que em alguns casos, o verbo foi utilizado com significado diferente
do seu significado real, esses casos devem fazer parte de uma lista de possveis sinnimos que
pode ser analisada pelo executor. Outra possibilidade o uso de ontologia para definir os
termos do negcio e facilitar a identificao de sinnimos.
Tambm necessrio aperfeioar o mtodo para que seja possvel incorporar a anlise
dos substantivos. Acredita-se que a base ser mantida e devero ser incorporados os demais
modelos da metodologia DEMO que representam as classes de objetos, tipos de fatos, tipos de
resultados e leis de existncia que se aplicam s transaes ontolgicas. A incorporao
desses modelos permitir a descoberta da essncia e dos interesses transversais principalmente
nos modelos de dados da organizao que no estavam disponveis em nenhum dos dois
estudos de caso realizados.
Como forma de melhorar o resultado do mtodo, possvel utilizar catlogos para
organizar os interesses transversais identificados. Com a realizao de mais estudos de caso
tambm possvel descobrir se existem interesses transversais comuns a diversos domnios.
Outra possibilidade a anlise de pacotes de soluo de distintas reas organizacionais para
identificar interesses transversais comuns (CAPPELLI et al., 2010a). Mesmo considerando o
resultado do estudo de caso realizado na empresa ABCD, possvel incrementar as
concluses ao realizar entrevistas e aplicar um questionrio mais amplo a outros participantes,
com perfis mais diversos, considerando mesmo estudantes, professores e outros profissionais
de outras reas da empresa que participou do estudo de caso.
Para aprimorar a representao gerada pelo mtodo poderia ser explorada a criao de
diagramas em que a matriz de Zachman utilizada para representar a essncia e os interesses
transversais apresentado em uma terceira dimenso (SANTOS et al., 2011). Ou utilizando
DSM (Design Structure Matrix) conforme tambm proposto por Cappelli et al (2010a).
162

REFERNCIAS

gora.

Disponvel

em:

http://np2tec.uniriotec.br:9089/wikiprocess/index.php/Inscrever_veterano_em_disciplinas.
Acessado em Jan 2012.
ALI, B. S. KASIRUN, Z. M. D., 2011, An approach for crosscutting concern identification
at requirements level using NLP, International Journal of the Physical Sciences, vol. 6(11),
pp. 2718-2730.
AVISON, D. E., GOLDEN, P. A., SHAH, H. U., 1992, Towards an SSM toolkit: rich picture
diagramming,

European

Journal

of

Information

Systems,

1,

pp.

397408.

doi:10.1057/ejis.1992.17.
ARMOUR, F. KAISLER, S. GETTER, J., PIPPIN, D., 2003, A UML-Driven Enterprise
Architecture Case Study. In: Proceedings of the 36th Annual Hawaii International
Conference on System Sciences (HICSS'03) - Track 3 - Volume 3 (HICSS '03), Vol. 3, pp.72b.
IEEE Computer Society, Washington, DC, USA.
ARMOUR, F. J. KAISLER, S. H, LIU, S. Y., 1999, A Big-Picture Look at Enterprise
Architectures. IT Professional 1, pp.35-42. DOI=10.1109/6294.774792.
ARMOUR, F. J. KAISLER, S. H, LIU, S. Y., 1999, Building an Enterprise Architecture
Step

by

Step,

IT

Professional 1,

pp.

31-39.

DOI=10.1109/6294.781623

http://dx.doi.org/10.1109/6294.781623, 1999.
BRITO, I., MOREIRA, A., 2006, Towards an Integrated Approach for Aspectual
Requirements. Requirements Engineering, 14th IEEE International Conference, pp. 341342, Minneapolis/St. Paul, MN, USA.
BOTTO, R., 2004, Arquitetura Corporativa de TI. Rio de Janeiro, Brasport. ISBN 85-7452177-9.

163

BUCKL, S. MATTHES, F. SCHWEDA, M., 2010, Conceptual Models for Cross-cutting

Aspects in Enterprise Architecture Modeling, Enterprise Distributed Object Computing
Conference Workshops (EDOCW), 14th IEEE International, pp. 245-252, Vitria, ES, Brasil.
CAPPELLI, C., 2009, Uma Abordagem para Transparncia em Processos Organizacionais
Utilizando Aspectos. Tese de Doutorado, Departamento de Informtica, Pontifcia
Universidade Catlica do Rio de Janeiro.
CAPPELLI, C., SANTORO, F., LEITE, J., BATISTA, T., 2010a, The Concept of Aspects In
Information Systems. International Conference on Research and Practical Issues of
Enterprise Information Systems (CONFENIS), Natal, RN, Brasil.
CAPPELLI, C., SANTORO, F., LEITE, J.C.S.P., BATISTA, T., MEDEIROS, A.
ROMEIRO, C., 2010b, Reflections on the Modularity of Business Process Models: the Case
for Introducing the Aspect-Oriented Paradigm, Business Process Management Journal, vol.
16 Iss: 4, pp.662-687.
CHARFI, A., 2007, Aspect-Oriented Workflow Languages: AO4BPEL and Applications.
D.Sc., Darmstadt University of Technology, Darmstadt, Alemanha.
CHARFI, A., MULLER, H., MEZINI, M., 2010, Aspect-Oriented Business Process
Modeling with AO4BPMN, In: Modelling Foundations and Applications, Lecture Notes in
Computer Science, v. 6138/2010, pp.48-61.
CLARK, T., BARN, B. S., OUSSENA, S., 2011, LEAP: a precise lightweight framework for
enterprise architecture. In: Proceedings of the 4th India Software Engineering
Conference (ISEC '11). ACM, New York, NY, USA, 85-94. DOI=10.1145/1953355.1953366
http://doi.acm.org/10.1145/1953355.1953366.
CORREAL, D., CASALLAS, R., 2007, Using Domain Specific Languages for Software
Process Modeling. In: ACM OOPSLA,Workshop on Domain-Specific Modeling.
DIETZ, J.L.G., 2006, Enterprise Ontology Theory and Methodology. ISBN-10 3-54029169-5. Springer Berlin Heidelberg New York.
DIETZ, J., DUMAY, M., MULDER, H., 2005, Demo or Practice: Critical Analysis of the
Language/Action Perspective. In: 10th International Conference on the Language-Action
Perspective.
164

DIETZ, J. L. G., HABING, N., 2004, A Meta Ontology for Organizations. In: Lecture
Notes in Computer Science, v. 3292, pp. 533-543, On the Move to Meaningful Internet
Systems 2004: OTM 2004 Workshops.
DIETZ, J. L. G., HOOGERVORST, J. A. P., 2008, Enterprise Ontology in Enterprise
Engineering. In: Symposium on Applied Computing, pp. 572-579, Fortaleza, Cear, Brasil.
DoDAF,

2009,

DoD

Architecture

Framework

v2.0.

Disponvel

em:

http://www.digitalgovernment.com/media/Downloads/asset_upload_file700_2518.pdf.
Acessado em Mai 2012.
ELRAD, T., AKSIT, M., KICZALES, G., LIEBERHERR, K., OSSHER, H., 2001,
Discussing aspects of AOP. In: Communications of ACM, v. 44, ed. 10, pp. 33-38.
ENGIEL, P., 2009, HABILITANDO PROCESSOS DE PRESTAO DE SERVIOS
PARTICIPAO E DEMOCRACIA - O CASO DA ESCOLA DE INFORMTICA
APLICADA/UNIRIO. Projeto final. Universidade Federal do Estado do Rio de Janeiro,
UNIRIO, Brasil.
FEA reference models, FBI Records Management Architecture: Integrate with FBI Enterprise
Architecture.

Disponvel

em:

http://www.archives.gov/records-mgmt/toolkit/fbi/rma-

integrate-with-fbi-ea.html#footnote_3. Acessado em Mai 2012.

FEA Consolidated Reference Model Document, Version 2.3, October 2007. Disponvel em:
http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_O
ct_2007_Revised.pdf. Acessado Jun de 2011.
FEA

Practice

Guidance,

November

2007.

Disponvel

em:

http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_Practice_Guidance_
Nov_2007.pdf. Acessado em Jun de 2011.
FEAF,

1999,

Federal

Enterprise

Architecture

Framework.

Disponvel

em

http://www.cio.gov/documents/fedarch1.pdf. Acessado em Mai 2012.

Bizagi. Disponvel em http://www.bizagi.com/. Acessado em Nov 2011.

165

FRANCESCOMARINO, C. D., TONELLA, P., 2008, Crosscutting Concern Documentation

by Visual Query of Business Processes. In: Proceedings of the 4th Int'l Workshop On
Business Process Design (BPD'08), pp. 18-31, Milano, Italy, Springer.
GMEZ-PREZ, A., FERNNDEZ-LPEZ, M., CORCHO, O., 2004. Ontological
Engineering, 2nd edn, Springer, Berlin Heidelberg New York.
GRUBER, T., 1995. Towards Principles for the Design of Ontologies Used for Knowledge
Sharing, International Journal of Human-Computer studies, 43 (5/6): 907928.
GUARINO, N., 1998, Formal Ontologies and Information Systems, in Guarino N. (ed),
Proc. of FOIS98, IOS Press, pp.315.
HILLIARD, R., 2000, IEEE-Std-1471-2000 Recommended Practice for Architectural
Description

of

Software-Intensive

Systems.

Disponvel

em:

http://www.enterprise-

architecture.info/Images/Documents/IEEE%201471-2000.pdf. Acessado em Mai 2012.

KAISLER, S. H., ARMOUR, F., VALIVULLAH, M., 2005, "Enterprise Architecting:
Critical Problems". In: Proceedings of the 38th Annual Hawaii International Conference on
System Sciences (HICSS'05), p. 224b, .
KICZALES, G., LAMPING, J., MENDHEKAR, A., MAEDA, C., LOPES, C., LOINGTIER,
J, IRWIN, J., 1997, Aspect-oriented programming. In: Proceedings of the 11th European
Conference on Object-Oriented Programming. Springer-Verlag.
LANKHORST, M., 2009, Enterprise architecture at work: Modelling, communication and
analysis, 2nd ed., Springer-Verlag Berlim Heidelberg, ISBN 978-3-642-01309-6.
LANKHORST et al., 2005, Enterprise Architecture at Work: Modelling, Communication, and
Analysis, Springer; 1 edition, pp. 334, ISBN-10: 3540243712.
MCCARTHY, R. V., 2006, Toward a Unified Enterprise Architecture Framework: An
Analytical Evaluation. In: Issues on Information Systems, v. VII, n. 2.
MOREIRA, A., ARAUJO, J., RASHID, A., 2005, A Concern-Oriented Requirements
Engineering Model. In: International Conference on Advanced Information Systems
Engineering. Porto, Portugal, v. 3520, pp. 293-308.
OMG UML (Unified Modeling Language) Infrastructure, 2011. Disponvel em:
http://www.omg.org/spec/UML/2.4.1/. Acessado em: Jun 2012.
166

PARK, C., CHOI, H-J., LEE, D., KANG, S., CHO, H-K., SOHN, J-C., 2007, KnowledgeBased AOP Framework for Business Rule Aspects in Business Process, ETRI Journal, vol.
29, n.4, pp. 477-488.
RASHID, A., MOREIRA, A., ARAUJO, J., 2003, Modularization and composition of
Aspectual Requirements. In: International Conference on Aspect-Oriented Software
Development (AOSD 2003), pp. 11-22, Boston, USA.
RITTGEN, P. A., 2006, A language-mapping approach to action oriented development of
information systems, European Journal of Information Systems, 15, pp7081.
BizAgi. Disponvel em: http://www.bizagi.com/. Acessado em Jan 2012.
SANTOS, F. J. N., LEITE, J. C. S. P., CAPPELLI, C., SANTORO, F., BATISTA, T. V.,
2011, Using goals to identify aspects in business process models. In: Proceedings of the
International Workshop on Early Aspects (EA '11). ACM, New York, NY, USA, pp. 19-23.
DOI=10.1145/1960502.1960507 http://doi.acm.org/10.1145/1960502.1960507
SANTOS, F. J. N., LEITE, J. C. S. P., CAPPELLI, C. SANTORO, F., BATISTA, T. V.,
2012, A Proposal for Ownership Representation in the Context of Business Process Models.
In: ENTERPRISE, BUSINESS-PROCESS AND INFORMATION SYSTEMS MODELING
Lecture Notes in Business Information Processing, 2012, Volume 113, Part 1, Part 2, 61-75,
DOI: 10.1007/978-3-642-31072-0_5
SANTOS, F. J. N., SANTORO, F. M, CAPPELLI, C., 2011, Crosscutting concerns at
Enterprise Architecture Level. In: Proceedings of the 2011 IEEE International Conference
on Systems, Man, and Cybernetics (SMC), pp. 345-350, Alasca, USA.
SILVA, L., 2007, A engenharia de requisitos orientada a aspectos: a abordagem DAORE.
Maring, PR. 233p. Dissertao de mestrado. UEM.
SILVA, L., 2006, Uma Estratgia Orientada a Aspectos para Modelagem de Requisitos. Rio
de Janeiro. 220p. Tese de Doutorado em Engenharia de Software - PUC-Rio.
SILVA, L., LEITE, J. C. S. P., 2005, Uma Linguagem de Modelagem de Requisitos
Orientada a Aspectos. In: Workshop de Engenharia de Requisitos (WER 2005).

167

Site

UNIRIOTEC.

Disponvel

em:

http://www.uniriotec.br/index.php?option=com_content&view=article&id=52:escola-deinformatica-aplicada&catid=45:institucional&Itemid=63. Acessado em Abr 2012.

Site UNIRI. Disponvel em: http://www.unirio.br/. Acessado em Abr 2012.
SHANKARDASS, A., 2009, The dynamic adaption of an aspect oriented business process in
service oriented architecture platform, M.Sc., Athabasca University, Canada.
SOUZA, G., 2004, Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento de
Software Orientado a Aspectos. Recife, PE. 177p. Dissertao de mestrado. UFPE.
TANG, A., HAN, J., CHEN, P., 2004, A Comparative Analysis of Architecture
Frameworks. In: Proceedings of the 11th Asia-Pacific Software Engineering Conference
(APSEC04), pp. 640-647, .
TEAF,

2000,

Treasury

Enterprise

Architecture

Framework.

Disponvel

em:

http://www.ea.or.kr/upload_files/TEAF1.0.pdf. Acessado em Mai 2012.

TOGAF, 2009, The Open Group Architecture Framework (TOGAF), v. 9.
TIRELO, F., BIGONHA, R., BIGONHA, M., VALENTE, M., 2004, Desenvolvimento de
Software Orientado por Aspectos. In: XXIII JAI Jornada de Atualizao em Informtica.
URBACZEWSKI, L., MRDALJ, S., 2006, A Comparison of Enterprise Architecture
Frameworks. In: Issues on Information Systems, v. VII, n. 2.
XEMOD. Disponvel em http://www.mprise.eu/xemod-product-overview.aspx. Acessado em
Fev de 2012.
YIN, R. K.,1984, Case study research: design and methods. London: Sage.
Yu, Y., Leite, J., MYLOPOLOUS, J., 2004, From goals to aspects : discovering aspects from
requirements goal models. In: Proc. of IEEE Int. Symp. on Requirements Engineering
(RE'04), Japan, pp. 38-47.
WADA, H., SUZUKI, J., OBA, K., 2008, Early Aspects for Non-Functional Properties in
Service Oriented Business Processes. In: Proceedings of the 2008 IEEE Congress on
Services - Part I - Volume 00 (July 06 - 11, 2008), pp. 231-238.

168

WANG, J., ZHU, J., LIANG, H., XU, K., 2007, Concern Oriented Business Process
Modeling. In: IEEE International Conference on e-Business Engineering, pp. 355-358.
WHITE, A.S., 2004, Introduction to BPMN, IBM. Disponvel em: http://www.bpmn.org/.
Acessado em Jun 2011.
ZACHMAN, J. A., 2008, John Zachmans Concise Definition of the Zachman Framework.
Zachman International.
ZACHMAN, J. A., 1987, A Framework for Information Systems Architecture. In: IBM
Systems Journal, v. 26, n. 3, pp. 276.
ZACHMAN, J. A., 1997, Enterprise Architecture : The Issue of the Century. In: March97
issue of Database Programming and Design magazine.

169

ANEXOS

I.

Convite para participar da pesquisa

O presente convite visa obter sua colaborao em parte do estudo de caso relacionado
Dissertao de Mestrado sendo realizada no Programa de Ps Graduao em Informtica da
UNIRIO pela aluna Fabiana Jack Nogueira Santos, orientada pelas professoras Flvia Maria
Santoro e Cludia Cappelli.
Esta pesquisa tem como objetivo a elaborao de um mtodo que possibilite a
identificao e representao de interesses transversais na Arquitetura Empresarial, pois, em
geral, os mesmos se encontram dispersos em diversas representaes da organizao.
Os interesses transversais so conceitos que apoiam o funcionamento da organizao.
Eles so assim chamados por possurem caractersticas de espalhamento e entrelaamento.
Isso significa que um mesmo interesse transversal est inserido em diversas partes das
representaes organizacionais ou que um determinado interesse transversal parte de uma
representao organizacional que contm outros interesses.
A identificao e representao dos interesses transversais til quando h
necessidade de manuteno, reuso ou melhoria de um conceito. Por exemplo, imagine que
uma empresa que fabrica carros precisa que seus processos sejam mais rpidos e inicia esse
projeto pelas etapas dos processos onde acontece algum tipo autorizao, uma vez que
possvel automatizar esse tipo de ao que no parte de sua essncia. Como saber todos os
lugares da organizao onde acontece autorizao? Como saber de quais formas as
autorizaes esto atualmente implementadas?
Ao final do mtodo proposto gerada a especificao de tudo que foi considerado
interesse transversal da organizao. Nessa especificao descrito o tipo de elemento que
implementa o interesse e todos os lugares onde exatamente ele ocorre.
Para soluo do problema dos interesses transversais espalhados e entrelaados nas
representaes organizacionais foi construdo um mtodo. Para verificar se o mtodo
soluciona o problema foi realizado um estudo de caso. Nesse estudo de caso, o mtodo foi
aplicado a alguns artefatos da rea de TI de uma empresa que comercializa combustveis. O
presente questionrio uma forma de avaliar se o resultado do mtodo coerente.
A confidencialidade de informaes ser mantida ao no divulgarmos os nomes dos
participantes dessa pesquisa, bem como suas respectivas respostas. Em caso de dvida, estou
disponvel para contato atravs do seguinte e-mail: fabiana.nogueira@uniriotec.br.
170

Agradeo antecipadamente a sua colaborao.

Fabiana Jack Nogueira Santos
II.

Apresentao do mtodo

Para facilitar o entendimento do mtodo proposto, algumas definies devem ser

explicitadas, como interesse transversal, essncia da organizao, Arquitetura Empresarial e
representao organizacional. Essas definies so apresentadas na Tabela 26.
Tabela 26 Definies
Nome

Definio

Interesses transversais

conceitos que apoiam ou exercem influncia na essncia de uma organizao, ou seja, nos
interesses essenciais da organizao. Com essa definio, sabe-se que os interesses transversais
no fazem parte da essncia das organizaes
so atos realizados pelos papis de ator e os fatos resultantes de tais atos onde h produo de
algo novo ou tomada de deciso, esses atos so denominados transaes ontolgicas. Esses atos
so apoiados por outros atos e fatos onde h computao de informao ou manipulao de
dados que indicam como a realizao e implementao da essncia da organizao
um conjunto coerente de princpios, mtodos e modelos que so usados no projeto e realizao
da estrutura, dos processos de negcio, dos sistemas de informao e da infraestrutura de uma
empresa
qualquer documento, lista, artefato, modelo ou diagrama que representa alguma parte da
organizao

Essncia da organizao

Arquitetura Empresarial

Representao organizacional

O mtodo proposto para resolver o problema do espalhamento e entrelaamento dos

interesses transversais na Arquitetura Empresarial representado na Figura 60. O mtodo
recebe como entrada todo e qualquer representao organizacional. A partir de tais
representaes, o executor do mtodo deve definir quais so os tipos de elementos bsicos de
cada uma. Esses tipos de elementos bsicos so aqueles que explicam o propsito da
representao. Por exemplo, em um documente de requisitos, o tipo de elemento bsico a
definio dos requisitos, j a introduo do documento no considerada elemento bsico.
Depois disso, o executor listar os trechos que compem os elementos bsicos, no exemplo do
documento de requisitos, a lista dos requisitos definidos.
Com essa informao, o executor do mtodo deve identificar os trechos das
representaes que indicam criao de algo novo ou tomada de deciso. Isso caracteriza as
transaes ontolgicas que so a essncia da organizao. A partir da identificao das
transaes ontolgicas, o executor deve represent-las utilizando a representao proposta
pela metodologia DEMO (Design and Engineering Methodology for Organizations).

171

Em seguida o executor deve identificar quais dos trechos das representaes

organizacionais operacionalizam as transaes ontolgicas e descart-los, pois esses trechos
no caracterizam um interesse transversal, j que eles apoiam a essncia da organizao que
representada atravs das transaes ontolgicas.
Feito isso o executor deve identificar os verbos de cada trecho ainda presente na lista.
Para cada verbo identificado, o executor deve realizar anlise semntica e agrupar verbos com
mesmo significado. Em seguida, o executor deve calcular o nmero de ocorrncias de cada
verbo e descartar aqueles que possuem apenas uma ocorrncia, isso caracteriza a ausncia de
espalhamento do interesse que na verdade no transversal. Em seguida o executor deve
identificar os trechos elementares que compartilham o mesmo verbo e os verbos dominantes,
aqui temos caracterizada a intruso de um interesse transversal. Se houver apenas 1 verbo
dominante, o executor deve revisar a lista dos interesses transversais, pois os verbos no
dominantes devem ser removidos, se no houver mais de uma ocorrncia do mesmo.
Na sequencia o executor deve descartar verbos repetidos em apenas um tipo de
elemento bsico dos artefatos e remov-los da lista de interesses transversais, pois esses
podem ser interesses transversais pertencentes a apenas um tipo de representao e no
Arquitetura Empresarial. A partir desse passo tem-se os interesses transversais da
organizao, o executor deve nome-los, represent-los utilizando o diagrama de interesses
transversais e especificar o relacionamento transversal de cada um dos interesses transversais
identificados.

III.

Artefatos utilizados
Os artefatos utilizados para aplicao do mtodo esto listados na Tabela 13. Na

Tabela 14 apresentado o contedo a ser analisado de cada representao organizacional.

172

Figura 60 Passo a passo do mtodo para Identificar e Representar Interesses Transversais

173

IV.

Resultado
Considerando como entrada para o mtodo os trechos apresentado na Seo 5.2.20.3, a

aplicao do mtodo resultou no seguinte Diagrama de Interesses Transversais apresentado na

Figura 44. Esse diagrama indica quais so os interesses transversais da rea de informtica da
empresa ABCD. Essas so os interesses transversais da essncia da organizao ABCD
representada na Figura 43.
Alm disso, o relacionamento transversal do interesse transversal Elaborao
apresentado na Figura 54. O relacionamento transversal especifica onde o interesse
transversal ocorre e de quais tipos ele . No caso do interesse transversal Permisso, no
escopo da rea de informtica, ele ocorre durante a descrio da iterao 8 no documento
PN2-PlanoDesenvSoftware e exatamente no trecho onde esto descritos os objetivos das
iteraes. Ele ocorre tambm depois do objetivo Priorizar casos de uso... no artefato PN2Iterao-1 no trecho onde so listados os objetivos da iterao.
Com base nessas informaes, responda s questes.
V.

Roteiro da entrevista
A partir do contedo exposto nos Anexos I, II, III e IV questiona-se:
1) Considerando os artefatos analisados, possvel identificar algum conceito

espalhado nas representaes organizacionais que no esteja presente no diagrama

apresentado na Figura 43?
2) Quais dos conceitos apresentados na Figura 43 so interesses transversais na
Arquitetura Empresarial? Por que?
3) Voc considera que os trechos elementares apresentados nas letras a, b e c podem
indicar um conceito transversal? Voc consegue identificar alguma relao entre eles?
a) Iterao 2 - Analisar, projetar e implementar funcionalidades
significativas para a arquitetura. Objetivo Elaborao TIR/PNE recebendo informaes do
servidor WAS.
174

b) Iterao 4 - Incluindo o "workflow"

c) Iterao 7 - produto completo - Sistema completo para homologao
e testes.
4) O conceito de priorizao est repetido no mesmo artefato, ele pode ser considerado
um interesse transversal da Arquitetura Empresarial?
5) Considerando os trechos representados nas letras a, b e c, possvel afirmar que
eles esto espalhados na da Arquitetura Empresarial?
a) Workshop de Requisitos
b) Volta o status do voucher para disponvel, se estiver com o status de
reservado
c) Toda lgica da integrao deve ficar no BP

175