Universidade São Tomás de Moçambique

Faculdade Ciências e Tecnologias de Informação

Lourino Alberto Chemane Júnior

Proposta de aplicativo para gestão e execução de processos de reconciliação de

transacções resultantes da interoperabilidade de sistemas.

Maputo, Setembro de 2022

 Universidade São Tomás de Moçambique
Faculdade Ciências e Tecnologias de Informação

Lourino Alberto Chemane Júnior

Proposta de aplicativo para gestão e execução de processos de reconciliação de

transacções resultantes da interoperabilidade de sistemas.

Supervisor: Luís Olumene, Msc.

Monografia para obtenção do grau de licenciatura em Administração de Sistemas
de Informação e Redes de Computadores

Maputo, Setembro de 2022

 Dedicatória
A minha família e a todos que directa ou indirectamente e de diferentes formas
tornaram possível a minha formação. Em especial aos meus pais que sempre me
apoiaram de modo a seguir em frente.

i
 Agradecimento
Agradeço à minha mãe Sandra Salvador Inguane Chemane e ao meu pai Lourino
Alberto Chemane que sempre estiveram ao meu lado e batalharam por anos para
proporcionar a melhor educação para seus filhos. A minha namorada Clara Karina pelo
apoio, partilha de conhecimentos e experiências durante a jornada académica. Aos meus
irmãos que acreditaram no meu sonho e me deram forças todos os dias.
Agradeço imenso a todos incomparáveis docentes que se dedicaram a ensinar e
compartilhar todo o seu conhecimento. Um agradecimento especial ao meu supervisor
Luís Olumene, pois fez toda a diferença na orientação da minha monografia.
Agradeço aos meus familiares e amigos, que apesar das minhas ausências
frequentes, sempre me apoiaram e demonstraram a sua gratidão nesta longa caminhada.
E agradeço a todos os que, directa ou indirectamente, contribuíram na minha
formação académica e pessoal.

ii
 Declaração de honra
Eu, Lourino Alberto Chemane Júnior declaro por minha honra que sou autor
deste trabalho, o qual submeto à Universidade São Tomás de Moçambique em
cumprimento dos requisitos para a obtenção do grau de Licenciatura em Administração
de Sistemas de Informação e Redes. Este trabalho é fruto de uma investigação e o seu
conteúdo original e todas as fontes consultadas estão devidamente mencionadas no
contexto, nas notas e nas referências bibliográficas. Declaro, ainda, que este trabalho
nunca foi apresentado em nenhuma outra instituição de ensino para obtenção de
qualquer grau académico.

Lourino Alberto Chemane Júnior

________________________________________________________________
Maputo, Setembro de 2022

iii
 Resumo
Os conceitos de interoperabilidade e a integração desempenham um papel
crucial para a implementação de mecanismos que permitem efectuar transacções a fim
de consumir serviços de diversas empresas através de bancos comerciais, facilitando a
ligação entre estes dois tipos de intervenientes. Contudo, muitas vezes, a reconciliação
bancaria é única maneira que as equipes de finanças tem para verificar o que realmente
acontece dentro dos negócios e se está de acordo com o esperado. Deste modo, surge a
necessidade de tornar o processo de reconciliação de transacções resultantes da
interoperabilidade eficiente e eficaz. O presente estudo visa desenhar o modelo da
aplicação para gestão e execução de processos de reconciliação de transacções
resultantes da interoperabilidade de sistemas. Foi realizada uma pesquisa qualitativa de
carácter exploratório, mediante o uso de entrevistas e análise documental, bem como o
uso de metodologias ágeis de desenvolvimento de aplicações por forma apurar as
dificuldades enfrentadas para concepção de uma aplicação que se adapte facilmente as
necessidades.

Palavras-chave: Reconciliação, transacções, interoperabilidade, Metodologias

ágeis, TIC’s.

iv
 Abstract
The concepts of interoperability and integration play a crucial role in the
implementation of mechanisms that allow transactions to be carried out in order to
consume services from various companies through commercial banks, facilitating the
connection between these two types of actors. However, often, bank reconciliation is the
only way that finance teams have to verify what really happens within the business and
if it is in line with expectations. Thus, the need arises to make the process of
reconciliation of transactions resulting from interoperability efficient and effective. The
present study seeks to design an application for managing and executing transaction
reconciliation processes resulting from systems interoperability. An exploratory
qualitative research was carried out, through the use of interviews and document
analysis, as well as the use of agile application development methodologies in order to
determine the difficulties faced in designing an application that easily adapts to the
needs.

Keywords: Reconciliation, transactions, interoperability, agile methodologies,

ICTs.

v
 Índice de figuras
Figura 2.1.1.1 : Conta ativo, passivo e patrimônio líquido representados em
conta T. ............................................................................................................................. 6
Figura 2.2.1 : Diagrama de um processo. ............................................................. 7
Figura 2.3.1: Exemplos de cabeçalhos http. ......................................................... 8
Figura 2.4.2.1.1: Fluxo do Scrum para um Sprint .............................................. 12
Figura 2.4.2.2.1: Um exemplo de quadro kanban .............................................. 13
Figura 2.5.1: Arquitetura MVC .......................................................................... 14
Figura 2.7.1.1: Diagrama de tradução de programa Java para linguagem de
máquina. ......................................................................................................................... 15
Figura 4.1.1.1: Actual processo de reconciliação de transacções........................23
Figura 4.2.1: Novo processo de reconciliação de transacções ........................... 25
Figura 4.5.1.1.1: Diagrama de casos de uso do administrador ........................... 26
Figura 4.5.1.2.1: Casos de uso do usuario e da entidade externa ....................... 27
Figura 4.5.2.1: Diagrama de classes ................................................................... 28
Figura 4.5.3.1: Diagrama de entidades e relacionamentos. ................................ 29
Figura 4.5.4.1: Diagrama de atividades para visualizar o relatório de
reconciliação ................................................................................................................... 30
Figura 4.5.5.1: Diagrama de sequência de login ................................................ 31
Figura 4.5.5.2: Diagrama de sequência para criar um processo de reconciliação
........................................................................................................................................ 32
Figura 4.5.5.3: Diagrama de sequência para visualizar relatório de reconciliação
........................................................................................................................................ 33
Figura F.1: Tela de login……………………………………………………………50
Figura F.2: Tela principal do usuário..…………………………………………….51
Figura F.3: Tela principal do administrador..……………………………………..52
Figura F.4: Formulário de criação de processo de reconciliação.………………..53
Figura F.5: Tela de relatório de reconciliação……………………………………..54

vi
 Índice de tabelas
Tabela 2.9.1: Comparação entre soap e rest webservice...................................18
Tabela B.1: Requisitos Funcionais da aplicação ................................................ 43
Tabela D.1: Casos de Uso do administrador ...................................................... 46
Tabela E.1: Casos de uso do usuário e da entidade externa. .............................. 49

vii
 Lista de Abreviaturas
API – Application Programming Interface
CSS – Cascading Style Sheets
ECMA – European Computer Manufacturers Association
HTML – HyperText Markup Language
HTTP – Hypertext Transfer Protocol
MVC – Model View Controller
REST – Representational State Transfer
RUP – Rational Unified Process
SGBD – Sistema de Gestão de Base de Dados
SOAP – Simple Object Access Protocol
SQL – Structured Query Language
TIC’s – Tecnologias de Informação e Comunicação
UML – Linguagem de Modelagem Unificada
WEB – World Wide Web

viii
Índice
Dedicatória............................................................................................................. i

Agradecimento...................................................................................................... ii

Declaração de honra ............................................................................................ iii

Resumo ................................................................................................................ iv

Abstract ................................................................................................................. v

Índice de figuras .................................................................................................. vi

Índice de tabelas ................................................................................................. vii

Lista de Abreviaturas ......................................................................................... viii

1. Introdução ................................................................................................... 1

1.1. Contextualização ........................................................................................ 1

1.2. Descrição do Problema .............................................................................. 2

1.3. Justificativa ................................................................................................ 3

1.4. Objectivos .................................................................................................. 4

1.4.1. Objectivos gerais .............................................................................. 4

1.4.2. Objectivos específicos ...................................................................... 4

2. Fundamentação Teórica .............................................................................. 5

2.1. Contabilidade ............................................................................................. 5

2.1.1. Livro diário ....................................................................................... 6

2.2. Processo de reconciliação bancaria ............................................................ 7

2.3. Aplicação web ............................................................................................ 8

2.4. Desenvolvimento de aplicações ................................................................. 9

2.4.1. Rational Unified Process .................................................................. 9

2.4.2. Metodologias ágeis de desenvolvimento ........................................ 11

2.4.2.1. Scrum ............................................................................................. 12

2.4.2.2. Kanban ........................................................................................... 13

2.5. Arquitectura Model-View-Controler ....................................................... 13

ix
 2.6. Linguagem de modelação de aplicações .................................................. 14

2.7. Linguagem de Programação .................................................................... 14

2.7.1. Java ................................................................................................. 15

2.7.2. JavaScript ....................................................................................... 15

2.8. Linguagem de marcação e estilização web .............................................. 16

2.9. Tecnologias de integração........................................................................ 16

2.10. Sistema de gestão de base de dados ....................................................... 17

3. Metodologia .............................................................................................. 19

3.1. Metodologia de desenvolvimento da aplicação .................................... 20

4. Apresentação dos resultados..................................................................... 23

4.1. Actual processo de reconciliação de transacções no âmbito de

interoperabilidade ....................................................................................................... 23

4.2. Limitações do actual processo de reconciliação de transacções de

interoperabilidade .................................................................................................... 24

4.3. Descrição do novo processo de reconciliação de transacções no âmbito

interoperabilidade ....................................................................................................... 24

4.4. Camadas de aplicação ........................................................................... 25

4.5. Diagramas ............................................................................................. 26

4.5.1. Diagrama de caso de uso ................................................................... 26

4.5.1.2. Usuário e entidade externa .......................................................... 27

4.5.2. Diagrama de classes .......................................................................... 27

4.5.3. Diagrama de entidades e relacionamentos ........................................ 28

4.5.4. Diagrama de actividades ................................................................... 29

4.5.5. Diagrama de sequência...................................................................... 30

5. Conclusões e recomendações ................................................................... 34

5.1. Conclusões ............................................................................................ 34

5.2. Recomendações .................................................................................... 35

6. Referências bibliográficas ........................................................................ 36

x
APÊNDICES ...................................................................................................... 41

xi
 1. Introdução
1.1. Contextualização
As Tecnologias de Informação e Comunicação (TIC’s) estão presentes nos
diversos sectores da sociedade, no entanto, elas desempenham um papel importante na
área bancaria pois contribuiu para o aumento do potencial dos bancos em oferecer mais
produtos e serviços, ampliando sua capacidade de serem mais funcionais.
Os bancos comerciais em Moçambique na intenção de providenciar produtos e
serviços financeiros de alta qualidade aos seus clientes, criam diversas parcerias com
outras empresas, e algumas delas culminam na ligação dos sistemas do banco com os
sistemas de outras empresas, ou seja, culminam na interoperabilidade de sistemas.
Contudo, de acordo com Insights for professionals (2019), no ato de
transaccionar recursos financeiros uma das principais tarefas de uma equipe de finanças
é manter todas as partes do negócio a funcionar perfeitamente.
Segundo Khartit (2021), as equipes de finanças verificam se as transacções
requisitadas ocorreram efectivamente através da reconciliação.
Nesse contexto, para verificar se todas as transacções resultantes da
interoperabilidade com outros sistemas ocorreram com sucesso os bancos comerciais
precisam efectuar a reconciliação dessas transacções.
No entanto, para tornar a reconciliação eficiente e eficaz é importante considerar
o uso de soluções tecnológicas, pois essas ferramentas podem tirar muitos dos processos
manuais das mãos dos colaboradores para que eles possam se focalizar na execução de
outras tarefas importantes.
O presente trabalho visa propor uma aplicação para melhorar a gestão e
execução de processos de reconciliação de transacções resultantes da interoperabilidade
de sistemas.
Como forma de embasamento prático do conteúdo deste trabalho, foi realizada
uma entrevista em uma instituição idónea, íntegra e sólida do ramo de bancos. Porém,
por questões de sigilo a empresa será chamada de Banco XPTO.

1
 1.2. Descrição do Problema
O Banco XPTO conta com uma aplicação para a execução de reconciliação de
transacções adquirida através de terceiros. A aplicação permite inserir, reconciliar e
visualizar relatórios de reconciliação de transacções. Contudo, a aplicação de
reconciliação possui limitações na gestão da informação relacionada com o processo de
reconciliação de transacções resultantes da interoperabilidade de sistemas, o que causa
os seguintes problemas:
 Processos lentos de entrada de dados: a aplicação de reconciliação apenas
suporta a entrada de dados em um formato de ficheiro proprietário, isso exige
que os dados das transacções que o banco e os parceiros possuem sejam
convertidos para o ficheiro compatível com a aplicação de reconciliação antes de
serem inseridos na aplicação de reconciliação do banco.
 Dados de entrada sujeitos a erros: quando os dados são convertidos e
inseridos na aplicação de reconciliação podem ocorrer erros em qualquer estágio
do processo, e quanto mais etapas tiver nesse processo mais provável isso se
torna, podendo dar uma impressão imprecisa do fluxo de caixa.
 Potencial para fraude: embora a detenção de fraude seja um dos motivos mais
importantes para a realização de reconciliação, se o processo não tiver
supervisão adequada, eles também podem ser usados por funcionários
maliciosos para esconder evidências de delitos dentro da instituição.

2
 1.3. Justificativa
O processo de reconciliação de transacções é considerada uma actividade
demorada e que consome muitos recursos, portanto requer mecanismos eficientes para a
sua execução e gestão. No entanto, é fundamental o estudo e desenvolvimento de
ferramentas baseadas nas novas TIC’s que simplifiquem o trabalho dos profissionais
que trabalham na reconciliação de transacções resultantes da interoperabilidade de
sistemas, de modo a melhorar a monitoria, armazenamento, disseminação e gestão de
informações em todo o processo.
A proposta na qual o trabalho se assenta, tem em vista o auxílio a gestão de
processos de reconciliação de transacções resultantes da interoperabilidade de sistemas
com recurso as tecnologias Web.

3
 1.4. Objectivos
1.4.1. Objectivos gerais
O presente trabalho consiste em desenhar o modelo de um aplicativo para gestão
e execução de processos de reconciliação de transacções resultantes da
interoperabilidade dos sistemas do Banco XPTO com os sistemas de outras empresas.
1.4.2. Objectivos específicos
 Analisar o processo actual de reconciliação de transacções resultantes da
interoperabilidade dos sistemas do banco com outras empresas;
 Identificar os requisitos necessários para o desenvolvimento da aplicação
para gestão e execução de processos de reconciliação de transacções
resultantes da interoperabilidade dos sistemas do banco com outras
empresas.
 Definir o modelo da aplicação para gestão e execução de processos de
reconciliação de transacções resultantes da interoperabilidade dos sistemas
do banco com outras empresas.

4
 2. Fundamentação Teórica
2.1. Contabilidade
A contabilidade pode ser entendida como ciência social que visa fornecer
informações de natureza económica de uma determinada pessoa física ou jurídica. O
objecto da contabilidade é o património, que pode ser entendido como o conjunto de
bens, direitos e obrigações que uma pessoa física ou jurídica possui. (Lyrio, Almeida, &
Portugal, 2015)
De acordo com Olivo e Boschilia (2012) as informações contabilísticas
registram todos os fatos que ocorrem e podem ser representados em valor monetário.
Tais informações interessam as seguintes entidades pelas seguintes razões:
 Bancos: têm interesse em verificar a capacidade financeira das pessoas e
empresas antes de conceder crédito para conhecer a viabilidade económica e
a capacidade de pagamentos;
 Empresas ou pessoas: para auxiliar na tomada de decisões e realizar planos;
 Governo: necessita de obter informações sobre as receitas e as despesas, bem
como o lucro obtido para que possa cobrar correctamente as taxas.
A técnica utilizada pela contabilidade para registrar, em ordem cronológica,
todos os fatos que ocorrem no património de uma pessoa física ou jurídica, assim como
para fornecer informações sobre a composição e as variações ocorridas em determinado
período é a escrituração. (Bächtold, 2011)
Segundo Olivo e Boschilia (2012), a escrituração pode ser feita de várias
maneiras, tais como:
 Manual: é escrita com a mão;
 Maquinizada: é escrita através de máquinas dactilográficas;
 Electrónica: é escrita através de programas ou aplicações de computador.
Para efectuar à escrituração contábil dos actos e dos fatos que ocorrem no
património de uma pessoa física ou jurídica recorre-se aos livros contábeis. (Bächtold,
2011)
De acordo com The Corporate Finance Institute (2019), o livro contábil que todo
contabilista deve dominar é o livro diário, pois sem domínio desse livro os registros
contabilísticos de uma pessoa física ou jurídica seriam imprecisos.

5
 2.1.1. Livro diário
Uma maneira fácil de entender o livro diário é pensando na terceira lei de Isaac
Newton, que afirma que, para cada acção, há uma reacção oposta. Assim, sempre que
houver uma transacção, deve haver pelo menos duas contas sendo afectadas. (The
Corporate Finance Institute, 2019)
O livro diário é o livro contábil para o qual é efectuado o lançamento diário de
todos os actos ou operações que modifiquem ou possam a vir a modificar a situação
patrimonial da pessoa física ou jurídica. (Olivo & Boschilia, 2012)
De acordo com The Corporate Finance Institute (2019), os livros diários podem
ser registrados e rastreados em uma conta chamada Conta T. A Conta T é uma
representação visual de contas individuais que se parece com um “T” para que todas as
adições e subtracções à conta possam ser facilmente rastreadas. O lado esquerdo da
conta T é sempre o lado do débito e o lado direito é sempre o lado do crédito, não
importa qual seja a conta. Porém, para diferentes contas, débitos e créditos podem
significar um aumento ou uma diminuição. Contudo, os principais tipos de contas
usadas para acompanhar transacções financeiras são:
 Conta Activo: contabiliza todos os bens que a pessoa jurídica ou física
possui seja, dinheiro, estoque, equipamentos e automóveis.
 Conta Passivo: contabiliza todas as obrigações que a pessoa jurídica ou física
deve para os outros em uma data futura, como empréstimos bancários,
contas por pagar, entre outros.
 Conta Património líquido: contabiliza todos os direitos que a pessoa jurídica
ou física pode reivindicar sobre um determinado activo.
Agora vejamos os diferentes tipos de conta representados na conta T.

Figura 2.1.1.1 : Conta activo, passivo e património líquido representados em

conta T.
Fonte: Autor.

6
 Para conta activo o lado esquerdo da conta T (lado do débito) é sempre um
aumento na conta. O lado direito (lado do crédito) é uma redução para a conta do activo.
Para contas de passivo e património líquido, os lados de débito e crédito da conta T são
os mesmos, no entanto, o lado débito significa uma diminuição na conta e o lado do
crédito significa um aumento na conta.
2.2. Processo de reconciliação bancaria
Processo é um conjunto de actividades inter-relacionadas com o objectivo de
transformar insumos (input) em produto (output). (Damelio, 2011)

Figura 2.2.1 : Diagrama de um processo.

Fonte: (Scartezini, 2009)
Entender como funciona um determinado processo é importante porque permite
saber como gerir o processo de modo a atingir melhores resultados na sua execução.
Segundo Damelio (2011), o mapeamento do processo é uma ferramenta analítica que
tem a intenção de ajudar a melhorar processos existentes. Esse processo mapeia dados
como o nome, objectivo, entradas (insumos) e saídas (produto) do processo, com vista a
explicar as actividades desenvolvidas dentro do processo.
Para entender como funciona o processo de reconciliação, Kelly (2015) explica
o seguinte:
 Objectivo: a reconciliação bancaria é efectuada com o objectivo de
certificar que todas as transacções efectuadas em um determinado
período de tempo ocorreram sem erros, de modo a dar confiabilidade e
precisão aos registos contabilísticos.
 Entradas do processo: os dados de entrada de um processo de
reconciliação são transacções e as contas afectadas pelas transacções.
 Saídas do processo: a reconciliação bancaria resulta na criação de um
relatório. O objectivo do relatório é ilustrar as transacções efectuadas,
porém indicando efectivamente os débitos e créditos entre as contas
afectadas pela transacção.

7
 2.3. Aplicação web
Uma aplicação ou programa de computador é uma sequência de instruções
projectadas para direccionar um computador para executar determinadas funções.
Embora comumente associada a internet, a web é uma rede de conteúdo em HTML que
podem ser acedidos pela internet e/ou intranet. A web está dividida em 3 partes: o
servidor, que contém os documentos e imagens, a rede pela qual as informações
trafegam e o cliente que possui um navegador da web que exibe as informações. Assim
sendo, uma aplicação web é uma aplicação que é executado em um servidor e acedido
por meio de um navegador da web. (Maxim & Pressman, 2016)
Para que haja transmissão de dados entre o cliente e o servidor na web é
necessário seguir o protocolo HyperText Transfer Protocol (HTTP). O protocolo HTTP
usa Uniform Resouce Locator (URL) para identificar e efectuar requisições de
informações na web. Normalmente a URL é formado pelo protocolo, nome do servidor
e o caminho para um determinado recurso. Ex.: http://localhost/helloworld
Além do URL, cada requisição e resposta do protocolo HTTP contêm um
header (cabeçalho). O header visa disponibilizar informações adicionais relacionadas
com a requisição ou resposta enviada. (Mozilla, 2022)

Figura 2.3.1: Exemplos de cabeçalhos HTTP.

Fonte: (Mozilla, 2022)
De acordo com Mozilla (2022), para a execução do processamento de
requisições no servidor web existe um método responsável por processar determinados
tipos de informação, tais como:
 Get: efectua busca ou pesquisa de registos em um servidor web;
 Post: efectua o envio de dados ao servidor web para efeitos de inserção ou
adição de registos;
 Put: efectua o envio dados ao servidor para efeitos de actualização de
registos inseridos;

8
  Delete: usado para remover registos do servidor web.
 Head: obter dados do cabeçalho.

2.4. Desenvolvimento de aplicações

O processo de desenvolvimento de aplicações é um conjunto de actividades
relacionadas que levam a produção de uma aplicação a partir do zero. (Sommerville,
2011)
O desenvolvimento de aplicações, segundo Maxim e Pressman (2016) é
realizado nas seguintes fases:
1. Fase de definição e planeamento da aplicação: visa fornecer uma indicação
da viabilidade da aplicação através da análise de requisitos para poder fazer
levantamento dos recursos necessários e as estimativas de custos.
2. Fase de desenvolvimento: consiste na produção da especificação de projecto
com vista a efectuar a codificação.
3. Fase de verificação, manutenção e realização de testes: visa descobrir o
máximo de erros. Faz-se a manutenção da aplicação ao longo da sua vida
útil.
2.4.1. Rational Unified Process
O RUP, em português Processo Unificado Racional, é um modelo de processo
de desenvolvimento de aplicações moderno, iterativo e incremental, que fornece uma
abordagem disciplinada para a atribuição de tarefas e responsabilidades no processo de
desenvolvimento de programas. O seu objectivo é garantir a produção de programas de
alta qualidade que atendam as necessidades dos seus usuários finais. (Wysocki, 2014)
Segundo Sommerville (2011), o RUP foi concebido usando como base boas
práticas do desenvolvimento de aplicações, que consiste em abordagens comercialmente
aprovadas para o desenvolvimento de aplicações. Para tornar o RUP adequado para uma
ampla gama de projectos de desenvolvimento de aplicações o modelo adoptou as
seguintes boas práticas:
 Usar arquitecturas baseadas em componentes;
 Modelar visualmente a aplicação;
 Verificar continuamente a qualidade da aplicação.

9
 A componente de uma aplicação pode ser definida como um módulo, pacote ou
subsistema com uma função ou responsabilidade que pode ser integrado em uma
arquitectura bem definida.
De acordo com Maxim e Pressman (2016), o desenvolvimento de aplicações
baseado em componentes tem os seguintes benefícios:
 Uma arquitectura modular permite identificar, isolar, desenvolver e testar
componentes bem organizados. Esses componentes podem ser testados
individualmente e integrados gradualmente para formar um sistema;
 Alguns componentes podem ser desenvolvidos para serem reutilizáveis,
especialmente os componentes que fornecem soluções comuns para uma
ampla gama de problemas comuns.
Modelar visualmente a aplicação nos ajuda a compreender e moldar o problema
e a sua solução, ou seja, é a simplificação de um problema real para ajudar a
compreender um sistema complexo. (Sommerville, 2011)
No modelo RUP não existe trabalhador responsável somente pela qualidade da
aplicação, pois a qualidade da aplicação é responsabilidade de cada membro da equipe
de desenvolvimento da aplicação. A verificação da qualidade da aplicação em RUP é
efetuada por meio de teste, porém o teste não é efetuado apenas no produto final, ele
inicia com o desenvolvimento da aplicação, e é efetuado em cada módulo presente na
arquitectura da aplicação. (Wysocki, 2014)
Segundo Maxim e Pressman (2016), o teste é executado em diferentes estágios
no desenvolvimento da aplicação. Estes estágios progridem a partir dos elementos mais
pequenos até ao sistema como um todo. Os quatro estágios de teste são:
 Teste unitário: os menores elementos testáveis do sistema são testados
individualmente, normalmente no momento em que esses elementos são
implementados;
 Teste de integração: as unidades integradas (ou componentes ou
subsistemas) são testadas;
 Teste de sistema: o aplicativo ou sistema completo é testado;
 Teste de aceitação: o aplicativo ou sistema completo é testado por usuários
finais (ou representantes) com propósito de determinar a prontidão para
implantação.

10
 2.4.2. Metodologias ágeis de desenvolvimento
A metodologia ágil de desenvolvimento é uma abordagem utlizada no âmbito
de desenvolvimento de aplicações com vista a apoiar equipas de desenvolvimento a
entregar novas aplicações rapidamente para obterem proveito de novas oportunidades e
responder a pressões competitivas. Processos de desenvolvimento de aplicações que
planejam especificar completamente os requisitos e em seguida construir e testar uma
aplicação, não estão adaptados ao desenvolvimento rápido de aplicações, pois se houver
mudança ou descoberta de problemas o projecto e a implementação da aplicação
precisam ser refeitos e consequentemente é entregue depois do tempo planificado.
(Sommerville, 2011)
Segundo Wysocki (2014), o desenvolvimento ágil é fruto da constatação feita
por diversos profissionais renomados da área de engenharia de software, de que, só
conseguiriam minimizar os riscos associados ao desenvolvimento de aplicações se
pensassem e agissem de forma diferente do que tradicionalmente está nos livros. Com
base nisso, criaram o manifesto para o desenvolvimento ágil de aplicações,
frequentemente chamado manifesto ágil.
Surgiram várias metodologias ágeis após o manifesto ágil, tais como: Scrum,
Kanban, entre outros. Contudo, segundo Sommerville (2011) os princípios das
metodologias ágeis são:
 Envolvimento do cliente: os clientes devem estar intimamente envolvidos no
processo de desenvolvimento, com objectivo de fornecer e priorizar novos
requisitos da aplicação e avaliar suas interacções.
 Entrega incremental: a aplicação é desenvolvida em incrementos com o
cliente, especificando cada requisito para serem incluídos.
 Pessoas, não processos: cada membro da equipe deve desenvolver suas
próprias maneiras de trabalhar, sem processos prescritivos.
 Aceitar as mudanças: deve-se ter em mente que os requisitos do sistema vão
mudar. Por isso, projectar a aplicação de maneira a acomodar essas
mudanças.
 Manter a simplicidade: sempre que possível, trabalhar activamente para
eliminar a complexidade da aplicação.

11
 2.4.2.1. Scrum
Scrum é uma metodologia ágil projectada para entregar valor significativo
rapidamente ao longo de um projecto, e é caracterizada por ser adaptativa, interactiva,
rápida, flexível e eficaz, de modo a garantir transparência na comunicação de
responsabilidades e do progresso colectivo. (Wysocki, 2014)
SCRUMstudy™ (2016) explica que um ponto forte do Scrum está no uso de
equipas multifuncionais, auto-organizadas e capacitadas que dividem seu trabalho em
ciclos de trabalho curtos e concentrados chamados Sprints.
O ciclo de desenvolvimento começa com uma reunião de Stakeholders, durante
a qual a visão do projecto é criada. O Product Owner (proprietário do produto) então
desenvolve um Backlog que contém os requisitos prioritários do projecto. Cada Sprint
começa com uma reunião de planeamento do Sprint. O Sprint geralmente dura entre
uma e seis semanas e envolve a equipe Scrum trabalhando para criar entregáveis ou
incrementos de produto. Durante o Sprint, são conduzidas reuniões diárias, curtas e
altamente focadas, onde membros da equipe discutem o progresso diário.
No final do Sprint, uma reunião de revisão do Sprint é realizada, onde o Product
Owner e os Stakeholders recebem uma demonstração dos entregáveis. O Product
Owner aceita as entregas somente se elas atenderem aos critérios de aceitação
predefinidos. O ciclo termina com uma reunião de retrospectiva, onde a equipe discute
maneiras de melhorar os processos e desempenho à medida que avançam para o Sprint
subsequente. (SCRUMstudy™, 2016)

Figura 2.4.2.1.1: Fluxo do Scrum para um Sprint

Fonte: (SCRUMstudy™, 2016)

12
 2.4.2.2. Kanban
Segundo Anderson e Carmichael (2016) a metodologia kanban foi projectada
para tornar visíveis conhecimentos intangíveis para garantir a entrega de um
determinado produto. Para alcançar o seu objectivo, o kanban faz uso de cartões que
representam tarefas e um fluxo de estágios pré-estabelecidos que visam limitar a
quantidade de tarefas em progresso através de sinais visuais para prevenir que seja feito
demasiado ou pouco trabalho, com vista a servir maior valor aos clientes.
Kanban é uma metodologia para definir, gerenciar e melhorar serviços que
envolvem partilha de conhecimento, tais como: serviços profissionais de design de
produtos físicos e de software.

Figura 2.4.2.2.1: Um exemplo de quadro kanban

Fonte: (Anderson & Carmichael, 2016)
2.5. Arquitectura Model-View-Controler
A arquitectura MVC (Modelo-Visão-Controle) é uma forma de dividir as
funcionalidades de objectos envolvidos na manutenção e apresentação de dados para
minimizar o grau de acoplamento entre os objectos. Foi originalmente desenvolvido
para mapear o processo tradicional de entrada de dados (input), processamento,
informação de saída (output) com a interface gráfica para interacção do usuário. Esta
abstracção ajuda no processo de separação do aplicativo em módulos lógicos para que
possa ser facilmente arquitectado. (Maxim & Pressman, 2016)
Na arquitectura MVC, a camada modelo é a essência da aplicação, e é formada
por um conjunto de classes com o objectivo de auxiliar a implementação de uma
determinada lógica de negócio. A camada visão é a camada de interface de usuário, e é
formada por um conjunto de classes que representam telas. A camada controlo é a
camada da lógica de negócios, e é formada por classes que implementam a lógica de
negócio para solucionar um determinado problema.

13
 Figura 2.5.1: Arquitectura MVC
Fonte: (de Almeida, s/d)
2.6. Linguagem de modelação de aplicações
Modelagem da aplicação consiste em produzir modelos abstratos que representa
uma visão ou perspetiva diferente da aplicação, com vista a explicar o funcionamento
do mesmo. (Sommerville, 2011)
Maxim & Pressman (2016) definem a Linguagem Unificada de Modelagem
(UML) como sendo uma linguagem de modelagem visual de uso geral que permite
especificar, visualizar, construir e documentar artefactos de um sistema ou aplicação.
Para representar o sistema, o UML recorre a vários diagramas para oferecer
múltiplas visões ao sistema a ser modelado. Porém subdividem-se nos seguintes grupos
de diagrmas:
 Diagramas de casos de uso: representam a visão do sistema na perspectiva
do seu utilizador.
 Diagramas de classes: especificam a estrutura estática de um sistema
segundo a abordagem orientada por objectos.
 Diagramas de interacção entre objectos, transição de estados e actividades:
especificam a dinâmica ou o comportamento de um sistema segundo a
abordagem orientada por objectos.
 Diagramas de componentes e de instalação: dão uma visão da disposição dos
componentes físicos (software e hardware) de um sistema.
2.7. Linguagem de Programação
Em uma sociedade, a comunicação entre os seus membros é mediatizada por
uma linguagem. Desde que os computadores passaram a fazer parte da nossa sociedade,
tornou-se incontornável a necessidade de dialogarmos com eles. Para satisfazer essa
necessidade foi preciso estabelecer uma ponte entre a linguagem humana e a linguagem
de máquina. Aceite este princípio, a consequência é de que é preciso um ser humano
descreva seus problemas num programa escrito numa linguagem de programação que

14
seja próxima da sua linguagem e é forçoso que o computador traduza esses programas
na sua própria linguagem. (Costa, 2015)
2.7.1. Java
Segundo Eck (2014), quase todas as aplicações ou programas são escritos em
linguagens de programação de alto nível, porém uma linguagem de alto nível não pode
ser executada directamente em qualquer computador, primeiro deve ser traduzido para a
linguagem de máquina por um programa chamado compilador. Uma vez feita a
tradução, o programa em linguagem de máquina pode ser executado qualquer número
de vezes, mas só pode ser executado em um tipo de computador. Os programas escritos
em Java são compilados em linguagem de máquina, mas é uma linguagem de máquina
para um computador virtual. Este computador "virtual" é conhecido como Java Virtual
Machine. A linguagem de máquina para o Java Virtual Machine é chamada de Java
bytecode.

Figura 2.7.1.1: Diagrama de tradução de programa Java para linguagem de

máquina.
Fonte: (Eck, 2014)
2.7.2. JavaScript
De acordo com Haverbeke (2018), o JavaScript foi inicialmente apresentado
como uma forma de adicionar programas no navegador Netscape, mas após a sua
adopção em outros navegadores a associação europeia de fabricantes de computadores
(European Computer Manufacturers Association - ECMA) estabeleceu o padrão
ECMAScript, para que diferentes tipos de aplicações pudessem suportar a execução da
linguagem. Assim sendo, a linguagem de programação JavaScript é uma tecnologia de
aprimoramento da web, pois a linguagem permite tornar uma página HTML estática em
uma página com conteúdo interactivo.

15
 2.8. Linguagem de marcação e estilização web
Linguagens de marcação e estilização são omnipresentes na computação
cotidiana, devido a necessidade que as aplicações de processamento de documentos
possuem em estruturar e apresentar documentos.
Em aplicações de computadores, marcação de texto é definido como o conjunto
de instruções que definem a estrutura lógica de um texto. A marcação de texto é
efectuada por meio da linguagem de marcação, que visa em codificar a estrutura lógica
de um documento mantendo a capacidade de distinguir marcações de texto e texto
simples de um documento. (Powell, 2010)
Ao efectuar marcação de texto surge a necessidade de definir propriedades de
texto, tais como: tamanho da fonte, família de fontes, espessura da fonte, alinhamento
de parágrafo e outros. Para definir as propriedades do texto é necessário usar uma
linguagem de estilo pois, visa descrever a representação visual de documentos
estruturados.
Para o desenvolvimento web a linguagem de marcação usada é HTML e a
linguagem de estilização usada é CSS.
O HTML é o acrónimo para HyperText Markup Language, que significa
linguagem de marcação de hipertexto. Segundo Powell (2010), HTML é uma linguagem
de marcação usada para descrever aos navegadores web a estrutura de uma página web.
Instruções de marcação encontradas em um documento HTML retransmitem a
estrutura da página da Web para o navegador através da disposição dos elementos que
posteriormente são interpretadas pelos navegadores web para poder exibir a página ao
utilizador.
O CSS é o acrónimo para Cascading Style Sheets, e de acordo com Powell
(2010) oferece à web designers um mecanismo para o controle do estilo de uma página
web. Sendo assim, as regras de CSS podem ser colocadas directamente na maioria dos
elementos do documento HTML com o propósito de deixar as páginas mais atractivas e
amigáveis ao utilizador final.
2.9. Tecnologias de integração
Para a integração de sistemas recorre-se à web services e outras tecnologias. De
acordo com Sommerville (2011), web services são aplicações que promovem
portabilidade e reusabilidade em aplicações web, pois permitem que uma aplicação
armazenada em um computador possa ser acessado por uma outra aplicação em outro
computador através de uma rede.

16
 A comunicação entre aplicações em computadores diferentes é possível graças
às API’s que disponibilizam web services para que terceiros possam consumir. Os dois
principais tipos de web services são: SOAP e REST.
O SOAP e REST webservices possuem as seguintes diferenças:
Tabela 2.9.1 : Comparação entre soap e rest webservice
Item SOAP REST
Estrutura de dados Protocolo baseado Protocolo
em XML baseado no estilo
arquitectural
Comunicação de Utiliza padrão de Utiliza XML ou
dados mensagens baseado em JSON para envio e
XML recebimento dos dados
Comunicação Invoca serviços por Baseado 100%
meio de http e rpc (remote em http e nas URI’s
procedure call)
Formato da Resultado Resultado
mensagem codificado no padrão SOAP facilmente interpretado
por um humano
Compatibilidade com Complexa Simplificada
JavaScript
Desempenho Médio Alto
Fonte: Autor
2.10. Sistema de gestão de base de dados
De acordo com Elmasri & Navathe (2015), uma base de dados é uma colecção
de dados que pode ser mantida em ficheiros de sistema operativo ou em um sistema de
gestão de base de dados (SGBD). O SGBD é um programa que visa auxiliar a criação e
a manipulação de bases de dados. Contudo, manter uma base de dados em um SGBD
tem as seguintes vantagens:
 Acesso de dados eficiente: os SGBD fornecem mecanismos eficientes para
busca e armazenamento dos dados.
 Redução do tempo de desenvolvimento de aplicações: os SGBD fornecem
várias funcionalidades importantes exigidas por aplicações, tais como:

17
 controle de simultaneidade, falhas, recuperação, facilidades de consulta de
alto nível, entre outros.
 Integridade e segurança de dados: o mecanismo de manipulação de dados em
SGBD requer autorizações, permitindo dessa forma controle ao acesso e
manipulação dos dados.
 Acesso simultâneo: o SGBD suporta a noção de uma transacção, que é
conceitualmente um programa sequencial de um único usuário. Sendo assim,
os usuários podem escrever transacções como se seus programas estivessem
sendo executados isoladamente no banco de dados
Normalmente os sistemas de gestão de base de dados estão associados a
Linguagem de Consulta Estruturada (Structured Query Language - SQL), pois uma
grande porção dos sistemas de gestão de base de dados faz uso do SQL. SQL é uma
linguagem de computador usada para interagir com uma base de dados. Porém, SQL
não é um produto autónomo, é integrante de um sistema de gestão de base de dados, por
isso, anda associado ao SGBD.
Actualmente existem diversos SGBD que fazem uso do SQL, a seguir iremos
destacar o MySQL e o SQL Server.
O MySQL é o SGBD de código aberto mais popular do mundo, pois permite que
pequenas, medias e grandes organizações possam oferecer aplicativos com base de
dados escaláveis e de alto desempenho de maneira económica. (MySQL, 2022)
O MySQL oferece suporte para várias linguagens de programação tais como:
Java, Python, JavaScript, PHP, C, C++, C#, entre outros. Adicionalmente pode ser
executado também em diversos sistemas operativos como Linux, Windows, Mac OS.
O SQL Server é um SGBD desenvolvido e comercializado pela Microsoft que
lidera o mercado pelo facto de oferecer alta escalabilidade, desempenho e
disponibilidade para aplicativos de missão crítica. (Microsoft, 2022)
Contudo, o SQL Server possui vários benefícios, porém o seu uso para fins
comerciais acarreta custos elevados, além de fornecer fraca compatibilidade com outros
sistemas operativos em comparação com outros SGBD.

18
 3. Metodologia
Em ciências, método é um conjunto de procedimentos e técnicas racionais
adoptadas com o objectivo de ampliar o conhecimento sobre um determinado objecto,
fato ou fenómeno. (Zanella, 2013)
A metodologia visa estudar os métodos usados para efectuar uma determinada
pesquisa, de modo a compreender todos os procedimentos e técnicas implementadas
para executar a pesquisa.
A presente pesquisa pode ser classificada da seguinte forma:
 Quanto a natureza
Quanto a natureza classifica-se como aplicada, pois possui referencial teórico
como base para gerar soluções para problemas específicos (de Oliveira, 2011). Visto
que o processo de reconciliação de transacções resultantes da interoperabilidade de
sistemas do banco e outras empresas possui défices, o presente trabalho visa
implementar uma solução para melhorar o processo de reconciliação.
 Quanto a abordagem
Quanto a abordagem classifica-se como qualitativa, pois preocupa-se em
compreender de forma lógica todas as informações que explicam um determinado
fenómeno ao invés de utilizar elementos estatísticos. (Zanella, 2013)
Esta abordagem é ideal para a pesquisa, pois busca explorar e compreender os
problemas encontrados no processo de reconciliação de transacções resultantes da
interoperabilidade de sistemas de entidades diferentes sem recorrer a medidas
estatísticas para a compreensão do processo.
 Quanto ao objectivo
Quanto ao objectivo classifica-se como exploratória, pois segundo Zikmund,
Babin, Carr, e Griffin (2010) a pesquisa exploratória visa diagnosticar situações
ambíguas procurando definir o problema de modo a gerar informações claras para a
investigação. A investigação procede através da análise dos estudos efectuados no
assunto, interagindo com pessoas conhecedoras do assunto e investigando
informalmente o assunto.
 Quanto ao procedimento técnico
Quanto ao procedimento técnico classifica-se como bibliográfica, pois consiste
no uso de fontes bibliográficas com vista a dar maior cobertura dos dados ao

19
pesquisador. Ex.: livros, revistas, jornais, boletins, monografias, dissertações, teses,
artigos da internet, entre outros. (Zanella, 2013).
 Técnicas de recolha de dados
Para a execução do presente trabalho foi feita a combinação de duas técnicas de
recolha, nomeadamente:
o Entrevista: consiste em uma conversa de duas ou mais pessoas, sendo
que pelo menos uma delas responde a um conjunto de questões, com o
propósito de colectar informações sobre um determinado assunto.
(Zikmund, Babin, Carr, & Griffin, 2010) Para a realização deste trabalho
foram feitas entrevistas no Banco XPTO. Conforme é descrito no
apêndice A, foram entrevistados os técnicos responsáveis pela gestão das
aplicações do banco.
o Análise documental: embora seja semelhante a pesquisa bibliográfica,
essa análise diferencia-se pelo facto de basear-se em dados que ainda não
receberam tratamento analítico (de Oliveira, 2011). A análise documental
permitiu o aprofundamento de conhecimentos de áreas relacionadas com
a pesquisa tendo como base informações em bibliotecas e na internet.
 Análise e interpretação de dados
A análise e interpretação de dados é o passo que sucede a recolha e manipulação
de dados, consistindo em organizar os dados de modo que sejam interpretados e
proporcionem respostas a investigação. (Zikmund, Babin, Carr, & Griffin, 2010)
Os dados obtidos na entrevista e análise documental foram a base para
identificar os problemas encontrados durante o processo de reconciliação de transacções
resultantes da interoperabilidade de sistemas de entidades diferentes.
3.1. Metodologia de desenvolvimento da aplicação
Para o desenvolvimento da aplicação objecto deste trabalho, foram utlizadas as
seguintes metodologias e ferramentas:
 Processo de desenvolvimento
Projectos de desenvolvimento de aplicações as vezes falham devido a vários
factores, e a tardia descoberta dessas falhas é apenas um sintoma para problemas
maiores que são causados por inconsistências não detectadas nos requisitos e
implementações do projecto. Para resolver essas falhas desde a raiz foi escolhido o
processo de desenvolvimento RUP, pois propõe desenvolver e manter a aplicação de
forma repetitiva e previsível, seguindo boas práticas do desenvolvimento de aplicações.
20
  Metodologia ágil de desenvolvimento
Para o desenvolvimento da aplicação recorreu-se a metodologia ágil de
desenvolvimento kanban, pois visa organizar fluxos de trabalho auxiliando a
visualização das tarefas, optimização do tempo e maior agilidade.
 Modelação da aplicação
Para a realização deste trabalho foi utilizada a linguagem de modelação UML
porque é usada universalmente pela indústria de engenharia de software para expressar
modelos baseados em paradigmas de orientação a objectos.
Para a modelação da aplicação foram escolhidos os seguintes digramas:
o Diagrama de caso de uso: para descrever os requisitos funcionais da
aplicação.
o Diagrama de classes: para demonstrar a estrutura das classes da
aplicação.
o Diagrama de entidades e relacionamentos: para representar as
diferentes entidades dentro da aplicação e como se relacionam.
o Diagrama de actividades: visa mostrar o fluxo de acções da aplicação
e seus resultados.
o Diagrama de sequência: para apresentar a colaboração dinâmica entre
os atores da aplicação.
 Gestão de base de dados
Para efectuar a gestão de uma base de dados na maior parte dos casos recorre-se
a sistemas de gestão de base de dados.
Para a realização deste trabalho foi escolhido o MySQL para efectuar a gestão da
base de dados da aplicação, pois fornece suporte para as necessidades do aplicativo em
desenvolvimento a baixo custo.
 Linguagem de programação
A criação de aplicações pressupõe o uso de linguagens de programação, deste
modo, o autor recorreu as seguintes linguagens:
o Java: programas escritos na linguagem de programação java podem ser
executados em qualquer computador, tudo que o computador precisa é de
um compilador para bytecode Java.
o JavaScript: a linguagem de programação JavaScript permite tornar uma
página HTML estática em uma página com conteúdo interactivo.

21
  Linguagem de marcação
Para o desenvolvimento de interfaces de aplicações web é usada a linguagem de
marcação HTML, pois é o padrão para a criação de estruturas de páginas web.
 Linguagem de estilo
Para efectuar a estilização de páginas HTML usa-se a linguagem de estilo
Cascading Style Sheets (CSS).

22
 4. Apresentação dos resultados
4.1. Actual processo de reconciliação de transacções no âmbito de
interoperabilidade
Para a realização de reconciliações de transacções no âmbito da
interoperabilidade, o banco recebe ficheiros das empresas com as quais efectua a
interoperabilidade. Nesses ficheiros o banco recebe as transacções efectuadas no dia
anterior.
Neste contexto, é desenvolvida uma aplicação que ficará em modo de espera ou
escuta de ficheiros e irá iniciar o processo de reconciliação das transacções assim que
forem disponibilizados os ficheiros esperados para a data correspondente.
Com a aplicação desenvolvida pretende-se que os ficheiros a serem enviados
pelas empresas sejam inseridos na aplicação de reconciliação, e as transacções
armazenadas na base de dados do banco sejam convertidas em ficheiros para que sejam
inseridas na aplicação de reconciliação.
Após inseridas as transacções na aplicação de reconciliação é executada a
reconciliação. Por fim, os profissionais de finanças do banco acedem a aplicação de
reconciliação para poder ter acesso ao relatório de reconciliação das transacções
reconciliadas pela aplicação de reconciliação.

Figura 4.1.1: Actual processo de reconciliação de transacções

Fonte : Autor

23
 4.2. Limitações do actual processo de reconciliação de transacções de
interoperabilidade
A aplicação actual para reconciliação de transacções do banco é uma ferramenta
excelente para a reconciliação de transacções, mas apesar disso ela possui limitações
que impedem de tornar o processo de reconciliação de transacções resultantes da
interoperabilidade de sistemas seja eficiente e eficaz, a destacar as seguintes:
 A aplicação não suporta a leitura de dados na base de dado relacional
SQL adoptada no banco, por esse motivo surge necessidade de criar
aplicações com o propósito de ler dados das transacções na base de
dados e converter em ficheiros a fim de inserir transacções na aplicação.
No entanto, o processo de conversão de dados consome tempo e para
grandes empresas com imensas transacções, pode drenar rapidamente os
recursos, deixando-os com menos tempo do dia para outras actividades
importantes.
 Não é segura a permissão de leitura e escrita de ficheiros no directório
onde a aplicação de reconciliação efectua a leitura dos ficheiros de
reconciliação para utentes fora do domínio do banco pois é para esse
directório que vão todos os ficheiros de reconciliação, por esse motivo
surge a necessidade de criar aplicações com o propósito de recolher
ficheiros gerados pelas outras empresas a fim de inserir dados na
aplicação. No entanto, após os ficheiros de reconciliação serem movidos
para o banco, se um funcionário (banco) tiver permissão para modificar
os ficheiros manualmente pode alterar dados para encobrir os rastros de
alguém que cometeu fraude.
4.3. Descrição do novo processo de reconciliação de transacções no âmbito
interoperabilidade
Com a nova aplicação o processo actual de reconciliação de transacções
resultantes da interoperabilidade de sistemas sofre alterações significativas, pois as
transacções internas passam a ser lidas pela aplicação directamente na base de dados do
banco e as transacções externas passam a ser inseridas através de web services ao invés
de ficheiros em directórios.
Com a nova aplicação pretende-se criar, visualizar, actualizar, apagar e executar
processos de reconciliação resultantes da interoperabilidade dos sistemas do banco com
outras empresas.
24
 O aplicativo irá disponibilizar uma interface gráfica que permitirá criar,
visualizar, actualizar, apagar processos de reconciliação com diferentes entidades
externas e visualizar os relatórios resultantes da reconciliação.

Figura 4.3.1: Novo processo de reconciliação de transacções

Fonte: Autor
4.4. Camadas de aplicação
A aplicação proposta utiliza a arquitectura MVC que visa segregar a aplicação
em 3 camadas com vista a repartir um problema grande em porções menores.
A camada modelo visa auxiliar a camada de controle, sendo composta por
classes que representam tabelas de base de dados e estruturas de input ou output dos
web services.
A camada visão visa representar telas, sendo composta por ficheiros HTML que
representam páginas web, para além do uso de linguagem de programação de marcação,
predomina também o uso de linguagem de estilo CSS e a linguagem de programação
JavaScript com vista a tornar a experiência do utilizador agradável por meio validações
de erros e implementação de interfaces bonitas.
A camada controle serve de veículo de ligação entre a camada de visão e
modelo, pois gere o fluxo e a manipulação de dados necessária para a implementação
das regras de reconciliação. A linguagem de programação predominante nesta camada é
o Java, porque responde as solicitações dos utilizadores e executa a reconciliação.

25
 4.5. Diagramas
4.5.1. Diagrama de caso de uso
Face aos requisitos da aplicação, foram elaborados três diagramas de caso de uso
para ilustrar como os administradores, usuários e a entidade externa poderão interagir
com a aplicação.
4.5.1.1. Administrador

Figura 4.5.1.1.1: Diagrama de casos de uso do administrador

Fonte: Autor

26
 4.5.1.2.Usuário e entidade externa

Figura 4.5.1.2.1: Casos de uso do usuario e da entidade externa

Fonte: Autor
4.5.2. Diagrama de classes
O diagrama de classes fornece uma visão geral da aplicação, com propósito de
construir um código executável e descrever as interacções que os administradores ou
usuários e as entidades externas têm através da camada visão com os controladores para
poder executar a reconciliação.

27
 Figura 4.5.2.1: Diagrama de classes
Fonte: Autor
4.5.3. Diagrama de entidades e relacionamentos
O diagrama de entidades e relacionamentos permite representar de forma
abstracta a estrutura de uma base de dados por meio da ilustração das entidades e
atributos ou relacionamentos que a entidade contém.
Para o armazenamento de informações são necessárias nove entidades em que
cada uma armazena um determinado tipo de informação. A entidade Usuário armazena
os dados dos usuários e administradores. A entidade Conta e Subconta armazenam os
dados relacionados com contas de reconciliação. A entidade Nome armazena os dados
relacionados com nome de contas, usuários e administradores. A entidade Transacao
armazena dados das transacções. A entidade Relatorio armazena dados das transacções
reconciliadas. A entidade Regra armazena os dados relacionados com as regras para a
reconciliação. A entidade Entidade_Externa armazena dados relacionados com as
empresas que efectuam interoperabilidade com o banco. A entidade
Base_De_Dados_Interna armazena os dados necessários para poder aceder as bases de
dados internas que contem as transacções internas.

28
 Figura 4.5.3.1: Diagrama de entidades e relacionamentos.
Fonte: Autor
4.5.4. Diagrama de actividades
O diagrama de actividades conforme mencionado na metodologia, é óptimo para
a modelagem de processos, pois visa ilustrar os processos envolvidos em uma
actividade. Abaixo é ilustrado um diagrama de actividades com os processos que o
usuário deve passar para poder visualizar o relatório de reconciliação.

29
 Figura 4.5.4.1: Diagrama de actividades para visualizar o relatório de
reconciliação
Fonte: Autor
4.5.5. Diagrama de sequência
Os diagramas de sequência permitem visualizar os diferentes momentos da
execução de um processo, dando uma visão geral do comportamento e das
responsabilidades de cada um dos intervenientes do processo. A seguir são apresentados
três diagramas de sequência: login, criar processo de reconciliação e visualizar relatório
de reconciliação.
 Login: este diagrama ilustra o processo de login de usuários ou
administradores. Inicia com a introdução de credencias de acesso, a partir de
uma interface gráfica que invoca o método login que vai ao controlador de
dados e verifica se as credencias são válidas. Caso sejam válidas o usuário é
redireccionado para a tela principal da aplicação. Caso sejam inválidas é
exibida uma mensagem de erro na interface.

30
 Figura 4.5.5.1: Diagrama de sequência de login
Fonte: Autor
 Criar processo de reconciliação: após o login, uma das principais
funcionalidades da aplicação é a criação de processo de reconciliação. O
administrador na tela principal selecciona a opção processo de reconciliação,
esse pedido lhe direcciona para o formulário de criação de processos de
reconciliação. Em seguida o administrador preenche o formulário e pressiona
o botão criar, o pedido será reencaminhado para o controlador que invoca o
método registrar que efectua o registo do processo de reconciliação.
Independentemente do estado do processo de registo será exibida uma
mensagem com o respectivo estado.

31
 Figura 4.5.5.2: Diagrama de sequência para criar um processo de reconciliação
Fonte: Autor
 Visualizar relatório de reconciliação: a obtenção do relatório de
reconciliação é crucial para o funcionamento da aplicação, pois permite aos
usuários da aplicação visualizar o relatório dos processos de reconciliação
criados. Após o login, o usuário na tela principal selecciona relatório de
reconciliação, esse pedido lhe direcciona para a tela de relatórios. Em
seguida, o usuário pesquisa do relatório de reconciliação preenchendo os
campos de filtragem que são apresentados na tela de relatórios e selecciona o
botão pesquisar, o pedido será reencaminhado para o controlador de dados
através do método visualizar, por sua vez o controlador devolve a lista de
transacções reconciliadas a interface, por fim a interface filtra a lista
devolvida pelo controlador e exibe o relatório de reconciliação ao usuário.

32
Figura 4.5.5.3: Diagrama de sequência para visualizar relatório de reconciliação
Fonte: Autor

33
 5. Conclusões e recomendações
5.1. Conclusões
Com o desenvolvimento do presente trabalho foi possível apresentar uma
solução que responde as limitações encontradas no processo de reconciliação de
transacções resultantes da interoperabilidade dos sistemas do Banco XPTO com os
sistemas de outras empresas.
A implementação da solução é uma mais-valia no âmbito da exploração de
tecnologias emergentes com vista a conferir eficiência, eficácia e interactividade entre
diferentes sistemas.
A aplicação apresenta melhorias significativas na gestão de processos de
reconciliação no âmbito de interoperabilidade, pois provê maior controle na gestão das
transacções que serão reconciliadas, bem como capacidade de diferentes sistemas
interagir directamente com a aplicação.
Para além de melhorar o processo actual de reconciliação no âmbito de
interoperabilidade, a nova aplicação possui uma vantagem em comparação com actual,
pelos seguintes motivos:
 Reduz custos de produção, pois deixa de haver necessidade de se produzir
programas com o objectivo de converter dados para inserir na actual aplicação
de reconciliação do banco
 Reduz o consumo de recursos computacionais do banco alocados a programas
com o objectivo de converter dados para inserir na aplicação de reconciliação,
liberando os recursos computacionais do banco para outras tarefas mais
importantes.
Com a implementação desta aplicação, o Banco XPTO passará a gerir melhor os
seus recursos, sendo capazes de criar e executar em curto espaço de tempo os processos
de reconciliação no âmbito de interoperabilidade.
A aplicação proposta mostrou-se versátil, uma vez que apresenta uma
arquitectura simples podendo funcionar completamente independente e assim ser
aplicado em cenários similares principalmente na área bancária.

34
 5.2. Recomendações
Com base na experiência adquirida durante o desenvolvimento da pesquisa o
autor deixa as seguintes recomendações:
Banco:
o Partilhar o modelo da aplicação com outras instituições que actuam na
área bancária.
o Efectuar implementação do modelo da aplicação.
Usuários:
o Manter as suas credenciais de acesso a plataforma segura;
o Propor melhorias a aplicação.

35
 6. Referências bibliográficas
Abreu. (2016). Desenvolvimento de um sistema Web para utilização e gerenciamento
de dados de Cupons Fiscais e Saúde.
Anderson, D. J., & Carmichael, A. (2016). Essential Kanban condensed. Seattle, WA:
Lean Kanban University Press.
Associação Moçambicana de Bancos. (2021). Serviços Bancários. Obtido em 1 de 12 de
2021, de Associação Moçambicana de Bancos: amb.co.mz/index.php/educacao-
financeira/servicos-bancarios
Bächtold, C. (2011). Contabilidade Básica. Curitiba: Instituto Federal Paraná.
Beck, K., & Fowler, M. (2000). Planning Extreme Programming (1ª ed.). Addison-
Wesley Professional.
Ben-Ari, M. (2006). Understanding Programming Languages. Chichester: John Wiley
& Sons.
Castro, V. A. (2007). Introdução ao Desenvolvimento Ágil. Obtido de DevMedia:
https://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916
Costa, E. (2015). Programação em Python. Lisboa: FCA - Editora de informatica, Lda.
Damelio, R. (2011). The Basics of Process Mapping (2ª ed.). New York: CRC Press.
de Almeida, R. R. (s.d.). Model-View-Controller (MVC). Obtido de
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm
de Oliveira, M. F. (2011). METODOLOGIA CIENTÍFICA: um manual para a
realização de pesquisas em administração. CATALÃO-GO: UNIVERSIDADE
FEDERAL DE GOIÁS.
Deacon, J. (Maio de 2009). Model-View-Controller (MVC) Architecture. Obtido em 1
de Agosto de 2021, de https://www.rareparts.com/pdf/MVC.pdf
Deitel, P. J., & Deitel, H. M. (2008). Internet & World Wide Web HOW TO PROGRAM
(4ª ed.). Upper Saddle River, New Jersey: Pearson Education, Inc.
Eck, D. J. (2014). Introduction to Programming Using Java (7ª ed.). Geneva, NY.
Elmasri, R., & Navathe, S. (2015). Fundamentals of Database Systems (7ª ed.).
Pearson.
Fischer, E. A., & Grodzinsky, S. F. (1993). The Anatomy of Programming Languages.
Englewood Cliffs: NJ: Prentice Hall.
Framework: saiba como usar e quais são os mais populares. (s.d.). Obtido em 2021, de
Revelo: https://blog.revelo.com.br/o-que-e-framework-exemplos-e-aplicacoes/

36
Fuori, W. M., & Aufiero, L. J. (1989). Computers and information processing (2ª ed.).
Englewood Cliffs, New Jersey: Prentice-Hall.
Goodman, D. (2001). JavaScript Bible (4ª ed.). New York: Hungry minds.
Groff, J. R., & Weinberg, P. N. (1999). SQL: The Complete Reference (1ª ed.).
Berkeley, California: Osborne/McGraw-Hill.
Groffe, R. J. (2013). Modelagem de sistemas através de UML. Obtido em 2021, de
DevMedia: https://www.devmedia.com.br/modelagem-de-sistemas-atraves-de-
uml-uma-visao-geral/27913
Guedes, M. (s.d.). RUP (Rational Unified Process). Obtido em 2021, de Treina Web:
https://www.treinaweb.com.br/blog/o-que-e-rup-rational-unified-process/
Harold, E. R. (1999). XML™ Bible. Foster City, CA: IDG Books Worldwide.
Haverbeke, H. (2018). Eloquent JavaScript (3ª ed.). No starch press.
Hunsaker, C. (18 de Maio de 2015). REST vs SOAP: When is REST Better. Obtido de
Okta: https://stormpath.com/blog/rest-vs-soap
Imsirovic, A. (2018). Vue.js Quick Start Guide. Birmingham, Uk: Packt Publishing.
Insights for professionals. (28 de Novembro de 2019). 4 Chalanges of reconciliation
and how to overcome them. Obtido em 1 de 12 de 2021, de
insightsforprofessionals.com:
https://www.insightsforprofessionals.com/finance/accounting/challenges-of-
reconciliation-and-how-overcome-them
Internet & World Wide Web HOW TO PROGRAM (4ª ed.). (2008). Upper Saddle River,
New Jersey: Pearson Education, Inc.
Java. (s.d.). Obtido em 2021, de Wikipedia :
https://en.wikipedia.org/wiki/Java_(programming_language)
Kassem, N. (2000). Designing Enterprise Applications with the JavaTM 2 Platform,
Enterprise Edition. Sun Microsystems, Inc.
Kelly, J. E. (2015). Bookkepping & Accountiing all-in-one for dummies. Chichester:
John Wiley & Sons, Ltd.
Khartit, K. (21 de Junho de 2021). Why Is Reconciliation Important in Accounting?
Obtido em 1 de Dezembro de 2021, de Investopedia.com:
https://www.investopedia.com/ask/answers/041515/why-reconciliation-
important-accounting.asp
Kruchten, P. (2002). The rational unified process. Addison Wesley.
Lage, M. (2008). Accounting Bank Reconciliation. LPF Group Ltd. Co.

37
Lakatos, E. M., & Marconi, M. d. (2003). Fundamentos de metodologia cientifica. São
Paulo: Atlas S.A.
LIMA, L. S. (2003). Um breve histórico conceitual da Automação Industrial e Redes
para Automação Industrial.
Linguagem de programação. (Setembro de 2020). Obtido em 2021, de Wikipedia:
https://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o
Lyrio, E. F., Almeida, S., & Portugal, G. T. (2015). Gestão contábil: aspectos
introdutórios (1ª ed.). Rio de Janeiro: Rede Sirius.
Macore, S. A. (2017). Importância da Reconciliação Bancária Como Método de
Integração Financeira: Caso do Corredor de Desenvolvimento do Norte 2013 -
2015.
Matthew, N., & Stones, R. (1996). Beginning linux programming (1ª ed.). Birmingham,
UK: Wrox.
Maxim, B. R., & Pressman, R. R. (2016). Engenharia de software: uma abordagem
profissional (8ª ed.). New york: AMGH Editora Lda.
Microsoft. (2022). SQL Server 2017. Obtido de Microsoft:
https://www.microsoft.com/en-us/sql-server/sql-server-2017#OneGDCWeb-
hero-8khejep
Modelagem de sistemas através de UML. (s.d.). Obtido em 2021, de DevMedia:
https://www.devmedia.com.br/modelagem-de-sistemas-atraves-de-uml-uma-
visao-geral/27913
Mozilla. (2022). MDN Web Docs. Obtido de developer.mozilla.org:
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Messages
MySQL. (2022). MySQL Products. Obtido de MySQL :
https://www.mysql.com/products/
Noback, M. (2015). Principles of Package Design. Leanpub.
Object-oriented programming. (s.d.). Obtido em 2021, de Wikipedia:
https://en.wikipedia.org/wiki/Object-oriented_programming
O'Brien, J. A. (2010). Sistemas de informação e as decisões gerencias na era da internet
(3ª ed.). (C. K. Moreira, & C. K. Moreira, Trads.) Saraiva.
Olivo, A. M., & Boschilia, L. (2012). Contabilidade geral e gerencial: conceitos
introdutorios para os cursos superiores de tecnologia. Florianópolis: IF-SC.
OWEN, G. e. (2005). A dictionary of accounting. Oxford University Press.

38
Powell, T. A. (2010). HTML & CSS: The Complete Reference (5ª ed.). New York:
McGraw-Hill.
Ramakrishnan, R., & Gehrke, J. (2003). DATABASE MANAGEMENT SYSTEMS (3ª
edição ed.). McGraw-Hill Higher Education.
Red hat. (8 de Janeiro de 2019). What is an IDE. Obtido de redhat.com:
https://www.redhat.com/en/topics/middleware/what-is-ide
REST API Tutorial. (19 de Outubro de 2021). What is REST. Obtido de REST API
Tutorial: https://restfulapi.net/
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modeling Language
Refrence Manual. Reading, Massachusetts: Addison wesley.
Scartezini, L. M. (2009). Análise e Melhoria de Processos. GOIÂNIA.
Scheer, A.-W., Abolhassan, F., Jost, W., & Kirchmer, M. (2004). Business Process
Automation: ARIS in Practice. Springer.
SCRUMstudy™. (2016). A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK™
GUIDE) (3ª ed.). Avondale, Arizona USA: SCRUMstudy™.
Silva, A. M., & Videira, C. A. (2001). UML, Metodologias e Ferramentas CASE.
Famalicão: Centro Atlantico.
Singh, V. (15 de 05 de 2021). Obtido em 01 de 09 de 2021, de Hackr.io:
https://hackr.io/blog/what-is-frameworks
Sommerville, I. (2011). Engenharia de software (9ª edição ed.). (K. Oliveira , & I.
Bosnic, Trads.) Pearson.
Spring Framework. (s.d.). Obtido em 2021, de Wikipedia:
https://en.wikipedia.org/wiki/Spring_Framework.
The Corporate Finance Institute. (2019). Accounting Book. Vancouver: The Corporate
Finance Institute.
The Investopedia team. (23 de Fevereiro de 2021). Financial Services Sector. Obtido
em 2021 de 12 de 1, de Investopedia:
https://www.investopedia.com/ask/answers/030315/what-financial-services-
sector.asp
Tripathi, A. M. (2018). Learning Robotic Process. Birmingham, UK: Packt.
Vilarinho, L. (2018). Front-end com Vue.js. São Paulo, Brasil.
VUE.JS. (17 de Dezembro de 2021). Introdução. Obtido em 30 de Agosto de 2021, de
vuejs: br.vuejs.org/v2/guide/
Walls, C., & Breidenbach, R. (2005). Spring in Action. Manning Publications Co.

39
Wells, D. (2009). The Values of Extreme Programming. Obtido de Extreme
programming: http://www.extremeprogramming.org/values.html
Wikipedia. (Dezembro de 2021). Software development. Obtido em 2021, de Wkipedia:
https://en.wikipedia.org/wiki/Software_development
Wysocki, R. K. (2014). Effective Project (7ª ed.). Indianapolis: John Wiley & Sons, Inc.
Zanella, L. C. (2013). Metodologia de Pesquisa (2ª edição ed.). Universidade Federal de
Santa Catarina.
Zikmund, W. G., Babin, B. J., Carr, J. C., & Griffin, M. (2010). Business Research
Methods. 8ª edição.

40
 APÊNDICES
Apêndice A: Guião de Entrevista
Chamo-me Lourino Alberto Chemane Júnior, estudante finalista do curso de
Administração de Sistemas de Informação e Redes na Universidade São Tomás de
Moçambique e venho por meio deste pedir o seu contributo para a compilação da minha
monografia bastando para tal, permitir que se prossiga com uma entrevista. Este
instrumento de recolha de dados poderá adicionar valor relevante a culminação dos
meus estudos o que condiciona a atribuição do título académico de Licenciado. A
pesquisa em curso cinge-se na partilha de recursos, processos, serviços e produtos entre
o Banco e outras empresas para efectuar a reconciliação de transacções resultantes da
interoperabilidade de sistemas.
1. Bom dia, como se chama?
2. Há quanto tempo trabalha no Banco e qual e a sua função?
3. Como funciona o processo actual de reconciliação transacções resultantes da
interoperabilidade entre o Banco e outras empresas para fornecer serviços de
outras empresas através do banco?
4. Os processos de reconciliação das transacções resultantes da interoperabilidade
do Banco e outras empresas são automáticos?
5. Quem são os responsáveis pelo desenvolvimento e manutenção do sistema
actual para a reconciliação de transacções resultantes da interoperabilidade entre
o banco e outras empresas?
6. Quais são os procedimentos que deve se proceder para inserir as transacções
internas e externas no actual sistema de reconciliação para efectuar reconciliação
das transacções resultantes da interoperabilidade dos sistemas do banco e
outros?
7. Quais são as dificuldades enfrentadas durante o processo de actual de
reconciliação transacções resultantes da interoperabilidade entre o Banco e
outras empresas?
8. O actual sistema dispõe de mecanismos para integrar com outros sistemas
usando webservices REST ou SOAP?
9. Com recurso as TIC’s, que tipos de melhorias poderiam ser feitas para melhorar
o processo?
10. O Banco está aberto a compartilhar, seus serviços e produtos com outras
empresas do ramo através de plataformas sofisticadas?

41
11. Na sua opinião, a implantação de uma única plataforma para automatizar os
processos de reconciliação de transações resultantes da interoperabilidade de
sistemas seria viável para os envolvidos (empresas e o banco)?
12. Tem alguma coisa mais para dizer em torno da nossa conversa?

42
 Apêndice B: Requisitos funcionais
Os requisitos funcionais descrevem as funcionalidades que se esperam do
sistema.
Tabela B.1: Requisitos Funcionais da aplicação
Dependênc
Código Requisito Prioridade
ia
RF01 Login Alta ---
RF02 Logout Alta RF01

Cadastrar
RF03 Alta RF01
usuário
Visualizar
RF04 Alta RF01
usuário
Editar
RF05 Alta RF03
usuário
Eliminar
RF06 Alta RF03
usuário

Registrar
RF07 Alta RF01
entidade externa

Visualizar
RF08 Alta RF01
entidade externa
Editar
RF09 Alta RF07
entidade externa
Eliminar
RF10 Alta RF07
entidade externa
Criar
processo de
RF11 Alta RF01
reconciliação com
entidade externa
Visualizar
processo de
RF12 Alta RF01
reconciliação com
entidade externa
Editar
processo de
RF13 Alta RF11
reconciliação com
entidade externa
Eliminar
processo de
RF14 Alta RF11
reconciliação com
entidade externa
Criar regra
RF15 Alta RF11
de reconciliação
43
 Visualizar
RF16 regra de Alta RF11
reconciliação
Editar regra
RF17 Alta RF15
de reconciliação
Eliminar
RF18 regra de Alta RF15
reconciliação
Registar
configurações da
RF19 Alta RF11
base de dados sql
interna
Visualizar
configurações da
RF20 Alta RF11
base de dados sql
interna
Editar
configurações da
RF21 Alta RF19
base de dados sql
interna
Remover
configurações da
RF22 Alta RF19
base de dados sql
interna
Registar
RF23 Alta RF23
transacção externa
Visualizar
RF24 relatório de Alta RF01
reconciliação
Registar
RF25 parâmetros do Media RF01
servidor de email
Alterar
RF26 palavra passe do Alta RF03
usuário
Receber
RF27 notificação por Media RF11
email
Solicitar
RF28 cadastro na Alta ---
aplicação
Fonte: Autor

44
 Apêndice C: Requisitos não funcionais
Os requisitos não funcionais descrevem propriedades relacionadas com as
funcionalidades do sistema.
1. Requisitos de desempenho
 NF01 – Possuir alta disponibilidade para responder aos pedidos dos
usuários.
2. Requisitos de segurança
 NF02 – a permissão para a criação de usuários, deve ser atribuída apenas ao
administrador ou supervisor da aplicação.
 NF03 – Encriptar as senhas dos usuários da aplicação.
 NF04 – Restringir o acesso a aplicação para usuários autenticados.
 NF05 – Alterar a senha de acesso inicialmente atribuída.
 NF06 – Restringir o acesso a base de dados da aplicação.
 NF07 – Restringir o acesso ao servidor onde estiver hospedada a aplicação.
3. Requisitos de interface
 NF08 – Possuir interface simples para permitir acesso imediato a informação
desejada.
4. Requisitos de portabilidade
 NF09 – Deve ser portátil para permitir a mudança de sistemas operativos
onde a aplicação estiver hospedada.

45
 Apêndice D: Descrição de casos de uso do Administrador
Tabela D.1: Casos de Uso do administrador
Caso de uso
Login
Logout
Cadastrar usuário
Listar usuário
Editar usuário
Eliminar usuário
Registrar entidade externa
Listar entidade externa
Editar entidade externa
Eliminar entidade externa
Criar processo de reconciliação
com entidade externa
Visualizar processo de
reconciliação com entidade externa
Descrição
Permite ao administrador iniciar
sessão na aplicação
Permite ao administrador terminar
a sessão na aplicação
Permite ao administrador
cadastrar um usuário na aplicação, depois
é enviado um email para o utilizador com
a sua palavra passe.
Permite ao administrador
visualizar todos os usuários cadastrados
na aplicação.
Permite ao administrador editar as
suas informações.
Permite ao administrador eliminar
o usuário da aplicação.
Permite ao administrador registrar
uma entidade externa na aplicação.
Permite ao administrador
visualizar as informações da entidade
externa.
Permite ao administrador editar as
informações da entidade externa.
Permite ao administrador eliminar
a entidade externa da aplicação.
Permite ao administrador criar um
processo de reconciliação entre
transacções internas e externas.
Permite ao administrador
visualizar as informações do processo de
reconciliação.
46

Editar processo de
reconciliação com entidade externa
Eliminar processo de
reconciliação com entidade externa
Criar regra de reconciliação
Seleccionar regra de
reconciliação
Editar regra de reconciliação
Eliminar regra de reconciliação
Registar configurações da base
de dados SQL interna
Listar configurações da base de
dados SQL interna
Editar configurações da base de
dados SQL interna
Remover configurações da base
de dados SQL interna
Permite ao administrador editar as
informações do processo de
reconciliação.
Permite ao administrador eliminar
o processo de reconciliação entre
transacções internas e externas.
Permite ao administrador criar
uma regra de reconciliação para ser
alocada a um processo de reconciliação.
Permite ao administrador
seleccionar uma regra de reconciliação.
Permite ao administrador editar a
regra de reconciliação.
Permite ao administrador eliminar
a regra de reconciliação do processo de
reconciliação.
Permite ao administrador registrar
as configurações de acesso a base de
dados SQL por onde serão pesquisadas as
transacções internas.
Permite ao administrador
visualizar as configurações de acesso a
base de dados SQL por onde serão
pesquisadas as transacções internas.
Permite ao administrador editar as
configurações de acesso a base de dados
SQL por onde serão pesquisadas as
transacções internas.
Permite ao administrador remover
da aplicação configurações de acesso a
base de dados SQL por onde serão
pesquisadas as transacções internas.
47

Visualizar relatório de
reconciliação
Registar parâmetros do
servidor de email
Receber notificação por email
Fonte: Autor
Permite ao administrador
visualizar o relatório de reconciliação de
um determinado processo de
reconciliação.
Permite ao administrador registrar
os parâmetros de acesso ao servidor de
envio de email.
Permite ao administrador receber
notificação por email sempre que um
usuário se cadastrar para a aplicação.
48
Apêndice E: Descrição de casos de uso do usuário e entidade externa
Tabela E.1: Casos de uso do usuário e da entidade externa.
Caso de uso
Solicitar cadastro na aplicação
Alterar palavra passe do
usuário
Login
Logout
Visualizar usuário
Editar usuário
Listar contas de reconciliação
Seleccionar conta de
reconciliação
Receber notificação por email
Visualizar relatório de
reconciliação
Listar transacções
transacções no relatório de reconciliação.
Registrar transacção externa
Fonte: Autor
Descrição
Permite ao usuário solicitar ao
administrador da aplicação permissão
para usar a aplicação.
Permite ao usuário alterar a sua
palavra passe caso tenha esquecido.
Permite ao usuário iniciar sessão
na aplicação
Permite ao usuário terminar a
sessão na aplicação
Permite ao usuário visualizar as
informações do usuário.
Permite ao usuário editar as suas
informações.
Permite ao usuário visualizar as
contas de reconciliação.
Permite ao usuário seleccionar
uma determinada conta de reconciliação
Permite ao usuário receber
notificação por email com o link para
alterar a palavra-passe.
Permite ao usuário visualizar o
relatório de reconciliação de um
determinado processo de reconciliação.
Permite ao usuário visualizar as
Permite a entidade externa
registrar uma transacção na aplicação a
fim de executar um processo de
reconciliação.
49
Apêndice F: Protótipos de telas

Figura F.1: Tela de login.

Fonte: Autor

50
Figura F.2: Tela principal do usuário.
Fonte: Autor

51
Figura F.3: Tela principal do administrador.
Fonte: Autor

52
Figura F.4: Formulário de criação de processo de reconciliação.
Fonte: Autor

53
Figura F.5: Tela de relatório de reconciliação
Fonte: Autor

54