Embed Size (px)
Citation preview
Wikis para Sistemas de Informação Emergentes
Marco André Gonçalves Pinheiro
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e Computadores
Júri
Presidente: Prof. Nuno João Neves Mamede, IST/UTL
Orientador: Prof. António Manuel Ferreira Rito da Silva, IST/UTL
Vogais: Prof. Pedro Alexandre de Mourão Antunes, FC/UL
Prof. João Vieira da Cunha, FE/UNL
Maio 2011
Agradecimentos
Gostaria de agradecer a todos aqueles que estiveram presentes e me apoiaram ao longo da
minha vida academica e em particular durante a realizacao desta dissertacao.
Ao meu orientador Professor Antonio Rito Silva pelo apoio, disponibilidade, perseveranca e
espırito crıtico que em muito contribuıram para o resultado final agora apresentado.
Ao Professor Joao Vieira da Cunha pelas sugestoes e melhorias, dando total atencao as
questoes acerca do caso de estudo, de sua, autoria, que serviu de base a realizacao desta dis-
sertacao.
A todos os colegas e professores com quem trabalhei ao longo do curso.
A todos os meus amigos por estarem sempre presentes com palavras de amizade e incentivo.
A Ines, por toda a compreensao, dedicacao e enorme ajuda a ultrapassar os obstaculos.
E por fim aos meus pais e irmao, o meu profundo agradecimento pelo acompanhamento e
apoio incondicional ao longo de toda a minha vida.
Maio 2011,
Marco Andre Goncalves Pinheiro
i
ii
Resumo
Na era digital, grande parte das organizacoes usa sistemas de informacao como suporte
para diversas actividades aos nıveis operacional, estrategico e de gestao. Tradicionalmente,
esses sistemas sao prescritos como resultado das decisoes de governacao. No entanto, numa visao
mais minuciosa, vislumbram-se sistemas de informacao nao prescritos, ditos emergentes, os quais
nao resultam directamente do desenho inicial. Independentemente da natureza do seu suporte
(electronico ou nao), esses sistemas surgem no seio da organizacao entre os sistemas prescritos e
sao em parte promovidos por iniciativas dos agentes humanos da organizacao. Sao exemplos de
sistemas e tecnicas de trabalho emergentes: anotacoes e apontamentos em documentos impressos
ou post-it de informacao relevante e necessaria para a realizacao de tarefas, coordenacao e
visao geral sobre o progresso de uma tarefa complexa atraves de tabelas em folhas de calculo
e papel onde se anota informacao oriunda de diferentes fontes nao integradas. Este tipo de
sistemas tem desvantagens inerentes, como por exemplo, falham no suporte a rastreabilidade
e actualizacao da informacao, nao sao orientados a partilha de informacao e nao suportam
a colaboracao entre grupos de actores. Esta tese procura providenciar um modelo de como as
transferencias de informacoes emergente e prescrita e as praticas de trabalho que usam artefactos
emergentes podem ser suportados por uma plataforma emergente. Apos modelar em Tropos as
caracterısticas dos sistemas de informacao emergentes e de estudar um cenario de como estes
surgem e gerado uma arquitectura centrada em tres conceitos principais: artefactos, dados e
importacao/exportacao. Proposta a arquitectura, a XWiki e estendida de modo a potenciar
as suas caracterısticas de suporte a emergencia obtendo-se uma plataforma emergente que e
posteriormente validada ao simular o cenario usado para expor o problema.
iii
iv
Abstract
In the digital era, most organizations use information systems as support for activities at
operational, strategic and management level. Traditionally, these systems are prescribed as a
result of governance’s decisions. However, on a more meticulous evaluation, some of them are
not prescribed, said emergent, which are not derived directly from the initial design. Regardless
of its medium nature (electronic or not), these systems arise within the organization alongside
the prescribed ones and are in part promoted by initiatives of non-manager agents. Examples
of unprescribed systems and work are: annotations and notes in printed documents, and post-it
with information necessary to accomplish tasks; coordination and overview of the progress of a
complex task through structured spreadsheets; and running logs where information is written
down from different sources that are not integrated. Such systems have inherent disadvantages,
for example, fail to support traceability and updating information, are not oriented to sharing
information and do not support well collaboration among an large group of users. This thesis
seeks to provide a model of how emergent and prescribed information and artifacts can be
supported by an emerging platform. After modeling in Tropos the features of unprescribed
systems of a case study and to consider a scenario of how emerging aspects arise, software
architecture is generated focused on three main concepts: artifacts, data, and import/export.
After that, XWiki is extended so as to enhance its features to support emergency resulting in
an emerging platform that is subsequently validated by simulating the scenario used to expose
the problem previously.
v
vi
Palavras-Chave
Palavras-Chave
Sistema de Informacao Emergente
Artefacto Emergente
Informacao Emergente
Wiki
Keywords
Unprescribed Information System
Emergent Artefacts
Emergent Information
Wiki
vii
viii
�Indice
Agradecimentos i
Resumo iii
Palavras-Chave vii
Indice xiii
Lista de Figuras xvii
Lista de Tabelas xix
Lista de Acronimos xxi
1 Introducao 1
1.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Estrutura da Dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Trabalho Relacionado 5
2.1 Sistemas de Informacao Emergentes . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Funcionalidades dos Artefactos . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Adopcao e Aprendizagem Improvisada da Tecnologia . . . . . . . . . . . . 10
ix
2.2 Wikis e Waves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Google Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Problema 19
3.1 Descricao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Caso de Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Lista de Afazeres e Post-It . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Pilha de Documentos e Correio Electronico . . . . . . . . . . . . . . . . . 23
3.2.3 Running Log e Folha de Calculo . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Situacao A – relembrar de tarefas . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Situacao B – priorizar tarefas . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3 Situacao C – relembrar de informacao . . . . . . . . . . . . . . . . . . . . 29
3.4 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Solucao 31
4.1 Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Tipo de Vista Modulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1.1 Estilo Decomposicao . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1.2 Estilo Utilizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1.3 Estilo Generalizacao . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Tipo de Vista Componente e Conector . . . . . . . . . . . . . . . . . . . . 41
x
4.4 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Implementacao 45
5.1 Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1 XWiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.2 Google Web Toolkit e Smart GWT . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.2 Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3 Importacao, Exportacao e Conectores . . . . . . . . . . . . . . . . . . . . 54
5.3 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Validacao 61
6.1 Configuracao do ambiente na plataforma emergente . . . . . . . . . . . . . . . . . 61
6.2 Validacao das situacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.1 Situacao A – relembrar de tarefas . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.2 Situacao B – priorizar tarefas . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.3 Situacao C – relembrar de informacao . . . . . . . . . . . . . . . . . . . . 65
6.3 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7 Conclusao 75
7.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Principais contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
xi
A Arquitectura de Software 83
A.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.3 Cenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3.1.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3.1.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3.1.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.3.2 Leitura e Escrita de Dados Emergentes atraves de Artefactos . . . . . . . 85
A.3.2.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.3.2.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.3.2.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.3.3 Definicao de Tipos de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.3.3.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.3.3.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.3.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.4 Importacao de Novos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.4.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3.4.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3.4.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3.5 Importacao de Novos Dados mantidos num Ficheiro . . . . . . . . . . . . 89
A.3.5.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.3.5.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.3.5.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
xii
A.3.6 Importacao de Novos Dados mantidos num Sistema Prescrito . . . . . . . 90
A.3.6.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.3.6.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.3.6.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.3.7 Exportacao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3.7.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3.7.2 Tacticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3.7.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.4 Responsabilidade dos modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B i*/Tropos 97
B.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.2 Principais Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.3 Caso de Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.4 i*/Tropos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.5 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
xiii
xiv
Lista de Figuras
1.1 Natureza do alinhamento com os objectivos da empresa segundo a classificacao
emergente e prescrita das duas dimensoes - tecnologia de informacao e praticas
de utilizacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Entidades de uma wave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Desafios que levam o vendedor a utilizar artefactos emergentes. . . . . . . . . . . 20
3.2 Artefactos emergentes modelados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Modelo relacional estrategico referente a lista de afazeres. . . . . . . . . . . . . . 22
3.4 Modelo relacional estrategico (simplificado) referente ao post-it. . . . . . . . . . . 23
3.5 Modelo relacional estrategico referente a pilha de documentos. . . . . . . . . . . . 24
3.6 Modelo relacional estrategico referente ao correio electronico. . . . . . . . . . . . 25
3.7 Modelo relacional estrategico referente ao running log. . . . . . . . . . . . . . . . 26
3.8 Modelo relacional estrategico referente a folha de calculo. . . . . . . . . . . . . . 27
4.1 Vista geral da solucao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Decomposicao num nıvel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Decomposicao do modulo Dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Decomposicao do modulo Fonte de Dados. . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Estilo utilizacao do tipo de vista modulo. . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Generalizacao dos Conectores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Generalizacao dos Artefactos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
xv
4.8 Vista Componente e Conector — Repositorio de Dados. . . . . . . . . . . . . . . 42
5.1 Menu do editor grafico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Modelo de renderizacao da XWiki. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Modelo de tratamento de pedidos HTTP da XWiki. . . . . . . . . . . . . . . . . 48
5.4 Area de trabalho com post-its, pilhas de documentos e paineis. . . . . . . . . . . 51
5.5 Diagrama entidade-relacao do meta-modelo. . . . . . . . . . . . . . . . . . . . . . 52
5.6 Configuracao de tipo de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7 Interaccao do Conector com a Importacao e Exportacao. . . . . . . . . . . . . . . 55
5.8 Interaccao entre modulos durante a importacao de um ficheiro CSV. . . . . . . . 55
5.9 Interaccao entre modulos durante a exportacao para um ficheiro CSV. . . . . . . 56
5.10 Configuracao do conector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Configuracao da transferencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.12 Configuracao da estrategia de transferencia. . . . . . . . . . . . . . . . . . . . . . 58
5.13 Configuracao do mapeamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Escrita de uma nova pagina usando o editor grafico WYSIWYG preenchendo
hierarquia, tıtulo, corpo e sumario da versao. . . . . . . . . . . . . . . . . . . . . 63
6.2 Modo de edicao in-line do artefacto pilha. . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Artefacto pilha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Botoes de adicao de artefactos e colunas na area de trabalho durante o seu modo
de edicao in-line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 Adicao de um post-it escrevendo o conteudo e opcionalmente um tıtulo. . . . . . 64
6.6 Artefacto post-it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.7 Nuvem de tags e lista de documentos na area de trabalho MTEL. . . . . . . . . . 66
6.8 Modo de edicao in-line numa pagina com referencias. As caixas de texto sao as
referencias prontas a editar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
xvi
6.9 Exportacao para um ficheiro CSV os clientes modificadas desde ultima exportacao. 67
6.10 Criacao e visualizacao de anotacoes numa pagina. . . . . . . . . . . . . . . . . . . 68
6.11 Navegacao na hierarquia de dados e insercao de referencias numa pagina. . . . . 69
6.12 Importacao a partir de um ficheiro CSV todos os clientes actualizando os impor-
tados anteriormente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.13 Configuracao da referencia no processo de importacao. . . . . . . . . . . . . . . . 71
6.14 Adicionar uma tag a um documento. . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.1 Decomposicao apos o primeiro cenario. . . . . . . . . . . . . . . . . . . . . . . . . 85
A.2 Decomposicao apos o segundo cenario. . . . . . . . . . . . . . . . . . . . . . . . . 86
A.3 Decomposicao apos o terceiro cenario. . . . . . . . . . . . . . . . . . . . . . . . . 87
A.4 Decomposicao apos o quarto cenario. . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.5 Decomposicao apos o quinto cenario. . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.6 Decomposicao apos o sexto cenario. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.7 Decomposicao apos o setimo cenario. . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.1 Modelo de dependencia estrategica para o caso de estudo. . . . . . . . . . . . . . 101
B.2 Modelo racional estrategico para o caso de estudo. . . . . . . . . . . . . . . . . . 102
xvii
xviii
Lista de Tabelas
2.1 Artefactos para organizacao de elementos num escritorio. . . . . . . . . . . . . . 7
2.2 Principais diferencas entre robots e gadgets. . . . . . . . . . . . . . . . . . . . . . 16
3.1 Artefactos e respectivos formatos para o suporte de cada desafio. . . . . . . . . . 21
4.1 Estrategias para seleccao de dados sujeito a importacao e exportacao. . . . . . . 32
4.2 Relacao entre os atributos de qualidade e os modulos e componentes arquitecturais. 43
5.1 Aspectos tecnicos e funcionais dos artefactos da plataforma emergente. . . . . . . 50
5.2 Funcionalidades XWiki usadas para a implementacao de alguns modulos e com-
ponentes arquitecturais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xix
xx
Lista de Acr�onimos
AJAX Asynchronous Javascript and XML
API Application Programming Interface
CSV Comma-Separated Values
ETL Extract, Transform, Load
GWT Google Web Toolkit
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
JRE2 Java Runtime Environment 2
RPC Remote Procedure Call
RSS Really Simple Syndication
SQL Structured Query Language
TAM Technology Acceptance Model
XDOM eXtensible Document Object Model
WYSIWYG What You See Is What You Get
xxi
1Introdu�c~ao
1.1 Introducao
O termo sistema de informacao tem sido comummente usado para referir interaccoes entre
pessoas, processos, dados e tecnologia (Laudon and Laudon 2006). Nesse sentido, o termo refere-
se nao so a tecnologia de informacao e comunicacao usada por uma organizacao, mas tambem na
forma pela qual os utilizadores interagem com a mesma enquanto meio de suporte para atingir
os seus objectivos e satisfazer as suas necessidades.
Os sistemas de informacao de uma organizacao podem ser classificados quanto a tecnologia
utilizada e quanto a forma de utilizacao da tecnologia em um dos seguintes tipos: prescrito ou
emergente. Adicionalmente os objectivos e necessidades que levam os utilizadores a interagir
com o sistema de informacao podem convergir ou divergir dos objectivos da organizacao. A
figura 1.1 apresenta a natureza desse alinhamento quando a tecnologia e a forma de utilizacao
sao classificadas como emergentes ou prescritas.
Figura 1.1: Natureza do alinhamento com os objectivos da empresa segundo a classificacaoemergente e prescrita das duas dimensoes - tecnologia de informacao e praticas de utilizacao.
A tecnologia utilizada nos sistemas de informacao pode ser de um dos seguintes tipos: pres-
crita ou emergente. A primeira e desenhada e implementada como consequencia das decisoes
de governacao da organizacao. A segunda aparece num contexto organizacional de emergencia
como uma tecnologia adoptada para suportar as tarefas diarias, promovida em parte por inici-
ativas dos membros da organizacao. Em relacao as praticas de utilizacao, estas sao prescritas
quando a tecnologia (independentemente da sua natureza) e utilizada de acordo com os padroes
e regras de trabalho planeados e definidos pela governacao e consequentemente encontram-se ali-
nhadas com os objectivos da organizacao. As praticas de utilizacao emergentes, pelo contrario,
estendem as funcionalidades dos sistemas de informacao ao serem usados de forma nao prevista
pela governacao (Leclercq et al. 2009). Importa frisar que essa extensao do sistema advem, nao
da sua implementacao, mas da utilizacao das funcionalidades existentes de uma forma diferente
do habitual.
A convergencia e divergencia resumem-se a natureza do alinhamento com os objectivos gerais
da organizacao. Tomemos como exemplo uma recem-formada equipa de vendas que tem como
objectivo demonstrar a sua importancia para a organizacao. Se esse objectivo e derivado de um
desejo de aumento de poder e desse modo as praticas de utilizacao nao prescritas vao no sentido
de ocultar o fracasso da equipa em atingir os objectivos de vendas, entao resulta em divergencia
com os objectivos da organizacao. Por outro lado, se o objectivo e derivado de um desejo de
aumentar o valor gerado pela organizacao e desse modo as praticas de utilizacao nao prescritas
vao no sentido de tornar o trabalho mais eficiente e eficaz, entao resulta em convergencia com
os objectivos da empresa.
Este trabalho foca-se no estudo da relacao entre sistemas de informacao prescritos e emer-
gentes e as suas caracterısticas. Pretende-se estudar a utilizacao de sistemas de informacao
emergentes e o modo como estes surgem no seio da organizacao. Nesse sentido, sera necessario
adoptar uma metodologia de levantamento de requisitos que possa capturar os porques e as
intencoes dos utilizadores enquanto promotores deste tipo de sistemas. Ao aplicar a metodolo-
gia adoptada a casos de estudo exemplificativos de emergencia, obtem-se uma aproximacao das
funcionalidades e caracterısticas pretendidas de um sistema emergente.
Por outro lado, pretende-se avaliar um conjunto de plataformas colaborativas, principal-
mente wikis e waves, com o objectivo de identificar as caracterısticas e funcionalidades que
oferecem. Numa analise empırica, pensa-se que este tipo de plataformas podera acarretar be-
nefıcios importantes para o desenho e criacao de um sistema de informacao emergente assente
em tecnologia. Essas ferramentas poderao ser a base sobre as quais os utilizadores desenvolverao
2
os sistemas emergentes.
1.2 Objectivos
O objectivo deste trabalho passa por um levantamento das caracterısticas dos sistemas que
surgem no seio de uma organizacao, usando para tal tecnicas de levantamento de requisitos
sobre um caso de estudo que descreve a emergencia ocorrida numa organizacao em particular.
De seguida compara-se essas caracterısticas com as caracterısticas de ferramentas do tipo wikis
ou waves de forma a concluir se essas plataformas colaborativas servem as necessidades de um
sistema emergente. Por fim serao implementadas as funcionalidades mais relevantes na plata-
forma colaborativa escolhida com o objectivo desta servir de base para o desenvolvimento de um
sistema, pelos proprios utilizadores finais, capaz de satisfazer as suas necessidades emergentes.
1.3 Estrutura da Dissertacao
A dissertacao e dividida em 7 capıtulos.
Este capıtulo introduziu o tema do sistema de informacao emergente e prescrito e formalizou
os objectivos do trabalho.
O capıtulo 2 focado no trabalho relacionado divide-se em dois temas: sistemas de informacao
emergentes e wikis e waves. O primeiro tema revela conceitos de mudanca emergente, artefactos
emergentes e suas funcionalidades e aprendizagem improvisada. O segundo tema fala sobre as
wikis e waves e o modo como estas podem suportar a emergencia.
O capıtulo 3 formaliza a descricao do problema e faz um levantamento das caracterısticas e
funcionalidades dos artefactos emergentes, tendo em conta um caso de estudo exemplificativo. A
partir da modelacao e do caso de estudo, o capıtulo finaliza com a descricao de um cenario com
aspectos emergentes. Este capıtulo e acompanhado pelo anexo B que descreve a metodologia de
engenharia de requisitos usada para modelar o caso de estudo — i*/Tropos.
O capıtulo 4 inicia com uma vista geral sobre a solucao proposta e aprofunda-a ao longo
do capıtulo descrevendo os atributos de qualidade e a arquitectura de software. Este capıtulo e
acompanhado pelo anexo A que descreve a decomposicao dos modulos.
3
O capıtulo 5 apresenta a tecnologia XWiki AS-IS, o seu grau de extensibilidade e o seu
potencial de suporte a sistemas emergentes. De seguida apresenta-se as decisoes de desenho e
os detalhes tecnicos e de que modo a implementacao usa funcionalidades da XWiki.
O capıtulo 6 valida a plataforma emergente desenvolvida de acordo com o modelo de imple-
mentacao dos capıtulos anteriores. A validacao e feita atraves de configuracao e utilizacao da
plataforma emergente de modo a suportar o cenario descrito no capıtulo 3.
O capıtulo 7 tira as principais conclusoes e contributos e termina com propostas para tra-
balho futuro dentro do mesmo tema.
4
2Trabalho Relacionado
Os sistemas de informacao emergentes, tema central deste trabalho, surgem num contexto
de transformacao organizacional improvisada e nao planeada. Com o intuito de perceber a
adopcao e reinvencao espontanea da tecnologia por parte dos seus utilizadores, sao descritos
modelos de adopcao e reinvencao de tecnologia. Torna-se importante analisar as caracterısticas
e funcionalidades dos sistemas emergentes. Comeca-se pelo levantamento de tipos de artefactos
que servem de suporte as necessidades dos seus utilizadores num escritorio vulgar. De modo
a desenvolver um levantamento mais completo de requisitos torna-se necessario analisar casos
de estudo que descrevem tecnologias e praticas emergentes. Assim, examina-se previamente
diversas metodologias de engenharia de requisitos. As metodologias orientadas a objectivos sao
analisadas de modo a encontrar uma tecnica apropriada para tratar de contextos emergentes e
levantar os requisitos de sistemas emergentes. Esta seccao descreve, ainda, as caracterısticas de
duas plataformas colaborativas. Wiki e wave podem vir a ser estendidas de modo a implementar
um conjunto de requisitos levantados atraves da metodologia escolhida. A construcao dessa nova
plataforma tem o objectivo de vir a ser adoptada pelos utilizadores para o desenvolvimento de
sistemas de suporte a necessidades emergentes.
2.1 Sistemas de Informacao Emergentes
As organizacoes vivem num meio ambiente cada vez mais dinamico e agressivo onde diaria-
mente e necessario acompanhar e responder a alteracoes economicas, polıticas e tecnologicas. Os
aspectos de flexibilidade, aprendizagem, agilidade e auto-organizacao tornaram-se importantes
para as organizacoes contemporaneas. O conceito de mudanca evoluiu de um acontecimento
episodico em segundo plano para uma actividade constante durante a vida de uma organizacao.
Consequentemente, o conjunto existente de perspectivas de transformacao organizacional tornou-
se insuficiente para suportar esta nova visao. Essas perspectivas partilhavam as assumpcoes de
que a mudanca apenas era episodica, rapida, radical e obrigatoriamente planeada, e os seus
impulsionadores eram (consoante a perspectiva) os gestores ou a tecnologia em si (Orlikowski
1996).
Em oposicao as estrategias e mudancas deliberadas, existem tambem as emergentes. En-
quanto a mudanca deliberada e a realizacao de um novo padrao organizacional1 de acordo com o
originalmente concebido, a mudanca emergente e a realizacao de um novo padrao organizacional
sem qualquer intencao explıcita ou concepcoes previas (Orlikowski 1996). Essas transformacoes
emergentes devem-se ao improviso e adaptacao local encenados, mesmo que inconscientemente,
pelos agentes quando experimentam excepcoes ou consequencias imprevistas durante a realizacao
das suas tarefas diarias e quando procuram planos de contingencia ou deparam-se com oportuni-
dades. Por isso a mudanca emergente, mesmo que nao intencional ou apercebida, esta inerente
as accoes humanas realizadas diariamente.
A transformacao emergente pode ser caracterizada pela: (i) analise das praticas que incitam
as mudancas emergentes, (ii) analise do desenho e propriedades organizacionais que influenciam
e que sao influenciadas pelas transformacoes, (iii) as caracterısticas dos sistemas emergentes
alinhadas com as necessidades que surgiram, (iv) os novos padroes e praticas de trabalho e
utilizacao de sistemas prescritos e emergentes, (v) as consequencias inesperadas que resultaram
das mudancas e que ao mesmo tempo influenciam transformacoes futuras. Este trabalho foca-se
principalmente nos aspectos (iii) e (iv). De seguida serao descritos alguns exemplos de cada um
dos aspectos.
2.1.1 Artefactos
Os agentes humanos possuem limitacoes em capacidade de memoria e processamento sis-
tematico. Por isso, os agentes humanos tornam-se dependentes de artefactos que ajudem a
mitigar essas limitacoes. O mesmo tipo de artefacto e usado por diferentes utilizadores para o
suporte de tarefas simples. Contudo quando se trata de um tarefa mais complexa, o artefacto
ou sistema que surge e igualmente mais complexo tornando-o cada vez mais unipessoal e ao
1Uma padrao organizacional envolve praticas de trabalho, estruturas organizacionais, padroes de interaccao,mecanismos de coordenacao e outros aspectos.
6
mesmo tempo aumentando o grau de dificuldade de usabilidade e compreensibilidade por parte
de outros utilizadores.
Os sistemas emergentes nao electronicos, adoptados pelos utilizadores, sao geralmente im-
provisados a partir de artefactos conhecidos. Pastas, arquivos, pilhas, dossiers, quadros negros,
calendarios, notas em post-it sao alguns exemplos desses artefactos (Malone 1983; Bondarenko
and Janssen 2005; Mander et al. 1992). Num estudo sobre a organizacao de escritorios, foram
destacados dois tipos de artefactos como os mais importantes: arquivo e pilha (Malone 1983).
Ambos sao modos de agrupamento de elementos (por exemplo, folhas de papel, pastas, livros,
relatorios, revistas, envelopes) em conjuntos mas possuem caracterısticas diferenciaveis.
Elementos Grupos
Intitulados Ordenados Intitulados Ordenados
Arquivo Sim Sim ? ?
Pilha ? Nao Nao ?
Pastas ? Nao Sim ?
Tabela 2.1: Artefactos para organizacao de elementos num escritorio.
Tal como indicado na tabela 2.1, o arquivo e um tipo de artefacto onde os elementos sao
explicitamente intitulados e colocados numa ordem especıfica (por exemplo, numa ordem al-
fabetica ou cronologica). Em alguns casos os proprios grupos que o artefacto cria (por exemplo,
as gavetas de um arquivo) sao igualmente nomeados com um tıtulo ou ordenados de alguma
forma.
Na pilha, por outro lado, os elementos individuais nao sao necessariamente nomeados com
um tıtulo e geralmente nao sao ordenados. A dinamica na criacao de uma pilha de elementos leva
consequentemente a um ordem cronologica inversa, mas tal nao e necessariamente uma ordem
intencional do utilizador (Malone 1983), contudo e util na funcionalidade de procura. Adicio-
nalmente, cada pilha nao possui um tıtulo e nao sao necessariamente alinhadas numa mesa por
uma ordem em particular. Contudo, a sua localizacao espacial e importante para as funcoes de
procura e relembranca. Por outro lado, pode ser vista como uma unidade sujeita a mudanca.
Por exemplo, os elementos de uma pilha podem ser facilmente remexidos ou reordenados e sepa-
rados em duas ou mais sub-pilhas, iniciando-se, assim, um processo informal de categorizacao.
As pilhas sao criadas com objectivos diferentes, por exemplo, podem agrupar elementos segundo
uma das seguintes estrategias: tipo de documento, estado de processamento, projecto a que o
7
documento se refere, ou meramente aleatorio especialmente quando se trata de documentos que
nao se inserem em outras pilhas. A sua localizacao espacial pode tambem seguir uma estrategia
ou ser meramente aleatoria. A distancia de uma pilha a area de trabalho pode reflectir a sua
importancia ou prioridade (Mander et al. 1992). Existem ainda diferentes formas de separar
elementos dentro de uma pilha: elementos em diferentes angulos ou um separador de material
diferenciador dos elementos.
A categorizacao rıgida inerente a uma hierarquia de pastas e uma das razoes que levam os
utilizadores a usarem pilhas. A estrutura hierarquica de pastas e ficheiros nao e o modo natural
como os agentes organizam a informacao enquanto realizam as suas actividades (Bondarenko
and Janssen 2005). Alias, existem evidencias da dificuldade cognitiva em classificar informacao
(Malone 1983) e da preferencia dos utilizadores em lidarem com documentos atraves de agrupa-
mentos (como as pilhas) em oposicao a categorizacao imediata em pastas especıficas (Mander
et al. 1992).
A tabela 2.1 resume a classificacao dos tres tipos de artefactos anteriormente analisados
quanto a intitulacao dada e a ordem gerada segundo dois graos: os elementos dentro do artefacto
e o proprio artefacto enquanto conjunto de elementos. As definicoes indicadas na tabela foram
escolhidas de acordo com o significado comum do termo, mas podem ser utilizadas noutras
situacoes. Por exemplo, uma prateleira de livros pode ser vista como uma pilha, uma vez que
os elementos nao estao ordenados nem a prateleira possui um nome. Mas, numa biblioteca,
uma prateleira de livros pode ser vista como um arquivo, uma vez que os seus elementos estao
ordenados e possuem uma designacao relevante, como por exemplo o nome do autor.
Os sistemas emergentes electronicos, adoptados pelos utilizadores, sao geralmente impro-
visados utilizando software de produtividade, como e o caso das folhas de calculo, devido a
facilidade de utilizacao sentida pela maior parte dos utilizadores. As folhas de calculo podem
manter e organizar informacao sobre uma tarefa complexa cujo estado e actualizado ao longo do
tempo. O correio electronico e um exemplo de um sistema emergente que deve-se nao a tecnolo-
gia em si mas pela utilizacao nao prescrita. Mais do que um meio de comunicacao assıncrono, o
correio electronico tornou-se numa agenda, num gestor de lembretes, contactos e lista de afaze-
res, e ate num local de armazenamento de ficheiros e transferencia dos mesmos (Gwizdka 2002).
O facto de novas tarefas e pedidos a satisfazer resultarem respectivamente de mensagens recebi-
das e enviadas por correio electronico, este tornou-se mais atractivo do que ferramentas digitais
8
especificamente desenhadas para as funcoes de planeamento, relembranca e armazenamento
(Bondarenko and Janssen 2005). Sendo um centro de comunicacao, o correio electronico reflecte
as actividades principalmente dos trabalhadores que trabalham com informacao, pois as suas
actividades sao baseadas em comunicacao e coordenacao que passam pelo correio electronico.
2.1.2 Funcionalidades dos Artefactos
Malone identifica as duas funcoes basicas proporcionadas pela artefactos (Malone 1983). A
primeira funcionalidade e a de procura. Os agentes organizam os documentos para que possam
encontra-los mais tarde. Contudo a par desta funcionalidade existe a de relembranca, igualmente
importante. Existem artefactos visıveis no topo das mesas na maioria dos escritorios que estao
la com o intuito de relembrar visualmente tarefas pendentes aos utilizadores do escritorio e nao
apenas pela disponibilidade prestada. Dix et al diferenciam dois papeis que podem ser encenados
pelo mesmo artefacto: trigger e placeholder (Dix et al. 1998). A diferenca essencial entre os dois
assenta no facto do trigger exprimir que existe algo a realizar e o placeholder exprimir o que e
necessario realizar. Por exemplo, um medico pode ter na sua agenda a necessidade de analisar o
caso de um paciente (trigger) mas precisa de obter informacao do prontuario ou registos medicos
para saber o estado actual do paciente (placeholder).
A informacao e um bem importante para as organizacoes. Os humanos possuem uma capa-
cidade de memoria limitada e por isso usam os artefactos para suportar a necessidade de manter
uma quantidade de informacao superior das suas capacidades. A “memoria” pode ser mantida
de tres maneiras diferentes: internamente (no cerebro dos agentes humanos), externa e explicita-
mente (no conteudo dos artefactos) ou externa e implicitamente (na localizacao e nos atributos
dos artefactos) (Dix et al. 1998). O facto de existir um parte da “memoria” que e mantida
internamente conduz a visao dos sistemas unipessoais e do problema da interpretacao onde o
contexto cultural e organizacional ganha uma relevancia natural. Por exemplo, um sistema de
cores basicas (vermelho, amarelo e verde) que reflecte o risco de determinada tarefa e geralmente
interpretado da mesma forma por diferentes pessoas. Por outro lado, a localizacao de documen-
tos numa pilha a esquerda e noutra a direita do monitor e geralmente apenas interpretado por
quem os colocou daquele sıtio.
9
2.1.3 Adopcao e Aprendizagem Improvisada da Tecnologia
Entre os varios modelos sobre adopcao de tecnologia, o Modelo de Aceitacao de Tecnolo-
gia (TAM) criado por Fred David e um dos mais influentes devido a forte base teorica e apoio
empırico que tem. O modelo argumenta que a intencao comportamental de um indivıduo utilizar
um sistema e determinado por duas crencas do mesmo: a facilidade de utilizacao apercebida e
a utilidade apercebida. A facilidade de uso apercebida refere-se ao grau o qual um utilizador
acredita que a utilizacao e livre de esforco. A utilidade apercebida e o grau ao qual um utili-
zador acredita que a sua utilizacao ira melhorar a sua performance nas suas tarefas. O modelo
argumenta que o efeito de factores externos sao mediados pelas duas crencas apresentadas ante-
riormente, isto e, factores externos influenciam a utilidade e facilidade de utilizacao apercebidas
e sao essas duas crencas do utilizador que, por sua vez, influenciam a intencao do utilizador em
usar o sistema (Adams et al. 1992).
Contudo o modelo apresenta varias limitacoes. O TAM nao avalia as influencias do contexto
organizacional, a perspectiva de utilizacao em grupo e nao um indivıduo apenas, nem a existencia
de diferentes opcoes de sistemas concorrentes com o sistema analisado.
Segundo Boudreau e Robey a aprendizagem improvisada impulsiona a mudanca gradual da
fase de inercia para a fase de reinvencao da tecnologia (Boudreau and Robey 2005). No momento
em que um novo sistema prescrito e colocado em producao, os utilizadores evitam o seu uso ou
usam-no de uma forma perfunctoria. Essa fase de uso limitado da nova tecnologia e designada por
inercia. Deve-se ao facto do sistema nao corresponder as expectativas, necessidades ou objectivos
de cada utilizador. Esses objectivos podem estar alinhados com os objectivos da organizacao (por
exemplo, aumento da produtividade ou simplicidade das actividades diarias) ou pelo contrario,
divergirem dos objectivos da organizacao (por exemplo, quando o novo sistema resultar na
perda de poder por parte dos utilizadores). A aprendizagem improvisada, ao contrario de
uma formacao formal, resulta da aprendizagem sem qualquer metodo ou estrutura, iniciada
pelos proprios utilizadores atraves da pratica de utilizacao do novo sistema. Por exemplo,
ocorre quando um utilizador descobre alguma funcionalidade ou metodo que vai ao encontro
das suas necessidades e e partilhado com os outros utilizadores. A medida que os utilizadores
comecam adoptar o novo sistema, comecam a encontrar limitacoes e inflexibilidade por parte do
sistema. Essas limitacoes sao apercebidas pelos utilizadores, podendo existir ou nao na realidade.
Consequentemente, os utilizadores comecam a adoptar padroes de utilizacao nao prescritos de
10
forma a contornar as restricoes apercebidas do sistema.
2.2 Wikis e Waves
O principal proposito deste trabalho e criar uma plataforma apta a servir de base para os
sistemas emergentes. Direccionado a esse proposito, uma plataforma existente sera estendida
em vez de criar uma de raiz. O intuito desta seccao e descrever as principais funcionalidades e
caracterısticas de duas plataformas colaborativas — wikis e waves — e avaliar a extensibilidade
de cada uma. Ambas plataformas sao potenciais plataformas de emergencia, uma vez estendidas
as suas funcionalidades.
2.2.1 Wikis
Wikis sao coleccoes de paginas ligadas entre si, que podem ser editadas por qualquer pessoa,
em qualquer altura, a partir de qualquer lugar (Ebersbach et al. 2008); resultam do trabalho
contınuo de uma comunidade. A primeira wiki foi desenvolvida em 1995 por Ward Cunningham
que a considerou originalmente como a mais simples possıvel base de dados on-line. O principal
objectivo era permitir que o trabalho colaborativo em codigo fonte fosse facilmente publicado
numa pagina web. Desde entao o conceito de wiki ganhou reputacao na area de gestao in-
formatica como uma das ferramentas mais uteis e faceis de implementar e tem sido promovida
como uma ferramenta social que mudara a forma como a investigacao e os negocios sao desen-
volvidos (Bean and Hott 2005). Algumas empresas tem adoptado wikis para os trabalhadores
acederem, editarem colectivamente e guardarem informacao e documentos relacionados com o
trabalho. A medida que este tipo de software colaborativo se move da esfera social para a empre-
sarial, desafia a governacao das empresas e envolve os trabalhadores num ambiente de partilha
e geracao de conhecimento (Hasan and Pfaff 2006).
Qualquer pessoa pode contribuir facilmente para o conteudo e estrutura da wiki, simples-
mente criando novas ligacoes e adicionando novas paginas. Esta caracterıstica — a abertura —
e um dos aspectos mais inovadores e importantes das wikis. O leitor, ao encontrar uma pagina
que, do seu ponto de vista, encontra-se incompleta ou mal organizada, tem a possibilidade de
edita-la como entender.
11
As versoes de cada pagina sao mantidas pela wiki em forma de historico permitindo a
consulta e restauro de versoes anteriores. A cada edicao e associado o nome do utilizador,
pelo que cada membro da comunidade e responsabilizado pelas suas edicoes limitando, assim,
o potencial problema de vandalismo (Hasan and Pfaff 2006). Ainda em relacao a edicao, e
possıvel (e util) criar paginas inexistentes, isto e, que ainda nao foram sequer escritas. Posteri-
ormente, a comunidade pode escrever as paginas inexistentes aumentando, assim, o conteudo da
wiki. As notificacoes por RSS ou correio electronico permitem os utilizadores acompanharem a
evolucao e crescimento da wiki incentivando, mais cedo, contribuicoes e comentarios sobre de-
terminada pagina recentemente modificada. Efectivamente, esta ultima funcionalidade favorece
a frequencia de edicao acelerando a conclusao de actividades relacionadas, e assegura que todos
os utilizadores envolvidos sejam melhor informados sobre o processo evolutivo.
A wiki cresce e envolve-se organicamente com a comunidade que a usa. Isto deve-se a uma
mudanca de paradigma fundamental. Wikis afastam o paradigma de controlo e aproximam a
visao de confianca e partilha, democratizando a colaboracao e o acesso a informacao. Delibe-
radamente, foi afastado das wikis a predefinicao de estruturas e procedimentos complexos. A
este nıvel, e o papel dos utilizadores aprenderem e adoptarem o estilo de utilizacao da wiki e
definirem o modo de organizacao da informacao2. Esta flexibilidade permite que a plataforma
seja usada para uma serie de necessidades(Mader 2008) e promove a partilha, e consequente
adopcao, de conhecimento tacito incluindo praticas mais produtivas.
Ferramentas menos flexıveis ou fechadas necessitam de ajustes e artifıcios a medida que os
objectivos e necessidades dos utilizadores mudam, e mesmo assim nao desempenham de forma
elegante e eficiente outras funcoes para alem da sua concepcao original. Do ponto de vista
social, os sistemas fechados delegam a tecnologia o controlo e acesso a informacao, assumindo
implicitamente que tal poder nao pode ser confiado aos utilizadores. Por outro lado, as wikis
afastam a ideia antiquada de que um agente salvaguarda para si informacao com o intuito
de proteger a sua posicao de poder. Numa cultura wiki, os agentes sao recompensados pelo
quao activo contribuem para a comunidade. Aqueles que mais participam tornam-se geralmente
lıderes do pensamento, porque a sua experiencia pode ser medida de forma tangıvel pelas suas
contribuicoes e abordagens. Desta forma, esses agentes tornam-se realmente indispensaveis para
a organizacao, nao so porque possuem um conhecimento rico, mas mais importante, que estao
2Uma das formas de organizacao de informacao, vulgar em wikis, e o sistema de rotulagem (do ingles, tagging).
12
dispostos a compartilha-lo.
Ate recentemente as wikis continham, na sua maioria, texto corrido (prosa). Varios motores
suportam o acesso a dados estruturados de uma base de dados e oferecem a funcionalidade de
programacao pelo proprio utilizador de forma a apresentar e trabalhar com dados de outros
sistemas no contexto de uma wiki (Anslow and Riehle 2008).
A wiki e uma possıvel plataforma sobre a qual serao desenvolvidos, pelos proprios utilizado-
res, sistemas de informacao emergentes. Portanto, e relevante averiguar se as wikis satisfazem as
assumpcoes da programacao pelo proprio utilizador final. Sao analisados os seguintes aspectos
atendendo as wikis: programacao incremental e incompleta, inexistencia da distincao clara en-
tre o modelo e a instancia de execucao, e a execucao e sempre efectuada independentemente da
ocorrencia de falhas. Em primeiro, uma pagina wiki encontra-se sempre num estado consistente
mesmo que nao esteja completa ou os resultados nao facam sentido. Alias, do ponto de vista
da wiki, qualquer pagina encontra-se sempre em desenvolvimento. Em segundo, nao existe uma
clara distincao entre o modelo de execucao — o programa — e a instancia da execucao — o
resultado. Apesar de existirem diferencas entre o modo de edicao e o de visualizacao, o utilizador
nao visiona uma distincao clara, devido a proximidade entre o que se escreve no modo de edicao
e o que se ve no modo de visualizacao. Por ultimo, a execucao de uma wiki nunca falha. O
motor da wiki nao deixa de mostrar a pagina mesmo que algo nao seja possıvel interpretar. E
deixado ao utilizador julgar se o resultado e o correcto ou pretendido.
Tal como as folhas de calculo, as wikis satisfazem as assumpcoes da programacao pelo uti-
lizador (Anslow and Riehle 2008). Contudo, as folhas de calculo sao baseadas no paradigma de
tabelas e numeros. As wikis, pelo contrario, usam um paradigma computacional de hiperligacoes
que nao restrige o potencial de adaptar-se a necessidades emergentes. Nao sao por natureza es-
pecıficas a um domınio e isso e uma vantagem para a adopcao desta ferramenta como plataforma
para os objectivos do trabalho.
As wikis direccionadas para organizacoes estao alinhadas com a necessidade de estruturas de
dados predefinidas e customizaveis mas com conteudo nao necessariamente estruturado. Tendo
como base a analise em duas dimensoes — estruturacao e contextualizacao da informacao — as
wikis tem informacao contextualizada porque existem hiperligacoes entre paginas relacionando
a informacao contida nessas paginas. Seguindo a outra dimensao possibilitam ter informacao
estruturada e nao estruturada. Texto numa pagina wiki tem um nıvel de estruturacao baixo
13
enquanto que estruturas de dados ou classes tem um nıvel de estruturacao elevado. Fazendo
a ponte com os sistemas emergentes, a informacao surge frequentemente contextualizada, por
exemplo, um conjunto de folhas numa pasta esta contextualizado porque nessa pasta se guarda
as facturas do mes. Em relacao a estruturacao, existe informacao estruturada e nao estruturada
nos sistemas emergentes. Em detalhe, a informacao e mais estruturada quando esta e prescrita
ou possui um relacao directa com alguma entidade prescrita. Mas tambem existe informacao
nao estruturada nos sistemas emergentes como por exemplo notas soltas temporarias.
Wikis que possibilitam guardar informacao em diferentes nıveis de estruturacao sao uteis
para satisfazer as necessidades emergentes, porque num contexto organizacional existem entida-
des estruturadas que devem ser mantidas e por outro lado deve haver flexibilidade para suportar
entidades com pouca estruturacao.
2.2.2 Google Wave
Google Wave e uma ferramenta on-line para colaboracao e comunicacao em tempo real.
Baseia-se no conceito fundamental — wave. Existem tres partes a distinguir: o protocolo, o
servidor e o cliente. O protocolo e aberto a federacoes de modo a que fornecedores de waves
— servidores — possam inter-operar entre si. Os utilizadores acedem as waves atraves do seu
fornecedor utilizando uma aplicacao cliente, que no caso do Google tem a designacao de Google
Wave3.
Tal como demonstra a figura 2.1, a anatomia de uma wave e constituıda por wavelets que por
sua fez possuem blips (Gina Trapani 2009). Uma wave e uma conversa, ou um documento, sobre
a qual os participantes podem comunicar e trabalhar em conjunto e em tempo real usando texto
formatado, fotos, vıdeos, mapas e qualquer outro artefacto disponibilizado atraves de extensoes.
Formalmente, trata-se de uma entidade dinamica que mantem estado e historico, servindo de
contentor para uma ou mais wavelets. Uma wavelet e um subconjunto da conversacao global
que, apesar de independente das outras wavelets, se encontra contextualizada por pertencer a
um contentor — a sua wave. Por se tratar da unidade basica de controlo de acesso a dados, cada
wavelet possui um conjunto diferente de participantes. Consequentemente, conversas privadas
(em forma de wavelets) podem ser mantidas. A blip e a unidade basica de conversacao e
3A aplicacao pode ser acedida em http://wave.google.com/
14
consiste numa unica mensagem. Adicionalmente, blips podem conter outras blips, formando
uma hierarquia. Existem tres formas de modificar uma wave: respondendo por de baixo de uma
blip, respondendo dentro de uma blip (de modo intercalado), ou editando o conteudo de uma
blip existente. O acto de responder corresponde a criacao de uma nova blip a par ou intercalada
com as existentes.
Figura 2.1: Entidades de uma wave.
O Google Wave e tambem uma plataforma com um conjunto disponıvel de APIs que permite
embeber waves em outros servicos web e desenvolver extensoes que trabalham dentro de waves.
Existem, portanto, dois tipos de desenvolvimento: extensao e integracao.
E possıvel facilmente integrar esta ferramenta de comunicacao e colaboracao com aplicacoes
web. Ao embeber waves em sites, os seus utilizadores ficam aptos a discutirem e colabora-
rem usando uma interface identica ao cliente Google Wave. Essas waves possuem o mesmo
comportamento como as waves dentro do cliente.
A extensao permite construir robots com o objectivo de automatizar tarefas numa wave
ou construir gadgets que fornecem novas formas de interaccao entre agentes. Ambos podem
ser utilizados conjuntamente. Robots sao aplicacoes que participam em waves para as quais
foram convidados, tal como um utilizador humano se tratasse. Por isso, do ponto de vista da
wave, participantes humanos ou participantes robots sao vistos de igual modo — sao agentes
que operam sobre uma wave. Ao contrario dos gadgets, os robots correm num servidor fora da
wave e podem ler e modificar o conteudo da wave, adicionar e remover participantes, adicionar
novas blips ou novas waves. O modo de funcionamento dos robots segue uma arquitectura de
resposta a eventos e mantem, atraves de wavelets (privados), informacao escondida de outros
participantes mas que e fundamental para a sua actividade na wave.
15
Gadgets possibilitam que um programa, que se executa numa wave, seja partilhado e a que
todos os participantes dessa wave tenham acesso. Um gadget e uma pequena aplicacao que e
executada dentro do cliente wave. Uma wave pode conter uma ou mais instancias independentes
desse gadget e os respectivos estados sao partilhados por todos os participantes. O gadget
nao tem influencia sobre a propria wave. Apenas e usada como um add-on que aperfeicoa
algum aspecto de uma conversacao. Por exemplo, uma wave pode incluir um gadget com um
artefacto (como a pilha de documentos) que permite os participantes manterem uma pratica de
colaboracao aprimorada devido ao artefacto partilhado.
A possibilidade de extensao da plataforma possibilita aperfeicoar a forma como os agentes
comunicam numa wave permitindo satisfazer melhor as suas necessidades. A tabela 2.2 resume
as diferencas entre as duas alternativas de extensao da plataforma.
Robot Gadget
E executado num servidor aplicacional e inte-rage com a wave atraves de um protocolo.
E executado dentro do proprio cliente wave.
Um robot e um participante numa wave, logoexiste quanto muito uma instancia por cadawave. Mas uma wave pode possuir varios parti-cipantes/robots.
Cada gadget pode ser instanciado multiplas vezesnuma wave.
Robots podem modificar uma wave e realizar asmesmas operacoes como se de um participantehumano se tratasse.
Gadgets nao podem modificar uma wave e tem visi-bilidade limitada. Um gadget apenas pode detectaralteracoes nos participantes da wave.
Robots podem modificar gadgets. Gadgets nao possuem forma de aperceber da pre-senca de robots e por isso nao estao aptos a modi-fica-los.
Tabela 2.2: Principais diferencas entre robots e gadgets.
2.3 Sumario
O paradigma associado as wikis democratiza a colaboracao e o acesso a informacao pois
qualquer agente pode contribuir e visualizar o conteudo e estrutura da wiki. Visto que o estilo de
utilizacao e o modo de organizacao da informacao sao definidos pelos utilizadores, as wikis podem
ser usadas para uma serie de propositos. Apesar da flexibilidade igualmente proporcionada pelas
folhas de calculo, estas sao baseadas no paradigma de tabelas e numeros. As wikis, pelo contrario,
nao se restringem a um paradigma computacional especıfico ou um modo de visualizacao em
particular. Logo ao utilizar esta plataforma para as necessidades emergentes, os utilizadores nao
16
se restringem a um paradigma predefinido.
As waves surgiram recentemente como uma forma de comunicacao e colaboracao em tempo
real, caracterıstica na qual as wikis nao se focam. Uma wave e uma conversacao ou documento
cuja estrutura tambem nao e predefinida. Os actores (humanos e computacionais) podem inte-
ragir e trabalhar em conjunto usando texto formatado, fotos, vıdeos, mapas e qualquer outro
artefacto disponibilizado atraves de extensoes que aperfeicoa algum aspecto na forma de comu-
nicar.
17
18
3Problema
A descricao do problema e uma descricao concisa dos aspectos que sao enderecados durante
o desenho da solucao. Neste capıtulo redefine-se o problema que foi apresentado brevemente
no capıtulo de introducao. De seguida um caso de estudo onde surgem aspectos emergentes
e descrito em duas vertentes — uma mais geral e outra direccionada aos artefactos e praticas
associadas. O objectivo passa por levantar os requisitos (caracterısticas e funcionalidades) exis-
tentes nos artefactos emergentes. Por fim, com base no caso de estudo, apresenta-se um cenario
que conjuga artefactos e praticas de trabalho emergentes e prescritas.
3.1 Descricao do Problema
Os sistemas de informacao de uma organizacao podem ser classificados quanto a tecnologia
e quanto a forma de utilizacao da tecnologia em um dos seguintes tipos: prescrito ou emergente.
Os sistemas de informacao emergentes surgem num contexto de transformacao organizacional
improvisada e nao planeada. Os utilizadores adoptam sistemas emergentes por dois motivos: (i)
os sistemas prescritos tornaram-se desajustados com as actividades prescritas e necessidades dos
utilizadores ou (ii) os utilizadores precisam de manter actividades emergentes para as quais nao
podem utilizar os sistemas prescritos. Contudo muitos dos artefactos emergentes que surgem nao
estao sobre um plataforma propria. Grande parte dos artefactos sao fısicos perdendo assim as
qualidades que um artefacto digital oferece e quando sao artefactos digitais surgem em aplicacoes
diversas.
Assim, pretende-se criar uma plataforma com o objectivo de servir de base ao desenvol-
vimento de sistemas pelos proprios utilizadores finais, capaz de satisfazer as suas necessidades
emergentes.
3.2 Caso de Estudo
O caso de estudo exemplificativo descreve uma etnografia realizada sobre um departamento
de vendas de uma empresa de telecomunicacoes. Essa unidade de vendas aplica esforcos na
utilizacao dos sistemas de informacao para a construcao de uma aparente observancia com as
regras, procedimentos e objectivos prescritos. Na realidade, os colaboradores deste departa-
mento realizam parcialmente outro trabalho para o qual a gestao de topo nao delegou e que na
verdade esta delegado a outros departamentos. Eis porque surge uma aparente observancia e
consequentemente a necessidade de desenvolver trabalho nao prescrito de modo a manter essa
aparencia. Explica-se o modo como os utilizadores improvisaram um sistema de informacao
emergente de forma a coordenar ao longo do tempo o trabalho nao prescrito. Cunha aponta tres
desafios de auto-coordenacao que os empregados enfrentavam: relembrar das tarefas e respec-
tivo estado, relembrar da informacao necessaria para completar cada uma das tarefas e priorizar
tarefas (Vieira da Cunha 2005). De modo a suportar esses desafios, os utilizadores adopta-
ram varios artefactos e tecnicas de utilizacao. A figura 3.1 reproduz em Tropos o modelo de
dependencia estrategica do utilizador face aos artefactos. Apesar de existirem em diferentes
formatos, os principais artefactos resumem-se a listas de afazeres, pilha de documentos e um
registo de execucao ou running log. A figura 3.2 ilustra os artefactos que sao modelados em
Tropos.
VendedorArtefacto
Emergente
Priorizar Tarefas
u u
Não esquecer de
tarefas por realizaru u
uu
Mantida informação necessária
para completar tarefas
Utilidade
Facilidade de
Utilização
u
u
u
u
+-u
Actor
Objectivo
Softgoal
Recurso
Fronteira do Actor
Decomposição
Contribuição positiva
Contribuição negativa
Dependência
Tarefa
Means-ends
Legenda:
Figura 3.1: Desafios que levam o vendedor a utilizar artefactos emergentes.
A tabela 3.1 identifica os principais artefactos e respectivos formatos que surgiram de modo
a suportar cada um dos desafios mencionados. Para alem disso resume as nuances que surgem
em cada formato.
20
Artefacto
Emergente
Folha de
Cálculo
Running
Log
Pilha de
Documentos
Post-It
Lista de
Afazeres
ISA
Correio
Electrónico
ISAISA ISA
ISAISA ISA
Figura 3.2: Artefactos emergentes modelados.
Desafio Artefacto Formato dos Artefactos Nuances
Relembrar das tarefas
Lista de afazeres
(to-do list)
Página de um caderno de apontamentos ● Riscar quando completo; ● Um item por linha Simples folha de papel
Página de um calendário
Post-it ● Um para cada tarefa; ● Deitar fora quando completo; ● Posicionamento do artefacto;
Caixa de entrada do correio electrónico ● Impossibilidade de fazer anotações junto da informação a que se referem; ● Utilizadores reportam dificuldade de utilização (no objectivo de relembrar tarefas e informação). Havia desconfiança/medo de esquecer algo importante
Relembrar da
informação
Pilha (to-do pile)
Correio electrónico assinalado com cores diferentes que simulam diversas pilhas
Documentos impressos com notas
● Desfolhar e separar documentos de forma a refrescar a memória do que tem de fazer durante o resto do dia ● Colecção documentos e informação de diversas origens: sistemas de comunicação electrónicos (email), telefonemas com clientes, vendedores ou representantes operacionais, sistemas de informação prescritos, entre outros ● Possibilidade de fazer anotações no papel e junto da informação a que se referem ● Cada documento é orientado à tarefa, já que o próprio documento pode ser o próprio espaço de suporte à tarefa (e não apenas de acesso à informação)
Pastas ou dossieres
Documentos organizados por conta cliente
● Separadores ● Associação de documentos por conta cliente
Running log
Página de um caderno de apontamentos ● Não organizado ● Informação não correlacionada na mesma folha/página Simples folha de papel
Folha de cálculo
● Organizado ● Paradigma tabelas ● Uma folha de cálculo por assunto ● Informação correlacionada na mesma folha
Post-it
Priorizar tarefas
Lista de afazeres numerados ● Numeração
Post-it posicionados num sítio em particular ● Posicionamento do artefacto
Tabela 3.1: Artefactos e respectivos formatos para o suporte de cada desafio.
21
3.2.1 Lista de Afazeres e Post-It
As listas de afazeres oferecem uma grande visibilidade das tarefas ainda por completar sem o
sobrecarregamento proveniente dos detalhes das mesmas. A descricao de cada tarefa e pequena
o que reforca a ideia das listas servirem para refrescar a memoria e nao para manter um registo
detalhado sobre a mesma. As listas de afazeres surgem em diferentes formatos e adaptados as
preferencias pessoais de cada utilizador. No caso de estudo surgem duas adaptacoes principais:
notas a frente de tarefas como por exemplo ”reuniao”ou ”fazer amanha”e numeros que indicam
a prioridade relativa face a outras tarefas. A prioridade de cada tarefa e determinada pela
combinacao de dois criterios: importancia e urgencia. A importancia corresponde a combinacao
de diversas medidas: a receita proveniente da execucao da tarefa, a facilidade de execucao
da tarefa, o estatuto da pessoa que pediu assistencia, e as preferencias pessoais. A urgencia
corresponde ao modo de comunicacao aplicado para realizar um pedido em conjunto com a
frequencia de contacto. Por exemplo, pedidos por telefone sao vistos como mais urgentes do que
os pedidos por correio electronico. A figura 3.3 apresenta a modelacao em Tropos da lista de
afazeres.
Vendedor
Tarefas
visualizadas
Lista de
Afazeres
Gerir tarefas
Tarefas pendentes
registadas
+
-
Registar
tarefa
Enumerar
tarefa
Escrever
nota
Marcar tarefa
com símbolo
Visualizar tarefas
completas
Personalização
Mantida informação necessária
para completar tarefas
u
u
Acrescentar
detalhe
Utilidade
u
u
Riscar
tarefa
Registar prioridade
da tarefa
Não sobrecarregar
com detalhes
Visualizar tarefas
pendentes
Obter noção de
progresso
Não manter registo
detalhado
u
Não esquecer de
tarefas por realizar
u
u
Priorizar
Tarefas
u
u
u
u
u
Figura 3.3: Modelo relacional estrategico referente a lista de afazeres.
Entre a variedade de formatos importa modelar o post-it dada a particularidade do posici-
onamento e visualizacao aumentada. A figura 3.4 apresenta a modelacao em Tropos do post-it.
Como a descricao das tarefas nao sao detalhadas, as listas de afazeres nao sao suficientes para
22
Vendedor
Post-It
+
Não esquecer de
tarefas por realizar
u
u
Priorizar
Tarefas
u
Lista de
Afazeres
ISA
Posicionar
post-it
Posicionar de acordo
com prioridade
Visualização
aumentada
u
Figura 3.4: Modelo relacional estrategico (simplificado) referente ao post-it.
coordenar tarefas complexas que envolvam um numero significativo de actividades precisando,
assim, de uma coordenacao interna ao longo do tempo. Os utilizadores, ao se envolverem numa
tarefa apos a leitura da lista de afazeres, relembram que tem de abrir um e-mail ou retirar
um documento de um dossier ou pilha. Tal facto leva a considerar a existencia de referencias
explıcitas ou implıcitas entre sistemas. Por exemplo, a expressao “ver e-mail” em conjunto com a
descricao da tarefa a realizar e uma referencia explıcita. Se mesmo que a expressao nao estivesse
escrita, invariavelmente o utilizador lembrar-se-ia de abrir o e-mail, entao tratar-se-ia de uma
referencia implıcita.
3.2.2 Pilha de Documentos e Correio Electronico
A pilha de documentos mantem a informacao necessaria para completar as tarefas. Trata-
se de um sistema hıbrido uma vez que a informacao e oriunda de multiplas fontes: sistemas
prescritos da M-Tel, conversas por telefone com o cliente ou representantes do servico, sistemas
de comunicacao electronica, documentos impressos. Para alem disso, os artefactos existentes
na pilha sao orientados a tarefa. Por exemplo, a impressao de um email com um pedido de
orcamento e utilizada para fazer anotacoes dos precos de cada produto e, assim, calcular o valor
do orcamento. A figura 3.5 apresenta a modelacao em Tropos da pilha de documentos.
O correio electronico e utilizado para simular uma pilha de mensagens em formato
electronico. No caso de estudo existem dois tipos de anotacoes que se podem aplicar a uma
mensagem: cores e editar o assunto incluindo um numero de referencia. Esse numero refere a
23
Vendedor
Pilha de
Documentos
Gerir
documentos
Documentos
guardados
+
Inserir
documentos
Separar
documentos em
várias pilhas
Reorganizar
documentos
Mantida informação necessária
para completar tarefas
uUtilidade
u
Retirar
documentos
Dispor pilha numa
localização espacial
em particular
Assegurada
utilidade da
informação
Não esquecer de
tarefas por realizar
u
u
u
Existência
aumentada
Reorganização
Processo de
categorização
informal
++
u
Limpar
pilha
Separar documentos
segundo critério
prioridade
Separar documentos
segundo critério conta
cliente
Reorganizar documentos
segundo critério prioridade
Reorganizar documentos
segundo critério conta cliente
Anotar documento com
informação extra
u
u
Anotar documento com
número de referência
Referência
Siebel
Figura 3.5: Modelo relacional estrategico referente a pilha de documentos.
24
uma entidade mantida nos sistemas prescritos. Por outro lado o sistema de correio de electronico
aproxima-se a um diario, dado que a maioria da comunicacao passa por esse sistema. No caso
de estudo surgem varios utilizadores a enviarem mensagens para a propria conta de email para
manterem um registo da sua actividade. A figura 3.6 apresenta a modelacao em Tropos do
correio electronico.
Vendedor
Correio
Electrónico
Gerir
mensagens
Mantida Informação
Mantida informação necessária
para completar tarefas
u
Não esquecer de
tarefas por realizar
u
u u
Tarefas pendentes
registadas
Manter na caixa de entrada
mensagens representativas de
tarefas pendentes
Associar cor Desassociar corAcrescentar número de
referência ao assunto
Actividades diárias
registadas
Enviar
mensagensReorganização
Separar
mensagens em
várias pastas
Limpar caixa
de entradaReferência
Siebel
u
u
Figura 3.6: Modelo relacional estrategico referente ao correio electronico.
3.2.3 Running Log e Folha de Calculo
O running log em formato de folha de papel e utilizado para manter informacao temporaria.
Por vezes designado tambem por folha de rascunho, a sua utilizacao segue uma estrutura ad-hoc
ou, no limite, nenhuma estrutura de todo. Por exemplo, sao anotados referencias e informacao
de outros sistemas como codigos de clientes ou de produtos e informacao recebida por telefone.
A sua utilizacao deve-se a dois aspectos. Em primeiro, permite um acesso a informacao mais
rapido do que os sistemas que sao fonte da informacao. Torna-se relevante quando a informacao
e proveniente de varias fontes ou encontra-se junto de muitos detalhes irrelevantes que dificultam
a leitura. Em segundo, a informacao e guardada durante a realizacao da tarefa. Se o utilizador
usasse apenas as suas proprias capacidades de memoria sem qualquer artefacto de suporte, apesar
do acesso a informacao fosse mais rapido a propriedade de durabilidade nao estaria assegurada.
A figura 3.7 apresenta a modelacao em Tropos do running log.
25
Vendedor
Running Log
Guardar
Informação
Informação guardada
temporariamente
Mantida informação necessária
para completar tarefas
u
Guardar itens
u
u
Estrutura ad-hoc ou
sem estrutura de todo
Utilização
rápida e fácil
Acesso de
escrita rápido
Acesso de
leitura rápido
+
Facilidade de
Utilização
u
Acesso rápido
à informação
u
Guardar Número
Telefone
Guardar Número
Referência
Siebel
Número
Telefone
Número
Referência
u
u
u
u
Figura 3.7: Modelo relacional estrategico referente ao running log.
26
A folha de calculo modelada em Tropos na figura 3.8 e um running log digital cuja informacao
encontra-se organizada e estruturada segundo o paradigma tabela.
Vendedor
Informação
Visualizada
Folha de
Cálculo
Organizar e
Guardar
Informação
Informação
mantida
+
+Guardar
Itens
Definir
colunas/linhas
Definir
Operações
Formatar
Células
Visualizar Itens
numa Tabela
Personalização
Mantida informação necessária
para completar tarefas
u
Facilidade de
Visualização
u
Estruturar
Folha de
Cálculo
Tarefas complexas
coordenadas
Facilidade de
Utilização
u
Utilidade
u
u
Representação das
actividades de uma
tarefa complexa
u
u
Figura 3.8: Modelo relacional estrategico referente a folha de calculo.
3.3 Cenario
Na descricao deste cenario e apresentado um departamento de vendas de uma empresa
fictıcia de telecomunicacoes designada por M-TEL. O cenario e baseado no caso de estudo refe-
rido na seccao 3.2. O departamento tem como objectivo prescrito a realizacao de vendas cujo
valor mensal total por cliente e inferior a um determinado limite. O departamento opera exclu-
sivamente a partir dos escritorios da empresa e vende perifericos e servicos de telecomunicacoes.
A gestao de topo determinou que este departamento usa o Siebel para registar e manter essen-
cialmente quatro tipos de entidades: vendas, oportunidades de venda, tarefas e contactos de
clientes.
O Duarte e um colaborador do departamento e possui, do ponto de vista de utilizador,
o conhecimento necessario para usar o Siebel. O cliente Supermercados, Lda. tem vindo a
aumentar os seus gastos em perifericos e servicos de telecomunicacoes. Apesar de continuar
a realizar pedidos junto do Duarte, ele sabe que o cliente ja nao deveria ser tratado pelo seu
27
departamento porque, caso as normas tivessem sido respeitadas, as ultimas duas encomendas
teriam ultrapassado o limite imposto ao departamento. O Duarte adiou a facturacao da ultima
encomenda para o mes seguinte de modo a ultrapassar as normas prescritas. Caso contrario o
cliente teria passado a interagir com um gestor dedicado atraves de um outro departamento com
essa funcao.
De seguida sao descritas tres situacoes: relembrar de tarefas, priorizar tarefas e relembrar
de informacao.
3.3.1 Situacao A – relembrar de tarefas
O Duarte recebe um email do cliente Supermercados, Lda. com pedido de orcamento para
um conjunto de perifericos e que deve enviar ainda nesse mesmo dia. Como nao e possıvel
efectuar essa tarefa no momento, necessita de um artifıcio de modo a relembra-lo da tarefa
pendente. Antecipadamente sabe que aquele orcamento vai atingir o tal limite imposto ao
departamento e por isso evita usar o sistema prescrito para registar a tarefa pendente. Por
isso coloca o conteudo do email no cimo da pilha que contem outros emails e documentos com
pedidos por tratar.
Entretanto recebe um telefonema do mesmo cliente a perguntar acerca da encomenda rea-
lizada na semana passada. Como o Duarte precisa de averiguar o porque do atraso necessita de
perguntar telefonicamente ao departamento de aprovisionamento. O Duarte escreve num post-it
a tarefa e coloca na sua area de trabalho de modo visıvel com o objectivo de nao esquecer. Mais
uma vez nao usa o sistema prescrito porque esta encomenda nao foi formalmente fechada, ou
seja, ainda nao foi facturada.
Ao terminar o assunto anterior o Duarte elimina o post-it referente a essa mesma tarefa.
Adicionalmente, as paginas necessarias para completar o trabalho ja tinham sido retirados da
pilha de documentos com pedidos por tratar. De seguida visualiza na sua area de trabalho a
existencia de um conjunto de post-its com tarefas por realizar. Ao lado surge uma pilha com
documentos e emails com pedidos. O Duarte precisa de saber qual a tarefa com maior prioridade.
28
3.3.2 Situacao B – priorizar tarefas
Duarte possui varios pedidos por cumprir distribuıdos pelos post-its e pilha que surgem na
area de trabalho. Precisa de decidir rapidamente quais sao os proximos pedidos a cumprir. Ele
sabe que existem pedidos que devem ser tratados ainda nesse mesmo dia dada a importancia do
cliente que os fizeram.
Decide posicionar os post-its de acordo com a ordem de prioridade — no topo os mais
prioritarios. Por outro lado, retira da pilha documento que, por acumularem-se mesmo apos
as respectivas tarefas terem sido concluıdas, ja nao sao importantes e podem ser arquivados ou
eliminados consoante a necessidade. A pilha e, assim, renovada e limpa de folhas desnecessarias
ao resto do trabalho semanal. Surgem no topo documentos relacionados com tarefas mais
prioritarias.
Ao seleccionar o primeiro post-it que surge na area de trabalho, o Duarte inicia uma nova
tarefa agora no contexto do cliente Supermercados, Lda. Trata-se dos pedidos previamente
efectuados e descritos em 3.3.1.
3.3.3 Situacao C – relembrar de informacao
Duarte precisa de averiguar o porque do atraso na instalacao dos servicos da ultima enco-
menda. Primeiro ele abre o sistema prescrito e procura o numero da encomenda. De seguida
abre o seu dossier no separador com documentos daquele cliente e procura pelos que tem no topo
uma anotacao com o respectivo numero da encomenda. Para alem disso abre no seu computador
uma folha de calculo relacionada com o tema. Com esse conjunto de documentos e artefactos
refresca a sua memoria com o ponto de situacao da ultima vez que empenhou-se neste tema.
Ele verifica que oito em dez servicos nao estavam instalados.
Telefona para o departamento responsavel pela instalacao com o objectivo de compreender
o ponto de situacao actual e o porque do atrasado na instalacao dos servicos que faltavam.
Duarte percebe que falta completar a instalacao de tres servicos estando um deles dependente
da actualizacao da morada de instalacao. Assim, actualiza a folha de calculo com o novo ponto
de situacao colocando a verde os servicos instalados, a amarelo os parcialmente instalados e a
vermelho o servico que se encontra dependente da recepcao por parte do cliente da nova morada.
Duarte comunica o ponto de situacao actual atraves do numero de telefone que foi apontado
29
no post-it quando recebeu a chamada. Pede a nova morada de instalacao e escreve numa folha
solta. Apos desligar passa essa informacao para o sistema prescrito e envia um email a indicar
tal facto ao departamento responsavel pela instalacao. Duarte elimina o post-it e fecha a folha
de calculo guardando-a. De seguida passa para um outro tema.
Duarte retira o documento que esta no topo da pilha. Trata-se do email impresso com um
pedido de encomenda por parte do mesmo cliente. Nesse documento e junto de cada periferico
referenciado anota os respectivos precos. Escreve um novo email de resposta utilizando como
base as anotacoes feitas no documento. Para alem disso, cria no sistema prescrito uma nova
oportunidade de venda descrevendo de um modo geral a oportunidade que teve como base o
orcamento pedido.
Duarte sabe que nao pode descrever a oportunidade de venda com muito detalhe pois
segundo as normas prescritas este cliente deveria ter sido redireccionado para outro departamento
com competencias para lidar com vendas e oportunidades de vendas daquela dimensao. Por
outro lado, nao pode eliminar o documento em papel pois precisa de manter essa informacao
caso o cliente realize a encomenda. Por conseguinte anota o documento com o numero de
oportunidade e o numero de cliente que surgem no sistema prescrito criando assim uma ligacao
nao tecnologica entre o artefacto fısico e as entidades digitais — cliente e oportunidade de venda
— no sistema prescrito. Coloca o documento num dossier com outros documentos organizados
por conta cliente.
3.4 Sumario
Este capıtulo apresenta o principal problema desta dissertacao: criar uma plataforma para
servir de base para o desenvolvimento de um sistema, pelos proprios utilizadores finais, capaz de
satisfazer as suas necessidades emergentes. Por isso mesmo e necessario realizar um levantamento
das caracterısticas dos sistemas que surgem no seio da organizacao, usando para tal tecnicas
de levantamento de requisitos sobre um caso de estudo que descreve a emergencia ocorrida
numa organizacao. Foram levantadas as caracterısticas e modelados em Tropos os artefactos
emergentes. Um cenario de utilizacao e descrito em tres desafios principais alinhado com o
caso de estudo. Tendo como base este capıtulo, um modelo de implementacao e desenvolvido,
implementado e validado ao longo dos proximos capıtulos.
30
4Solu�c~ao
Neste capıtulo, e apresentada uma solucao que cobre todos os problemas e qualidades levan-
tados durante a descricao do caso de estudo e, em particular, do cenario. Primeiro, apresenta-se
uma vista geral da solucao e serve de base para as proximas etapas. Em segundo, formaliza-se
os atributos de qualidade pretendidos da nova plataforma emergente. Por fim, descreve-se a
arquitectura de software que serve de base para o desenho e implementacao da plataforma.
4.1 Solucao
Os utilizadores fazem uso da plataforma emergente e do sistema prescrito para ultrapassarem
os desafios e atingirem os seus objectivos prescritos e emergentes. Concluindo da analise do
caso de estudo e no contexto da emergencia, os utilizadores criam nos sistemas prescritos uma
representacao do seu trabalho que cumpra as regras prescritas, mesmo que essa observancia seja
apenas aparente. Por outro lado, os utilizadores fazem uso de artefactos e sistemas emergentes
para os auxiliarem em tarefas e desafios que nao estao inteiramente alinhadas com o trabalho
imposto pelas chefias. Nesses sistemas emergentes, nao existe uma preocupacao em manter a
representacao do trabalho de forma prescrita porque esses sistemas sao ja de si nao prescritos e
nao representam formalmente para a organizacao o trabalho realizado pelo colaborador.
Tendo em conta essa analise do problema, tres aspectos elevaram-se: artefactos, dados e
processos de importacao/exportacao. A figura 4.1 mostra como esses aspectos se relacionam
entre si e onde surgem os sistemas externos.
O conceito artefactos abrange o modelo de interaccao com os dados e as praticas de trabalho
ajustadas as necessidades dos utilizadores. O conceito dados compreende os topicos relacionados
com a informacao emergente e prescrita e as operacoes efectuadas sobre a mesma. Por um lado,
Figura 4.1: Vista geral da solucao.
Estratégia Relação entre datas
Importação Exportação
Não
act
ual
izar
Act
ual
izar
Act
ual
izar
inal
tera
do
s d
esd
e ú
ltim
a tr
ansf
erên
cia
Act
ual
izar
inal
tera
do
s d
esd
e ú
ltim
a ex
po
rtaç
ão
Tud
o
Alt
erad
os
des
de
últ
ima
exp
ort
ação
Alt
erad
os
des
de
últ
ima
tran
sfer
ênci
a
Inal
tera
do
s d
esd
e ú
ltim
a
exp
ort
ação
Inal
tera
do
s d
esd
e ú
ltim
a tr
ansf
erên
cia
mod ≤ imp & mod ≤ exp × × × × × × imp ≤ mod ≤ exp × × × × × × exp ≤ mod ≤ imp × × × ×
×
Imp ≤ mod & exp ≤ mod × × × ×
Sem objecto × ×
Tabela 4.1: Estrategias para seleccao de dados sujeito a importacao e exportacao.
32
os artefactos usam esses dados e representam-nos num formato especıfico a cada artefacto. Por
outro lado os processos de importacao/exportacao permitem replicar internamente as entidades
que existem nos sistemas externos e externamente as entidades que foram criadas na plataforma
emergente. Essa transferencia de informacao e efectuada atraves dos conectores que comportam
diferentes tecnologias de integracao.
Em relacao aos tipos de dados e importante referir que existe um requisito importante
— a rastreabilidade. Ou seja, os dados importados devem manter a sua entidade de modo
que em posteriores exportacoes seja possıvel identificar o dado como aquele que foi importado
anteriormente mesmo que os seus valores tenham sido mudados. Por isso, os valores podem variar
mas a sua entidade mantem-se. Consequentemente sao necessarios dois tipos de atributos: os
atributos tipificados e os atributos de identidade. Sao os atributos de identidade que conferem
caracterısticas de rastreabilidade.
Adicionalmente, o tipo de dados possui tres atributos que correspondem aos momentos da
ultima modificacao, importacao e exportacao. Ao saber esses tres momentos e possıvel escolher
os dados que se pretende exportar ou actualizar se ja existirem na plataforma. A tabela 4.1
indica o estado relativo entre as datas necessario para que o dado seja sujeito de importacao ou
exportacao consoante a estrategia escolhida.
4.2 Atributos de Qualidade
Entre os objectivos da plataforma emergente destaca-se a sua capacidade de trabalhar com
dados de diferentes origens/sistemas externos e que estes sejam trabalhados/utilizados de acordo
com as praticas de trabalho identificadas. Adicionalmente, a confidencialidade de dados e arte-
factos emergentes deve ser salvaguardada. Eis porque surgem os quatro atributos de qualidade:
(i) facilidade de modificacao, (ii) interoperabilidade e (iii) facilidade de utilizacao, (iv) seguranca.
Em detalhe:
• Efectuar alteracoes em tempo de execucao aos artefactos, dados e tipo de dados (incluindo
a eliminacao e adicao desses conceitos) e a configuracao em tempo de execucao da fonte
de dados (mecanismos de importacao e exportacao incluindo os conectores);
• Efectuar alteracoes aos tipos de artefactos e conectores durante a implementacao e ser
possıvel incorpora-las facilmente;
33
• Autorizar apenas alguns colaboradores a acederem a artefactos e dados emergentes proi-
bindo o acesso por parte de chefias ou de outros utilizadores sem acesso determinado pelo
autor do artefacto/dado em questao;
• Carregar dados de diferentes fontes incluindo sistemas prescritos com os quais e possıvel
interoperar na actualizacao e realizacao de operacoes sobre os dados;
• Disponibilizar as mesmas operacoes e aproximar o modelo conceptual dos artefactos im-
plementados a dos respectivos formatos fısicos minimizando, assim, o tempo e dificuldade
de adaptacao aos artefactos;
• Disponibilizar operacoes dependentes do tipo de dados sobre os quais sao aplicadas.
4.3 Arquitectura de Software
A Arquitectura de Software de um programa ou sistema computacional e a estrutura ou
estruturas do sistema que abrangem os elementos de software, as suas propriedades externamente
visıveis e as relacoes entre si (Bass et al. 2003).
Esta seccao descreve as vistas relevantes que constituem a arquitectura proposta. Em de-
talhe as tacticas, isto e, as decisoes para satisfazer os atributos de qualidade, sao descritas
resultando numa arquitectura justificada. Assim, as tacticas permitem alinhar tecnicamente a
arquitectura com os atributos de qualidade e respectivos cenarios descritos no capıtulo anterior.
4.3.1 Tipo de Vista Modulo
Este tipo de vistas documenta a estrutura modular do sistema — as unidades de imple-
mentacao e as relacoes entre si (Clements et al. 2002). As unidades de implementacao, tambem
conhecidas por modulos, fornecem um conjunto coerente de funcionalidades com interfaces bem
definidas que escondem parcial ou totalmente estruturas de dados e algoritmos. De modo a de-
finir em pormenor o tipo de vista modulo sao usados tres estilos arquitecturais: decomposicao,
utilizacao e generalizacao.
34
4.3.1.1 Estilo Decomposicao
O estilo decomposicao e usado para demonstrar o modo como as responsabilidades sao
particionadas em modulos e sub-modulos. Esta seccao e acompanhada pelo anexo A onde e
descrito passo-a-passo os cenarios e tacticas usadas durante a decomposicao de modulos. Como
ilustrado na figura 4.2, a plataforma emergente divide-se em tres modulos:
• Modulo Artefactos – Encapsula os conceitos relacionados com praticas de trabalho e
artefactos;
• Modulo Dados – Encapsula os conceitos relacionados com dados prescritos e emergentes
e outros meta-dados;
• Modulo Fonte de Dados – Encapsula os conceitos relacionados com transferencia de
dados.
Figura 4.2: Decomposicao num nıvel.
O modulo Artefactos encapsula todos os conceitos relacionados com praticas de trabalho
onde existe interaccao com dados emergentes e prescritos. Cada artefacto disponibiliza uma
interface grafica possibilitando os utilizadores interagirem com os dados atraves do modelo de
interaccao que aquele artefacto faculta. Os artefactos existem por si independentemente dos
dados, alias os mesmos dados podem surgir em diferentes artefactos. Portanto os detalhes dos
tipos de dados sao escondidos de modo a prevenir efeitos em cascata quando novos tipos de
dados ou novos artefactos surgem.
O modulo Dados encapsula os conceitos relacionados com dados prescritos e emergentes e
outros meta-dados necessarios para identificar inequivocamente a entidade ou a hora da ultima
alteracao, importacao e exportacao. Como apresentado na figura 4.3 este modulo decompoe-se
em tres sub-modulos: operacoes sobre os dados, tipo de dados e configuracao do tipo de dados.
35
Figura 4.3: Decomposicao do modulo Dados.
O modulo Operacoes encapsula os conceitos relacionados com a escrita e leitura de dados a
partir dos artefactos. Para alem disso, surge o sub-modulo Instanciacao de Dados responsavel
pela criacao e preenchimento da estrutura de dados abstraindo, assim, uma interface comum
que e utilizada pelo processo de importacao.
O modulo Tipo de Dados encapsula os conceitos relacionados com as estruturas que com-
portam os dados. Os tipos de dados sao constituıdos por (i) atributos tipificados que correspon-
dem as propriedades da entidade, (ii) atributos de identidade que correspondem a identificacao
inequıvoca da entidade e (iii) meta-dados relacionados com a hora da ultima alteracao, im-
portacao e exportacao.
O modulo Configuracao Tipo de Dados encapsula os detalhes da configuracao e definicao
das estruturas do modulo tipo de dados. A configuracao de novos tipos de dados ocorre em
tempo de execucao. Este modulo e igualmente responsavel pela redefinicao de tipo de dados e
pelas alteracoes sofridas pelos dados assentes na definicao anterior.
O modulo Fonte de Dados encapsula os conceitos relacionados com transferencia de dados
entre os sistemas externos e a plataforma emergente. O modulo assegura a coerencia semantica
pois e o modulo responsavel por todas as funcionalidades que interagem com dados externos, isto
e, oriundos de sistemas prescritos. Tal como apresentado na figura 4.4 esse modulo decompoe-se
em tres sub-modulos: configuracao fonte de dados, transferencia de informacao e conector.
O Modulo Configuracao Fonte de Dados encapsula os detalhes de configuracao do mecanismo
de importacao. Apesar dos atributos de configuracao do processo de importacao e exportacao
serem estaveis, a configuracao dos conectores e dependente de cada um.
36
Figura 4.4: Decomposicao do modulo Fonte de Dados.
O Modulo Transferencia de Informacao encapsula os conceitos relacionados com o pro-
cesso de importacao e exportacao de dados. Este modulo e decomposto em tres sub-modulos:
importacao, exportacao e comum. Este ultimo sub-modulo encapsula funcionalidades que sao
comuns no processo de importacao e exportacao. A primeira funcionalidade comum e a rastrea-
bilidade. Esta funcionalidade permite assegurar a identidade dos dados no sistema externo e na
plataforma emergente, isto e, dado o conjunto de atributos que identifica inequivocamente cada
entidade e possıvel manter a identidade dos dados independentemente do sistema, ora no sis-
tema externo, ora na plataforma emergente. A segunda funcionalidade comum e o mapeamento.
O mapeamento indica qual o valor importado que corresponde a cada atributo de um tipo de
dado ou, do ponto de vista da exportacao, qual a ordem de atributos a formar para exportar
os valores para o sistema externo. Os modulos importacao e exportacao tambem decompoe-se
em sub-modulos. No caso do modulo de importacao decompoe-se em modulo de tipificacao
de valores e modulo para o carregamento dos valores na estrutura de dados interna. No caso
do modulo de exportacao decompoe-se em modulo para colectar os dados segundo regras de
exportacao escolhida e modulo de transformacao de dados tipificados em valores prontos para
serem entregues ao conector.
O Modulo Conector encapsula os conceitos relacionados com a tecnologia de ligacao aos
sistemas externos. Este modulo encobre qualquer dependencia que possa existir com os sistemas
37
externos, nomeadamente o modo de interoperabilidade. O modulo decompoe-se em dois sub-
modulos que correspondem a modos de integracao diferentes. O primeiro caso corresponde na
integracao por ficheiros CSV, ou seja, a troca de dados entre o sistema externo e a plataforma
emergente e realizada atraves de um ficheiro. O segundo caso corresponde na integracao por
web services. O modulo conector separa-se do modulo de transferencia de informacao porque
e necessario esconder do processo de importacao os detalhes na obtencao de dados externos.
Ainda de referir que cada tipo conector tem um sub-modulo de configuracao responsavel por
declarar as configuracoes necessarias para o conector funcionar.
4.3.1.2 Estilo Utilizacao
O estilo utilizacao indica os modulos que devem existir para a correcta execucao de de-
terminada parte do sistema. Com esse objectivo, existe a relacao utilizacao que estabelece a
propriedade correccao entre modulos, isto e, um modulo usa outro se a correccao do primeiro esta
dependente do correcto funcionamento do segundo. Dada a natureza da plataforma emergente,
existem dois modulos principais que interagem com o modulo dados, tal como apresentado na
figura 4.5. Por um lado, o modulo fonte de dados importa e exporta dados, ou seja, transfere
dados dos sistemas externos para a plataforma emergente e vice-versa. Por outro lado, o modulo
artefactos interage com os dados internos. De seguida a vista e explicada em detalhe.
O bom funcionamento do modulo fonte de dados depende de tres conjuntos de modulos: (i)
importacao e exportacao, (ii) conectores e (iii) configuracao. Antes do processo de transferencia
de dados e necessario configura-lo. Essa configuracao e composta por duas partes: a importacao
e exportacao cujos modelos de configuracao sao estaveis e o conector utilizado cujo modelo de
configuracao depende do mesmo. Por isso, o modulo configuracao fonte de dados depende dos
modulos de configuracao de cada conector. Configurado, o modulo fonte de dados usa o modulo
conector para receber os dados externos e usa o modulo importacao para colocar esses dados
nas respectivas estruturas internas. No caso da exportacao ocorre o mesmo no sentido inverso.
Os modulos importacao, exportacao e cada conector usam outros modulos que correspondem
aos passos bem definidos de um processo de transferencia de dados. Esses modulos sao explicados
em mais detalhe na seccao de implementacao 5.2.3.
Anteriormente foi apresentado que alguns modulos que decompoe o modulo fonte de dados —
cujos ındices comecam por 3 — usam os modulos que decompoem o modulo dados — cujos ındices
38
Figura 4.5: Estilo utilizacao do tipo de vista modulo.
comecam por 2 —, mas nunca se concretizou quais sao os modulos. O modulo mapeamento e
responsavel por mapear cada valor numa propriedade do tipo de dados interno. Neste sentido
o modulo mapeamento usa o modulo tipo de dados pois precisa de conhecer quais sao os tipos
existentes e as propriedades de cada um. Por outro lado, o modulo carregamento do processo de
importacao e o modulo colecta de dados do processo de exportacao usam o modulo operacoes. O
modulo operacoes encapsula as operacoes basicas sobre dados, nomeadamente a criacao, leitura,
alteracao e eliminacao. E aqui que surge o ponto de interaccao entre os dados e os processos de
importacao/exportacao.
Por fim, o modulo artefactos usa dois modulos: (i) o modulo tipo de dados de modo a
conhecer os tipos de dados e as propriedades de cada um e (ii) o modulo operacoes de modo a
interagir com os dados.
4.3.1.3 Estilo Generalizacao
O estilo generalizacao surge quando se pretende suportar extensao e evolucao de arquitectu-
ras e elementos individuais. Esta necessidade de suportar a extensao e evolucao surge de forma
evidente em duas partes da arquitectura. Primeiro, a plataforma emergente deve suportar a
39
importacao de dados de tal modo que a origem e formato desses dados nao seja limitativa para
essa importacao. Consequentemente a extensao de novos conectores torna-se, assim, necessaria.
Segundo, a plataforma emergente deve suportar formas de interaccao entre o utilizador e dados.
Essas interaccoes devem estar alinhadas com as necessidades do utilizador e ao longo do tempo
novas formas de interaccao surgem. Assim, torna-se relevante a extensao de novos artefactos
com essas novas formas de interaccao.
A figura 4.6 apresenta, do ponto de vista da generalizacao, os modulos referentes as funciona-
lidades de conectores. Na vista de utilizacao pode-se confirmar que os modulos de transferencia
de informacao — importacao e exportacao — utilizam o modulo conector. Adicionalmente exis-
tem varios conectores em que cada um se “liga” a fonte de dados com modos e tecnologias
diferentes. Tendo em conta estes dois aspectos e importante generalizar o modulo conector e
possibilitar o surgimento e evolucao de conectores sem consequencias semanticas e sintacticas aos
modulos de transferencia de dados. Novos conectores podem ser adicionados desde que respei-
tam a interface geral dos conectores permitindo que os mecanismos de importacao e exportacao
funcionem independentemente do conector utilizado. Por outro lado surgem generalizacoes de
conectores que assentam na mesma tecnologia de conexao. Neste caso a tecnologia web ser-
vice e utilizada em dois componentes. Diferentes sistemas externos disponibilizam contratos de
interaccao distintos apesar da tecnologia de web services manter-se.
Figura 4.6: Generalizacao dos Conectores.
40
A figura 4.7 apresenta os artefactos ao estilo de generalizacao. Os artefactos herdam uma
interface que permite de forma generica instanciar qualquer artefacto implementado. Isto per-
mite a aplicacao cliente — neste caso a wiki — instanciar o artefacto em questao. Surgem dois
tipos de artefacto — artefacto atomico e artefacto composto. A diferenca reside na existencia
de um corpo, nos artefactos compostos, que pode ser composto por texto e/ou artefactos.
Figura 4.7: Generalizacao dos Artefactos.
4.3.2 Tipo de Vista Componente e Conector
O tipo de vista componente e conector define modelos que consistem em elementos com
presenca em tempo de execucao e padroes de interaccao entre esses elementos (Clements et al.
2002). Deste modo o tipo de vista oferece uma imagem das entidades de execucao e potenciais
interaccoes entre si.
No estilo repositorio (shared-data), o padrao de interaccao e dominado pela troca de dados
persistentes. Os dados sao consumidos e produzidos por varios componentes e existe pelo menos
um repositorio que retem os dados de forma persistente.
41
Um requisito fundamental na plataforma emergente e a sua capacidade de transferir in-
formacao dos sistemas externos para a plataforma e vice-versa. Adicionalmente, a obtencao
de dados e da responsabilidade dos componentes consumidores — e nao, da base de dados de
informar os consumidores da existencia de dados. Logo, o estilo repositorio surge com evidencia
na arquitectura da plataforma emergente. A figura 4.8 concretiza esse estilo.
Figura 4.8: Vista Componente e Conector — Repositorio de Dados.
Por um lado, surgem componentes que sao executados num cliente browser. Esses compo-
nentes comunicam com outros, que se executam em servidores, atraves de RPC sobre HTTP.
O componente artefacto consome e produz dados de acordo com as operacoes realizadas pelos
utilizadores. O componente de configuracao produz o objecto de configuracao e comunica com
o motor de importacao e exportacao de forma a configura-lo para a sua execucao.
Por outro lado, surgem componentes que sao executados em servidores. A este nıvel existem
quatro componentes. Um dos componentes sao os sistemas externos que mantem de forma
persistente dados maioritariamente prescritos. A transferencia de dados entre estes sistemas e a
plataforma e concretizada pelo componente motor de importacao e exportacao. Este componente
comunica com os sistemas externos atraves de ficheiros (comunicacao baseada em ficheiros) e
de web services. Se de um lado estao os sistemas externos na outra ponta tem de estar um
repositorio que suporte a persistencia na plataforma de dados maioritariamente emergentes.
Esse repositorio, tambem apresentado na figura, guarda os dados segundo a definicao de tipos
declarada pelos utilizadores e pode ser concretizado por um motor de base de dados. Contudo,
tanto os artefactos como o motor de importacao e exportacao nao comunicam directamente com
o repositorio. Existe um componente designado por dados que comporta a API de domınio
escondendo particularidades do domınio e da comunicacao realizada por SQL com o repositorio.
O componente motor e componente artefacto comunicam com esta API atraves de RPC.
42
4.4 Sumario
A solucao e a arquitectura de software foram apresentados neste capıtulo. Artefactos, dados
e importacao/exportacao foram os principais conceitos apontados desde a visao geral da solucao
e surgiram nos atributos de qualidade e posteriormente na arquitectura de software. Na arqui-
tectura de software foram apresentados os estilos de decomposicao, utilizacao e generalizacao do
tipo de vista modulo onde foram identificados os modulos e as suas responsabilidades. O facto
da necessidade da plataforma emergente comunicar com sistemas externos e da plataforma se
tratar de uma aplicacao web levou a apresentacao do tipo de vista componente e conector de
forma a explicar a comunicacao entre os componentes e de que forma e realizada. Em resumo,
a tabela 4.2 relaciona os atributos de qualidade com os modulos e componentes arquitecturais.
Atributos de Qualidade Módulos e Componentes Arquitecturais
Facilidade Modificação Artefactos (modificar estado interno dos artefactos)
Módulo: Artefactos (estilo decomposição) Componente: Artefacto
Facilidade Modificação Dados (adicionar, modificar e eliminar informação)
Módulo: Dados Componente: Repositório
Facilidade Modificação Tipo de Dados (definir ou redefinir tipos de dados)
Módulos: Tipo de Dados e Configuração Tipo de Dados
Facilidade Modificação Conectores (desenvolvimento de novos conectores)
Módulos: Conector (estilo decomposição e generalização)
Interoperabilidade com Fontes Externas de Dados
Módulos: Importação, Exportação, Conector e Configuração Fonte de Dados (estilo decomposição) Fonte de Dados (estilo utilização) Componentes: Motor Importação/Exportação e Configuração Importação/Exportação
Facilidade Utilização Artefactos Módulo: Artefactos (estilo generalização)
Facilidade Utilização Dados (operações sobre dados)
Módulos: Operações e Instanciação de Dados Componentes: Dados (API Domínio)
Tabela 4.2: Relacao entre os atributos de qualidade e os modulos e componentes arquitecturais.
43
44
5Implementa�c~ao
Neste capıtulo, um prototipo e desenvolvido de acordo com o modelo de implementacao e
a arquitectura de software descritos no capıtulo anterior. Primeiro, apresenta-se as principais
tecnologias usadas no desenvolvimento, em particular a wiki que e objecto de extensao. Essa
extensao aumenta o poder da wiki no suporte aos aspectos emergentes desenvolvendo assim
uma plataforma emergente. Finalmente descreve-se o resultado da implementacao, nomeada-
mente os artefactos implementadas, o modo como os dados e suas estruturas sao suportadas e
a transferencia de dados entre a plataforma e os sistemas externos.
5.1 Tecnologia
Esta seccao apresenta as tecnologias usadas no desenvolvimento do prototipo. Para alem
da base de dados MySQL e o contentor de servlets usado — o Jetty —, duas outras tecnologias
sao relevantes mencionar. Primeiro, a XWiki que e objecto de extensao no desenvolvimento
do prototipo e, segundo, o Google Web Toolkit acompanhado pela biblioteca de widgets Smart
GWT.
5.1.1 XWiki
A XWiki autotitula-se como uma wiki de segunda geracao, ou seja, uma plataforma para
o desenvolvimento de aplicacoes web colaborativas usando o paradigma wiki. A motivacao que
levou ao desenvolvimento da XWiki esta alinhada com o objectivo inicial desta dissertacao. O
facto de muitas aplicacoes ad hoc serem desenvolvidas usando ferramentas, muitas das vezes
desadequadas, como o Microsoft Excel, serviu de base ao desenvolvimento de uma plataforma
que suportasse aplicacoes que, devido a sua natureza, demoram tempo e alavancam custos
onerosos num processo de desenvolvimento standard.
Para alem das funcionalidades que qualquer wiki oferece, a XWiki apresenta funcionalidades
cuja existencia e importante numa plataforma emergente. Destacam-se quatro aspectos funcio-
nais: (i) editor grafico WYSIWYG, (ii) processo de importacao de documentos office, (iii) gestao
de objectos, classes e propriedades e (iv) caracterıstica programavel da wiki em geral.
O editor grafico WYSIWYG permite alterar o conteudo de um documento atraves de um
editor grafico e obtendo de imediato o resultado final. Torna-se relevante pois o conteudo pode
incluir artefactos cuja edicao e suportada de igual modo. A figura 5.1 apresenta o menu do editor
grafico. O menu permite inserir os artefactos atraves do botao macros — que alias e o conceito
usado na XWiki para artefacto. Junto surgem botoes para inserir cada um dos artefactos mais
comuns. Este editor e objecto de extensao ao incluir mais botoes para facilitar a insercao de
artefactos desenvolvidos no ambito da dissertacao.
Figura 5.1: Menu do editor grafico.
O processo de importacao de documentos office permite converter o conteudo de documentos,
folhas de calculo e apresentacoes em paginas wiki. Os utilizadores evitam a curva de aprendiza-
gem associada a sintaxe wiki e torna-se possıvel integrar suavemente na plataforma emergente
as praticas de trabalho que anteriormente interagiam com as suites de produtividade enquanto
sistemas emergentes.
A XWiki permite ao utilizador gerir os conceitos objectos, classes e propriedades que sao
similares aos da programacao com objectos. Esta funcionalidade torna-se relevante pois a inte-
raccao e ciclo de vida destes conceitos esta orientada ao utilizador, ou seja, e possıvel manipula-
los atraves da interface de apresentacao e surgem no contexto de uma pagina wiki. Ao oferecer
conceitos onde e possıvel criar um modelo de dados permite desenvolver sistemas emergentes
mais complexos com necessidades de persistencia de informacao.
O ultimo aspecto a mencionar e a vertente programavel que surge na XWiki num modo
geral. Permite criar aplicacoes basicas ou complexas na propria camada de apresentacao sem
necessidade de compilar e instalar componentes desenvolvidas. Por outras palavras, pode-se usar
sintaxes de scripting em conjunto com sintaxes wiki ou HTML. A XWiki oferece a possibilidade
46
de usar as sintaxes de scripting — velocity e groovy — acompanhadas por uma API que expoe
funcionalidades como a manipulacao de objectos e classes.
Apos apresentar aspectos funcionais, sao apresentados quatro aspectos arquitecturais da
XWiki.
O primeiro aspecto arquitectural potencia a extensibilidade da XWiki. A sua arquitectura e
baseada no desenvolvimento baseado em modulos1. Existe um gestor de modulos que instancia os
modulos e gere as dependencias entre modulos que sao satisfeitas apenas em tempo de execucao.
O gestor escolhe a implementacao de cada modulo para satisfazer a dependencia de um outro.
Quando se pretende estender a wiki e possıvel registar junto do gestor modulos com novas
funcionalidades e/ou implementacoes que substituem a implementacao por defeito.
O segundo aspecto e relacionado com um modulo especıfico — o modulo de renderizacao. A
figura 5.2 mostra como uma entrada com conceitos wiki sao transformados e renderizados num
formato de saıda. O parser gera um objecto XDOM que representa blocos estruturados dos
conceitos da entrada. A saıda e gerada atraves do renderer que transforma o objecto XDOM
num formato especıfico. Opcionalmente, podem ocorrer transformacoes sobre alguns blocos que
surgem no objecto XDOM. Uma transformada importante e a transformacao de definicoes de
macro em blocos XDOM que possam ser renderizados. Por exemplo, uma macro que insere um
artefacto com determinada configuracao e transformado num bloco HTML que insere a interface
de utilizador do respectivo artefacto.
Figura 5.2: Modelo de renderizacao da XWiki.
1Na literatura, o nome usado para este conceito e componente e nao modulo e surge no contexto da engenhariade software baseada por componentes. Contudo, o conceito componente surge aqui com um significado bastantediferente do conceito com o mesmo nome usado na arquitectura de software. Decidiu-se usar o nome modulo nocorpo da dissertacao para evitar confusoes ao leitor.
47
O terceiro aspecto explica como os pedidos HTTP sao lidados. A figura 5.3 apresenta os
passos durante um pedido HTTP.
Figura 5.3: Modelo de tratamento de pedidos HTTP da XWiki.
O quarto aspecto menciona os modelos de extensao. Tornam-se relevantes porque a XWiki
e objecto de extensao durante o desenvolvimento da plataforma emergente. A wiki pode ser
estendida atraves de:
• Desenvolvimento de scripts em paginas wiki;
• Desenvolvimento de aplicacoes (conjunto de paginas wiki com uma logica aplicacional);
• Desenvolvimento de modulos em JAVA que fornecam conjunto de servicos coerente;
• Desenvolvimento de skins ou estendendo ja existentes;
• Extensao de APIs existentes quando estas fornecem ponto de extensao documentados;
• Extensao e configuracao do editor grafico WYSIWYG.
Em suma a XWiki segue o mesmo princıpio que o desta dissertacao — oferecer uma plata-
forma emergente que permita aos utilizadores criarem facilmente aplicacoes de acordo com as
suas necessidades. Apos mencionar-se o grau de extensibilidade e os quatro aspectos relevantes
desta wiki no contexto dos sistemas emergentes fica estabelecido um ponto de situacao da wiki
e o potencial de extensao para o desenvolvimento de um prototipo em conformidade com os
requisitos levantados no capıtulo anterior.
5.1.2 Google Web Toolkit e Smart GWT
Google Web Toolkit (GWT) e um toolkit de desenvolvimento para a construcao de aplicacoes
web, ou seja, fornece uma biblioteca de widgets e paineis para a construcao de interface graficas
48
web. O seu principal objectivo e permitir o desenvolvimento produtivo de aplicacoes web sem
a necessidade de conhecer javascript, ajax e particularidades de cada browser. APIs e widgets
JAVA sao usados no desenvolvimento que posteriormente sao traduzidos em codigo fonte javas-
cript optimizado para cada um dos browsers mais usados nao precisando, por isso, de qualquer
plugin JRE2. O pacote relacionado com o codigo servidor e compilado e executado na maquina
virtual java.
Em GWT, um widget e uma entidade que abstrai programaticamente um elemento de
interface web oferecendo uma API para controla-lo. Um painel e um widget que se foca no
layout grafico da interface. A biblioteca Smart GWT oferece um conjunto rico de widgets mais
avancados que o proprio GWT, como por exemplo, formularios, tabelas, menus e tabs.
Em suma, o desenvolvimento de aplicacoes web — como a plataforma emergente — consome
bastantes recursos e tempo. Adicionalmente, a plataforma emergente, como aplicacao colabora-
tiva que e, funciona melhor com tecnologia AJAX o que torna o seu desenvolvimento dificultado.
Concluindo, o GWT e a biblioteca widgets Smart GWT sao usados no desenvolvimento da pla-
taforma. Em particular e usada esta tecnologia no editor grafico da XWiki, no artefacto pilha e
na interface grafica da configuracao dos conectores e os processos de importacao e exportacao.
5.2 Implementacao
Apos mencionar as tecnologias mais relevantes, podem ser apresentados os detalhes tecnicos
de implementacao. A seccao divide-se em tres partes: artefactos, dados e a transferencia de
dados. Cada parte esta alinhada com um dos tres modulos resultantes do primeiro nıvel de
decomposicao durante o desenho da arquitectura. Portanto, nesta seccao sao explicados os
detalhes tecnicos e as decisoes de desenho durante a implementacao.
5.2.1 Artefactos
Os artefactos permitem aos utilizadores interagirem e trabalharem na wiki usando mais do
que texto formatado. Estes artefactos aperfeicoam algum aspecto a forma de comunicar ou
trabalhar.
49
Ao nıvel do desenho, os artefactos tem tres partes principais: (i) interface de utilizador, (ii)
macro para instancia-los e (iii) domınio para o seu estado.
A primeira parte engloba a interface de utilizador e o modelo de interaccao que o artefacto
faculta. O modelo de interaccao divide-se em visualizacao e edicao in-line. Consoante o modelo
de interaccao e activado ou desactivado no artefacto funcionalidades de navegacao e/ou edicao.
Como os artefactos correm num browser sao implementados usando exclusivamente HTML e
javascript ou, em alternativa, a tecnologia GWT apresentada anteriormente.
A segunda parte permite instanciar o artefacto dentro de um documento. As macros sao
um conceito usado na arquitectura de renderizacao da XWiki. Usando a sintaxe propria da wiki
pode-se inserir em qualquer documento um bloco de texto que corresponde a uma macro. No
momento da renderizacao cada macro e transformada em HTML e javascript — neste caso, e
injectado o codigo do artefacto e respectiva configuracao.
A terceira parte e um domınio para manter o objecto artefacto. O objecto artefacto e a
interface do artefacto sao desacoplados. Por exemplo, uma entidade pilha existe por si indepen-
dentemente do documento onde esta e visualizada. A entidade pilha pode ser visualizada em
qualquer documento bastando para isso instanciar e configurar a interface para a entidade em
particular. O domınio e mantido pelo modulo dados e nao surge em todos os tipos de artefacto.
Explicado as partes principais, a tabela 5.1 concretiza-as para cada artefacto da plataforma.
Artefacto Interface Utilizador – Funcionalidades
Macros Domínio Visualização Edição in-line
Documento Visualizar conteúdo
Habilitar modo de edição in-line dos artefactos embutidos no documento (Modificação do conteúdo através de
modo de edição normal)
― Conteúdo
(texto e artefactos)
Área de Trabalho
Visualizar artefactos posicionados
Inserir, eliminar e reposicionar artefactos ao arrastar e largar
― Configuração e posição
de cada artefacto
Painel Visualizar e esconder
painéis com artefactos ― ―
Configuração e posição de cada painel
Pilha de Documentos
Visualizar topo da pilha Navegar na pilha do topo para o fundo e vice-versa Clique sobre documento
para visualizá-lo
Inserir, eliminar e reordenar documentos
Nome da macro: • pilha Parâmetros: • página da pilha
• índice da pilha
Lista sequencial de documentos
Post-It Visualizar conteúdo ― Nome da macro: • post-it Parâmetros: • conteúdo a apresentar
―
Referência Visualizar valor do
atributo referenciado Modificar valor do
atributo referenciado
Nome da macro: • referencia Parâmetros: • página do objecto
• índice do objecto • atributo do objecto
Dado e Atributo
Anotação Visualizar, inserir e eliminar anotações do documento
― ― Texto alvo de anotação Conteúdo da anotação
Tag Visualizar, inserir e eliminar
tags do documento ― ― Nome da tag
Tabela 5.1: Aspectos tecnicos e funcionais dos artefactos da plataforma emergente.
50
A figura 5.4 ilustra a area de trabalho da plataforma emergente. Nela surgem post-its, pilha
de documentos e outros conteudos que pertencem a XWiki mas cuja utilidade para suportar a
emergencia nao foi estudada. No lado direito e possıvel deslumbrar tres paineis que estao sempre
visıveis ao longo da navegacao na plataforma.
Figura 5.4: Area de trabalho com post-its, pilhas de documentos e paineis.
5.2.2 Dados
A informacao tem um lugar destacado no desenho da plataforma emergente. Ao contrario
do que ocorre em outros sistemas de informacao, a definicao de novos dados e controlada pelo
utilizador em tempo de execucao — tal como relevado nos atributos de qualidade — e nao pelo
programador durante o desenvolvimento. Deste modo, e necessario definir um meta-modelo
capaz de suportar um modelo de dados construıdo ao longo do tempo durante a execucao da
plataforma emergente.
Dados e o conceito utilizado para referir todos os mecanismos e funcionalidades utilizados
para definir e operar sobre informacao emergente e prescrita. O modelo de domınio da XWiki
possui um meta-modelo que suporta, para alem de outros, dois aspectos fundamentais do ponto
de vista do problema: o suporte na definicao de entidades com atributos, tambem designados por
51
classes, e a relacao entre entidades, tambem conhecida por ligacao. O estado de maturidade do
meta-modelo e as funcionalidades na criacao e definicao de novas entidades atraves de interfaces
de utilizador sao os aspectos fortes que levaram a escolha da XWiki como wiki base.
No que toca a este assunto, elevam-se quatro temas que sao discutidos de seguida. Os quatro
temas estao alinhados com o resultado da decomposicao do modulo dados: (i) tipo de dados,
(ii) interface configuracao tipo de dados, (iii) operacoes sobre dados, (iv) adicao de referencias
para atributos e dados em documentos wiki.
Em relacao ao tipo de dados, a figura 5.5 apresenta o diagrama entidade-relacao do meta-
modelo da XWiki. O conceito dados da plataforma emergente e guardado na entidade BaseOb-
ject e associado a um documento wiki. Apesar da chave primaria ser um identificador numerico,
e possıvel identificar inequivocamente cada dado atraves do respectivo tipo de dados (atributo
classname) e da posicao (atributo number) que ocupa dentro de um documento. Dito de outra
forma, dentro de um documento existe, para cada tipo de dados, um conjunto sequencial de
dados desse tipo. No que se refere aos valores das propriedades, o conceito ISA no diagrama
permite que os valores de cada propriedade sejam tipificados. Um tipo diferenciador neste
meta-modelo e a lista de itens que permite modelar ligacoes entre dados.
Figura 5.5: Diagrama entidade-relacao do meta-modelo.
52
A definicao do tipo de dados e mantido no atributo class xml da entidade XWikiDocument
em formato XML e consequentemente so existe um tipo de dados por documento. Alias, o espaco
de nomes dos tipos e partilhado com o espaco de nomes dos documentos. Uma propriedade
importante deste meta-modelo e a separacao entre a definicao de tipo de dados e a instanciacao
dos dados. Essa desuniao relaxa restricoes que dificultariam a gestao aquando da redefinicao de
tipo de dados. Neste caso e possıvel acrescentar ou retirar atributos ao tipo sem afectar os dados
existentes — apenas ficam inconsistentes com a nova definicao. Apesar de tudo o verificador
apresenta ao utilizador essas inconsistencias dando-lhe o controlo do que pretende fazer com
esses dados inconsistentes.
Explicado o meta-modelo com suporte para a modelacao em tempo de execucao de tipos
de dados e ligacoes entre tipos, e importante que o utilizador possa configurar o domınio de
acordo com as suas necessidades atraves de uma interface grafica. A figura 5.6 apresenta essa
interface onde e possıvel adicionar, remover, reordenar e configurar atributos. O utilizador tem
a responsabilidade de configurar, para alem dos atributos tipificados da entidade ditos normais,
em primeiro os atributos de identidade para que sejam usados nos momentos de importacao e
exportacao de modo a manter a propriedade de rastreabilidade entre as entidades dos sistemas
externos e as da plataforma emergente, e em segundo os tres atributos do tipo de data para
manterem os momentos da ultima modificacao, importacao e exportacao.
Figura 5.6: Configuracao de tipo de dados.
53
Em relacao as operacoes sobre dados, e relevante referir as duas interfaces que o permitem:
interface de utilizador e interface programatica. A plataforma emergente permite inserir, editar
e remover entidades alojadas em qualquer documento xwiki atraves de uma interface grafica.
Quando se pretende inserir ou editar uma entidade, e usado o formulario com uma entrada
para cada atributo de acordo com o tipo de dados definido e escolhido previamente. Por isso,
a plataforma emergente permite nao so importar e exportar dados como tambem gerir o seu
ciclo de vida. A interface programatica permite efectuar as mesmas operacoes mas neste caso
oferecendo uma API. Essa API e exposta internamente como um modulo reutilizavel por outros
modulos e externamente como um servico que responde a pedidos remotos (RPC).
Em relacao as referencias de atributos, existe uma extensao ao editor WYSIWYG da XWiki.
Essa extensao permite escolher um tipo de dados e navegar pelas instancias incluindo as relacoes
entre dados. Durante essa navegacao existe a possibilidade de escolher os atributos a inserir no
documento. Esses atributos sao inseridos no documento atraves do artefacto referencia explicado
anteriormente.
5.2.3 Importacao, Exportacao e Conectores
O processo de transferencia de dados permite importar e exportar dos sistemas externos
para a plataforma emergente e vice-versa. Nesta seccao sao detalhados dois aspectos: o motor
de execucao e a interface de configuracao do processo.
Em relacao ao motor de execucao, os dados sao sucessivamente transformados ate, no caso
da exportacao, saırem da plataforma emergente e resultarem num ficheiro ou numa chamada a
um web service ou ate, no caso da importacao, serem persistidos internamente.
O modo de funcionamento de ferramentas aplicacionais de extraccao, transformacao e carre-
gamento de dados (ETL) e ainda de servicos similares ao Microsoft Integration Services baseia-se
num estilo de canais e filtros que transformam dados. No respeitante a plataforma emergente,
uma das principais funcionalidades e o mecanismo de importacao e exportacao de dados e por
isso mesmo, surgem na vista modulo dois elementos principais — modulo transferencia de da-
dos e modulo conectores. Em conjunto, os dois modulos sao responsaveis pela transformacao
bidireccional entre dados externos e dados internos. A interaccao entre si segue o estilo canais e
filtros tal como a figura 5.7 sugere. Durante a importacao de dados, o conector e responsavel por
54
obter os dados oriundos de sistemas externos e entrega-los segundo um formato preestabelecido
ao modulo de importacao. Por outro lado, durante a exportacao de dados, o conector recebe
os dados provenientes do modulo exportacao e concretiza-os em dados externos. O formato
preestabelecido e apenas uma coleccao de valores que representam os varios atributos do dado.
Figura 5.7: Interaccao do Conector com a Importacao e Exportacao.
Em detalhe, tanto no processo de importacao como o de exportacao, os dados sofrem um
conjunto de transformacoes. As transformacoes dependentes da ligacao aos dados externos
ocorrem no respectivo conector do qual dependem, enquanto as independentes ocorrem na im-
portacao/exportacao. A figura 5.8 detalha as transformacoes durante a importacao de um fi-
cheiro CSV.
Figura 5.8: Interaccao entre modulos durante a importacao de um ficheiro CSV.
O primeiro modulo e uma fonte de dados, o ultimo modulo e um destino ou consumidor de
dados e os restantes modulos servem de filtros para transformar dados. O modulo leitura de
ficheiro obtem linhas de um ficheiro CSV que sao posteriormente filtradas pelo modulo seguinte
— o modulo seleccao de linhas. As linhas de texto seleccionadas sao entregues ao modulo parsing
que desagrega a linha nos varios valores que a compoem e gera o formato preestabelecido. Estes
tres primeiros modulos fazem parte do modulo conector. Os tres modulos seguintes fazem parte
da importacao e por isso sao independentes do tipo de ligacao. O modulo transformacao de
atributos transforma a coleccao de valores em varias dimensoes: (i) tipifica cada valor, (ii)
agrega varios valores num so atributo, (iii) desagrega um valor em varios atributos segundo uma
expressao regular e (iv) deriva um novo valor segundo uma expressao. Os atributos tipificados
55
sao mapeados, de acordo com a configuracao aplicada, nos respectivos atributos de um objecto
interno de dados atraves do modulo mapeamento. Cada um desses objectos e persistindo de
seguida pelo modulo carregamento.
A figura 5.9 detalha as transformacoes durante a exportacao para um ficheiro CSV.
Figura 5.9: Interaccao entre modulos durante a exportacao para um ficheiro CSV.
O modulo colectar entidades selecciona os dados que sao alvo de exportacao de acordo com
a configuracao do utilizador. Os atributos de cada dado seleccionado sao transformados pelo
modulo transformacao de atributos tal como acontece na importacao mas neste caso num estilo
inverso — se na importacao desagregou-se valores, na exportacao esses dados sao potencialmente
agregados. Posteriormente os atributos sao mapeados, pelo modulo mapeamento, numa estrutura
generica que e trocada entre a importacao/exportacao e os conectores. Estes tres modulos fazem
parte da exportacao e por isso sao independentes do tipo de ligacao (conector). Os modulos que
fazem parte do conector sao o modulo producao de linhas que transforma a estrutura generica
num cadeia de caracteres representando uma linha com os valores separados por um delimitador
e o modulo escrita de linhas que escreve as linhas para um ficheiro de texto CSV.
Em relacao a interface de configuracao, existem igualmente duas partes — uma primeira
parte para escolher e configurar o conector e uma segunda parte para configurar o processo de
importacao/exportacao. Cada um dos modulos referidos anteriormente necessita de ser configu-
rado atraves da interface de utilizador que e exemplificada com varias figuras diferenciando os
casos de importacao e exportacao.
Antes de tudo, e necessario escolher o conector e configurar as suas particularidades. A
figura 5.10 mostra a interface de utilizador para a configuracao do conector “Ficheiro CSV”
cujas colunas sao delimitadas por um caracter. Em ambos os cenarios, e necessario escolher
o delimitador que separa as colunas no ficheiro. Adicionalmente e apenas na importacao —
figura 5.10a — e necessario escolher o ficheiro que contem os dados e opcionalmente escolher o
numero das linhas a ignorar aquando da importacao.
56
(a) Importacao (b) Exportacao
Figura 5.10: Configuracao do conector.
Apos o conector ser configurado, e o momento de configurar o processo de transferencia
atraves da interface de utilizador apresentada na figura 5.11. As propriedades de configurar sao:
(i) o tipo de dados previamente configurado na plataforma, (ii) a pagina que aloja as entidades,
(iii) a estrategia de transferencia que e explicada no proximo paragrafo, (iv) o nome do atributo
correspondente a data da ultima modificacao da entidade, (v) o nome do atributo correspondente
a data da ultima importacao da entidade e (vi) o nome do atributo correspondente a data da
ultima exportacao da entidade.
(a) Importacao (b) Exportacao
Figura 5.11: Configuracao da transferencia.
Apesar de muito similar, esta parte da configuracao apenas varia na estrategia de trans-
ferencia. A importacao possui um conjunto de estrategias — figura 5.12a — diferente as es-
trategias de exportacao — figura 5.12b. Em ambos os casos a estrategia de importacao esta
dependente da data da ultima importacao ou exportacao face a data da ultima modificacao
interna realizada sobre a entidade na plataforma emergente.
57
(a) Importacao (b) Exportacao
Figura 5.12: Configuracao da estrategia de transferencia.
Por fim, a configuracao fica completa com o mapeamento entre os atributos da estrutura
interna e a sequencia de valores no formato externo — neste caso, a sequencia de colunas do
ficheiro CSV. Mais uma vez surgem diferentes entre o processo de importacao e o de exportacao
tal como apresentado na figura 5.13. Na exportacao e suficiente escolher a sequencia de atributos
a exportar. No entanto, a configuracao e mais complexa na importacao. E necessario indicar: (i)
os atributos de identidade de servem para identificar durante a importacao se dois objectos sao
a mesma entidade, (ii) o mapeamento entre um valor externo e o atributo da estrutura interna
aplicando uma transformada durante a importacao. Existem dois tipos de transformadas: uma
para formatar o valor externo no respectivo tipo de dados para o qual o atributo esta configurado,
e outra para obter uma referencia para uma entidade existente na plataforma. Esta ultima
possibilita concretizar as ligacoes entre diferentes tipos de dados.
(a) Importacao
(b) Exportacao
Figura 5.13: Configuracao do mapeamento.
58
5.3 Sumario
Neste capıtulo, apresentou-se as principais funcionalidades da XWiki que sao uteis numa
plataforma emergente. Desta forma, alguns modulos e componentes arquitecturais foram im-
plementados com recurso a funcionalidades implementadas na XWiki. Apesar de tudo, outras
funcionalidades importantes numa plataforma emergente nao estao implementadas na XWiki.
Assim, a XWiki nao e suficiente mas serve de base para o desenvolvimento da plataforma emer-
gente. As decisoes de desenho e os detalhes tecnicos da implementacao dessa plataforma sao
descritos passando pelos tres conceitos gerais: artefactos, dados e processos de importacao e
exportacao.
A tabela 5.2 relaciona as funcionalidades da XWiki com os modulos e componentes arqui-
tecturais onde foram usadas. Dado que a XWiki possui um meta-domınio e um conjunto de
metodos para operar sobre esse meta-domınio, as funcionalidades mais usadas referem-se aos
conceitos de objecto, classe e propriedades.
Módulos e Componentes Arquitecturais Funcionalidades XWiki reutilizadas
1. Artefactos Macros Editor gráfico WYSIWYG para inserção de macros Renderização
2. Dados 2.2 Tipo de Dados Componente Repositório
Gestão de objectos, classes e propriedades
2.1 Operações 2.1.1 Instanciação de Dados
Operações (CRUD) sobre objectos através de interface de utilizador
2.3 Configuração Tipo de Dados Definição de classes e propriedades através de interface de utilizador
3.2.2.2 Carregamento (na importação) 3.2.3.1 Colecta Dados (na exportação) Componente Dados (API Domínio)
API – operações sobre objectos, classes e propriedades
Tabela 5.2: Funcionalidades XWiki usadas para a implementacao de alguns modulos e compo-nentes arquitecturais.
59
60
6Valida�c~ao
A validacao e feita atraves da configuracao e utilizacao da plataforma emergente de modo
a suportar o cenario descrito na seccao 3.2. O cenario divide-se em tres situacoes, cada uma
relacionada com um dos tres desafios principais que levam ao aparecimento de sistemas emer-
gentes. As tres situacoes sao: (i) relembrar de tarefas, (ii) priorizar tarefas e (iii) relembrar de
informacao. O cenario descreve como os utilizadores e sistemas emergentes interagem sem a
plataforma emergente. Este capıtulo de validacao descreve passo a passo como os mesmos utili-
zadores podem utilizar a plataforma emergente para suportar os tres principais desafios. Assim,
o modelo de implementacao proposto no capıtulo anterior e validado atraves da simulacao do
cenario.
6.1 Configuracao do ambiente na plataforma emergente
Antes de validar a plataforma e necessario configurar o ambiente para a simulacao do cenario.
O ambiente e concretizado por um pacote pre-configurado constituıdo por documentos, classes
e objectos. O pacote e importado atraves do espaco de administracao da plataforma. O pacote
e portanto constituıdo por tres conjuntos:
• MTEL – Area de trabalho com exemplos relacionados com o caso de estudo para demons-
trar o potencial da wiki enquanto plataforma emergente;
• WsieClasses – Conjunto de paginas relacionadas com as duas classes exemplo: cliente e
oportunidade de venda;
• WsieCode – Conjunto de paginas relacionadas com parte da implementacao, nomeada-
mente as macros de referencia, pilha e post-it e classes de suporte aos artefactos.
6.2 Validacao das situacoes
Uma vez configurado o ambiente segue a validacao de cada uma das situacoes. Em cada
seccao e descrita a utilizacao passo a passo da plataforma emergente acompanhada pela enu-
meracao das funcionalidades relevantes para cada situacao.
6.2.1 Situacao A – relembrar de tarefas
O Duarte recebe um email do cliente Supermercados, Lda. com pedido de orcamento para
um conjunto de perifericos e que deve enviar ainda nesse mesmo dia. Como nao e possıvel
efectuar essa tarefa no momento, necessita de registar a tarefa pendente de modo a relembra-lo
mais tarde. Antecipadamente sabe que aquele orcamento vai atingir o tal limite imposto ao
departamento e por isso evita usar o sistema prescrito para registar a tarefa pendente. Sendo
assim opta por usar o sistema emergente.
Desta forma, abre o sistema emergente e caso ainda nao o tenha feito autentica-se junto
da plataforma. Paginas e areas de trabalho apenas estao acessıveis a utilizadores autenticados
com permissao para tal. Assegura-se assim a privacidade da informacao controlada — um dos
objectivos dos utilizadores no uso da plataforma.
De seguida abre a area de trabalho MTEL e cria uma nova pagina carregando no botao
adicionar. A pagina fica hierarquicamente dentro da area de trabalho referida. Copia o conteudo
do email contendo os perifericos para a pagina — figura 6.1 — e guarda-a com o mesmo tıtulo
que o do email. Assim o tıtulo torna-se uma referencia implıcita de ligacao entre esta pagina e
o email em particular.
Apos guardar a pagina, Duarte pretende inseri-la na pilha da area de trabalho de modo a
nao se esquecer da existencia do pedido de orcamento. A pilha da area de trabalho contem os
pedidos por tratar. Por isso mesmo, ainda no contexto da pagina recentemente criada e atraves
das funcionalidades estendidas no painel, escolhe a pilha com o respectivo tıtulo e carrega no
botao adicionar. A pagina visualizada e entao inserida no topo da pilha.
Duarte pretende ainda adicionar na pilha o precario de modo a facilitar a elaboracao do
orcamento quando voltar a este tema mais tarde. Na wiki existe uma pagina com essa informacao
mas, ao contrario do que foi feito quando se inseriu a ultima pagina na pilha, Duarte nao tem
62
aberto o precario mas sim a area de trabalho. Neste caso opta por uma estrategia diferente.
Reabre a area de trabalho no modo de edicao in-line. Nesse modo e possıvel editar os artefactos
existentes e as suas posicoes na area de trabalho. Usa, neste caso, o modo edicao da pilha,
cuja interface grafica esta representada na figura 6.2, para inserir a pagina recentemente criada.
Escreve o nome da pagina com a ajuda das sugestoes que surgem ao escrever as primeiras letras
e carrega no botao adicionar. Guarda as alteracoes na pilha saindo do modo de edicao. O
resultado e uma pilha com mais um documento no topo tal como apresentado na figura 6.3.
Figura 6.1: Escrita de uma nova pagina usando o editor grafico WYSIWYG preenchendo hie-rarquia, tıtulo, corpo e sumario da versao.
Figura 6.2: Modo de edicao in-line do artefacto pilha.
Figura 6.3: Artefacto pilha.
63
Entretanto Duarte recebe um telefonema do mesmo cliente a perguntar acerca da encomenda
realizada na semana passada. Como o Duarte precisa de averiguar o porque do atraso necessita
de perguntar telefonicamente ao departamento de aprovisionamento. Assim, cria um novo post-it
para representar a tarefa. Abre o modo de edicao in-line da area de trabalho e carrega do botao
adicionar artefacto (gadget) tal como representado na figura 6.4. Selecciona o tipo de artefacto
post-it e apos escrever o seu conteudo insere-o na area de trabalho carregando botao inserir tal
como mostrado na figura 6.5. O resultado e um post-it — figura 6.6 — que e reposicionado
de acordo com as necessidades do Duarte. Por fim, fecha o modo de edicao in-line da area de
trabalho.
Figura 6.4: Botoes de adicao de artefactos e colunas na area de trabalho durante o seu modo deedicao in-line.
Figura 6.5: Adicao de um post-it escrevendo o conteudo e opcionalmente um tıtulo.
Figura 6.6: Artefacto post-it.
64
6.2.2 Situacao B – priorizar tarefas
Duarte possui varios pedidos por cumprir distribuıdos pelos post-its e pilha que posicionou
na area de trabalho. Precisa de decidir rapidamente quais sao os proximos pedidos a cumprir.
Ele sabe que existem pedidos que devem ser tratados ainda nesse mesmo dia dada a importancia
do cliente que os fez.
Decide posicionar os post-its de acordo com a ordem de prioridade — no topo os mais
prioritarios. Para isso, abre a area de trabalho no modo de edicao in-line. Neste modo e
possıvel reposicionar qualquer artefacto incluindo os post-its. Por outro lado, remove da pilha
documentos que, por acumularem-se mesmo apos as respectivas tarefas terem sido concluıdas,
ja nao sao importantes e podem ser retirados. Por isso, como apresentado na figura anterior 6.2,
utiliza as funcionalidades no modo de edicao da pilha: (i) arrastar e largar documentos para
reordena-los dentro da pilha e (ii) remover documentos da pilha. Destaca-se a vantagem imediata
face ao artefacto em formato fısico: os documentos nao precisam de serem arquivados em pastas
porque no formato digital eles mantem varios modelos de organizacao, ou seja, no formato
digital e possıvel colocar o mesmo documento em pilhas diferentes mantendo a sua organizacao
hierarquica. Portanto, no formato digital, basta retirar da pilha os documentos desnecessarios
ao resto do trabalho semanal. No topo surgem documentos relacionados com tarefas mais
prioritarias.
Ao visualizar o primeiro post-it que surge quando abre a area de trabalho, o Duarte ini-
cia uma nova tarefa agora no contexto do cliente Supermercados, Lda. Trata-se dos pedidos
previamente efectuados e descritos na seccao anterior.
6.2.3 Situacao C – relembrar de informacao
Duarte precisa de averiguar o porque do atraso na instalacao dos servicos da ultima en-
comenda. Durante a realizacao da encomenda afixou uma tag nas paginas relacionadas com
essa encomenda. Duarte visualiza a nuvem de tags que surge na area de trabalho tal como e
apresentado na figura 6.7. Ele reconhece quais sao as tags que correspondem a encomendas —
sao as que tem um numero acompanhado pelo ano. Rapidamente encontra a tag respectiva e
selecciona-a abrindo uma lista de paginas com aquela tag afixada. Entre a lista de documentos
— agora menor, pois na pratica foi aplicado um filtro de documentos — encontra o documento
65
desejado atraves do seu tıtulo. Abre o documento e visualiza o seu conteudo de modo a refrescar
a sua memoria com o ponto de situacao da ultima fez que empenhou-se no tema. Ele verifica
que oito em dez servicos estavam instalados.
Figura 6.7: Nuvem de tags e lista de documentos na area de trabalho MTEL.
Telefona para o departamento responsavel pela instalacao com o objectivo de compreender
o ponto de situacao actual e o porque do atraso na instalacao dos servicos que faltavam. Du-
arte percebe que falta completar a instalacao de tres servicos estando um deles dependente da
actualizacao da morada de instalacao. Assim, actualiza o documento atraves do editor grafico
WYSIWYG com o novo ponto de situacao colocando a verde os servicos instalados, a amarelo
os parcialmente instalados e a vermelho o servico que se encontra dependente da recepcao por
parte do cliente da nova morada. Guarda a pagina. Duarte comunica o ponto de situacao actual
atraves do numero de telefone que foi escrito no post-it quando recebeu a chamada. Pede a nova
morada de instalacao e altera a entidade cliente que surge no documento atraves do artefacto
referencia. Para isso abre a pagina do modo de edicao in-line activando as funcionalidades de
edicao dos artefactos, tal como ilustrado na figura 6.8. Edita na respectiva caixa de texto a
morada e guarda o documento.
Figura 6.8: Modo de edicao in-line numa pagina com referencias. As caixas de texto sao asreferencias prontas a editar.
66
Apos desligar o telefone transfere essa informacao para o sistema prescrito e partilha o
documento ao departamento responsavel pela instalacao. De modo a transferir a nova morada
do local de instalacao, Duarte utiliza o processo de exportacao de informacao da plataforma
emergente. Abre a interface apresentada na figura 6.9 para configurar o processo atraves de um
hiperligacao situada no painel de acesso rapido. Durante a configuracao e necessario indicar: (i)
o tipo de conector, neste caso o sistema prescrito permite importar dados atraves de CSV e por
isso e escolhido o conector para a criacao desse tipo de ficheiros; (ii) configuracoes particulares
desse conector, neste caso o delimitador usado para separar valores; (iii) o tipo de entidade, neste
caso a entidade cliente que para alem de outras propriedades possuiu a propriedade morada;
(iv) a pagina onde as entidades estao instanciadas; (v) a estrategia de exportacao, neste caso
so e necessario exportar as entidades modificadas desde a ultima exportacao; (vi) configuracao
das propriedades de meta-dados, neste caso a configuracao e automatica nao precisando de
alteracoes; (vii) seleccao das propriedades a exportar, neste caso todas excepto as encomendas
associadas ao cliente que, devido a existencia de encomendas fora do ambito do departamento,
nao se pretende que sejam exportadas para o sistema externo dado que vai colocar em causa
a observancia as regras prescritas. Apos carregar no botao submeter obtem-se o ficheiro CSV
de acordo com a configuracao. Posteriormente o Duarte utiliza as funcionalidades prescritas do
sistema externo para importar dados em ficheiros CSV.
Figura 6.9: Exportacao para um ficheiro CSV os clientes modificadas desde ultima exportacao.
67
Duarte elimina o post-it atraves do botao eliminar artefacto que surge no modo de edicao
in-line da area de trabalho. De seguida passa para um outro tema.
Duarte regressa novamente a area de trabalho e visualiza o documento que esta no topo
da pilha fazendo duplo clique sobre a pilha. Trata-se do pedido de encomenda realizado pelo
cliente Supermercados, Lda. Nesse documento e junto de cada periferico referenciado anota os
respectivos precos. Para isso, selecciona o texto referente ao periferico e com uma combinacao
de teclas surge o artefacto anotacao tal como ilustrado na figura 6.10. Nesse artefacto e possıvel
escrever o preco ou qualquer outra informacao. Escreve um novo email de resposta utilizando
como base as anotacoes feitas no documento. E possıvel visualizar todas as anotacoes da pagina
activando a respectiva funcionalidade na propria pagina.
Figura 6.10: Criacao e visualizacao de anotacoes numa pagina.
Para alem disso, Duarte e obrigado em criar no sistema prescrito uma nova oportunidade de
venda descrevendo de um modo geral a oportunidade que teve como base o orcamento pedido.
Assim mantem uma aparente observancia com as regras prescritas, mas Duarte sabe que nao
pode descrever a oportunidade de venda com muito detalhe pois segundo as normas prescritas
este cliente deveria ter sido redireccionado para outro departamento com competencias para
lidar com vendas e oportunidades de vendas daquela dimensao. Contudo, precisa de manter
informacao emergente mais detalhada para o caso do cliente realizar a encomenda.
Duarte decide manter a informacao emergente na propria entidade oportunidade de venda
mas apenas no sistema emergente dado que pretende esconder essa informacao. Para isso, pri-
meiro, precisa de actualizar as entidades oportunidades de venda na plataforma, isto e, transferir
68
informacao do sistema externo para a plataforma emergente. Um aspecto importante e o facto
da entidade oportunidade de venda possuir uma propriedade emergente adicional que e usada
para manter uma descricao mais detalhada, isto e, a informacao emergente. Naturalmente, essa
propriedade apenas existe no sistema emergente e e preenchida posteriormente. Apos replicar a
oportunidade venda no sistema emergente, esta pode ser inserida atraves do editor grafico em
qualquer documento nomeadamente o documento onde esta o orcamento. A figura 6.11 mos-
tra que, durante a edicao do documento, e possıvel adicionar com duplo clique as propriedades
desejadas da oportunidade venda associadas ao cliente Supermercados, Lda. Por fim, apos o
documento ser guardado, e o momento de editar as propriedades inseridas no documento atraves
do modo de edicao in-line como apresentado anteriormente na figura 6.8.
Figura 6.11: Navegacao na hierarquia de dados e insercao de referencias numa pagina.
Em relacao a importacao de dados e possıvel realiza-la de duas formas: manual ou au-
tomatica. Duarte podia criar manualmente a entidade no sistema emergente — e possıvel. Mas
opta por transferir automaticamente porque existem outras entidades antigas por actualizar no
sistema emergente. Essa importacao e realizada em duas fases1 — primeiro importa as opor-
tunidades de venda e so posteriormente os clientes. A isto deve-se a relacao entre clientes e
oportunidades de venda. Como a entidade cliente e dona da relacao, antes de importar os
clientes, as oportunidades de venda tem de existir de modo a que a relacao seja criada na se-
gunda fase de importacao. O Duarte inicia a configuracao do processo de importacao usando
1Apenas a segunda fase e exemplificada por ser mais complexa. A primeira fase difere no facto da entidadecliente nao possuir referencias ao contrario da entidade oportunidade de venda
69
para isso a interface propria para o efeito tal como mostra a figura 6.12. mostra a interface de
configuracao onde e necessario indicar: (i) o tipo de conector, neste caso o sistema prescrito
permite exportar dados para CSV e por isso e escolhido o conector para a importacao desse tipo
de ficheiro; (ii) configuracoes particulares desse conector, neste caso o delimitador usado para
separar valores e as linhas a ignorar como por exemplo o cabecalho; (iii) o tipo de entidade, neste
caso a entidade cliente; (iv) a pagina onde as entidades estao instanciadas; (v) a estrategia de
importacao, neste caso sao actualizadas e criadas todas as entidades; (vi) configuracao das pro-
priedades de meta-dados, neste caso a configuracao e automatica nao precisando de alteracoes;
(vii) mapeamento entre o numero da coluna do ficheiro CSV e as propriedades do tipo de enti-
dade escolhido; (viii) indicacao das propriedades que identificam inequivocamente a entidade no
sistema externo, neste caso a propriedade “identificador” e suficiente. Durante a configuracao e
preciso especial atencao para o mapeamento das oportunidades de venda. E necessario obter a
oportunidade que foi previamente importada. Assim, utilizando a janela da figura 6.13 indica a
classe e a pagina onde procurar e as colunas de valores do CSV a utilizar em cada propriedade
para filtrar a oportunidade de venda associada.
Figura 6.12: Importacao a partir de um ficheiro CSV todos os clientes actualizando os importadosanteriormente.
70
Figura 6.13: Configuracao da referencia no processo de importacao.
Por fim adiciona ao documento o numero de oportunidade e o numero de cliente atraves de
tags tal como mostrado na figura 6.14. Nao e necessario organizar o documento segundo um
sistema de pastas ou dossiers tal como acontecia no cenario, pois as tags sao suficientes para
encontra-lo mais tarde.
Figura 6.14: Adicionar uma tag a um documento.
6.3 Sumario
Neste capıtulo validou-se o modelo de implementacao apresentado no capıtulo 5. Essa
validacao consistiu na simulacao do cenario apresentado na seccao 3.3 usando a plataforma
emergente desenvolvida de acordo com o modelo de implementacao proposto.
Ao longo dos tres desafios, focou-se nos seguintes aspectos:
• Area de trabalho – simula a mesa e o restante espaco de trabalho onde se posiciona
artefactos, tal como acontece na plataforma emergente;
• Pilha – artefacto que contem uma sequencia de documentos onde e possıvel navegar do
topo para o fundo ou vice-versa; e possıvel adicionar, remover e reordenar os documentos
durante a edicao da pilha;
• Tag – afixa-se a pagina um nome relacionado com o conteudo e de acordo com as neces-
sidades do utilizador no que toca a organizacao e procura de informacao;
71
• Post-it – artefacto que mostra todo o seu conteudo;
• Anotacao – artefacto que permite anotar informacao extra a qualquer parte do conteudo
numa pagina;
• Referencia – artefacto que mostra o valor de uma propriedade de um objecto em parti-
cular;
• Importacao e Exportacao – processos para a transferencia de dados entre sistemas
externos e plataforma emergente;
• Dados e Tipo de Dados – a plataforma emergente mantem as entidades e tipos de dados
que podem conter propriedades e informacao emergentes;
• Modo de edicao in-line – ao abrir paginas e areas de trabalho neste modo, as funcio-
nalidades de edicao dos artefactos que aı surgem sao activadas;
A transferencia de informacao entre sistemas externos e a plataforma emergente surge neste
cenario com uma importancia acrescida. Essa importancia deve-se ao facto da necessidade
de cumprir com os objectivos e praticas prescritas impostos pela gestao de topo. Contudo a
observancia com essas regras e apenas aparente. Neste caso o Duarte tinha o dever de delegar
a interaccao com o cliente ao departamento responsavel mas preferiu mante-lo. Ao ocultar
certos aspectos relacionado com encomendas e pedidos de orcamento, conseguiu manter o cliente
durante mais alguns meses. Independentemente da situacao prejudicar ou beneficiar o cliente
e/ou a empresa — nao e isso que esta em causa — Duarte pode tirar proveito da situacao para
atingir objectivos impostos pela organizacao sobre o proprio ou a sua equipa.
Assim, surgem necessidades emergentes que ficaram bem patentes nos tres grandes desafios
descritos no capıtulo. Em particular, a necessidade de manter informacao emergente nas entida-
des do domınio leva ao aparecimento de propriedades-extra que nao existem no sistema prescrito.
Essas propriedades que servem para manter informacao emergente so existem, portanto, na pla-
taforma. Contudo nao e so em propriedades-extra que surge informacao emergente. Pode surgir
em tipos de entidades que nao existem no sistema externo e mesmo propriedades nao-extra, ou
seja, propriedades que existem nos sistemas externos. Independentemente da situacao, o pro-
cesso de exportacao permite escolher quais os tipos de entidades e suas propriedades que serao
72
usados para actualizar os sistemas externos — neste cenario em particular, apenas os tipos de
entidades e sua propriedades que possuem informacao prescrita.
Tendo em conta o sucesso da plataforma em satisfazer as necessidades emergentes nos tres
desafios, conclui-se que o modelo de implementacao e eficaz em situacoes e desafios similares
ao do cenario. O proximo capıtulo explicita as principais conclusoes retiradas ao longo da
dissertacao.
73
74
7Conclus~ao
Tendo em conta os resultados positivos obtidos, no capıtulo anterior, da aplicacao do cenario
na plataforma implementada segue um sumario do trabalho realizado e as suas principais con-
tribuicoes.
7.1 Conclusoes
Esta dissertacao tem como objecto de estudo os sistemas, praticas e informacao emergentes
e como cada item se relaciona com o prescrito correspondente. Os sistemas de informacao
emergentes surgem devido a duas situacoes. Em primeiro, deve-se ao facto dos sistemas prescritos
nao estarem alinhados com os objectivos e necessidades tecnologicas prescritas da organizacao
em parte devido aos objectivos e necessidades serem mais volateis do que a capacidade dos
sistemas se adaptarem. Em segundo, os utilizadores podem deparar-se com desafios emergentes
proprios ou de equipa e ou os sistemas prescritos nao estao preparados para essa emergencia ou
os utilizadores nao pretendem deixar uma representacao desse trabalho emergente nos sistemas
prescritos.
O caso de estudo da MTEL e a literatura sobre sistemas emergentes foram a base para se
efectuar um levantamento das caracterısticas e funcionalidades de um sistema emergente, em
particular dos artefactos que compoem esse sistema. A modelacao desses sistemas em Tropos
nao descurou a captura do racional que leva os utilizadores a usarem sistemas emergentes —
que nao se deve apenas as funcionalidades e caracterısticas tecnicas dos sistemas.
A partir do caso de estudo desenvolveu-se um cenario representativo de aspectos emergentes
facultando uma percepcao de como, em que situacao e para que proposito cada tipo de artefacto
emergente e utilizado. Por outro lado, tambem capturou o racional em usar um sistema em
detrimento do outro — emergente versus prescrito — e a coreografia na utilizacao de um e do
outro procurando ligacoes ou transferencias de informacao entre os mesmos.
A modelacao dos artefactos emergentes e o cenario de utilizacao permitiram criar uma
solucao assente em tres topicos: artefactos, dados e mecanismos de importacao e exportacao.
Alias, o primeiro nıvel de decomposicao segue os mesmos topicos, ou seja, surge os modulos
artefactos, dados e fonte de dados.
O modulo artefactos encapsula todos os conceitos relacionados com modelos de interaccao
de cada tipo de artefacto e os dados que aı sao manipulados. Cada artefacto disponibiliza uma
interface de utilizador alinhada com os requisitos identificados.
O modulo dados encapsula os conceitos relacionados com dados prescritos e emergentes e
outros meta-dados nomeadamente identificadores da entidade em sistemas externos e os mo-
mentos de ultima modificacao, importacao e exportacao. O primeiro conjunto de meta-dados
e utilizado para garantir a rastreabilidade e manter a identidade dos dados independentemente
da sua replicacao entre sistemas externos e a plataforma. O segundo conjunto de meta-dados
e utilizado pelas estrategias de importacao e exportacao para escolher os dados que devem ser
objecto de importacao ou exportacao.
O modulo fonte de dados encapsula os conceitos relacionados com a transferencia de dados
entre sistemas externos e a plataforma emergente. Importa mencionar um nıvel de decomposicao
dentro do modulo fonte de dados. Este modulo e decomposto em modulos independentes e em
modulos dependentes da tecnologia de integracao e da orquestracao necessaria para integrar a
plataforma emergente com os sistemas externos.
Apos desenvolver o modelo de implementacao incluindo a arquitectura proposta, sao apre-
sentados em seccao propria os detalhes tecnicos de implementacao e as decisoes de desenho. Ao
analisar a XWiki verifica-se que esta apresenta funcionalidades e caracterısticas arquitecturais
alinhadas com o modelo de implementacao, mas por si so nao sao suficientes para satisfazer
as necessidades identificadas num contexto de emergencia. Assim, foi necessario desenvolver os
seguintes aspectos na XWiki enquanto plataforma emergente:
• Desenvolvimento do artefacto pilha de documentos com funcionalidades de navegacao nos
documentos e edicao in-line;
• Desenvolvimento do artefacto post-it ;
76
• Desenvolvimento do artefacto referencia com funcionalidades de edicao in-line;
• Extensao do editor grafico XWiki de modo a facilitar a insercao de referencias em docu-
mentos;
• Desenvolvimento dos mecanismos de configuracao e execucao de importacao e exportacao;
• Desenvolvimento de API para gestao de dados da plataforma emergente.
7.2 Principais contribuicoes
O principal objectivo da dissertacao e facultar aos utilizadores uma plataforma que sirva de
base para o desenvolvimento de um sistema capaz de satisfazer as suas necessidades emergentes.
As principais contribuicoes sao:
• Modelacao em Tropos das funcionalidades e do racional de utilizacao dos artefactos —
lista de afazeres, post-it, pilha de documentos, correio electronico, running log e folha de
calculo;
• Desenvolvimento de uma arquitectura de software orientada as plataformas emergentes;
• Integrar caracterısticas de sistemas emergentes em wikis;
• Disponibilizar aos utilizadores uma plataforma flexıvel para o desenvolvimento de sistemas
emergentes e tratamento de informacao emergente.
7.3 Trabalho futuro
Ao longo do trabalho surgiram outros aspectos ou propostas que podiam ter sido seguidas
no ambito desta dissertacao. De seguida sao apresentados quatro pontos para trabalho futuro.
Em primeiro, analisar os benefıcios em esconder dos utilizadores os meta-dados ou deixar
controlo total sobre os mesmos. Os tipos de dado possuem dois conjuntos de meta-dados. Um
conjunto para identificar a entidade interna e externamente e um outro conjunto para indicar
o momento da ultima modificacao, importacao e exportacao. Ao deixar o controlo total aos
77
utilizadores, estes podem modificar os seus valores tendo consequencias no modo como a im-
portacao/exportacao se comporta. Por outro lado, ao esconder esses meta-dados, os utilizadores
tem uma menor percepcao do que ocorre tornando menos transparente uma plataforma onde
essa propriedade e relevante.
Em segundo, e proposta uma integracao estendida com as fontes de dados. A integracao
estendida possibilita efectuar operacoes sobre o domınio e replica-las, com autorizacao previa
dos utilizadores, nas fontes de dados. As operacoes actuais sao apenas operacoes CRUD, mas
sao interessantes operacoes alinhadas com a logica de negocio implementadas pelos proprios
utilizadores.
Em terceiro, e proposta a propriedade de bidireccionalidade das referencias. As referencias
com bidireccionalidade permitem identificar os documentos ou artefactos que se referem a uma
determinada entidade. Ao ser usada a mesma referencia em documentos diferentes, estes ficam
relacionados por intermedio da entidade referida por ambos documentos. Um dos desafios do
utilizador e procurar informacao e esta funcionalidade reforca o suporte a esse desafio. Apesar
de ter sido desenvolvido parte deste requisito, existe necessidade de uma analise mais pormeno-
rizada.
Em quarto, e proposta a funcionalidade de guardar configuracoes de importacao/exportacao
e executa-las automaticamente segundo regras de escalonamento. A possibilidade de guardar
configuracoes de importacao e exportacao sem necessidade de intervencao do utilizador. A gestao
e replicacao das entidades em mais do que um sistema sao facilitadas ao sincronizar os sistemas
prescritos e a plataforma emergente atraves de regras de importacao/exportacao definidas e
despoletadas periodicamente.
78
Referencias
Adams, D. A., R. R. Nelson, and P. A. Todd (1992). Perceived Usefulness, Ease of Use, and
Usage of Information Technology: A Replication. MIS Q. 16 (2), 227 – 247.
Anslow, C. and D. Riehle (2008). Towards End-User Programming with Wikis. In WEUSE
’08: Proceedings of the 4th international workshop on end-user software engineering, New
York, pp. 61 – 65. ACM.
Anton, A. I. (1996). Goal-Based Requirements Analysis. In Second IEEE International Con-
ference on Requirements Engineering (ICRE’96), pp. 136 – 144.
Bass, L., P. Clements, and R. Kazman (2003). Software Architecture in Practice, Second
Edition. Addison Wesley.
Bean, L. and D. D. Hott (2005). Wiki: A speedy new tool to manage projects. Journal of
Corporate Accounting & Finance 16 (5), 3–8.
Bondarenko, O. and R. Janssen (2005). Documents at Hand: Learning from Paper to Im-
prove Digital Technologies. In CHI ’05: Proceedings of the SIGCHI Conference on Human
Factors in Computing Systems, New York, pp. 121 – 130. ACM.
Boudreau, M.-C. and D. Robey (2005). Enacting Integrated Information Technology: A Hu-
man Agency Perspective. Organization Science 16, 3–18.
Castro, J., M. Kolp, and J. Mylopoulos (2002). Towards Requirements-Driven Information
Systems Engineering: The Tropos Project. Information Systems 27 (6), 365 – 389.
Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Iversa, R. Little, R. Nord, and J. Stafford
(2002). Documenting Software Architectures: Views and Beyond. Addison Wesley.
Dix, A., J. Wilkinson, and D. Ramduny (1998). Redefinig Organizational Memory: Artefacts,
and the Distribution and Coordination of Work. In Workshop on Understanding Work
and Designing Artefacts.
Ebersbach, A., M. Glaser, R. Heigl, and A. Warta (2008). Wiki: Web Collaboration. Springer.
79
Gina Trapani, A. P. (2009). The Complete Guide to Google Wave.
Giorgini, P., M. Kolp, J. Mylopoulos, and M. Pistore (2004). The Tropos Methodology: An
Overview. Kluwer Academic Publishing.
Grau, G., X. Franch, E. Mayol, C. P. Ayala, C. Cares, M. Haya, F. Navarrete, P. Botella, and
C. Quer (2005). RiSD: A Methodology for Building i*-Strategic Dependency Models. In
W. C. Chu, N. J. Juzgado, and W. E. Wong (Eds.), SEKE, pp. 259 – 266.
Gwizdka, J. (2002). Reinventing the Inbox: Supporting the Management of Pending Tasks in
Email. In L. G. Terveen and D. R. Wixon (Eds.), CHI Extended Abstracts, pp. 550 – 551.
ACM.
Hasan, H. and C. C. Pfaff (2006). The Wiki: An Environment to Revolutionise Employees’
Interaction with Corporate Knowledge. In T. Robertson (Ed.), OZCHI, Volume 206 of
ACM International Conference Proceeding Series, pp. 377 – 380. ACM.
Lapouchnian, A. (2005). Goal-Oriented Requirements Engineering: An Overview of the Cur-
rent Research.
Laudon, J. and K. Laudon (2006). Management Information Systems: Managing the Digital
Firm (10th ed.). Prentice Hall.
Leclercq, A., A. Carugati, A. Giangreco, J. Vieira da Cunha, and T. Jensen (2009). A Soci-
omaterial View on the Scaffolding of Work Practices with Information Technology. The
International Conference on Information Systems.
Mader, S. (2008). Wikipatterns. Wiley.
Malone, T. W. (1983). How Do People Organize Their Desks? Implications for the Design
of Office Information Systems. ACM Transactions on Office Information Systems 1, 99 –
112.
Mander, R., G. Salomon, and Y. Y. Wong (1992). A “Pile” Metaphor for Supporting Casual
Organization of Information. In CHI, pp. 627 – 634.
Martınez, A., O. Pastor, and H. Estrada (2003). Closing the Gap between Organizational
Modeling and Information System Modeling. In L. E. G. Martins and X. Franch (Eds.),
WER, pp. 93 – 108.
Orlikowski, W. J. (1996). Improvising Organizational Transformation Over Time: A Situated
Change Perspective. Information Systems Research 7 (1), 63 – 92.
80
van Lamsweerde, A. (2000). Requirements Engineering in the Year 00: A Research Perspec-
tive. In ICSE ’00: Proceedings of the 22nd International Conference on Software Engine-
ering, New York, NY, USA, pp. 5 – 19. ACM Press.
van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour. In RE
’01: Proceedings of the Fifth IEEE International Symposium on Requirements Engineering,
Washington. IEEE Computer Society.
Vieira da Cunha, J. (2005, Outubro). Making the Numbers: Agency in Computer-Generated
Formal Representations of Saleswork. Ph. D. thesis, Sloan School of Management.
Yu, E. and J. Mylopoulos (1998). Why Goal-Oriented Requirements Engineering. Proceedings
of the 4th International Workshop on Requirements Engineering: Foundation for Software
Quality , 15 – 22.
Yu, E. S. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements
Engineering. In International Symposium on Requirements Engineering, Annapolis, Mary-
land, pp. 226 – 235.
81
82
AArquitectura de Software
A.1 Introducao
Este anexo apresenta o desenho passo-a-passo do estilo de decomposicao da arquitectura
de software. Dado os atributos de qualidade, sao descritos cenarios para exemplificar esses
atributos. De seguida sao aplicadas tacticas surgindo um estilo de decomposicao alinhado com
os cenarios.
A.2 Atributos de qualidade
Entre os objectivos da plataforma emergente destaca-se a sua capacidade de trabalhar com
dados de diferentes origens/sistemas externos e que estes sejam trabalhados/utilizados de acordo
com as praticas de trabalho identificadas. Adicionalmente, a confidencialidade de dados e arte-
factos emergentes deve ser salvaguardada. Eis porque surgem os quatro atributos de qualidade:
(i) facilidade de modificacao, (ii) interoperabilidade e (iii) facilidade de utilizacao, (iv) seguranca.
Em detalhe:
• Efectuar alteracoes em tempo de execucao aos artefactos, dados e tipo de dados (incluindo
a eliminacao e adicao desses conceitos) e a configuracao em tempo de execucao da fonte
de dados (mecanismos de importacao e exportacao incluindo os conectores);
• Efectuar alteracoes aos tipos de artefactos e conectores durante a implementacao e ser
possıvel incorpora-las facilmente;
• Autorizar apenas alguns colaboradores a acederem a artefactos e dados emergentes proi-
bindo o acesso por parte de chefias ou de outros utilizadores sem acesso determinado pelo
autor do artefacto/dado em questao;
• Carregar dados de diferentes fontes incluindo sistemas prescritos com os quais e possıvel
interoperar na actualizacao e realizacao de operacoes sobre os dados;
• Disponibilizar as mesmas operacoes e aproximar o modelo conceptual dos artefactos im-
plementados a dos respectivos formatos fısicos minimizando, assim, o tempo e dificuldade
de adaptacao aos artefactos;
• Disponibilizar operacoes dependentes do tipo de dados sobre os quais sao aplicadas.
A.3 Cenarios
A.3.1 Artefactos
A.3.1.1 Cenario
• Fonte de Estımulo: Equipa de Desenvolvimento
• Estımulo: Implementar um novo tipo de artefacto que trabalha sobre os mesmos dados
(partilhados) que outros artefactos utilizam
• Artefacto: Plataforma Emergente
• Ambiente: Durante a implementacao da plataforma
• Resposta: Uma vez instalado o novo tipo de artefacto e possıvel instancia-lo sem a
necessidade de modificar o tipo de dados ou o comportamento de outros artefactos
• Medida: O novo tipo de artefacto foi testado e implementado em X meses; o novo tipo
de artefacto foi instalado e instanciado em poucos minutos
A.3.1.2 Tacticas
• Esconder os detalhes dos tipos de artefacto de modo a prevenir efeitos em cascata;
• Abstrair uma interface comum para os dados de modo a manter coerencia semantica e
serem usados pelos tipos de artefactos existentes;
• Abstrair uma interface comum para os artefactos de modo a manter coerencia semantica
e serem usados pelo contentor que instancia e envolve os artefactos.
84
A.3.1.3 Arquitectura
• Definir o modulo “Artefacto” e respectivos sub-modulos com os diferentes tipos de arte-
factos;
• Definir um modulo que esconde os detalhes dos dados.
Figura A.1: Decomposicao apos o primeiro cenario.
A.3.2 Leitura e Escrita de Dados Emergentes atraves de Artefactos
A.3.2.1 Cenario
• Fonte de Estımulo: Utilizador
• Estımulo: Aceder e modificar, atraves de qualquer artefacto, aos dados emergentes defi-
nidos e importados previamente; possibilidade de aceder e modificar o valor dos atributos
prescritos e emergentes.
• Artefacto: Plataforma Emergente
• Ambiente: Durante a execucao da plataforma
• Resposta: Uma vez importados os dados e possıvel aceder e modifica-los atraves de
qualquer artefacto instalado sem a necessidade de modificar o processo de importacao de
dados ou os artefactos ja existentes.
• Medida: Nao sao afectados os dados e funcionalidades ja existentes na plataforma; o
tempo de configuracao estende-se por apenas alguns minutos
A.3.2.2 Tacticas
• Esconder os detalhes dos dados de modo a prevenir efeitos em cascata;
• Esconder os detalhes de leitura e escrita de dados emergentes de modo a prevenir efeitos
em cascata.
85
A.3.2.3 Arquitectura
• Definir o modulo “Dados” que esconde os detalhes dos dados;
• Definir o modulo “Operacoes” que esconde os detalhes das operacoes de leitura e escrita
dos dados.
Figura A.2: Decomposicao apos o segundo cenario.
A.3.3 Definicao de Tipos de dados
A.3.3.1 Cenario
• Fonte de Estımulo: Utilizador
• Estımulo: Criar ou modificar tipos de dados que corresponde a definicao de atributos
tipificados e atributos de identidade. Os atributos tipificados correspondem a campos
para guardar valores e podem ser emergentes ou prescritos — estes ultimos sao oriundos
de uma fonte de dados. Os atributos de identidade permitem identificar cada dado como
uma entidade unica independentemente da plataforma onde residem e das modificacoes
efectuadas aos valores dos seus atributos tipificados.
• Artefacto: Plataforma Emergente
• Ambiente: Durante a execucao da plataforma
• Resposta: A modificacao de tipos de dados existentes despoleta, se necessario, modi-
ficacoes automatizadas nos dados. Uma vez configurado um novo tipo de dados e possıvel
criar novos dados desse tipo e aceder aos mesmos atraves dos artefactos sem a necessidade
de modificar comportamento e funcionalidades ja existentes.
86
• Medida: Nao sao afectados os dados e funcionalidades ja existentes na plataforma; o
tempo de configuracao estende-se por apenas alguns minutos
A.3.3.2 Tacticas
• Generalizar o modulo de dados, isto e, aumentar o nıvel de abstraccao deste modulo de
modo a abranger qualquer tipo de dados definido em tempo de execucao;
• Esconder os detalhes de definicao de novos tipos de dados de modo a prevenir efeitos em
cascata. A definicao de novos tipos de dados ocorre em tempo de execucao ? corresponde
assim a uma configuracao dos mesmos.
A.3.3.3 Arquitectura
• Definir um sub-modulo do modulo “Dados” com a responsabilidade privada de abranger
qualquer tipo de dados;
• Definir um sub-modulo do modulo “Dados” com a responsabilidade privada de configurar
qualquer tipo de dados que o utilizador deseje.
Figura A.3: Decomposicao apos o terceiro cenario.
A.3.4 Importacao de Novos Dados
A.3.4.1 Cenario
• Fonte de Estımulo: Utilizador
87
• Estımulo: Importar novos dados de acordo com um tipo de dados configurado previa-
mente estabelecendo um mapeamento de atributos. Esses novos dados mantem atributos
de identidade que indicam a origem e entidade desse mesmo dado.
• Artefacto: Plataforma Emergente
• Ambiente: Durante a execucao da plataforma
• Resposta: Uma vez configurado o mecanismo de importacao, os dados sao importados
e ficam disponıveis na plataforma sem a necessidade de modificar o mecanismo de trans-
ferencia de dados ou outras funcionalidades ja existentes
• Medida: Nao sao afectados os dados e funcionalidades ja existentes na plataforma; o
tempo de configuracao estende-se por apenas alguns minutos
A.3.4.2 Tacticas
• Assegurar a coerencia semantica num modulo responsavel por todas as funcionalidades
que interagem com dados externos oriundos de sistemas prescritos;
• Esconder os detalhes do mecanismo de importacao de dados para prevenir efeitos em
cascata;
• Esconder os detalhes da configuracao do mecanismo de importacao;
• Abstrair uma interface comum para a criacao de dados durante o processo de importacao
de modo a manter a coerencia semantica.
A.3.4.3 Arquitectura
• Definir o modulo “Fonte de Dados” responsavel pelas funcionalidades que interagem com
dados externos oriundos de sistemas prescritos;
• Definir o modulo “Transferencia de Informacao” e o sub-modulo “Importacao” responsaveis
pela transformacao de informacao, neste caso, no sentido do exterior para o interior da
plataforma;
• Definir o modulo “Configuracao Fonte de Dados” que esconde os detalhes de configuracao;
• Definir o sub-modulo “Instanciacao de Dados” que esconde os detalhes na instanciacao de
um novo dado.
88
Figura A.4: Decomposicao apos o quarto cenario.
A.3.5 Importacao de Novos Dados mantidos num Ficheiro
A.3.5.1 Cenario
• Fonte de Estımulo: Utilizador
• Estımulo: Importar dados oriundos de um ficheiro (CSV por exemplo) tornando-os dis-
ponıveis nos artefactos instalados
• Artefacto: Plataforma Emergente (Dados e Fonte de Dados)
• Ambiente: Durante a execucao da plataforma
• Resposta: Uma vez configurado o conector “Ficheiro CSV” e o mecanismo de importacao,
os dados sao importados e ficam disponıveis de imediato na plataforma. Nao e necessario
modificar o mecanismo de importacao.
• Medida: A configuracao da fonte de dados demora ate 10 minutos e o carregamento e
automatizado
A.3.5.2 Tacticas
• Esconder os detalhes do processo de obtencao de dados a partir de um ficheiro CSV;
• Generalizar a configuracao dos conectores de modo que novos conectores sejam suportados
pelo modulo responsavel pela configuracao;
• Tornar a configuracao dos conectores auto-descriminativa de modo a prevenir efeitos em
89
cascata (assim o modulo de configuracao utiliza esses meta-dados para saber que modelo
de configuracoes e necessario para cada conector).
A.3.5.3 Arquitectura
• Definir o modulo “Conector” responsavel por obter dados;
• Definir o sub-modulo “Conector CSV” responsavel por obter dados a partir de um ficheiro
CSV.
• Definir o modulo de “Modelo de Configuracao” responsavel por declarar as configuracoes
necessarias para acesso ao servico de importacao de dados oriundos de um ficheiro CSV.
Figura A.5: Decomposicao apos o quinto cenario.
A.3.6 Importacao de Novos Dados mantidos num Sistema Prescrito
A.3.6.1 Cenario
• Fonte de Estımulo: Equipa de Desenvolvimento
• Estımulo: Importar um conjunto de dados atraves de um web service tornando-os dis-
ponıveis nos artefactos instalados
• Artefacto: Codigo
• Ambiente: Durante a implementacao da plataforma
90
• Resposta: Novo conector desenvolvido e instalado sem a necessidade de modificar funcio-
nalidades existentes ou outros conectores. Os mecanismos de transferencia de dados podem
ser reutilizados. Uma vez configurados o conector novo e o mecanismo de importacao, os
dados sao importados e ficam disponıveis de imediato na plataforma.
• Medida: A implementacao do novo conector demora alguns dias. A sua instalacao e
configuracao demora alguns minutos
A.3.6.2 Tacticas
• Esconder os detalhes de importacao de dados a partir de um sistema prescrito de modo a
prevenir efeitos em cascata.
A.3.6.3 Arquitectura
• Definir o modulo “Conector web service” responsavel por obter dados;
• Definir o modulo de “Modelo de Configuracao” responsavel por declarar as configuracoes
necessarias para acesso ao servico de importacao de dados por web service.
Figura A.6: Decomposicao apos o sexto cenario.
91
A.3.7 Exportacao de Dados
A.3.7.1 Cenario
• Fonte de Estımulo: Utilizador
• Estımulo: Exportar dados mantidos na plataforma para um ficheiro CSV
• Artefacto: Plataforma Emergente
• Ambiente: Durante a execucao da plataforma
• Resposta: Uma vez configurados o conector correcto e o mecanismo de exportacao, os
dados sao exportados para um ficheiro estruturado. Nao e necessario modificar artefactos,
dados, tipo de dados e configuracao de mecanismos de exportacao ja existentes
• Medida: A configuracao da fonte de dados demora ate 10 minutos e o carregamento e
automatizado
A.3.7.2 Tacticas
• Esconder os detalhes do processo de exportacao de dados para prevenir efeitos em cascata;
• Esconder os detalhes da configuracao do mecanismo de exportacao;
• Esconder os detalhes do processo de escrita de dados para um ficheiro CSV.
A.3.7.3 Arquitectura
• Definir os modulos “Exportacao”;
• Definir o sub-modulo de escrita no modulo “Conector CSV”.
A.4 Responsabilidade dos modulos
Plataforma Emergente: Plataforma base para o desenvolvimento de sistemas, pelos
proprios utilizadores finais, capaz de satisfazer as suas necessidades emergentes. Em particular,
o desenvolvimento de sistemas e realizado atraves de configuracao e customizacao da plataforma
e a utilizacao de dados oriundos de sistemas externos.
1 Artefactos: Modulo responsavel por apresentar um interface de utilizar e disponibilizar
um modelo de interaccao com os dados apresentados em cada tipo de artefacto.
92
Figura A.7: Decomposicao apos o setimo cenario.
2 Dados: Modulo responsavel por criar um interface generica de utilizacao de dados inde-
pendentemente destes serem emergentes ou prescritos e do sistema do qual sao oriundos
2.1 Operacoes: Modulo responsavel por disponibilizar um interface para a execucao
de operacoes genericas sobre os dados nomeadamente as operacoes CRUD (criacao,
leitura, actualizacao e eliminacao).
2.1.1 Instanciacao de Dados: Modulo responsavel por instanciar dados a partir de
um tipo de dados definido previamente
2.2 Tipo de Dados: Modulo responsavel pela definicao de estruturas que encapsulam
qualquer tipo de dado escondendo as suas particularidades. Este modulo, pela neces-
sidade de ser bastante generico, deve comportar os diferentes tipos de valores (inteiro,
decimal, caracter, cadeia de caracteres, booleano) e associacao entre dados. Por outro
lado, a definicao do tipo de dados suporta ainda a distincao entre atributos tipificados
e atributos de identidade. Os primeiros correspondem aos valores associados ao dado
em si, e os segundos correspondem a meta-informacao auxiliar indicativa da origem
e entidade de cada dado.
2.3 Configuracao Tipo de Dados: Modulo responsavel pela configuracao assistida dos
tipos de dados.
3 Fonte de Dados: Este modulo encapsula todas as funcionalidades necessarias para a
comunicacao com sistemas e dados externos. Essa comunicacao resume-se, em muito, a
importacao e exportacao de dados.
3.1 Configuracao Fonte de Dados: Modulo responsavel pela configuracao assistida
93
das fontes de dados.
3.2 Transferencia de Informacao: Modulo responsavel por importar e exportar dados
e a sua meta-informacao associada. Este modulo recebe dos conectores um conjunto
de valores que retratam uma entidade dado. Esse conjunto de valores foi lido atraves
da conexao estabelecida pelo conector, e sao usados para preencher a estrutura de
dados interna de acordo com o tipo de dados definido e o mapeamento realizado. Os
valores podem ainda ser transformados de acordo com regras de transformacao.
3.2.1 Comum: Modulo responsavel pelas funcionalidades comuns que sao usadas nos
dois mecanismos de transferencia de informacao : a importacao e a exportacao.
3.2.1.1 Rastreabilidade: Este modulo encapsula as funcionalidades associadas ao
requisito de rastreabilidade dos dados. Ou seja, os dados importados devem
manter a sua entidade de modo que em posteriores exportacoes seja possıvel
identificar o dado como aquele que foi importado anteriormente mesmo que
os seus valores tenham sido mudados. Por isso, os valores podem variar mas
a sua entidade mantem-se. Consequentemente sao necessarios dois tipos de
atributos: os atributos tipificados e os atributos de identidade. Sao os atri-
butos de identidade que conferem caracterısticas de rastreabilidade. Existe
ainda um estado associado a cada objecto que indica se este foi alterado ou
eliminado desde a ultima exportacao.
3.2.1.2 Mapeamento: Este modulo e responsavel por mapear o conjunto de valores
oriundos do conector em atributos definidos pelo tipo de dados.
3.2.2 Importacao: Este modulo encapsula o mecanismo de importacao de dados. Os
dados sao recebidos do conector numa estrutura generica de valores. Este modulo
e sub-modulos sao responsaveis por tipificar os valores, e carregar os dados num
modulo de persistencia. Este modulo usa o modulo auxiliar com o qual e possıvel
transformar valores antes de mapea-los na estrutura definida no tipo de dados.
3.2.2.1 Tipificacao: Modulo responsavel por tipificar os valores externos num tipo
de valor de acordo com os atributos.
3.2.2.2 Carregamento: Modulo responsavel por carregar para o repositorio. Trata-
se da ultima fase do processo de importacao.
3.2.3 Exportacao: Este modulo encapsula o mecanismo de exportacao de dados. Os
dados sao entregues ao conector numa estrutura generica de valores. Este modulo
94
e sub-modulos sao responsaveis por colectar as entidades que foram seleccionadas
como entidades a exportar. Essa seleccao e feita pelo utilizador atraves do modulo
de configuracao fonte de dados e consiste em escolher o tipo de dados e/ou o
estado da entidade nomeadamente se foi ou nao alterada.
3.2.3.1 Colecta Dados: Modulo responsavel pela seleccao dos dados internos se-
gundo a estrategia de exportacao definida
3.2.3.2 Transformacao Dados: Modulo responsavel por transformar os valores dos
varios atributos numa sequencia de valores perceptıvel para o conector.
3.3 Conector: Modulo responsavel pela ligacao da plataforma emergente ao ambiente
externo com o objectivo de obter dados. Esses dados externos surgem em diferentes
suportes com diferentes modos de obte-los. Nesse sentido, o modulo conector e res-
ponsavel por esconder as particularidades de cada modo de obtencao. Os conectores
devolvem ao modulo de importacao e recebem do modulo de exportacao um conjunto
de valores que retratam uma entidade dado.
3.3.1 Conector Ficheiro CSV: Este modulo encapsula o mecanismo de obtencao de
dados a partir de um ficheiro CSV. Neste tipo de ficheiros, cada linha contem um
conjunto de valores que retratam o dado. Esses valores podem estar separados
por um caracter especial que nao surge no corpo do valor (como por exemplo a
vırgula) ou e declarado um numero de caracteres fixo para cada coluna de valores.
3.3.1.1 Parsing: Este modulo e responsavel por realizar a extraccao de valores a
partir de um ficheiro de texto. A extraccao segue um conjunto de regras
definidas pelo utilizador assistido pela plataforma.
3.3.1.2 Producao (Escrita): Este modulo e responsavel por criar um ficheiro de
texto que segue determinadas regras na delimitacao de valores. Essas regras
sao definidas pelo utilizador.
3.3.1.3 Modelo de Configuracao: Este modulo e responsavel pela configuracao
neste conector em particular. Na configuracao deste conector surge a lo-
calizacao e nome do novo ficheiro, insercao de cabecalho e metodo de deli-
mitacao de valores
3.3.2 Conector web service: Este modulo encapsula o mecanismo de obtencao de
dados atraves de uma interface conhecida no momento de implementacao do
modulo. Existem duas vertentes neste tipo de conectores: (i) um conector
95
generico que comporta operacoes CRUD se o web service em questao assim o
permitir, ou (ii) conectores especıficos que orquestram uma sequencia de chama-
das a metodos, especıfica para o web service em questao, para obter ou entregar
dados externos.
3.3.2.1 Protocolo: Este modulo e responsavel pela orquestracao de metodos de
modo a ler, escrever, criar e eliminar dados. Deve ter em conta o contrato
do web service.
3.3.2.2 Modelo de Configuracao: Este modulo e responsavel pela configuracao
neste conector em particular.
96
Bi*/Tropos
B.1 Introducao
Um sistema de informacao e construıdo devido a uma intencao ou proposito inicial. O grau
de alinhamento do sistema com o seu proposito e a principal medida de sucesso desse sistema.
Portanto, identificar essa intencao deve ser considerado como uma das principais actividades no
desenvolvimento de sistemas (Lapouchnian 2005).
A Engenharia de Requisitos e o primeiro passo do processo de desenvolvimento de siste-
mas. Envolve varios aspectos fulcrais: a identificacao de objectivos dos stakeholders acerca do
sistema pretendido, a especificacao de servicos e restricoes que constrangem esses objectivos e
a atribuicao de responsabilidades de cada requisito resultante aos agentes, independentemente
de estes serem ou nao humanos (van Lamsweerde 2000). A modelacao aparece como o principal
processo nas varias tarefas. Tanto os sistemas e organizacao existentes, bem como, as possıveis
alternativas de configuracoes do sistema pretendido sao modelados. Estes modelos servem de
base para actividades de levantamento, comunicacao, negociacao, reutilizacao e evolucao de
requisitos, entre outras (Lapouchnian 2005).
Contudo uma das principais dificuldades da engenharia de requisitos e a imprecisao e infor-
malidade natural dos requisitos. Deve-se ao facto de se tratar de uma traducao de observacoes
informais do mundo real para linguagens formais de especificacoes (Yu and Mylopoulos 1998).
De facto, os requisitos existem num certo contexto social e portanto, durante o seu levanta-
mento, um elevado grau de comunicacao e negociacao e necessario. Lamsweerde apresenta em
(van Lamsweerde 2000) uma lista de aspectos que tornam a engenharia de requisitos um processo
complexo.
Dada essa complexidade inerente ao processo de engenharia de requisitos, tecnicas rigo-
rosas sao necessarias para proporcionar um suporte efectivo nesse processo. Nesse sentido,
as mesmas tem evoluıdo ao longo dos anos e recentemente tem surgido e ganho popularidade
tecnicas orientadas a objectivos. A razao de tal facto deve-se as tecnicas de analise tradicio-
nais mostrarem-se inadequadas a lidar com sistemas cada vez mais complexos. Ao nıvel dos
requisitos, estas tecnicas tradicionais tratam-nos como se resumissem apenas a accoes e dados
e desprezam a razao do sistema existente ou a intencao de construir um. Torna-se assim difıcil
de capturar as preocupacoes (de alto nıvel) do problema. A maioria das tecnicas limitam-se
a focar na modelacao e especificacao de sistemas, mas falham no suporte a analise do sistema
pretendido enquanto agente a existir num ambiente, ou a analise de diferentes configuracoes de
atribuicao de responsabilidades (van Lamsweerde 2000). A Engenharia de Requisitos Orientada
a Objectivos pretende resolver estes e outros problemas que as tecnicas tradicionais nao resol-
vem. Lapouchnian apresenta em (Lapouchnian 2005) um conjunto de benefıcios associados com
a modelacao, refinamento e analise de objectivos.
B.2 Principais Conceitos
Baseado em (Lapouchnian 2005; Anton 1996; van Lamsweerde 2001), sao definidos os se-
guintes conceitos no contexto da engenharia de requisitos:
• Objectivo e um proposito ou um alvo a atingir pelo negocio, organizacao ou sistema atraves
da cooperacao entre os seus agentes e o ambiente; podem ser formulados em diferentes
nıveis de abstraccao e podem-se catalogar em funcionais (acerca do servicos) ou nao fun-
cionais (acerca da qualidade dos servicos).
• Softgoal e usado para caracterizar um objectivo que nao possui um criterio de satisfacao
claro e facilmente mensuravel;
• Requisito e um objectivo cuja responsabilidade de satisfaze-lo e delegada a um unico agente
do ambiente, mais especificamente a um sistema;
• Assumpcao e um objectivo cuja responsabilidade de satisfaze-lo e delegada a um unico
agente do ambiente (onde o sistema existe). Especifica as expectativas que um sistema
pode esperar do seu ambiente, como por exemplo um aspecto sobre o comportamento
98
humano enquanto utilizador do sistema. Normalmente existe um equilıbrio entre o numero
de requisitos que tornam o sistema mais complexo e o numero de assumpcoes que em grande
quantidade podem tornar-se irrealistas;
• Restricao impoe um constrangimento sobre um outro objectivo, ou seja, e um requisito
que deve ser satisfeito como condicao necessaria para satisfazer um outro objectivo;
• Agente e um componente activo do sistema (ou organizacao), isto e, com capacidades
comportamentais, que procura alcancar atraves de accoes os objectivos pelos quais e res-
ponsavel;
• Operacionalizacao e o processo de definicao de objectivos com detalhe suficiente tal que os
seus subobjectivos possuem definicoes operacionais, diminuindo o desalinhamento entre o
espaco do problema (objectivos, requisitos e objectos) e o espaco das solucoes (operacoes
realizadas por agentes e objectos).
B.3 Caso de Estudo
Os exemplos utilizados para ilustrar as metodologias que se seguem sao baseados num caso
de estudo. Trata-se de um caso sobre o servico privado de saude no qual e estabelecido um
contrato entre um cliente designado de paciente e uma organizacao designada de seguradora.
O contrato explicita a disponibilidade de servicos de saude ao cliente segundo uma polıtica de
cobertura acordada entre o cliente e a seguradora em troca de um valor monetario.
B.4 i*/Tropos
Durante a fase de engenharia de requisitos e necessario balancear as consideracoes tecnicas
com os aspectos sociais e organizacionais, bem como, modelar o ambiente operacional onde o
sistema ira funcionar (Castro et al. 2002). Tropos segue a premissa que a construcao de um
sistema que opera num sistema dinamico obriga a analise e modelacao explıcita do ambiente em
termos de actores, seus objectivos e dependencias entre actores (Martınez et al. 2003). Seguindo
essa filosofia, e privilegiada a fase inicial de analise da requisitos onde e considerado o como o
sistema ira satisfazer os objectivos da organizacao, o porque da necessidade do sistema, que
99
alternativas existem, quais as implicacoes das varias alternativas sobre os varios stakeholders e
como os interesses e preocupacoes dos stakeholders sao geridos (Yu 1997).
A metodologia proposta prolonga-se por quatro fases: analise antecipada de requisitos,
analise prolongada de requisitos, desenho arquitectural e desenho detalhado. Segue-se a descricao
de cada fase acompanhada de um exemplo para as duas primeiras fases.
A analise antecipada de requisitos pretende esclarecer o contexto organizacional no qual um
eventual sistema ira operar. Ao permitir a tomada de atencao as actividades que precedem
a especificacao de requisitos do sistema a construir, pode-se capturar e analisar as intencoes
dos stakeholders modelando-as como objectivos. Esses objectivos tomam um papel essencial
durante a definicao dos requisitos. Visto de outra forma, enquanto os requisitos capturam o
que e o como do sistema a construir, a analise antecipada de requisitos captura a razao e o
porque do sistema ser desenvolvido. Esta perspectiva, por sua vez, suporta uma analise mais
refinada das dependencias do sistema e um tratamento mais uniforme entre requisitos funcionais
e nao funcionais. (Giorgini et al. 2004) A modelacao realizada nesta fase segue os modelos
adoptados da framework i* criado por Eric Yu. Esta framework oferece os conceitos primitivos
de actor, objectivo e dependencia entre actores. Os stakeholders sao representados como actores
que mantem dependencias entre si de modo a alcancarem objectivos e softgoals, realizarem
actividades e obterem recursos. Essas dependencias sao mantidas de forma deliberada, pois
o actor esta impossibilitado de satisfazer, totalmente ou pelo menos de uma forma eficiente e
eficaz, as suas necessidades sem ser pela via da dependencia. Nesse sentido, o actor possui
oportunidades de modo a satisfazer melhor e mais necessidades atraves da relacao dependencia
com outro actor, mas ao mesmo tempo torna-se vulneravel caso o fornecimento nao seja contınuo.
A framework i* inclui dois modelos: modelo de dependencia estrategica e modelo racional
estrategico.
O modelo de dependencia estrategica (do ingles, strategic dependency model) oferece um
determinado nıvel de abstraccao para a descricao de ambientes organizacionais e os sistemas de
informacao aı embebidos. Nesse nıvel de abstraccao e mostrado a rede de dependencias entre
actores escondendo os detalhes subadjacentes as intencoes internas que levaram a elaboracao de
determinada dependencia (Giorgini et al. 2004). Ou seja, este modelo captura as dependencias
externas que por serem suficientemente importantes para os actores sao mantidas por estes de
forma deliberada. Assim, e possıvel a analise das oportunidades e vulnerabilidades de cada actor.
100
Durante a analise prolongada de requisitos, este modelo e usado para analisar as mudancas que
a organizacao, e consequentemente a rede de dependencias inerente a organizacao, pode sofrer
devido a introducao de um sistema (Lapouchnian 2005).
No exemplo do servico privado de saude (figura B.1) o paciente depende do medico para
o tratamento da sua doenca (dependencia para atingir objectivo). O medico depende do labo-
ratorio para elaborar exames em amostras de sangue. Neste caso trata-se de uma dependencia
de tarefa, pois o medico esta interessado em atingir um estado – os exames obtidos – seguindo
um processo em particular – o processo cientıfico e rigoroso de analise de amostras de sangue.
O medico esta ainda dependente da aprovacao do plano de tratamento por parte da seguradora
(representada por um agente que efectua a gestao de pedidos) de modo a ser reembolsado pelas
suas despesas e servico efectuado. Ambas sao dependencias de recursos pois o medico deseja
obter uma entidade (declaracao de aprovacao e montante em dinheiro) sem se importar com
o processo em si. Existem ainda dependencias de objectivos e de softgoals entre agentes. Por
exemplo, o paciente esta interessado em ser tratado. Nesse caso existe um criterio claro de
satisfacao do objectivo - o do paciente curar-se. Por outro lado, o paciente procura por um bom
servico de saude. Neste caso nao existe um criterio claro e bem definido do conceito de bom
servico e consequentemente e tratado como sendo uma dependencia de softgoal.
Paciente Seguradora
Médico
Laboratório
Gestor de
Pedidos
Assessor
Médico
Doença
tratada
uu
Bom Serviço
Médico
Cobertura
sobre doenças
Pagamento
u u
u
uu
u
Elaborar testes
em amostras
u
u
Aprovação do
tratamento
Reembolso das
despesas
u
u
u
u
Rapidez na
Aprovação de
Pedidos
Política de
Cobertura
u
uu
Tratamento
Avaliadou
u
Eficiência
nos Custos
u
u
u
u
Actor
Objectivo
Softgoal
Recurso
Dependência
Tarefa
Legenda:
Figura B.1: Modelo de dependencia estrategica para o caso de estudo.
Durante a analise antecipada de requisitos, contudo, e indispensavel aclarear as razoes e
interesses dos stakeholders, bem como, o modo como esses interesses e regulado e o impacto de
diferentes configuracoes do conjunto sistema e ambiente sobre esses interesses (Yu 1997). O mo-
delo racional estrategico (do ingles, strategic rationale model) e usado para analisar com grande
101
detalhe os processos internos ao actor explicitando a razao pela qual os actores estabelecem
dependencias entre si. Os conceitos — objectivos, softgoals, recursos e actividades — aparecem
nao so como dependencias externas, mas tambem como elementos internos ligados por dois tipos
de relacoes. Um dos tipos de ligacao — means-ends — e usado para especificar alternativas para
alcancar cada objectivo. O outro tipo — decomposicao — liga um objectivo ou actividade aos
elementos que o compoem. Existe ainda outro tipo de ligacoes similar as ligacoes da framework
NFR. Essas ligacoes especificam dois nıveis de contribuicao positiva (“+” e “++”) ou negativa
(“−” e “−−”) que informam o efeito positivo (ou negativo) sobre um determinado softgoal ao
satisfazer um objectivo ou realizar uma actividade (Lapouchnian 2005).
Voltando ao mesmo exemplo, a figura B.2 mostra o racional do gestor de pedidos quando
pretende avaliar um pedido. O agente necessita de verificar se o tratamento e coberto pelo
seguro do paciente (tarefa) e obter uma avaliacao medica (objectivo) durante um perıodo de
tempo aceitavel (softgoal). Este racional e capturado atraves da decomposicao da tarefa prin-
cipal. Existem duas alternativas de obter uma avaliacao medica: requerer essa avaliacao junto
de um assessor medico, ou o proprio agente efectuar a avaliacao com a ajuda de um sistema de
conhecimento medico que possui a informacao necessaria (dependencia de recurso). Esta ultima
alternativa tem uma contribuicao positiva na rapidez do processo, enquanto a primeira alterna-
tiva aumenta o tempo global do processo. Essas contribuicoes foram igualmente capturadas no
modelo.
Seguradora
Médico
Sistema de
Conhecimento
Médico
Assessor
Médico
u
u
Aprovação do
tratamento
Rapidez na
Aprovação de
Pedidos
Política de
Coberturau
Tratamento
Avaliado
u
Gestor de
Pedidos
Avaliar
Pedido
Verificar
Cobertura do
Paciente
Pedido
Avaliado
Avaliação
Médica Obtida
+
-
Efectuar
Avaliação
Requerer
Avaliação
Rapidez na
Avaliação
u
u
Conhecimento de
Avaliação Médica
+-u
Actor
Objectivo
Softgoal
Recurso
Fronteira do Actor
Decomposição
Contribuição positiva
Contribuição negativa
Dependência
Tarefa
Means-ends
Legenda:
Figura B.2: Modelo racional estrategico para o caso de estudo.
Durante a analise prolongada de requisitos, o modelo conceptual desenvolvido durante a
fase antecedente e estendido de forma a incluir o sistema a desenvolver como um (ou mais) novo
actor em conjunto com as dependencias entre este novo actor (o sistema) e os outros (o ambiente
102
do sistema). Estas dependencias definem os requisitos funcionais e nao funcionais desse novo
sistema. Por outras palavras, o sistema de informacao aparece no diagrama como um ou mais
actores que contribuem para a satisfacao de objectivos de outros actores (Castro et al. 2002).
Do desenho arquitectural resulta uma arquitectura do sistema que descreve como os compo-
nentes trabalham em conjunto. Em Tropos foram organizados estilos arquitecturais organizacio-
nais para guiar o desenho da arquitectura. Esses estilos arquitecturais sao baseados em conceitos
de gestao de organizacoes e foram avaliados e comparados entre si segundo varios atributos de
qualidade. Em (Castro et al. 2002) e mostrado uma tabela de comparacao.
A primeira tarefa passa por seleccionar o estilo arquitectural usando um criterio sobre as
qualidades ou softgoals desejados e identificados nas fases previas. Essa analise e conduzida pela
framework NFR. De seguida o sistema a desenvolver e decomposto segundo o estilo arquitectural
escolhido.
A fase de desenho detalhado introduz detalhes adicionais para cada componente arquitec-
tural do sistema.
B.5 Sumario
Segue uma descricao das principais vantagens e desvantagens dos varios metodos analisados.
Apesar de tudo, apenas o Tropos foi descrito em pormenor ao longo do anexo.
As vantagens da framework NFR devem-se em parte por esta focar-se na analise de requisi-
tos nao funcionais, ao contrario de outras tecnicas que nao dao a importancia devida. Torna-se
relevante devido a importancia dos requisitos nao funcionais no sucesso e adopcao dos sistemas
de informacao. A framework oferece uma ferramenta de modelacao que permite capturar as con-
tribuicoes de uns requisitos sobre outros e analisar e comparar as diferentes alternativas. Apesar
de nao capturar a relevancia que cada stakeholder da a cada requisito e de nao possuir muitos
dos conceitos e ferramentas de outras tecnicas, a framework NFR pode e deve ser usada em
conjunto com outras metodologias. Nesta framework e ainda utilizado catalogos de informacao
que capturam e organizam o conhecimento de experiencias anteriores.
O Tropos foca-se no contexto organizacional e nas intencoes dos stakeholders. Entre as
tecnicas descritas nesta seccao, e a mais completa para todo o processo de engenharia de re-
103
quisitos. Adoptou os conceitos e diagramas do i* que se focam nas actividades de modelacao
antes da formulacao dos requisitos. O i* e ainda acompanhado com outras metodologias que
reduzem a subjectividade inerente a modelacao de objectivos, como e o caso da metodologia
RiSD (Grau et al. 2005). O Tropos tem ainda a vantagem de usar os mesmos conceitos — actor
e objectivo — tanto para descrever requisitos como tambem para modelar sistemas diminuindo,
assim, a diferenca semantica entre as fases inicias e finais de desenvolvimento (Giorgini et al.
2004). Possui a desvantagem de ainda nao existirem ferramentas que suportam a transicao entre
as diferentes fases (Giorgini et al. 2004).
O KAOS permite usar uma notacao formal que torna-se util aquando da analise de conflitos
e obstaculos. Possui a desvantagem de nao fornecer um metodo de avaliacao de requisitos nao
funcionais e impacto das decisoes. Contudo uma variacao da framework NFR pode ser integrada
no KAOS (Lapouchnian 2005). Por outro lado, apenas os objectivos correspondentes aos nos-
folha resultantes da decomposicao sao delegados a agentes, tornando a tecnica inapropriada para
a analise de sistemas complexos onde a componente social entre agentes revela-se importante.
Adicionalmente a delegacao dos objectivos a agentes ocorre apos a seleccao entre alternativas
do modelo de objectivos, o que se revela numa desvantagem na analise de alternativas.
Durante a analise de casos de emergencia de sistemas de informacao e necessario focar-se
no contexto organizacional e nas intencoes dos utilizadores que promovem esses sistemas que
emergem. A tecnica escolhida para a analise sera o Tropos, pois revela-se a mais adequada para
a analise de requisitos num contexto organizacional onde as intencoes dos stakeholders e a com-
ponente social entre agentes sao importantes. Os sistemas de informacao emergentes resultam
da adopcao de tecnologia emergente ou da reinvencao de tecnologia prescrita atraves de novos
padroes e regras de trabalho que nao foram planeadas pela governacao da organizacao. Ambas
possuem um racional fundamentado dos seus promotores que se resume em necessidades, objec-
tivos e intencoes dos utilizadores. A metodologia Tropos e a que melhor captura esse racional
importante na engenharia de sistemas de informacao emergentes. Adicionalmente a metodolo-
gia Tropos e particularmente apropriada para sistemas genericos constituıdos por componentes
como aplicacoes e-bussiness que podem ser usados numa variedade de ambientes e plataformas
(Castro et al. 2002).
104
![Introdu¸c˜ao a Complexidade de Kolmogorovacm/cpx1.pdf · 2012. 10. 15. · Cap´ıtulo 1 Informa¸c˜ao e Objectos A Teoria de Informa¸c˜ao segundo Shannon ([Sha48]) quantifica](https://img.pdfslide.tips/doc/110x75/611ee0e79ac7755f6d5e8e92/introducoeao-a-complexidade-de-kolmogorov-acmcpx1pdf-2012-10-15-captulo.jpg)
