Universidade Lrio

Faculdade de Engenharia
Departamento de Engenharia Informtica

Sistema de Gesto de Concursos para Centro de Formao de Pessoal de

Sade de Pemba

Monografia apresentada Universidade Lrio,

como cumprimento dos requisitos parciais para
obteno do ttulo de licenciado em Engenharia
Informtica.

Autor: Valinho Antnio

Orientador: Eldio Toms da Silva, MSc.
Co-Orientador: Eng. Celso Vanimaly

Pemba, 2015

PGINA DE ACEITAO

_______________________________________________
Presidente do Jri
_______________________________________________
Secretrio
_______________________________________________
Vogal

Cidade: Pemba
Data: Agosto de 2015

DECLARAO DE HONRA
Declaro que sou autor desta Monografia e que autorizo a Universidade Lrio, a fazer
uso da mesma, com a finalidade que julgue conveniente.

Assinatura: ______________________________________

Data: _______de ___________________de______________

II

AGRADECIMENTOS
Agradeo primeiramente a Deus, por ter-me dado a sade e fora, que permitiram
que tudo isso acontecesse, ao longo da minha vida, e no somente nestes anos
como universitrio, mas que em todos momentos o maior mestre que algum pode
conhecer.
Agradeo grandiosamente a Universidade Lrio, Faculdade de Engenharia,
concretamente ao Departamento de Engenharia Informtica, seu corpo docente,
direco e administrao que abriram a janela que hoje vislumbro um horizonte
superior, repleto de confiana atravs do mrito e tica aqui presentes.
A todos docentes, vai a minha grandiosa gratido, por me proporcionar o
conhecimento no apenas racional, mas a manifestao do carcter e efectividade
da educao no processo de formao profissional. Em especial aos meus
orientadores, MSc. Eldio Toms da Silva e Eng. Celso Vanimaly, pelo empenho
dedicado na orientao, correco, incentivos, confiana e, que no pouco tempo que
lhes coube, tornaram o trabalho realizado.
Aos meus queridos pais, pelo amor, incentivo, e apoio incondicional. No lugar da
minha amada me, Joana Gustavo, herona que me deu suporte nas horas difceis,
de desnimo e cansao, solidificando assim, toda jornada do cursar. Ao meu prezado
pai, Antnio Muahaja Uahilive (em memria), que apesar das dificuldades me
fortaleceu e que para mim foi to importante e, dizer que sempre estar ao meu lado.
Aos meus irmos e primos, que nos momentos da minha ausncia dedicados ao
estudo superior, sempre entenderam que o futuro feito a partir da constante
dedicao. Em especial vai para o meu irmo mais velho, Benito Antnio que se fez
presente em toda maratona do curso. Aos tios e tias pela contribuio valiosa,
destacando a tia Eullia ssamo pela sua deliciosa receita que diariamente me deu.
Meus agradecimentos no deixam de ir aos meus amigos de Engenharia Informtica,
turma 2011, companheiros estes de trabalho e irmos na amizade que fizeram parte
da minha formao e que continuaro presentes eternamente em minha vida.

III

DEDICATRIA
Dedico este trabalho minha querida me, Joana Gustavo, ao meu carssimo pai,
Antnio Muahaja Uahilive (em memria) e aos meus irmos por acreditarem e
investirem em mim e, no s, por terem tambm transmitido com generosidade e
carinho a saudvel educao, que me foi sustento e me deu coragem para
questionar realidades e propor um novo mundo de possibilidades.
Dedico esta, bem como todas as minhas demais conquistas, a minha namorada
Amlia Matsinhe, que de forma especial e carinhosa me deu fora e coragem, me
apoiando tambm nos momentos de angstia. Na mesma linhagem, dedico aos
meus comparsas do curso, pelas alegrias, tristezas e dores compartilhadas e, a
todos aqueles que de alguma forma estiveram e esto prximos de mim, fazendo
esta vida valer cada vez mais a pena.

IV

RESUMO
Esta monografia centra-se no desenvolvimento de um sistema computacional web
para gesto de concursos na Seco de Assuntos Estudantis e Recursos Didcticos,
no Departamento Pedaggico do Centro de Formao de Pessoal de Sade de
Pemba.
Faz uma abordagem do actual sistema de gesto de concursos, onde identifica o
problema cientfico a resolver, faz um estudo dos fundamentos tericos e
metodolgicos que engrandecem o desenvolvimento do sistema proposto.
O desenvolvimento do sistema de gesto de concursos baseou-se na metodologia
RUP (Rational Unified Process, em portugus, Processo Unificado da Rational),
coadjuvado por UML (Unified Modeling Language, de portugus, Linguagem de
Modelao Unificada) na construo dos modelos suportados por EA (Enterprise
Architet) na sua verso 8.0, que uma ferramenta CASE, fez-se uso da Linguagem
de Programao de alto nvel Java no ambiente de desenvolvimento integrado
Netbeans 7.4. Para a implementao da base de dados utilizou-se o sistema de
gesto de base de dados MySQL na sua verso 6.0 com auxlio da interface Navicat
for MySQL de verso 11.0, fez-se uso do Hibernate 3.6.10 para persistncia e
mapeamento objecto relacional. Utilizou-se Apache Tomcat 7.0.41 para servir a
aplicao aos clientes, framework ZK para construo das interfaces de forma
rpida, utilizou-se como guia a arquitectura MVC e Cliente-Servidor de 4 camadas e,
finalmente fez-se uso das bibliotecas JasperReport de verso 5.6 com auxlio de
iReport da mesma verso para construo e gerao de relatrios.
O sistema desenvolvido permite aperfeioar e dinamizar a gesto de concursos,
poupar recursos materiais e humanos, reduzindo custos, desgaste e fluxo de
trabalho, o que se traduz em preciso e ganho de tempo. Na mesma ordem,
possibilita obter consultas fceis, rpidas e dinmicas contribuindo imensamente na
tomada de deciso pela Direco Pedaggica, especificamente na Seco de
Assuntos Estudantis e Recursos Didcticos na gesto de concursos do Centro de
Formao do Pessoal de Sade de Pemba.
V

LISTA DE ABREVIATURAS E SIGLAS

Abreviatura e Sigla

Significado

API

Application Programming Language

BD

Base de Dados

CFPSP

Centro de Formao de Pessoal de Sade

CPU

Central Processing Unit

DP

Direco Pedaggica

EA

Enterprise Architect

GPL

General Public License

HQL

Hibernate Query Language

HTML

Hypertext Markup Language

MDS

Metodologia de Desenvolvimento de Software

MVC

Model View Controller

OMG

Object Management Group

ORM

Object Relation Mapping

RUP

Rational Unified Process

SAERD

Seco de Assuntos Estudantis e Recursos Didcticos

SGBD

Sistema de Gesto de Base de Dados

SIGECO

Sistema de Gesto de Concursos

SQL

Structured Query Language

UML

Unified Modeling Language

WebApps

Web Application

XP

Extreme Programming

VI

LISTA DE FIGURAS
Figura 1: Modelo Cliente-Servidor. Fonte: Adaptado pelo autor. ............................... 15
Figura 2: Aplicao Web com arquitectura em 4 camadas. Fonte: Adaptado pelo
autor. .......................................................................................................................... 16
Figura 3: Vises ligadas a um modelo MVC. Fonte: GAMMA et al, 2006. ................. 18
Figura 4: Compreenso de um gestor de base de dados. Fonte: Adaptado pelo autor
................................................................................................................................... 21
Figura 5: Simplificando o desenvolvimento com ZK. Fonte: ZKbrasil, 2014. ............. 27
Figura 6: Relao entre as fases e actividades do RUP. Fonte: Lus, 2005. ............. 32
Figura 7: Diagrama de caso de uso de negcio-SAERD na Gesto de Concursos. .. 41
Figura 8: Diagrama de actividades de caso de uso Efectuar Inscrio. ..................... 43
Figura 9: Diagrama de actividades de caso de uso Publicar Resultado. ................... 44
Figura 10: Diagrama de classes do modelo dos objectos de CU Efectuar Inscrio. 45
Figura 11: Diagrama de classes do modelo dos objectos de CU Formar Turma. ...... 45
Figura 12: Diagrama de classe do modelo dos objectos de CU Publicar Resultado.. 45
Figura 13: Diagrama de caso de uso do SIGECO. .................................................... 51
Figura 14: Diagrama de Implantao do SIGECO. .................................................... 65
Figura 15: Interface principal do sistema para o candidato. ....................................... 66
Figura 16: Interface principal do sistema para o funcionrio, depois da autenticao.
................................................................................................................................... 67
Figura 17: Pgina principal com submenus identificados. ......................................... 68
Figura 18: Edital de inscrio. .................................................................................... 69
Figura 19: Ficha de inscrio com tab-Dados Pessoais. ........................................... 69
Figura 20: Ficha de inscrio com tab-Documentos. ................................................. 70
Figura 21: Ficha de inscrio com tab-Dados Acadmicos ....................................... 71
Figura 22: Ficha de Inscrio com tab-Informaes para Contacto. .......................... 72
Figura 23: Submenu Consultas enumerado. .............................................................. 73
Figura 24: Submenu Consultas com tela de pesquisa. .............................................. 73
Figura 25: Submenu Consultas com lista provisria. ................................................. 74
Figura 26: Submenu Consultas com Lista Definitiva. ................................................. 74
Figura 27: Tela de Submenu Consultas com lista de escolas. ................................... 75
VII

Figura 28: Tela de procura de salas de exame por curso. ......................................... 75

Figura 30: Tela com campo de pesquisa do candidato. ............................................. 76
Figura 31: Tela com resultado dos exames. .............................................................. 77
Figura 32: Submenu Funcionrio com funcionalidades enumeradas......................... 78
Figura 33: Tela de pesquisa de candidato por cdigo. ............................................... 79
Figura 34: Tela de pesquisa com cdigo do candidato a validar................................ 80
Figura 35: Tela de validao do candidato. ............................................................... 80
Figura 36: Tela de validao aps seleccionar-se no boto validar. .......................... 81
Figura 37: Tela de busca de candidatos por curso e local de realizao do exame. . 82
Figura 39: Tela com turma formada. .......................................................................... 84
Figura 40: Tela com campo de pesquisa de turma por editar. ................................... 84
Figura 43: Diagrama de actividades de caso de uso Formar Turma............................. I
Figura 44: Diagramas de actividades dos casos de uso ver Turma e Resultado. ......... I
Figura 45: Diagrama de classes para CU Efectuar Inscrio. ...................................... II
Figura 46: Diagrama de classes para CU Alterar Inscrio. ........................................ II
Figura 47: Diagrama de classes para CU Eliminar Inscrio. ..................................... III
Figura 48: Diagrama de classe para CU Gerir Turma. ................................................ III
Figura 49: Diagrama de classes de CU Elaborar Pauta............................................. IV
Figura 50: Diagrama de classes de CU Gerir Consultas. ............................................ V
Figura 51: Diagrama de sequncia de CU Efectuar Inscrio. .................................. VI
Figura 52: Diagrama de sequncia de CU Alterar Inscrio. ..................................... VI
Figura 53: Diagrama de sequncia de CU Eliminar Inscrio. .................................. VII
Figura 54: Diagrama de sequncia de CU Gerir Turma Curso Normal. ................. VII
Figura 55: Diagrama de sequncia de CU Gerir Turma Formar Turma. ............... VIII
Figura 56: Diagrama de sequncia de CU Gerir Turma Alterar Turma. .................. IX
Figura 57: Diagrama de sequncia de CU Gerir Turma Publicar Turmas. .............. IX
Figura 58: Diagrama de sequncia de CU Gerir Turma Apagar Turma. .................. X
Figura 59: Diagrama de sequncia de CU Elaborar Pauta. ....................................... XI
Figura 60: Diagrama de sequncia de CU Gerir Consultas Curso Normal. ............ XI
Figura 61: Diagrama de sequncia de CU Gerir Consultas Consultar Resultado. . XII
Figura 62: Diagrama de sequncia de CU Gerir Consultas Consultar Turma. ...... XIII
VIII

Figura 63: Diagrama de sequncia de CU Gerir Consultas Consultar Escola/Sala.

................................................................................................................................. XIII
Figura 64: Diagrama de modelo de dados do SIGECO. .......................................... XIV
Figura 65: Diagrama de componentes do SIGECO. ................................................. XV

IX

LISTA DE TABELAS
Tabela 1: Requisitos funcionais e no funcionais. ..................................................... 46
Tabela 2: Identificao de actores do sistema. .......................................................... 49
Tabela 3: Descrio de caso de uso Realizar Autenticao. .................................. 52
Tabela 4: Descrio de caso de uso - Alterar Senha. ................................................ 53
Tabela 5: Descrio de caso de uso Efectuar Inscrio. ........................................ 54
Tabela 6: Descrio de caso de uso - Editar Inscrio .............................................. 54
Tabela 7: Descrio de caso de uso Validar Candidato.......................................... 55
Tabela 8: Descrio de caso de uso Eliminar Inscrio .......................................... 56
Tabela 9: Descrio de caso de uso - Gerir Turma.................................................... 57
Tabela 10: Descrio de caso de uso - Inserir Nota. ................................................. 59
Tabela 11: Descrio de caso de uso - Elaborar Pauta ............................................. 60
Tabela 12: Descrio de caso de uso Publicar Pauta ............................................. 61
Tabela 13: Descrio de caso de uso - Gerir Consultas. ........................................... 62

ndice
INTRODUO ............................................................................................................. 1
CAPTULO I. FUNDAMENTAO TERICA .............................................................. 6
1.1

Introduo ....................................................................................................... 6

1.2

Objecto de Estudo .......................................................................................... 6

1.3

Descrio do Sistema Actual .......................................................................... 7

1.4

Processos do Negcio .................................................................................... 7

1.4.1

Processo de Inscrio .............................................................................. 8

1.4.2

Processo de Formao e Publicao de Turmas ..................................... 8

1.4.3

Processo de Publicao de Resultados ................................................... 9

1.5

Tecnologias Utilizadas .................................................................................... 9

1.5.1

Netbeans IDE ......................................................................................... 10

1.5.2

Java ........................................................................................................ 11

1.5.3

Aplicao Web (WebApp) ...................................................................... 12

1.5.4

Arquitectura Cliente-Servidor ................................................................. 14

1.5.5

Servidores Web ...................................................................................... 16

1.5.6

Arquitectura de Software Model View Controller (MVC) ......................... 17

1.5.7

Base de Dados (BD)............................................................................... 19

1.5.8

Sistemas de Gesto de Base de Dados (SGBD) ................................... 20

1.5.9

Persistncia de Dados............................................................................ 22

1.5.10 Framework ............................................................................................. 24

1.5.11 Geradores de Relatrios ........................................................................ 27
1.6

Concluso ..................................................................................................... 29

CAPITULO II. METODOLOGIAS ............................................................................... 30

2.1.

Introduo ..................................................................................................... 30
XI

2.2.

Metodologias de Desenvolvimento de Software (MDS) ................................ 30

2.2.1.
2.3.

Unified Modeling Language (UML) ............................................................... 36

2.3.1.
2.4.

Caractersticas da UML .......................................................................... 36

Ferramentas CASE (Computer Aided Software Engineering)....................... 37

2.4.1.
2.5.

Rational Unified Process (RUP) ............................................................. 31

Enterprise Architect (EA) ........................................................................ 38

Concluso ..................................................................................................... 38

CAPITULO III. ANLISE E DESENHO DA SOLUO .............................................. 39

3.1.

Introduo ..................................................................................................... 39

3.2.

Modelao do Sistema Proposto .................................................................. 39

3.2.1.

Diagrama de Caso de Uso de Negcio (DCUN) .................................... 39

3.2.2.

Descrio dos Casos de Uso do Negcio .............................................. 41

3.3.

Elicitao de Requisitos ................................................................................ 46

3.3.1.

Requisitos Funcionais e no Funcionais do Sistema ............................. 46

3.3.2.

Diagrama de Caso de Uso do Sistema (DCUS) ..................................... 48

3.4.

Diagrama de Classes de Desenho ............................................................... 63

3.5.

Diagrama de Sequncia................................................................................ 64

3.6.

Diagrama de Modelo de Dados .................................................................... 64

3.7.

Diagrama de Implantao ............................................................................. 64

3.8.

Concluso ..................................................................................................... 65

CAPTULO IV. IMPLEMENTAO ............................................................................ 66

4.1.

Introduo ..................................................................................................... 66

4.2.

Caractersticas Gerais do Sistema ................................................................ 66

4.3.

Interface do utilizador .................................................................................... 66

4.3.1.

Especificao do Menu Geral do Sistema .............................................. 68

XII

4.4.

Diagrama de Componentes .......................................................................... 86

4.5.

Concluso ..................................................................................................... 87

CONCLUSES .......................................................................................................... 88
RECOMENDAES .................................................................................................. 89
BIBLIOGRAFIA .......................................................................................................... 90
ANEXOS ....................................................................................................................... I

XIII

INTRODUO
Os custos e o desgaste so instrumentos muito preocupantes para vertente
humana. Assim como, a tomada de decises nas organizaes um processo difcil,
dada a quantidade de informao processada. Sendo assim, existem as Tecnologias
de Informao que trabalham como mecanismo de suporte e de melhoria das
actividades das organizaes com intuito de colmatar certos embaraos que os
sistemas manuais apresentam, e estas tecnologias continuam a alterar de modo
profundo como as organizaes evoluem e processam seus servios.
O Centro de Formao de Pessoal de Sade de Pemba (CFPSP) uma instituio
pblica de ensino profissional bsico e mdio que visa a formao de quadros na
rea de sade para todo o pas. constitudo por trs direces, nomeadamente
Direco Geral, Direco Pedaggica (DP) e Direco Administrativa. Dentre as
direces citadas, o trabalho centra-se na DP, concretamente na Seco de
Assuntos Estudantis e Recursos Didcticos (SAERD), na gesto de concursos.
A SAERD faz parte da Direco Pedaggica e responde no processo de lanamento
de concursos e publicao de resultados. Lana semestralmente concursos a partir
de um edital que recebe do Ministrio de Sade (MISAU) com o total de cursos,
nmero especfico de reas disponveis para a formao e de vagas para cada
Provncia do Pas. No perodo de inscries recebe candidatos oriundos de vrios
pontos da provncia e fora da provncia para candidatarem-se a um dos cursos
lanados.
A SAERD responsvel pela aplicao dos exames de conhecimentos e dever
seleccionar os candidatos aprovados para o exame psicotcnico, elaborando uma
lista (que publica-se na vitrina do centro e tambm enviam para o Servio Distrital de
Sade de Montepuez) em ordem decrescente na base da classificao obtida nos
exames de conhecimento e de acordo com o nmero de vagas disponveis para a
Provncia. O nmero mximo de candidatos seleccionados para exame psicotcnico
ou de redaco ser o dobro do nmero de vagas atribudas Provncia. A seleco
final de candidatos aos cursos ser feita com base nos resultados do exame
1

psicotcnico, devendo-se seleccionar por ordem decrescente os candidatos com

melhor classificao. Depois de todo o processo de concurso a SAERD elabora
relatrios relativos ao decurso do concurso. Com todas estas actividades realizadas,
consomem muito tempo e verifica-se um trabalho pesado para os funcionrios.
Actualmente, a SAERD utiliza um sistema manual que permite efectuar a gesto do
processo de concursos. Neste sistema identificou-se inconvenincias no que
concerne eficincia na gesto das actividades. A ttulo de exemplo, os distritos da
Zona Sul de Cabo Delgado (Chire, Ancuabe) e distritos da Zona Centro (Quissanga,
Macomia, Meluco, Metuge, Ibo) no tem centro para o processo de inscrio, deste
modo, o interessado se desloca para o Centro de Pemba que se localiza fora do seu
distrito para poder efectuar a inscrio e isso desgastante, e no s acarreta
custos. E para os funcionrios h um enormssimo trabalho como registar os
candidatos manualmente, formar turmas a partir dos inscritos para a realizao dos
exames, calcular mdias, identificar aprovados, suplentes e reprovados, publicar
pautas na vitrina e mandar para Montepuez e, elaborar relatrios.
Decorrente da situao actual acima apresentada e com o propsito de apresentar
uma soluo informatizada identificou-se o seguinte problema cientfico: Como
desenvolver um Sistema Computacional de Gesto de Concursos para o CFPSP de
tal modo que permita flexibilizar a execuo das actividades, o controlo e ajudar na
tomada de deciso?
Este trabalho tem como objecto de estudo o processo de gesto de concursos de
ingresso ao Centro de Formao do Pessoal da Sade de Pemba, e define como
objectivos:
Objectivo Geral
Desenvolver uma aplicao web para a gesto de Concursos no Centro de
Formao de Pessoal de Sade de Pemba.
Objectivos Especficos
Modelar o negcio
2

 Identificar Requisitos;
Analisar e Desenhar o Sistema;
Implementar o Sistema;
Testar o Sistema;
Implantar o sistema no negcio.
Para atingir com os objectivos especficos delineados, desenvolveram-se as
seguintes actividades:
Estudar os processos de gesto de concursos, na SAERD;
Definir

requisitos

junto

com

os

especialistas

de

negcio

para

desenvolvimento do sistema proposto;

Realizar um estudo terico sobre as tendncias das aplicaes e
ferramentas;
Estudar aspectos que cercam o desenvolvimento de Sistemas de
Informao, envolvendo a modelagem at o desenho de interfaces.
Foram utilizados mtodos cientficos de nvel terico e de nvel emprico para
responder as actividades deste trabalho.
Mtodos tericos
Histrico-Lgico
Utilizado no estudo do trajecto real do processo de gesto de concursos feito na
Seco de Assuntos Estudantis e Recursos Didcticos do Centro de Formao de
Pessoal de Sade de Pemba e a lgica das leis gerais do funcionamento desta
seco na gesto de concursos.
Anlise-Sntese
Utilizado na avaliao e na sntese dos seguintes processos: recolha de requisitos,
anlise e desenho, implementao e implantao do sistema e, no desenho de base
de dados.

 Modelao
Utilizado

em

todas

nomeadamente:

na

as

fases

de

desenvolvimento

modelao

do

negcio,

do

do

sistema

sistema,

de

proposto,
dados,

de

implementao, de interface e implantao.

Mtodos Empricos
Entrevista
Utilizado na etapa de gesto de negcio e na recolha de requisitos que o sistema
deve lograr.
Reviso Documental
Utilizado na reviso de documentos relacionados com a gesto de concursos com
intuito de conhecer a dinmica do negcio, recolher requisitos e por fim para melhor
descrever.
Resultados Esperados
Com o trabalho espera-se obter um sistema web eficaz e eficiente, que logra com os
seguintes resultados:
Ter uma interface amigvel, um servidor Web rpido, uma base de dados
robusta, que traro possibilidades de manter, alterar, apagar e disponibilizar a
informao completa do candidato, consultas comunicativas e seguras,
rpidas e dinmicas tornando possvel a rapidez, o dinamismo, a facilidade e,
uma boa interaco com os processos;
Ajudar os candidatos na reduo de custos e desgaste;
Proporcionar acesso simultneo de utilizadores com restries de maneira a
garantir maior usabilidade e consistncia dos dados armazenados na base de
dados;
Aprimorar a gesto de concursos, poupando recursos materiais, humanos e
financeiros, simplificando e flexibilizando o trabalho, o que se explanar em
preciso e ganho de tempo, contribuindo com maior relevncia na tomada de
4

decises pela Direco Pedaggica, em coordenao com o Director Geral

do Centro de Formao de Sade de Pemba.
Organizao do Trabalho
O presente trabalho composto por 4 captulos, os quais esto organizados da
seguinte maneira:
Capitulo I. Fundamentao Terica: apresenta-se o objecto de estudo, descreve-se
a situao actual da Seco de Assuntos Estudantis e Recursos Didcticos,
especificamente na gesto de concursos, so apresentados os principais embaraos
que motivam o desenvolvimento desta monografia, apresentam-se os processos do
negcio e, finalmente, faz-se uma abordagem das tecnologias actuais utilizadas.
Capitulo II. Metodologia: faz-se uma abordagem da metodologia utilizada para o
desenvolvimento do sistema proposto e, por ltimo, faz-se a referncia ao modelo de
estudo utilizado para a identificao dos processos do negcio em destaque.
Capitulo III. Anlise e Desenho da Soluo: faz-se estudo e desenho do sistema de
gesto de concursos proposto ao CFPSP seguindo-se a metodologia RUP. Esta
metodologia envolve diversas actividades, nomeadamente: modelao do negcio,
onde identificam-se os actores, trabalhadores e casos de uso, identificao dos
requisitos funcionais e no funcionais do sistema proposto, descrio da soluo
proposta em termos de diagrama de casos de uso do sistema, desenho dos
diagramas de sequncia, de classes, de modelo de dados e, finalmente de
instalao.
Capitulo IV. Implementao: faz-se apresentao dos aspectos relacionados com o
desenvolvimento da aplicao, onde so apresentadas as interfaces principais que,
descrevem as funcionalidades chaves da aplicao.

CAPTULO I. FUNDAMENTAO TERICA

1.1

Introduo

Neste captulo feita a fundamentao terica da investigao, com abordagem do

objecto de estudo, descrio do sistema actual, identificao e descrio dos
processos do negcio e tecnologias utilizadas para o desenvolvimento do sistema.
1.2

Objecto de Estudo

O CFPSP detm a posse do lanamento de concursos, atravs da DP. A DP um

rgo do CFPSP, onde pertence a SAERD, que foi criado com objectivo de executar
a poltica de planificao e gesto dos processos pedaggicos no Centro, cabendolhe em especial dirigir, promover, apoiar e supervisionar a realizao de actividades
de natureza organizativa, normativa e de pesquisa pedaggica, destinadas a
melhorar a qualidade do processo de ensino-aprendizagem e a eficcia das decises
respeitantes aos processos de formao dentro do Centro.
A SAERD uma seco da DP, responsvel na gesto de concursos e outras
actividades e, no comeo de cada semestre lana concursos a partir de um edital,
que recebe do Ministrio da Sade (MISAU), na Direco de Recursos Humanos
especificamente no Departamento de Formao, com um nmero especfico de
reas e de vagas disponveis para a formao. Esta seco, tem as seguintes
actividades:
Inscrever o candidato;
Formar turmas relativas aos candidatos;
Informar aos candidatos sobre o local, sala, data e hora de realizao dos
exames;
Zelar pelo processo de exames em coordenao com Inspeco Provincial (IP);
Corrigir exames, determinar mdia, elaborar e publicar pautas em coordenao
com a sua direco, direco geral e a IP;
Elaborar relatrios relativos ao concurso.

1.3

Descrio do Sistema Actual

Actualmente, a SAERD da DP do CFPSP utiliza um sistema manual que permite

efectuar as actividades supracitadas inerentes ao processo de gesto de concursos.
Tendo assim como inconvenincias:
Desgaste e custos para os candidatos, visto que devem deslocar-se para o
Centro de Pemba;
Enormssimo trabalho na parte dos funcionrios, visto que devem
manualmente inscrever o candidato, formar turmas, determinar mdias das
notas dos exames, elaborar e publicar pautas, assim como elaborar
relatrios e, como consequncia atraso na absoro do processo todo de
concurso;
Dificuldade na busca de informao relativa a um determinado candidato,
porque a informao encontra-se dispersa em papis armazenados em
pastas e, no de forma centralizada.
Lentido na execuo da inscrio, isso porque, o funcionrio deve atender
os candidatos, um por um.
Com intuito de resolver as inconvenincias supramencionadas que o sistema manual
apresenta, surge a necessidade de desenvolver um sistema computacional web, que
ajude na reduo de custos e desgaste e, dinamize os processos inerentes ao
concurso.
1.4

Processos do Negcio

Processo de Negcio um conjunto de tarefas e aces realizadas numa

organizao, cujas tarefas e aces tm um determinado objectivo, no qual
participam um ou diversos trabalhadores e actores. Para Alves (2005) processo de
negcio um conjunto ordenado de actividades realizadas numa empresa ao longo
do tempo, com um comeo e fim bem definidos com entradas e sadas. Portanto,
um processo de negcio no nada mais do que um conjunto de tarefas
estruturadas e relacionadas que produzem um servio ou produto especfico para um
ou mais clientes.
7

A SAERD possui muitos processos de negcio, dentre os quais, neste trabalho sero
abordados os processos de negcio referentes gesto de concursos, que so
pertinentes para a realizao do trabalho.
1.4.1 Processo de Inscrio
O processo de inscrio comea quando o interessado dirige-se ao CFPSP para
efectuar a inscrio, a qual s poder ser feita caso o candidato rena os requisitos
apresentados baixo. Caso se efective a inscrio, o colaborador do CFPSP entregar
ao candidato o comprovativo da inscrio.
Para este processo, so necessrios requisitos, a seguir listados, para que o
candidato tenha direito para se inscrever:
Ter cpia de certificado autenticado da 10 ou 12 classe, ou ainda
equivalente a um destes certificados;
Ter cpia de B.I. ou de passaporte;
Ter talo de depsito de 100, 00 MZN. Este valor serve de taxa de inscrio e,
depositado na conta do BIM do CFPSP;
Ter atestado Mdico.
1.4.2 Processo de Formao e Publicao de Turmas
Este processo d incio depois de encerado o processo de inscrio, onde so
observadas as seguintes actividades realizadas pela SAERD:
Seleccionar os candidatos por curso;
Elaborar relaes nominais (segue uma ordem alfabtica ascendente)
distribudas por turmas em cada curso e tendo em conta o nmero mximo de
candidatos por turma (que de 30);
Publicar na vitrina e enviar para os Servios Distrital de Sade, Mulher e
Aco Social de Montepuez conjuntamente com a data de realizao dos
exames de conhecimentos, horrio (indica a hora de realizao de exame de
cada disciplina), local e sala onde cada turma vai realizar os exames;

1.4.3 Processo de Publicao de Resultados

Terminada a realizao dos exames, a equipa examinadora (formada por chefe da
SAERD, Inspectores Provinciais e Formadores) aparecem nos locais de realizao
dos exames com finalidade de recolher-nos para o CFPSP, onde so corrigidos. Os
exames so corrigidos pela equipa supracitada depois dos inspectores codificarem
(retiram a parte de nome do candidato substituindo por cdigo). Depois de corrigidos,
o chefe da SAERD, a Directora Pedaggica e mais auxiliares pertencentes a DP,
determinam as mdias, identificam admitidos, suplentes e reprovados. De seguida,
elaboram a pauta seguindo a sequncia decrescente das mdias obtidas por cada
concorrente e assina o chefe da SAERD, assim como a Directora Pedaggica. Por
sua vez, o chefe da SAERD encaminha a pauta a DG para o director geral poder
assinar. Assinada a pauta pelo director, antes da sua publicao deve ser mostrada
Inspeco Provincial para a sua aprovao. Aprovada a pauta, o chefe da SAERD
manda publicar na vitrina e manda uma cpia para SDSMAS de Montepuez.
Os candidatos admitidos so submetidos ao processo de exame psicotcnico ou
exame de redaco.
1.5

Tecnologias Utilizadas

Tecnologia so recursos utilizados para aplicar o conhecimento tcnico na execuo

de tarefas como desenvolvimento de sistemas. Desta forma, para a execuo das
tarefas de desenvolvimento de sistemas de informao de extrema importncia o
processo selectivo de recursos tecnolgicos capazes de dar sustento eficaz e
eficiente

necessidades

demandadas

pelas

metodologias

para

reduzir

significativamente a complexidade e o custo de desenvolvimento de sistemas.

Portanto, para o desenvolvimento do sistema proposto foi realizada uma busca e
seleco de aplicativos, frameworks, arquitecturas e ferramentas vistas como
adequveis para sustentarem no desenvolvimento do sistema proposto. Dentre as
tecnologias seleccionadas destacam-se:

1.5.1 Netbeans IDE

Netbeans um IDE (Integrated Development Enviroment, em portugus Ambiente de
Desenvolvimento Integrado) gratuito e de cdigo-fonte aberto, que permite o
desenvolvimento rpido e fcil de programas de computadores em linguagem Java,
PHP, C/C++ e, outras. Oferece diferentes views de dados, de vrias janelas do
projecto ferramentas teis para configurar suas aplicaes e gerenci-las com
eficincia, permitindo o drill-down de dados de forma rpida e fcil e oferecendo
ferramentas de verso por meio de uma integrao inovadora com Subversion,
Mercurial e Git (Netbeans.org, 2015). Alm disso, oferece uma ferramenta de anlise
esttica com integrao especial com a ferramenta Findbugs, amplamente utilizada
para a identificao e correco de problemas comuns em cdigo Java
(Netbeans.org, 2015).
Caractersticas do Netbeans IDE
De acordo com a Netbeans.org (2015), o Netbeans tem as seguintes caractersticas
bsicas:
Fcil de manusear;
Multiplataforma;
Multilinguagem;
Obtido em forma de software;
Identifica erros com mais rapidez e eficincia;
Estruturado e desenvolvido para facultar o trabalho de desenvolvedores.
Para o desenvolvimento do sistema de gesto de concursos foi utilizado o Netbeans
na sua verso 7.4 por proporcionar assistncia especializada, optimizar a velocidade
e o uso de memria de sua aplicao e facilitar o desenvolvimento de aplicaes
Java confiveis e dimensionveis. O projecto criado foi do tipo Dynamic Web Project,
que tem a finalidade de desenvolvimento de uma aplicao web. Este tipo de
projecto j vem com configuraes bsicas estabelecidas, facilitando assim o

10

trabalho do desenvolvedor, que no perde tempo com configuraes, como estrutura

de pastas e servidor Java.
1.5.2 Java
Java uma linguagem de programao orientada a objectos desenvolvida nos
princpios de 1991 por uma equipa de programadores, membros de um projecto de
pesquisa corporativa interna financiada por Sun Microsystems, e dirigida por James
Gosling que se basearam na linguagem C++ para o seu desenvolvimento. Tudo isso
por que a Sun Microsystems viu o potencial de utilizar o Java para adicionar
contedo dinmico como a interactividade e animaes, s pginas da web. a
tecnologia mais utlizada na actualidade para o desenvolvimento de aplicativos
corporativos de grande porte, de aplicativos para dispositivos electrnicos de
consumo

(como

fornos

de

microondas

controlos

remotos),

aprimorar

funcionalidades de servidores da Web (computadores que fornecem o contedo que

vemos em nossos navegadores da Web), fornecer aplicativos para dispositivos
voltados para o consumo popular como telemveis, PDAs, SmartPhones, Pagers, e
para muitos outros propsitos (DEITEL & DEITEL, 2010).
O Java possui um conjunto de APIs (Applications Programing Interfaces, em
portugus Interface de Programao de Aplicativos) para desenvolvimento e
execuo de aplicativos eficientes portveis, robustos, seguros, escalveis,
confiveis, dinmicos e distribudos.
Caractersticas do Java
Segundo Schildt (2013), o Java possui diversas caractersticas, dentre as quais
destacam-se:
Portabilidade: independente de plataforma, e com possibilidade de ser
usada para gerar cdigo que pode ser executado em diversas CPUs e em
diferentes ambientes;
Simplicidade: criado para facilitar aprendizagem do programador profissional
e para ser usado de maneira eficaz;
11

 Orientado a Objectos: uma abordagem limpa, til e pragmtica com relao

aos objectos (tudo visto como objecto excepto tipos de dados primitivos
como inteiros e outros, que so mantidos como no objectos de alto
desempenho);
Segurana: proteco confinando applet no ambiente de execuo do Java e
no lhe permitindo acesso a outras partes do computador, isto , capacidade
de baixar applets limitando que nenhum dano ser causado e que nenhuma
segurana ser quebrada;
Multithreaded: permite escrever programas que faam muitas tarefas ao
mesmo tempo, criando programas interactivos e conectados;
Robusto: os programas bem escritos por esta linguagem so executados de
maneira confivel em vrios sistemas.
Portanto, o Java foi a resposta exacta para as procuras do ento novo e altamente
distribudo universo da informtica para a programao da internet, onde as
principais demandas destacam-se: a portabilidade e segurana.
1.5.3 Aplicao Web (WebApp)
uma aplicao cliente-servidor, que reside num servidor e que acedida por um
programa cliente (browser, em portugus navegador). Segundo Aniceto (2009), uma
aplicao web um sistema informtico projectado para utilizao de um navegador
para sua execuo, na Internet ou em redes privadas (intranet) e o seu
desenvolvimento tem muito a ver com a necessidade de simplificar a utilizao e a
manuteno, mantendo o cdigo fonte em um mesmo local, de onde acedido por
diferentes utilizadores. Neste contexto, uma aplicao web algo mais do que uma
simples pgina web, sendo uma aplicao que responde a requisies de um cliente,
e responde normalmente com a informao adequada.
Constituio de uma Aplicao Web
Uma aplicao web constituda por um conjunto de dois (2) tipos de ficheiros
diferentes, nomeadamente: texto HTML puro ou com cdigo embebido (cdigo

12

com outra linguagem como Java) e objectos diversos, tais como base de dados,
servidor Web, documentos anotados, cdigo executvel, ou imagens.
O texto HTML puro ou com cdigo embebido constitudo por texto anotado numa
linguagem de estruturao, formatao e ligao, linguagem essa que interpretada
pelo browser dando origem as pginas web. E os objectos so ficheiros normais ou
binrios (executveis ou no) que so chamados ou consultados pelos ficheiros de
texto HTML e do a sensao de que fazem parte da pgina em que esto a ser
chamados.
Caractersticas de Aplicao Web
Actualmente existem diversas caractersticas de uma aplicao web, dentre elas
destacam-se:
Orientada a contedo: o contedo compreende dados estruturados, como
base de dados e no estruturados como arquivos textos, vdeos e este
contedo dinmico;
Baseada em hipertexto: paradigma fundamental para estruturar a
informao na web, onde os elementos bsicos so: ns, elos (links) e
ncoras. Os ns exibem informaes e os elos permitem navegabilidade
entre os ns;
Virada na esttica: o look and feel da aplicao um factor de qualidade
essencial, pois a interface tem que ser auto-explicativa, intuitiva, e
consistente com estilo de interaco, visando uma fcil navegabilidade e
aceitao por parte do utilizador;
Suporta ubiquidade: possibilidade de aceder a aplicao por diferentes
tipos de dispositivos e em diferentes contextos de uso;
Suporta concorrncia: acesso mltiplo remoto de utilizadores ao sistema
atravs de redes internet, intranet, extranet mediante um navegador;
Suporta a interaco com outras aplicaes web;

13

Vantagens de Aplicao Web

As vantagens de uma aplicao web dentro dos sistemas de informao
relativamente aplicao desktop so:
Tem-se acesso remoto em qualquer lugar que esteja o utilizador por meio de
um navegador inserido numa rede;
Possibilidade de ser acedido simultaneamente por mltiplos utilizadores
distribudos em diferentes stios;
Simples instalao, isto , no necessrio instalar em diversos
computadores, e consequentemente, simples alteraes ou actualizaes no
sistema;
Uma das desvantagens mais preocupantes e notveis nas WebApps a segurana
(esto mais susceptveis a falhas de segurana por estarem vulnerveis a ataque de
vrus) pois esto disponveis na rede. E as outras desvantagens destacam-se:
difcil limitar o nmero de clientes que iro aced-lo;
No traz manual de utilizador, e com isso requer maior esforo no desenho
das pginas webs para auto-explicarem-se;
Para o seu acesso requer recursos como a rede e mediante um navegador.
1.5.4 Arquitectura Cliente-Servidor
Cliente-Servidor um modelo computacional que separa cliente e servidor, sendo
interligados geralmente mediante o uso de rede de computadores. Um cliente pode
enviar requisies de dado para um servidor conectado e aguardar pela resposta.
Por sua vez, se o servidor estiver disponvel pode aceitar tais requisies,
processando-as e retornar o resultado para o cliente (BEZERRA, 2007).
Este modelo foi criado tendo como finalidade a descentralizao dos dados e
recursos de processamento, em oposio do modelo centralizado utilizado
antigamente. A figura 1 mostra o modelo cliente-servidor, em uma rede de
computadores, onde existe uma mquina actuando como servidor, disponibilizando
recursos para as demais mquinas, as quais actuam como clientes.
14

Figura 1: Modelo Cliente-Servidor. Fonte: Adaptado pelo autor.

Actualmente, a arquitectura cliente-servidor encontra-se distribuda em nveis ou
camadas, dividindo sistemas de software em 2, 3, 4 at n camadas. Esta diviso de
um sistema de software em camadas permite que este seja modificvel e portvel
eficientemente. Uma camada de software um conjunto de unidades de software
(programas ou mdulos) que podem ser executadas ou acedidas (BEZERRA, 2007).
A seguir descreve-se de forma breve a arquitectura cliente-servidor de 4 camadas
por ser o guia para o desenho da soluo proposta.
A arquitectura em 4 camadas a evoluo da arquitectura em 3 camadas1 e a
base de WebApps. E a ideia principal desta arquitectura, de retirar a apresentao
do cliente e centraliza-las em um determinado ponto, o qual na maioria das vezes
tem sido um servidor web. Com isso o prprio cliente deixa de existir como um
programa que precisa ser instalado em cada computador da rede, e o acesso a
aplicao feito mediante um navegador, como o Google Chrome ou Firefox.
Recebe o nome de arquitectura de 4 camadas, por separar as partes da aplicao
em 4 nveis, nomeadamente: cliente (navegador), apresentao (servidor web, onde
se efectua as alteraes na interface da aplicao e estando automaticamente
disponveis para todos os utilizadores), lgica (regras de negcio, as quais
determinam de que maneira os dados sero acedidos e esto inseridas no servidor
de aplicaes) e dados (servidor de base de dados, onde reside toda informao
1- Para mais informaes consulte em: http://www.juliobattist.com.br/artigos/ti/ncamadas.asp.

15

necessria para o funcionamento da aplicao). A figura 2 ilustra o funcionamento de

uma aplicao web com arquitectura em quatro (4) camadas.

Figura 2: Aplicao web com arquitectura em 4 camadas. Fonte: Adaptado pelo

autor.
Todo o acesso do cliente para base de dados realizado de acordo com regras
contidas no servidor de aplicaes, pois o cliente no tem acesso directo a base de
dados, sem antes passar pelo servidor de aplicaes. Com o deslocamento da
camada de apresentao para um servidor web, resolve-se o problema de ter-se que
alterar ou actualizar aplicao, em centenas de computadores, cada vez que a
interface for alterada, tornando assim, a actualizao das aplicaes mais eficiente.
1.5.5 Servidores Web
Nos dias actuais, o conceito de rede transformou-se em uma alternativa prtica de
organizao, possibilitando processos capazes de responder s demandas de
flexibilidade, conectividade e descentralizao das esferas contemporneas de
actuao e articulao social (FOROUZAN, 2006). Um programa servidor um
software executado num computador remoto oferecendo servios aos clientes. De
acordo com Forouzan (2006), o programa inicializado e este abre portas para que
os clientes possam fazer requisies, e de seguida o programa servidor funciona de
forma passiva atendendo requisies dos clientes requisitantes.
Servidores web so programas que atendem as requisies dos protocolos HTTP
enviadas pelos navegadores. As requisies so de pginas HTML, XHTML, XUL,
16

ZUML, e outras incluindo imagens, som, documentos de texto entre outros formatos
de documentos.
Os servidores web em algumas vezes podem intermediar a execuo de programas
e scripts, conjunto de instrues que velam determinadas aces que os aplicativos
realizam, que interagem mais com os utilizadores e so chamados de aplicaes
web (TAFULA, 2012).
Existem diversos servidores de aplicaes web, e dentre eles destacam-se:
Glassfish, Internet Information Service (IIS) e Apache Tomcat.
A seguir descreve-se de forma sucinta o servidor Apache Tomcat por ser o utilizado
na soluo proposta.
Apache Tomcat
Apache Tomcat um servidor de aplicao web de cdigo aberto, no comercial,
disponibilizado pela Apache Foundation, escrito em Java para executar aplicaes
web que utilizam tecnologia Java e, o mais bem-sucedido dos servidores web
livres. Por ter sido escrito em Java, pede a instalao de Java Virtual Machine (JVM)
para sua execuo, pois centra-se na linguagem de programao Java. bastante
estvel, leve, seguro, eficiente, compatvel com HTTP 1.1, funciona em qualquer
sistema operacional sem grandes problemas, e tem todas as caractersticas que um
servidor comercial de aplicaes web possui, sendo assim, uma ptima escolha e
soluo para quem quer criar ou editar uma aplicao Web (DEVMEDIA, 2015).
1.5.6 Arquitectura de Software Model View Controller (MVC)
Model View Controller, em portugus Modelo Vista Controlador um padro de
projecto. Segundo Gamma et al. (2006), um padro de projecto so descries de
objectos e classes comunicantes que precisam ser personalizados para resolver um
problema geral de projecto num contexto particular. Para os mesmos autores
supracitados, a abordagem MVC composta por trs diferentes tipos de objectos,
que so:

17

 Modelo: o objecto de apresentao;

Viso: a apresentao na tela;
Controlador: o que define a maneira como a interface do utilizador reage
s entradas do mesmo.
O padro MVC separa viso e modelos pelo estabelecimento de um protocolo do tipo
subscrio ou notificao entre eles. Neste ponto de vista, uma viso deve assegurar
que seu aspecto reflicta no estado do modelo, quando os dados do modelo mudam,
o modelo notifica as vistas que dependem dele. Em resposta cada vista tem a
possibilidade de actualizar-se. Essa abordagem permite ligar vrias vistas a um
modelo para fornecer diferentes apresentaes, conforme ilustrado na figura 3
(GAMMA et al., 2006).

Figura 3: Vises ligadas a um modelo MVC. Fonte: GAMMA et al., 2006.

Segundo Macoratti (2014), a arquitectura de software MVC tem as seguintes
vantagens:
Como o modelo MVC faz a gesto de mltiplos visualizadores usando o
mesmo modelo fcil manter, testar e actualizar sistemas mltiplos;
simples incluir novos clientes apenas incluindo seus visualizadores e
controlos;
Torna a aplicao escalvel;
possvel ter o desenvolvimento em paralelo para o modelo, visualizador e
controlo, pois so independentes.
18

Ainda o mesmo autor citado nas vantagens desta arquitectura, descreve tambm
desvantagens do padro MVC, a saber:
Requer maior tempo para analisar e modelar o sistema;
Requer pessoal especializado;
No aconselhvel para pequenas aplicaes.
1.5.7 Base de Dados (BD)
Uma base de dados um sistema de armazenamento de dados inter-relacionados,
de uma forma contnua, num sistema computacional, com redundncia controlada,
acessveis a um grupo de utilizadores e estruturado sob forma de tabelas. De acordo
com Garcia (2010), uma base de dados um armazm cheio de dados, onde estes
so armazenados de uma forma ordenada de modo a podermos aceder a eles com
facilidade quando necessrio. Portanto, BD um compartimento de armazenamento
de dados estruturado em forma de tabelas ou ficheiros de dados que acedido a um
ou grupo de utilizadores.
Quando se fala de base de dados de extrema importncia distinguir dados de
informao. Os dados so elementos isolados, significativos, rigorosos e de grande
valor e podem ser vistos como a matria-prima necessria para um determinado
processamento. Enquanto a informao o conjunto de dados, organizados e
submetidos a um processamento, tornando assim a sua utilizao num determinado
contexto (ANTAO et al., 2005 apud VAZ e ALVEZ, 2005, p. 4). Contudo, os dados
no tem qualquer valor, so elementos na sua forma bruta e somente se
transformam em informao quando so processados logicamente.
Hoje em dia existem quatro classificaes para bases de dados, de acordo com o
modelo de programao associado, nomeadamente: modelo hierrquico, modelo em
rede, Modelo orientado a Objectos e modelo relacional (ELMASRI e NAVATHE,
2005). Mas o modelo mais utilizado e que vai tambm ser utilizado neste trabalho o
modelo relacional. O modelo relacional baseia-se num conjunto de operaes lgicas
de lgebras e em clculos relacionais, e as bases de dados so constitudas por
tabelas e relacionam-se entre elas. A correcta estruturao das tabelas e os seus
19

relacionamentos garantir, conjuntamente com um sistema de gesto de base de

dados relacional, um funcionamento coerente de uma base de dados, relativamente
a operaes como insero, actualizao, consulta e eliminao.
1.5.8 Sistemas de Gesto de Base de Dados (SGBD)
Todas organizaes, por menor que sejam, possuem quantidades cada vez maiores
de dados e informaes a armazenar. Todavia, a manipulao destas informaes
est se tornando cada vez mais impossvel de ser realizada manualmente (sobretudo
via papis), pois sua utilizao alm de demorada passvel de erros ocasionados
pelo desgaste do trabalhador em conseguir localizar informaes requisitadas. Neste
sentido, torna-se mais fcil encontrar a informao numa base de dados. E qualquer
empresa que pretenda garantir um controlo efectivo sobre todo o seu negcio, tem
obrigatoriamente de recorrer a sistemas de gesto de base de dados.
Sistema de Gesto de Base de Dados um programa que permite criar e manipular
base de dados (inserir, alterar, eliminar e consultar dados). Segundo Vaz e Alves
(2005) Um Sistema de Gesto de Base Dados um programa que disponibiliza
todos os servios bsicos relacionados com as bases de dados, como operaes de
definio de estrutura, manipulao dos dados e controlo dos dados. Portanto,
nada mais que um programa que possibilita a criao, a manipulao e o controlo de
base de dados.
Caractersticas de um SGBD
Um Sistema de Gesto de Base de Dados tem as seguintes caractersticas:
Gerir grandes volumes de dados;
Facilitar a eliminao de redundncia e inconsistncia de dados;
Facilitar o armazenamento e o acesso aos dados;
Garantir o acesso aos dados a vrios utilizadores simultaneamente;
Garantir a segurana dos dados;
Garantir a integridade dos dados.

20

Actualmente h diversos tipos e diferentes SGBD comerciais e no comerciais. Dos

comerciais identificam-se: Microsoft SQL-Server, Oracle, DB2 e outros. E dos no
comerciais tem-se: PostgreSQL, MySQL, FireBird, e mais outros. O SQL-Server da
Microsoft considerado por muitos como um SGBD para empresas de pequeno a
mdio porte, j a Oracle o SGBD mais adquirido pelas empresas de grande porte,
e o DB2 da IBM o mais utilizado por instituies financeiras (CANTU, 2005). A
seguir apresenta-se, figura 4, a ilustrao de compreenso de um SGBD.

Figura 4: Compreenso de um gestor de base de dados. Fonte: Adaptado pelo autor

Segundo Cantu (2005), constituem factores determinantes para a escolha de um
adequado SGBD as seguintes variveis: controlo de redundncia, compartilhamento
de dados, controlo de acesso, cpias de segurana (backup), suporte s
transaces, suporte programao, recuperao, desempenho e escalabilidade.
MySQL
O MySQL um sistema de gesto de bases de dados relacional (SGBDR) opensource, que utiliza linguagem SQL (Linguagem de Consulta Estruturada, do ingls
Structured Query Language) como interface, que a linguagem padro mais comum
usada para criar e manipular base de dados (ORACLE, 2014).
O MySQL apresenta diversas caractersticas, e dentre as principais destacam-se:
Portabilidade: suporta diversas plataformas, tais como Windows, Linux.
Suporta controlo transaccional: as caractersticas incluem suporte
completo a transaces ACID (Atomicidade, Consistncia, Isolamento e
Durabilidade), ilimitado bloqueio em nvel de linha, capacidade de transaco
distribuda e suporte a transaces multiverso, onde leitores nunca
bloqueiam escritores e vice-versa;
21

 Excelente desempenho: a arquitectura do motor de armazenamento

permite configuraes especficas para cada aplicao resultando em alto
desempenho;
Escalabilidade: oferece o mximo em termos de escalabilidade;
Pouco exigente quanto a recursos de Hardware;
um software livre com base na licena GPL (General Public License, em
portugus Licena Pblica Geral), mas, se o programa que aceder o MySQL
no for GPL dever adquirir uma licena comercial;
Suporta verificao e correco de corrompimento de tabelas.
Segundo Alecrim (apud MACHAVA, 2012, p. 11), o MySQL focado na agilidade.
Assim, se uma aplicao necessita de retornos rpidos (velocidade de operao) e
no envolve operaes complexas, o MySQL a opo mais adequada, pois
optimizado para proporcionar processamento rpido dos dados e tempo curto de
respostas sem exigir muito do hardware . Portanto, o MySQL considerado a base
de dados mais rpida dos SGBD no comerciais.
Uma das grandes desvantagens do MySQL de no suportar operaes to
complexas e grandes bases de dados de forma eficiente. E pode ser visto como
deficincia a falta de integridade referencial em todos seus tipos de tabelas.
Espelhando-se nos ideais do Alecrim citado por Machava e Cantu citado nos factores
determinantes para a escolha do SGBD e, olhando as necessidades do sistema
proposto, como ter um sistema rpido, dinmico, seguro, e mais outras supraditas foi
utilizado o MySQL como gestor de base de dados que responde estes anseios.
1.5.9 Persistncia de Dados
Com a popularizao do Java em aplicaes corporativas percebeu-se que uma
parte significativa do tempo de desenvolvimento consumia-se na codificao de
consultas SQL e no respectivo cdigo JDBC responsvel por trabalhar com elas por
manipularem grande quantidade de dados e a complexidade de trocar uma base de
dados pelo outro, mesmo que o SQL tenha padro ANSI. Em muitos casos, esses
dados so armazenados em bases de dados relacionais, pois os principais SGBD do
22

mercado actual utilizam o modelo relacional. Numa outra perspectiva, nos dias
actuais, as aplicaes corporativas tm sido desenvolvidas com linguagens
orientadas a objectos. Desta forma, como o modelo relacional e o modelo orientado a
objectos diferem notavelmente na estruturao dos dados, ento uma transformao
dos dados deve ocorrer toda vez que alguma informao trafegar da aplicao para
a base de dados e vice-versa. Essa transformao e a troca de base de dados pelo
outro por no ser simples e, com a ideia de tornar fcil so feitas mediante a
utilizao de ferramentas de persistncia de dados, tais como Hibernete da JBoss,
EclipseLink da Eclipse Foundation, OpenJPA da Apache, e mais outras (CAELUMJAVA-WEB-F21, 2014).
Estas ferramentas de persistncia so denominadas ORM (Object Relational
Mapping, em portugus Mapeamento Objecto Relacional) e funcionam como
intermedirios entre as aplicaes e as bases de dados, automatizando diversos
processos

importantes

relacionados

com

persistncia

dos

dados.

So

padronizadas pela especificao Java Persistence API (JPA) para permitir a

utilizao dessas ferramentas e torn-las compatveis com outros recursos da
plataforma Java (CAELUM-JAVA-WEB-F21, 2014).
Hibernete
O Hibernete um provedor de persistncia de dados ORM de cdigo livre e lder
do mercado, sendo a inspirao para a especificao Java Persistence API (JPA). O
Hibernete nasceu sem o JPA mas hoje em dia comum aceder o Hibernete pela
especificao JPA. E apesar do Hibernate ter originado a JPA, o EclipseLink2 a
implementao referencial. Ele abstrai o seu cdigo SQL, toda a camada JDBC e o
SQL ser gerado em tempo de execuo. Mais que isso, ele gerar o SQL que serve
para uma determinada base de dados, j que cada base fala um dialecto diferente
dessa linguagem. Assim h possibilidade de trocar de base de dados sem ter de
alterar o cdigo Java, j que isso fica na responsabilidade da ferramenta (CAELUMJAVA-WEB-F21, 2014).
2- Para mais detalhes sobre EclipsiLink consulte no endereo: https://dzone.com/articles/introducingeclipselink?page=0,0.

23

Portanto, o Hibernete uma ptima soluo open source para mapeamento objecto
relacional trazendo uma grande flexibilidade e poder para a aplicao, contando com
a linguagem de consulta Hibernate Query Language (HQL) e aceitando a utilizao
de SQL mesclado a esta linguagem de consultas. E a soluo mais utilizada nos
dias actuais.
1.5.10 Framework
Framework uma tcnica que aplicada tanto no projecto quanto no
desenvolvimento de um software orientado a objectos, com objectivo de explorar o
potencial de reutilizao de partes de software j desenvolvido. E a ideia chave para
a sua construo no desenvolver uma soluo para uma aplicao especfica,
mas sim capturar o comportamento geral de um domnio de aplicaes e montar uma
estrutura de controlo capaz de represent-lo. Essa ideia surge com a demanda
crescente de software, a necessidade de aumentar o desempenho de produo de
software, melhora de qualidade, rentabilizar o dispndio de esforos e aumentar
lucros (CAVALHEIRO, 2014).
Hoje em dia, existem vrios frameworks designados para suportar o desenvolvimento
de aplicaes web, que aliviam a sobrecarga associada a actividades comuns
realizadas no desenvolvimento web. Dentre os diversos frameworks actuais
destacam-se: Java Server Faces (JSF)3, Tapestry3, Vaadin4, ZK, entre outros.
Framework ZK
ZK um framework de aplicaes web em AJAX (Asynchronous JavaScript and
XML), cuja programao orientado a eventos e baseado em componentes. opensource, com licena GPL/ZOL/Comercial para o desenvolvimento de aplicaes web
escrito em Java que permite a criao de interfaces ricas de aplicao (RIA Rich
Interface Aplication) sem Javascript e poucos conhecimentos de programao. Para
ZKbrasil (2010), ZK um framework orientado a eventos para o desenvolvimento

3- Para mais informaes consulte: http://bibdig.poliseducacional.com.br/document/?view=66.

4- Para mais informaes visite o endereo: https://vaadin.com

24

web baseado em AJAX+Mobile de cdigo aberto, que permite o desenvolvimento de

interfaces ricas para aplicaes web com pouca programao e custos de
desenvolvimento reduzido (simplifica o desenvolvimento das aplicaes), tal como as
aplicaes desktop.
O ZK utiliza uma linguagem meta-definio baseada em XML (ZUML, ZK User
Markep Language em portugus Linguagem de Marcao de Utilizador ZK) para
definir a interface do utilizador traduzindo para cdigo HTML quando a pgina
solicitada pelo cliente.
O framework ZK possui a denominada abordagem server-centric na qual a
sincronizao de contedo de componentes e o pipelining de evento entre clientes e
servidores so feitas automaticamente pelo motor e os cdigos de canalizao AJAX
so completamente transparentes para os desenvolvedores de aplicativos web.
Caractersticas do ZK
Dentre vrias caractersticas tcnicas que o ZK possui, as mais destacveis so:
Baseado em padres: ZK uma soluo baseada em padres;
Extensibilidade e customizao: ZK totalmente personalizvel e extensvel
com uma arquitectura modular e plug-and-play, que torna bastante simples a
criao de novos componentes e a documentao boa e detalhada;
Acesso mvel: ZK estende o alcance da sua aplicao para os dispositivos
mveis, suportando Java Mobile, Android e diversos navegadores mveis;
Segurana: ZK concebido desde sua criao para ser seguro.
Fcil de utilizar: a simplicidade um dos valores de base do ZK, e outra
facilidade que se encontra nesse framework a disponibilidade com que a sua
equipa de desenvolvedores est disposta a ajudar.
Independncia de plataforma: o ZK tem diversos componentes j de
bandeja como listbox, listitem, textbox, image, label, command, datebox,
decimalbox, intbox, frame, bordelayout e suporta vrios navegadores.

25

 Suporta integrao com vrios framework: possui integrao com outros

frameworks, como Hibernate, JSP, JSF, Spring, JPA.
Vantagens do ZK
O ZK tem como vantagens:
Faculta aos desenvolvedores menos experientes desenhar eficientemente as
interfaces do utilizador;
No imperioso que o desenvolvedor tenha conhecimentos de Ajax ou
JavaScript;
um modelo baseado em componentes claros dirigidos por eventos;
Permite centrar toda lgica de programao no lado servidor.
E tem como notvel desvantagem de no ser apropriado para aplicaes com alto
grau de interaco, tais como vdeo jogos de aco, aplicaes baseadas em
grficos vectoriais ou tridimensionais e de edio fotogrfica ou de vdeo, entre
outras (ZKBRASIL, 2010).
A figura 6 ilustra a simplicao do desenvolvimento de aplicativo web usando zk, que
mais fcil e gil que os outros frameworks supracitados.

26

Figura 5: Simplificando o desenvolvimento com ZK. Fonte: ZKbrasil, 2014.

O ZK tem muitos componentes j prontos, AJAX embutido, integrao com
framework populares, suporte da comunidade de cdigo aberto (open-source), e tudo
isso tornou o ZK como uma escolha para o desenvolvimento da aplicao web
proposta.
1.5.11 Geradores de Relatrios
Dentre as tarefas de um sistema, a mais comum a gerao de relatrio. Presente
na maioria dos sistemas, e constitui um importante mdulo do sistema por que a
partir deles que boa parte dos dados de uma base de dados so analisados e do
auxlio em diversos aspectos, principalmente na tomada de deciso. O grande ponto
em questo que os relatrios demandam muito tempo para serem implementados,
isto , o tempo para se codificar todos os elementos que o compe muito grande e
por isso existe a necessidade de se automatizar essas tarefas, onde geradores de
relatrios acabam tendo papel fundamental nos resultados de um projecto de
desenvolvimento.
Geradores de relatrio so ferramentas que auxiliam no processo de gerao de
relatrios dentro de um sistema obtendo a informao com rapidez e objectividade. E
actualmente tem vrios tipos diferentes distribudos em comerciais e no comerciais.
Dos comerciais destaca-se: Crystal Reports, que uma soluo robusta e
multilinguagem para gerao de relatrios. E dos no comerciais, que so tambm
27

open-source

tem-se:

BIRT

(Business

Intelligence

and

Reporting

Tools)5,

JasperReports e iReports (K19, 2014).

Basicamente, o processo de gerao de relatrios resume-se na definio do disign
e mapeamento de dados para campos dentro de um layout definido.
JarsperReports e iReport
JasperReports um poderoso framework no comercial e open-source desenvolvido
pela JasperForge, e o mais actualmente utilizado para a gerao de relatrios.
escrito em Java, poderoso na organizao e apresentao de contedo, permitindo a
gerao dinmica de relatrios em formatos diversos, e podendo ser utilizada em
qualquer aplicao Java (K19, 2014).
Caractersticas do JasperReport
Segundo a K19 (2014), entre as caractersticas que fazem o JasperReport poderoso
destacam-se:
Capacidade de exportar/gerar relatrios em diversos formatos diferentes,
como PDF, HTML, XML, CSV, entre outros;
Aceita diversas formas de entrada de dados, tais como um arquivo XML ou
CSV, conexo com base de dados, uma sesso do Hibernete, uma coleco
de objectos em memria, e mais outras;
Permite o uso de diagramas, grficos, e at cdigos de barras;
Os passos para gerar um relatrio so simples.
Um aspecto importante do JasperReport que o layout do relatrio definido em um
arquivo XML, geralmente com a extenso .jrxml e, possui todas informaes de
formatao do relatrio.
J o iReport uma ferramenta tambm desenvolvida pela JasperForge, com o
propsito de usar com o JasperReports na gerao de relatrios. Uma das
dificuldades ao trabalhar com os relatrios, est na definio de layout. complicado
5- Para mais informaes consulte: http://www.eclipse.org/birt/.

28

escrever o layout totalmente em XML, sem ter que se aprofundar em todas as tags e
atributos possveis, e, alm disso, posicionar todos os elementos correctamente. Na
prtica, raro algum editar o JRXML manualmente, e salvo apenas para fazer
pequenos ajustes quando necessrio. O processo normal utilizar alguma
ferramenta para gerar o JRXML automaticamente, e o iReport utilizado com esse
propsito (K19, 2014).
O iReport um aplicativo grfico que permite estruturar um relatrio, utilizando uma
palheta, e arrastando e soltando componentes, de forma parecida com o desenho de
interfaces para programas desktop. Este gera, automaticamente, um JRXML que
pode-se utilizar na aplicao a desenvolver. A vantagem que no necessrio
conhecer a fundo o XML a ser editado, economizando tempo de desenvolvimento.
Ele tambm traz um conjunto pronto de templates que j podem utilizar-se
directamente, ou ento, escrever prprios templates e reaproveitar sempre que
precisar criar um novo tipo de relatrio (K19, 2014).
1.6

Concluso

Neste captulo, fez-se a descrio do objecto em estudo, abordou-se a necessidade

de desenvolver-se um sistema computacional Web para a gesto de concursos,
abordando-se os processos e a situao actual do negcio, onde foram identificadas
inconvenincias do actual sistema utilizado. Por ltimo, fez-se uma sucinta
apresentao das ferramentas e tecnologias utilizadas para o desenvolvimento da
aplicao proposta. Quanto s tecnologias destacam-se: Java, Arquitectura ClienteServidor e MVC, SGBD MySQL, framework ZK, Hibenate, Netbeans IDE, Apache
Tomcat, JasperReport e iReport.

29

CAPITULO II. METODOLOGIAS

2.1.

Introduo

Neste captulo, faz-se uma breve abordagem sobre as metodologias utilizadas

actualmente para o desenvolvimento de sistemas, e descreve-se com maior nfase a
metodologia utilizada para o desenvolvimento do sistema proposto, na mesma ordem
aborda-se de forma sucinta a UML e Ferramentas Case que auxiliaram na
visualizao e documentao do sistema.
2.2.

Metodologias de Desenvolvimento de Software (MDS)

A metodologia de desenvolvimento de software a utilizao de um conjunto

coerente e coordenado de mtodos para atingir um objectivo, de modo que se evite a
subjectividade na execuo das tarefas, fornecendo um roteiro, um processo
dinmico e interactivo para o desenvolvimento estruturado de projectos, software,
visando qualidade e produtividade dos projectos. Tem como finalidade definir de
forma clara quem faz o que, quando, como, e at mesmo onde, para todos
os que estejam envolvidos directamente ou no no desenvolvimento do software.
Existem diversas MDS que podem ser seguidas durante o desenvolvimento de
sistemas computacionais. Apesar de existirem tantas MDS que esto agrupadas em
classes, a maior parte dos sistemas desenvolvida utilizando-se metodologias
tradicionais (Cascata, Iterativa e Incremental e mais outros) quando os requisitos so
estveis e os requisitos futuros so previsveis e, metodologias pesadas (Rational
Unified Process (RUP), ICONIX, e outras) e geis (Extreme Programming (XP),
SRUM e outras) quando os requisitos mudam rapidamente e permitem que a equipa
de desenvolvimento se concentre no desenvolvimento, em vez do seu projecto e
documentao, com vista a entregar o software ao cliente o mais rpido possvel.
A seguir descreve-se detalhadamente a metodologia RUP por ser a escolhida para o
desenvolvimento do SIGECO por, facultar o seu uso em equipas pequenas, dar
enfse na documentao e na diviso das tarefas (permitindo o desenvolvimento em

30

paralelo), eliminar riscos logo em etapas preliminares e, acima de tudo por alinhar-se
aos objectivos almejados com o sistema.
2.2.1. Rational Unified Process (RUP)
O RUP uma MDS pesada, iterativa, orientada ao cliente e baseada em papel
desenvolvida e mantida pela Rational Software. adaptvel, podendo ser
customizada para diferentes tipos e tamanhos de produtos e projectos de software.
Para JACOBSON et al. (apud NUNES e ONEILL, 2003), RUP uma abordagem
iterativa e incremental que sugere a utilizao efectiva da UML.
Este processo e a UML so amplamente utilizados em mdios e grandes projectos
orientados a objectos, uma vez que, grande parte dos artefactos, tais como
documentos e diagramas podem ser produzidos utilizando a UML associado com a
Enterprise Architect.
Caractersticas do RUP
Segundo Nunes e ONeill (2003), o RUP tem as seguintes caractersticas tcnicas
destacveis:
Processo

iterativo

incremental:

iterativo

por

que

permite

desenvolvimento de projectos em ciclos sucessivos, pois de acordo com

Sommerville (2007), as actividades de software so repetidas regularmente
medida que o sistema retrabalhado, em resposta as solicitaes de
mudana; e incremental por permitir aumento gradual de conhecimento
sobre domnio de uma aplicao, das funcionalidades exigidas e a incluso
de novas funcionalidades e melhorias contnuas;
Processo centrado em casos de uso: espelha funes que um sistema
deve proporcionar a certo conjunto de utilizadores do sistema;
Processo baseado numa arquitectura de modelao: permite caracterizar
a estrutura e o comportamento do sistema, suas funcionalidades, seu nvel
de desempenho, as interfaces com os utilizadores e outros sistemas, e
enquadrar os contributos complementares dos diversos participantes no
31

projecto, tais como analistas, programadores, utilizadores, gestores, e mais

outros.
Com as caractersticas supracitadas, observa-se que, o RUP permite realizar tarefas
em paralelo, como forma de reduzir o ciclo temporal de desenvolvimento e facilita a
elaborao da documentao de utilizao e de administrao do sistema;
A metodologia RUP quando representada graficamente, figura 5, possui duas
perspectivas nomeadamente: uma dinmica (mostra as fases ao longo do tempo, tais
como ciclos, fases, iteraes e marcos (milestones) e outra esttica (mostra as
actividades realizadas durante o processo, como actividades, disciplinas, artefactos e
papis). Na perspectiva dinmica so identificadas 4 fases: incio ou concepo,
elaborao, construo e transio, e na perspectiva esttica so observadas nove
(9) actividades nomeadamente: modelao do negcio, levantamento de requisitos,
anlise e desenho, implementao, teste, instalao, gesto de configurao e
mudana, gesto de projecto e ambiente.

Figura 6: Relao entre as fases e actividades do RUP. Fonte: Lus, 2005.

Fases do RUP
No decorrer das fases de desenvolvimento so executadas diversas actividades,
dentre as quais existem as dominantes em cada fase, como compreenso do
32

problema e levantamento de requisitos para fase de incio, levantamento e

compreenso dos requisitos para fase de elaborao, implementao e teste do
software para fase de construo, instalao e treinamento do utilizador para fase de
transio. Neste contexto, a seguir so apresentadas as quatro (4) fases de
desenvolvimento que compem o RUP (NUNES e ONEILL 2003):
Incio: a primeira fase do RUP, tambm conhecida como fase de concepo
onde se define o mbito do projecto e suas fronteiras, os critrios de avaliao
de sucesso e de riscos, a estimativa dos recursos necessrios, efectua-se o
levantamento de requisitos e elabora-se um plano de trabalho com as
principais etapas, actividades e pontos de controlo. Os resultados esperados
nesta fase so: o plano de projecto inicial, diagramas de casos de uso iniciais e
por vezes um prottipo simplificado;
Elaborao: procura-se analisar profundamente o domnio do problema,
estabelecer uma arquitectura, desenvolver o plano de projecto e eliminar os
factores de riscos. Para que estas actividades ocorram com xito, deve-se ter
uma viso e compreenso de todo sistema (seu mbito, requisitos funcionais e
no funcionais). E tem como resultado a descrio da arquitectura do software,
um ou vrios prottipos que suportam os principais casos de uso e os
resultados da primeira fase com maior detalhe;
Construo: nesta fase, faz-se implementao do software, construo do
cdigo de forma iterativa e incremental at que todos os requisitos sejam
atendidos, visando a diviso em partes menores tornando-se mais facilmente
geridas. Nela detalham-se os restantes casos de uso, definem-se os critrios
de aceitao, refina-se o desenho, efectua-se a codificao e teste da
aplicao. Neste contexto, terminada esta fase, deve-se ter um produto de
software em funcionamento e a respectiva documentao pronta para ser
disponibilizada ao utilizador;
Transio: a ltima fase do RUP, onde o produto entregue aos
utilizadores. Nesta fase ocorre o treinamento dos utilizadores e a avaliao do
produto. E caso haja necessidade de se obter uma nova verso do sistema,
d-se incio a uma nova iterao do ciclo de desenvolvimento.
33

Actividades e Papis no RUP

O RUP define uma actividade como sendo o trabalho realizado por um papel, usando
artefactos de entrada e produzindo artefactos de sada. Os papis so no total de 30
e definem o comportamento e as responsabilidades do individuo. As actividades e os
papis esto agrupados em nove disciplinas, a saber (NUNES e ONEILL (2003)):
Modelao do Negcio so trs (3) papis: visa o entendimento da
estrutura onde o software ser implantado e os problemas actuais do cliente.
Esta actividade deve assegurar que o cliente, os seus utilizadores e os
desenvolvedores tenham um entendimento comum do produto a ser entregue;
Requisitos so cinco (5) papis: traduz as necessidades do sistema a
desenvolver em forma de casos de uso, desenhando a interface com
utilizador;
Anlise e Design (Desenho) so seis (6) papis: especifica a forma de
implementao (arquitectura) dos requisitos (casos de uso);
Implementao so 3 papis: implementa as classes e os objectos em
forma de componentes, os quais so individualmente testados;
Testes so 2 papis: testa e verifica se o produto funciona como o
esperado, documentando falhas e problemas. Traz respostas gesto do
projecto sobre a qualidade do software;
Implantao so 4 papis: tem como finalidade a distribuio, a instalao
e testes em campo (teste beta), provendo treinamento e possveis migraes
(base de dados) entre o sistema anterior e o actual;
Gesto de Configurao e Controlo de Mudanas so 2 papis: o intuito
destas actividades centra-se na garantia da rastreabilidade de verses dentro
de um projecto. Atravs da definio de uma poltica adequada e de
ferramentas especficas para questes de verses, doravante versionamento
(ClearCase, CVS, SVN) possvel garantir o mapeamento de alteraes
efectuadas bem como a recuperao de cdigos e verses antigas;

34

 Gesto do Projecto so dois (2) papis: tem como finalidade prover meios
para a entrega do produto ao cliente que atenda as suas necessidades,
fazendo gesto dos riscos do projecto;
Ambiente so 3 papis: traz suporte adequado organizao do projecto,
em ferramentas, mtodos e processos.
O RUP faz uma diviso de tarefas de forma especfica nas definies das actividades
(disciplinas) e os respectivos papis, onde d maior domnio num projecto, e usa
como meio de comunicao os artefactos (pedaos de informaes que so
produzidas, modificadas ou usadas por um processo (KRUCHTEN, 2000)), tais como
modelos, cdigo fonte e arquivos executveis.
Vantagens do RUP
As vantagens tcnicas do RUP preocupam-se no seguinte:
Permitir que o processo de desenvolvimento seja iterativo e incremental, o
que pressupe a existncia de sucessivas iteraes de refinamento que se
repetem ao longo do tempo at se obter a soluo final;
Administrar mudanas com simplicidade e permitir alto nvel de reuso;
Admitir ocorrncia simultnea de diversas actividades em cada fase, onde
existe a dominante que pode ser absorvida com maior ateno;
Capacidade de erros que levam aos riscos tcnicos, aos quais so atribudos
prioridades inicialmente, so revistos em cada iterao.
Desvantagens do RUP
O RUP tem como desvantagens:
Exigir muita experincia por parte dos desenvolvedores para o seu uso;
Ser trabalhoso, consequentemente complexo para projectos pequenos.
Portanto, o RUP uma metodologia que estrutura o projecto fazendo uma diviso
bem definida de actividades (tarefas e papis) e define um conjunto de artefactos
que so usados como produtos de entrada e sada de processos. Essa estruturao
35

do processo com auxlio de ferramentas permite que o RUP seja utilizado em

qualquer tipo de projecto.
2.3.

Unified Modeling Language (UML)

A UML uma linguagem padro de modelao unificada utilizada para

especificao, visualizao, construo e documentao de artefactos de um
sistema de software promovido pelo Object Management Group (OMG), com
contribuies e direitos de autoria de empresas como Hewlett-Packard (HP), IBM,
Microsoft, Oracle, ICON Computing, Rational e mais outras (SILVA e VIDEIRA,
2008). Para Guedes (2011), a UML uma linguagem visual utilizada para modelar
softwares baseados no paradigma orientado a objectos, e de propsito geral que
pode ser aplicada a todos domnios de uma aplicao. A UML no mais do que
uma simples linguagem grfica utilizada para visualizao, especificao, construo
e documentao de sistemas de software.
2.3.1. Caractersticas da UML
Segundo Silva e Videira (2008), dentre as diversas caractersticas existentes da
UML, as principais so:
Independente de domnio de aplicao: pode ser utilizada em diferentes
projectos, tais como sistemas cliente/servidores tradicionais, sistemas
baseados na Web, sistemas de tempo real, sistemas de informao
geogrfica, entre outros;
Independente de processo ou metodologia de desenvolvimento de
software: pode ser utilizada em diferentes processos/metodologias de
desenvolvimento de Software, tais como Cascata, Iterativa e Incremental,
XP e, RUP;
Independente de Ferramentas de Modelao;
Reuni um conjunto significado de diferentes diagramas: associa e
visualiza um grupo de diferentes modelos de diagramas que especificam
as vises que compem a UML, tais como Diagramas de Casos de Uso,
de Classes, de Objectos, de interaco, de Actividades, de Estados, de
36

Componentes e de Instalao. E todos estes diagramas combinados

visualizam todas as partes do sistema a ser construdo.
Independente das linguagens de programao;
A UML tem como finalidade auxiliar o desenvolvedor de software a definir e visualizar
caractersticas do sistema, tais como seus requisitos, seu comportamento, sua
estrutura lgica, a dinmica de seus processos, suas necessidades fsicas em
relao ao equipamento sobre qual vai ser implantado, promover e facilitar a
comunicao entre um grupo variado de intervenientes antes de o software entrar em
real desenvolvimento. independente, podendo ser realmente utilizada por diversos
processos de desenvolvimento de software, diferentes ou mesmo da forma que o
desenvolvedor considerar mais adequada.
Segundo Bezerra (2007), cada elemento grfico possui uma sintaxe (uma forma prdeterminada de desenhar o elemento grfico) e uma semntica que definem o que
significa o elemento e para que ele deve ser utilizado. A sintaxe e a semntica so
extensveis, e esta extensibilidade permite que a UML seja adaptada s
caractersticas especficas de cada projecto de desenvolvimento.
O uso dos padres pressupostos pela UML deu grande contribuio no
desenvolvimento do sistema de gesto de concursos-SIGECO.
2.4.

Ferramentas CASE (Computer Aided Software Engineering)

Computer Aided Software Engineering (em portugus Engenharia de Software

Auxiliada por Computador) um conjunto de tcnicas e ferramentas informticas
que auxiliam o desenvolvedor no desenvolvimento de aplicativos, com o intuito de
diminuir esforo e complexidade, de melhorar o controlo do projecto, de aplicar
sistematicamente um processo uniformizado e de automatizar algumas actividades,
como a verificao da consistncia e qualidade do produto final e a gerao de
artefactos (SILVA e VIDEIRA, 2005). Desta forma, uma ferramenta CASE no mais
do que um produto informtico destinado a suportar uma ou mais actividades de

37

engenharia de software, relacionadas com uma ou mais metodologias de

desenvolvimento.
As ferramentas CASE actuais suportam a UML, sendo esta, geralmente a principal
caracterstica. Existem diversas e diferentes ferramentas CASE hoje no mercado,
nomeadamente: Enterprise Architect (EA), Visual Paradigm for UML (VP-UML),
Poseidon for UML, ArgoUML, e outras6.
2.4.1. Enterprise Architect (EA)
Enterprise Architect uma ferramenta CASE baseada na linguagem UML, que
colabora na execuo de uma ou mais actividades realizadas durante o processo de
engenharia de software. uma das ferramentas que mais oferecem recursos
compatveis com a UML e, muito fcil de utilizar, embora no seja livre nem oferea
uma edio para a comunidade. Apesar de no dispor uma edio para a
comunidade, a Sparx System, a empresa que produz o EA, disponibiliza uma verso
de teste de 60 dias (GUEDES, 2011).
2.5.

Concluso

Neste captulo, abordou-se de forma breve a definio de metodologia e 3 classes

desta: tradicional, pesada e gil e, cada classe fez-se a meno do seu campo de
aco, onde se identificou a importncia destas metodologias no processo de
desenvolvimento de software. Fez-se uma descrio da metodologia RUP por ser a
que conduziu o desenvolvimento do sistema de gesto de concursos. Abordou-se
resumidamente linguagem UML e ferramenta EA, identificando-se assim a boa
combinao destas com o RUP, que dinamizam os processos de desenvolvimento
de aplicao.

6- Para mais informaes consulte: http://bibdig.poliseducacional.com.br/document/?view=106.

38

CAPITULO III. ANLISE E DESENHO DA SOLUO

3.1.

Introduo

Neste captulo faz-se estudo e desenho do sistema de gesto de concursos proposto

ao CFPSP seguindo-se a metodologia RUP. Envolvendo diversas actividades,
nomeadamente:

modelao

do

negcio,

onde

identificam-se

os

actores,

trabalhadores e casos de uso, identificao dos requisitos funcionais e no

funcionais do sistema proposto, descrio da soluo proposta em termos de
diagrama de casos de uso do sistema, desenho dos diagramas de sequncia, de
classes, de modelo de dados e, finalmente de instalao.
3.2.

Modelao do Sistema Proposto

Nesta seco faz-se abordagem dos diferentes tipos de diagramas UML necessrios
para a modelao do sistema proposto.
3.2.1. Diagrama de Caso de Uso de Negcio (DCUN)
O diagrama de caso de uso de negcio uma ilustrao grfica dos processos de
negcio que tem a finalidade de visualizar as interaces dos intervenientes do
negcio. Segundo Wthressx (2015), o DCUN descreve os processos de um negcio
e suas interaces com as partes externas, como clientes e parceiros.
O DCUN concentra-se em quatro (4) itens principais, que so: Actor de Negcio
(AN), Caso de Uso de Negcio (CUN), Comunicao e Negcio.
O Actor de Negcio - um elemento que interage com o negcio tirando algum
benefcio. Para Wthressx (2015), um AN um papel desempenhado em relao ao
negcio por algum ou algo no ambiente do negcio. E para a SAERD no que
concerne a Gesto de Concursos os actores do negcio so:
Candidato - pessoa interessada em realizar inscrio, ver listas e resultado
dos exames.
Chefe da SAERD - funcionrio da SAERD que responsvel por formar
turma e publicar resultados dos exames.
39

O Caso de Uso de Negcio - descreve a actividade ou o servio que o actor vai

realizar ou se beneficiar no negcio. De acordo com a Wthressx (2015), um CUN
define um conjunto de instncias de casos de uso de negcios, no qual cada
instncia uma sequncia de aces realizada por um negcio que produz um
resultado de valor observvel para um determinado actor de negcio. Sendo assim,
para a SAERD no que toca a Gesto de Concursos temos os seguintes casos de uso
por cada actor:
Candidato: Realizar Inscrio, Ver Turma e Ver Resultado.
Chefe da SAERD: Formar Turma e Publicar Resultado.
Comunicao aco de troca de pedido e resposta do actor para com o negcio.
O Negcio o sector em estudo, que neste caso a SAERD na Gesto de
Concursos. Onde temos os seguintes trabalhadores: Director Geral (responsvel do
centro, encarregue de dar suporte s decises gerais da empresa), Directora
Pedaggica (responsvel por controlar todo processo de gesto de concursos,
dando apoio ao chefe da seco), Chefe da SAERD (funcionrio encarregue por
controlar e executar todas actividades relativas ao concurso), Inspector Provincial
(funcionrio da direco provincial de cabo delgado na rea de inspeco mandado
para inspeccionar o processo de concurso desde a realizao dos exames at a
publicao dos resultados), Formador (funcionrio do CFSP, que ajuda no processo
de correco dos exames) e, Auxiliar do chefe da seco do negcio (auxilia na
inscrio dos candidatos e na publicao de turma e pauta).
A interaco entre os itens supracitados permite ilustrar com facilidade os processos
de funcionamento da Seco de Assuntos Estudantis e Recursos Didcticos no que
diz respeito a Gesto de Concursos. A seguir apresenta-se, na figura 9, o DCUN da
SAERD na Gesto de Concursos.

40

Figura 7: Diagrama de caso de uso de negcio-SAERD na Gesto de Concursos.

3.2.2. Descrio dos Casos de Uso do Negcio
A seguir descreve-se de forma textual e resumida cada caso de uso identificado a
partir dos processos do negcio:
Realizar Inscrio: comea quando o Interessado chega ao CFPSP para efectuar a
inscrio. L encontra um Colaborador que faculta o processo de inscrio e pede-o
para se inscrever. E por sua vez, o colaborador pede documentos necessrios para a
inscrio, caso tenha documentos completos entrega uma ficha de inscrio ao
candidato para poder preencher e caso contrrio no entrega a ficha e diz para ir
completar. De seguida o candidato recebe a ficha e preenche-a, depois de
devidamente preenchida entrega ao colaborador conjuntamente com requisitos
necessrios para o efeito. Por ltimo o colaborador emite um comprovativo de
inscrio. Identificou-se como regra de negcio: realiza inscrio somente o
candidato com maior de 16 anos que rena documentos necessrios para
inscrio.
41

Formar Turma: d incio depois de encerrado o processo de inscrio, onde o chefe

da SAERD executa as seguintes actividades: seleccionar os candidatos por curso,
elaborar relaes nominais distribudas por turmas em cada curso, tendo em conta o
nmero mximo de candidatos por turma, que de 30. Depois da formao das
turmas manda o auxiliar afixar na vitrina conjuntamente com a data de realizao dos
exames, horrio (indica a hora de realizao de exame de cada disciplina), local e
sala onde cada turma vai realizar os exames. Tem como regra de negcio: uma
turma formada com 30 candidatos no mximo.
Ver Turma: publicada a turma, o candidato desloca-se ao centro com objectivo de
consultar se foi seleccionado para uma determinada turma ou no. Caso no esteja
seleccionado, dirige-se a secretaria onde encaminhado a SAERD para regularizar
o caso.
Publicar Resultado: d incio depois de corrigidos os exames, onde o chefe da
SAERD, a Directora Pedaggica e mais auxiliares pertencentes a DP, determinam as
mdias, identificam admitidos, suplentes e reprovados. De seguida, elaboram a
pauta seguindo a sequncia decrescente das mdias obtidas por cada concorrente e
assina o chefe da SAERD, assim como a Directora Pedaggica. Por sua vez, o chefe
da SAERD encaminha a pauta a DG para o Director Geral poder assinar. Assinada a
pauta pelo Director, antes da sua publicao deve ser mostrada Inspeco
Provincial para a sua aprovao. Aprovada a pauta, o chefe da SAERD manda
auxiliar publicar na vitrina e envia uma cpia para Montepuez. Identificou-se como
regra de negcio: nota mnima por cada exame 8 e s transita quem tiver
mdia maior ou igual a 10 valores.
Ver Resultado: publicada a pauta, o candidato dirige-se a vitrina do CFPSP com
objectivo de ver resultado dos exames. Visto o resultado e caso sentir-se injustiado
dirige-se para SAERD, onde entregue uma ficha de reclamao para preencher e
entregar ao chefe da SAERD a pedido de recorreco do (s) exame (s).

42

Diagrama de Actividades
Diagrama de actividade descreve passos necessrios a serem seguidos para a
execuo de um fluxo de trabalho. Para Guedes (2011), um diagrama de actividade
centra-se na descrio dos passos a serem percorridos para a concluso de uma
actividade especfica, podendo estar representada por um mtodo com certo grau de
complexidade, por exemplo, um algoritmo. Este tipo de diagrama concentra-se na
representao do fluxo de controlo de uma actividade. A seguir so apresentados
diagramas de actividades referentes aos casos de uso do negcio em estudo.

Figura 8: Diagrama de actividades de caso de uso Efectuar Inscrio.

43

Figura 9: Diagrama de actividades de caso de uso Publicar Resultado.

Os diagramas referentes aos outros casos de uso de negcio podem ser consultados
no anexo 1.
Diagrama de Classes do Modelo dos Objectos do Negcio
Um modelo dos objectos de negcio um modelo interno do negcio, descrevendo
como cada caso de uso levado em considerao por parte dos trabalhadores que
utilizam as entidades do negcio que so representadas como classes na viso
lgica. Os diagramas de classes do modelo dos objectos para os casos de uso do
negcio, SAERD podem ser vistos nas figuras 10, 11 e 12.
44

Figura 10: Diagrama de classes do modelo dos objectos de CU Efectuar Inscrio.

Figura 11: Diagrama de classes do modelo dos objectos de CU Formar Turma.

Figura 12: Diagrama de classe do modelo dos objectos de CU Publicar Resultado.

45

3.3.

Elicitao de Requisitos

a etapa de compreenso do problema aplicada ao desenvolvimento de software, e

tem

como

principal objectivo

dar uma

viso

comum aos

utilizadores e

desenvolvedores sobre o problema a ser resolvido. Para isso, os desenvolvedores,

juntamente com os utilizadores levantam e definem as necessidades dos futuros
utilizadores do sistema a ser desenvolvido. Essas necessidades so geralmente
denominadas de requisitos, e estes podem ser funcionais e no funcionais
(BEZERRA, 2007).
3.3.1. Requisitos Funcionais e no Funcionais do Sistema
Requisitos funcionais correspondem ao que o cliente almeja que o sistema faa, isto
, funcionalidades do sistema. J os no funcionais correspondem s restries
(regras de negcio), condies, consistncias, validaes que devem ser levadas a
efeito sobre os requisitos funcionais (GUEDES, 2011). Portanto, quando se fala de
requisitos funcionais referencia-se as funcionalidades que um sistema deve ter, e os
requisitos no funcionais so as caractersticas de qualidade que um sistema deve
possuir e que se relacionam s suas funcionalidades.
Na tabela 1, a seguir, so descritos os requisitos funcionais e no funcionais do
sistema proposto, que se definiram mediante uma descrio textual do sistema e
elaborao de diagramas nomeadamente: diagrama de caso de uso de negcio e de
actividades, e estes componentes foram alcanados atravs de entrevistas
direccionadas aos especialistas de negcio e anlise bibliogrfica.
Tabela 1: Requisitos funcionais e no funcionais.
Requisitos Funcionais
Acesso ao Sistema
1

O sistema deve permitir ao utilizador (funcionrio da SAERD) autenticar-se mediante um nome

de utilizador e senha.

O sistema deve permitir a alterao dos dados necessrios para fazer autenticao.

O sistema deve permitir ao chefe da SAERD cadastrar e apagar Auxiliar.

O sistema deve permitir ao chefe da SAERD inserir, alterar e apagar cursos.

46

O sistema deve permitir ao chefe da SAERD a inserir, alterar e apagar escolas/locais onde iro
realizar os exames.

Gesto de Inscrio
4

O sistema deve permitir ao candidato efectuar inscrio.

O sistema deve permitir ao candidato alterar inscrio.

O sistema deve permitir ao funcionrio da SAERD eliminar uma inscrio.

O sistema deve permitir ao candidato cancelar inscrio.

O sistema deve permitir ao funcionrio validar candidato (validar inscrio).

Gesto de Formao de Turmas

9

O sistema deve permitir ao funcionrio da SAERD seleccionar candidatos por curso ou por
nome.

10

O sistema deve auxiliar no funcionrio na criao de turmas, mediante a busca de candidatos

por curso e, imprimir.

11

O sistema deve permitir ao funcionrio alterar uma turma formada.

12

O sistema deve permitir ao funcionrio eliminar uma turma.

13

O sistema deve permitir ao funcionrio cadastrar horrio de realizao dos exames.

14

O sistema deve permitir ao funcionrio publicar e imprimir as relaes nominais.

Gesto de publicao de Resultados

15

O sistema deve permitir ao funcionrio inserir notas dos candidatos.

16

O sistema deve ser capaz de determinar mdias dos candidatos, mediante as notas inseridas.

17

O sistema deve ser capaz de identificar automaticamente aprovados, suplentes e reprovados.

18

O sistema deve permitir ao funcionrio elaborar pautas.

19

O sistema deve permitir ao funcionrio imprimir as pautas.

20

O sistema deve permitir ao funcionrio publicar as pautas.

Gesto de Consultas
21

O sistema deve permitir ao candidato consultar turma em que est inserido, mediante pesquisa
por nome ou apelido.

22

O sistema deve permitir ao candidato imprimir listas provisrias e ou definitivas.

23

O sistema deve permitir ao candidato consultar local, sala e hora de realizao dos exames.

24

O sistema deve permitir ao candidato consultar resultado dos exames, mediante pesquisa por
cdigo do candidato.

25

O sistema deve permitir ao candidato imprimir o seu resultado.

26

O sistema deve permitir ao funcionrio obter o total de candidatos.

27

O sistema deve permitir ao funcionrio obter o total de candidatos por curso.

28

O sistema deve permitir ao funcionrio obter o total de candidatos por gnero.

29

O sistema deve possibilitar a obteno de candidatos por provenincia.

47

30

O sistema deve possibilitar a listagem de candidatos apurados.

31

O sistema deve possibilitar a listagem de candidatos suplentes.

32

O sistema deve possibilitar a listagem de candidatos reprovados.

33

O sistema deve possibilitar a listagem de candidatos apurados por gnero.

34

O sistema deve possibilitar a listagem de candidatos suplentes por gnero.

35

O sistema deve permitir a listagem de candidatos por naturalidade.

Requisitos no Funcionais

O sistema estar preparado para manter a integridade da informao que circula pelo sistema
tendo capacidades de resguardar aces no autorizadas, utilizar criptografia em senhas e
liberar aos menus do sistema de acordo com a hierarquia do utilizador garantindo a
segurana.

O sistema apresentar uma interface amigvel, intuitiva, de fcil utilizao, garantindo uma
boa comunicao entre utilizador e sistema (usabilidade).

O sistema processar mltiplas requisies em um espao de tempo reduzido, de modo a

obter-se uma eficincia aceitvel.

O sistema permitir uma fcil manipulao e alterao das suas funcionalidades e

componentes que o constituem, bem como a possibilidade de adicionar funcionalidades
garantindo a boa manuteno.

O sistema ter a capacidade de tratar excepes e de recuperar falhas, sem que haja perda de
dados garantindo a confiabilidade.

O sistema funcionar em diversas plataformas, tais como Windows, Linux, IOS, e outras.

O sistema ser publicado no servidor de aplicao Apache TOMCAT 7.0 funcionando em

qualquer plataforma, mediante um navegador.

O sistema ter alta disponibilidade para que o utente no desista das suas operaes.

3.3.2. Diagrama de Caso de Uso do Sistema (DCUS)

uma representao grfica simples, descrita em linguagem natural que facilita a
comunicao de desenvolvedores e utilizadores. Para Bezerra (2007), Um DCUS
uma viso externa do sistema e representa graficamente os actores, casos de uso e
o relacionamento entre esses elementos, e tem como intuito ilustrar em uma classe
alta de abstraco quais elementos externos interagem com que funcionalidades do
sistema. Portanto, o DCUS tem como finalidade apresentar um tipo de diagrama de
contexto que apresenta os elementos externos de um sistema e as maneiras como
estes agentes utilizam o sistema.
48

O DCUS tem quatro (4) constituintes nomeadamente: actores, casos de uso,

relacionamento de comunicao e fronteiras do sistema, que a seguir so descritos,
sucintamente, de forma separada.
Actores do Sistema
Actores so agentes externos que desenvolvem algum papel em relao ao sistema,
gerando informaes para o sistema ou necessitando servios do sistema. Os meios
externos podem ser pessoas, hardware ou software. Para ilustrar um actor em um
DCUS utilizada uma notao de figura de um boneco, com o nome do actor
definido abaixo da figura, e pode relacionar-se ou associar-se a vrios casos de uso
em um DCUS (BEZERRA, 2007). A tabela 2 mostra os provveis actores do sistema
de gesto de concursos.
Tabela 2: Identificao de actores do sistema.
Actores
Candidato

Justificativa
a pessoa que se inscreve a um dos cursos dos oferecidos pela SAERD,
executando tarefas de preencher formulrio de inscrio e submeter a
SAERD, consultar turma a que pertence, consultar local, consultar sala,
consultar hora para a realizao dos exames e por ltimo consultar
resultado dos exames.

Chefe da SAERD

a pessoa responsvel da Seco de Assuntos Estudantis e Recursos

Didcticos, que o domnio do negcio. No decorrer do concurso em
coordenao

com

auxiliares

dele

executam

diversas

tarefas

nomeadamente: Formar turmas, publicar turmas, lanar notas no sistema, e

publicar resultados.
Auxiliar

uma pessoa que auxilia certas actividades ao chefe da SAERD, como

validar o candidato, podendo ser trabalhador do centro ou dos servios
distritais de sade do pas.

Casos de Uso do Sistema

Caso de uso do sistema uma especificao de sequncia de interaces entre os
actores e um sistema, e define o uso de uma parte da funcionalidade de um sistema,
sem revelar a estrutura e comportamento interno desse sistema. Entretanto, cada
49

caso de uso deve ser definido atravs da descrio narrativa das interaces que
ocorrem entre os elementos externos e o sistema. Actualmente h trs (3) formatos
de descrio comummente utilizados na descrio de um caso de uso, que so:
descrio contnua, descrio numerada e descrio particionada, e cada um destes
tem o seu grau de detalhamento, que pode ser sucinto ou detalhado (BEZERRA,
2007).
Dentre os formatos citados, nesta monografia, na documentao dos casos de uso,
utilizar-se- o formato de descrio particionada e numerada, com grau de
detalhamento expandido.
Segundo Bezerra (2007), cada caso de uso representado por uma elipse, com o
nome do caso de uso posicionado dentro da elipse. Um relacionamento de
interaco representado por um segmento de recta ligando o actor e caso de uso.
Finalmente, uma fronteira do sistema representada por um rectngulo onde so
inseridos os casos de uso, com actores posicionados do lado de fora para enfatizar a
diviso entre o interior e o exterior do sistema.
Seguindo-se a ordem de ideias de definio de actores e casos de uso de sistema,
vai se construir o DCU do SIGECO. O diagrama tem como casos de uso: efectuar,
alterar, validar e eliminar inscrio, gerir turma, gerir centro/instituto, gerir curso,
realizar autenticao, alterar autenticao, inserir nota, elaborar e publicar pauta,
gerir auxiliar e, finalmente gerir consultas. Tem como actores chefe da SAERD,
auxiliar e candidato, sendo que a comunicao entre os casos de uso e os actores
mostrada na figura 13.

50

Figura 13: Diagrama de caso de uso do SIGECO.

Documentao dos Casos de Uso do SIGECO
A documentao de um caso de uso uma descrio, que utiliza uma linguagem
simples, de informaes como a funo em linhas gerais do caso de uso, quais
actores que interagem com o caso de uso, quais fases devem ser executadas pelo
actor e pelo sistema para que o caso de uso execute a sua funo, quais parmetros
devem ser fornecidos e quais restries e validaes que o caso de uso deve ter
(GUEDES, 2011). A documentao no descreve como o software ser
implementado, mas sim como ele se comportar quando estiver pronto. Cada caso
de uso tem uma descrio o qual descreve a funcionalidade que ir ser construda no
sistema proposto, o comportamento e as informaes do software.
A seguir, faz-se a descrio textual dos diferentes casos de uso do SIGECO.
51

Na tabela 3, esto descritos os passos em forma de documentao que o actor

funcionrio deve aplicar ao executar o caso de uso Realizar Autenticao no
sistema.
Tabela 3: Descrio de caso de uso Realizar Autenticao.
Nome

Realizar Autenticao

Sumrio

CSU01

Este caso de uso descreve o processo para autenticar-se no sistema.

Casos de uso (CU)

associados

Nenhum.

Actores Primrios: Chefe da SAERD, Auxiliar.

Actores Secundrios: ----Pr-condio: estar cadastrado no sistema.
Ps-condio: Acesso a interface principal com funcionalidades, relativas ao respectivo privilgio,
activas.
Fluxo Principal
Actor

Sistema
1. O sistema apresenta a interface principal sem
menu funcionrio.

2. O funcionrio selecciona boto autenticar.

3. O sistema apresenta uma tela de autenticao

com dois campos vazios.

4. O

funcionrio

insere

seu

nome

de

utilizador e a senha.

5. O sistema verifica o tipo de funcionrio e se os

dados (nome e senha) inseridos so vlidos.
6. O sistema apresenta a interface principal com
menu funcionrio com funcionalidades activas
correspondentes ao utilizador autenticado e o
caso de uso termina.

Fluxo Alternativo: no h.
Fluxo de Excepo [5]: nome de utilizador ou senha incorrecta
a) O funcionrio introduz nome de utilizador
e/ou senha incorrecta.

b) O sistema apresenta uma mensagem de erro

informando

que

utilizador

ou

senha

incorrecta.
c) O sistema volta ao passo 3 do fluxo principal.

Na tabela 4, esto descritos no documento de caso de uso as funes que o actor

funcionrio deve executar para Alterar Senha de autenticao do utilizador.
52

Tabela 4: Descrio de caso de uso - Alterar Senha.

Nome

Alterar Senha

Sumrio

CSU02

Este caso de uso descreve o processo de alterao da senha de

autenticao do utilizador (funcionrio).

CU associados

Nenhum.

Actores Primrios: Chefe da SAERD, Auxiliar.

Actores Secundrios: ----Pr-condio: Ter nome de utilizador e senha cadastrada no sistema.
Ps-condio: Senha alterada e actualizada
Fluxo Principal
Actor

Sistema
1. O sistema apresenta a interface principal.

2. O funcionrio selecciona boto autenticar.

3. O sistema apresenta uma tela de autenticao

com um boto alterar senha.

4. O funcionrio selecciona o boto alterar

senha.

5. O sistema apresenta 1 tela com 4 campos

vazios (1 para introduzir nome do utilizador, 2
senha corrente, 3 nova senha e 4 confirmar
nova senha) e um boto guardar.

6. O funcionrio introduz o nome, a senha

7. O

sistema

verifica

nova

mesma

senha

quando

volta

corrente, a nova senha e volta a introduzir

confirmao

a nova senha para sua confirmao.

introduzir no campo confirmar nova senha.

8. O funcionrio selecciona o boto guardar.

da

9. O sistema executa a operao actualizando a

nova senha e o caso de uso termina.

Fluxo de Excepo [7]: Senha de confirmao diferente de nova senha

a) O

funcionrio

introduz

senha

de

confirmao diferente da nova senha.

b) O sistema apresenta uma mensagem de erro

informando que a senha de confirmao
diferente da senha nova.
c) O sistema volta ao passo 5 do fluxo principal.

Fluxo de Excepo [8]: Senha ou nome de utilizador invlido

a) O funcionrio introduz senha ou nome de
utilizador invlido.

b) O sistema emite 1 mensagem informando que

senha ou nome de utilizador invlido.
c) O sistema volta ao passo 5 do fluxo principal.

Na tabela 5,esto descritos no documento de caso de uso as funes que o actor

candidato deve executar para Efectuar Inscrio.

53

Tabela 5: Descrio de caso de uso Efectuar Inscrio.

Nome

Efectuar Inscrio

Sumrio

CSU03

Este caso de uso descreve as etapas necessrias para a realizao de uma

inscrio.

CU associados

Nenhum.

Actores Primrios: Candidato.

Actores Secundrios: Funcionrio.
Pr-condio: O sistema deve estar disponvel.
Ps-condio: Inscrio efectuada.
Fluxo Principal
Actor

Sistema

1. O candidato solicita efectuar inscrio no

2. O sistema carrega uma interface com um

menu candidato.

formulrio vazio e boto guardar.

3. O candidato preenche o formulrio e

4. O sistema guarda os dados, gera dois cdigos,

selecciona o boto guardar.

um nmero do candidato e outro combinado

para edio da inscrio e o caso de uso
termina.
Fluxo Alternativo: no h.

Fluxo de Excepo [3]: Utilizador no preenche campos obrigatrios

a) O

funcionrio

no

preenche

campos

b) O sistema emite uma mensagem de erro

obrigatrios.

informando

que,

os

campos

so

de

preenchimento obrigatrio.
c) O sistema volta ao passo 2 do fluxo principal.
Regras de Negcio Associados
RN03: Inscreve-se somente candidato com maior de 16 anos de idade.
RN04: O candidato inscreve-se apenas em um curso.

Na tabela 6, esto descritos no documento de caso de uso as funes que o actor

candidato deve executar para Editar Inscrio j efectuada.
Tabela 6: Descrio de caso de uso - Editar Inscrio
Nome
Sumrio

Editar Inscrio

CSU04

Este caso de uso descreve as etapas necessrias para a alterao de dados

de uma inscrio.

CU associados

Nenhum.

54

Actores Primrios: Candidato.

Actores Secundrios: Funcionrio
Pr-condio: O sistema deve estar disponvel
Ps-condio: Inscrio editada.
Fluxo Principal
Actor

Sistema

1. O candidato solicita editar inscrio no

2. O sistema apresenta uma janela com dois

menu candidato.

campos para introduzir o cdigo combinado

gerado no acto da inscrio.

3. O candidato introduz o cdigo e chave

(cdigo combinado).

4. O sistema carrega os dados do candidato num

formulrio e boto guardar.

5. O candidato efectua a alterao pretendida

e selecciona o boto guardar.

6. O sistema actualiza os dados e, o caso de uso

termina.

Fluxo de Excepo [5]: Utilizador no preenche campos obrigatrios

a) O

funcionrio

no

preenche

campos

obrigatrios

b) O sistema emite uma mensagem de erro

informando

que,

os

campos

so

de

preenchimento obrigatrio
c) O sistema volta ao passo 4 do fluxo principal.

Tabela 7: Descrio de caso de uso Validar Candidato.

Nome

Validar Candidato

Sumrio

CSU05

Este caso de uso descreve as etapas necessrias para a validao de uma

inscrio.

CU associados

Nenhum.

Actores Primrios: Auxiliar e Chefe da SAERD (funcionrio).

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e funcionrio autenticado.
Ps-condio: Candidato validado.
Fluxo Principal
Actor

Sistema

1. O funcionrio solicita validar inscrio no

2. O sistema apresenta uma janela com campo

menu funcionrio.

para introduzir cdigo do candidato e boto

pesquisar.

3. O

funcionrio

introduz

selecciona o boto pesquisar.

cdigo

4. O sistema carrega uma tela com dados do

candidato numa tabela (contm uma colunatalo vazia), dois campos vazios (1 para inserir

55

nmero de talo e 2 para inserir local onde

pretende realizar os exames) e boto validar.
5. O funcionrio insere o nmero de talo,

6. O sistema efectua a operao validando o

local onde o candidato pretende fazer os

candidato e, mostra na coluna-talo da tabela

exames e selecciona o boto validar.

referenciada

em

nmero

de

talo

introduzido e mostra tambm uma mensagem

de sucesso e o caso de uso termina.
Fluxo de Excepo [3]: Funcionrio introduz cdigo invlido
a) O funcionrio introduz cdigo invlido.

b) O sistema emite uma mensagem informando

que, o cdigo invlido.
c) O sistema volta ao passo 2 do fluxo principal.

Fluxo de Excepo [5]: Funcionrio introduz nmero de talo e/ou local invlido
a) O funcionrio introduz nmero de talo ou
local de realizao de exame invlido.

b) O sistema emite uma mensagem informando

que, o nmero de talo ou local de realizao
de exame invlido.
c) O sistema volta ao passo 4 do fluxo principal.

Tabela 8: Descrio de caso de uso Eliminar Inscrio

Nome

Eliminar Inscrio

Sumrio

CSU05

Este caso de uso descreve as etapas necessrias para a eliminao de uma

inscrio.

CU associados

Nenhum.

Actores Primrios: Chefe da SAERD.

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e o chefe autenticado.
Ps-condio: Inscrio eliminada.
Fluxo Principal
Actor

Sistema

1. O funcionrio solicita eliminar inscrio no

2. O sistema apresenta uma janela com campo

menu funcionrio.

para introduzir cdigo do candidato ou nome e

boto pesquisar.

3. O funcionrio introduz o cdigo ou nome e

4. O sistema carrega os dados do candidato.

selecciona o boto pesquisar.

5. O funcionrio selecciona o candidato e

6. O sistema emite uma tela de confirmao.

selecciona o boto eliminar.

7. O funcionrio confirma a eliminao do

8. O sistema elimina o candidato e o caso de uso

56

candidato

termina.
Fluxo Alternativo: no h.

Fluxo de Excepo [3]:Funcionrio informa cdigo ou nome incorrecto

a) O funcionrio introduz cdigo ou nome
incorrecto.

b) O sistema emite uma mensagem informando

que, o cdigo ou nome no existe.
c) O sistema volta ao passo 2 do fluxo principal.

RN05: a inscrio somente eliminada por chefe da SAERD.

Na tabela 9, a seguir, esto descritos no documento de caso de uso as funes que

o actor funcionrio deve executar para Gerir Turma.
Tabela 9: Descrio de caso de uso - Gerir Turma.
Nome

Gerir Turma

Sumrio

CSU06

Este caso de uso descreve as etapas necessrias para a gesto de turmas

ou listas, no que toca a formao, edio, eliminao e publicao.

CU associados

Nenhum.

Actor Primrio: Chefe da SAERD (funcionrio)

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e funcionrio autenticado.
Ps-condio: turma formada, editada, eliminada e publicada.
Fluxo Principal
Actor
1. O funcionrio solicita a gesto de turma no
menu funcionrio.

Sistema
2. O sistema apresenta as opes: Formar, Editar,
Eliminar e Publicar.

3. O funcionrio escolhe a opo desejada.

4. O sistema regista a operao e o caso de uso

termina.

Fluxo Alternativo [3.1]: Formar

3.1.1.

O funcionrio escolhe formar turma.

3.1.2.

O sistema abre uma interface com campo

para inserir o curso.

3.1.3.

O funcionrio insere o curso.

3.1.4.

O sistema apresenta uma interface com

todos candidatos do correspondente curso e
mais 4 campos: 1 para inserir o nmero de
candidatos, 2 para inserir a turma, 3
mostra a sala e 4 a escola onde fica a
turma inserida.

3.1.5.

O funcionrio insere o nmero de

3.1.6.

O sistema forma a turma e visualiza-a numa

57

candidatos e a turma.

tabela e o caso de uso termina.

Fluxo Alternativo [3.2]: Editar

3.2.1.

O funcionrio escolhe editar turma.

3.2.2.

O sistema abre uma tela com campo para

introduz a turma.

3.2.3.

O funcionrio introduz a turma.

3.2.4.

O sistema abre uma tela com os dados da

turma e com campos descritos em 3.1.4
excepto o 1 campo que passou para
nmero de candidato.

3.2.5.

O funcionrio insere o nmero de

3.2.6.

sistema

transfere

candidato

ou

candidato (se pretende transferir um) e

candidatos para a turma inserida por o

insere a turma, ou somente insere a

funcionrio e o caso de uso termina.

turma (se pretende transferir todos).

Fluxo Alternativo [3.3]: Eliminar
3.3.1.

O funcionrio escolhe eliminar turma.

3.3.2.

O sistema abre uma tela com campo para

informar a turma e com um boto para
submeter o pedido

3.3.3.

O funcionrio introduz a turma.

3.3.4.

O sistema abre uma tela com todos

candidatos pertencentes a turma.

3.3.5.

funcionrio selecciona

boto

3.3.6.

apagar.

O sistema elimina a turma e o caso de uso

termina.

Fluxo Alternativo [3.4]: Publicar

3.4.1.

O funcionrio escolhe a opo publicar

3.4.2.

turmas.

sistema

apresenta

uma

interface

carregando todas turmas e, com um boto

publicar.

3.4.3.

funcionrio selecciona

boto

publicar.

3.4.4.

O sistema disponibiliza todas turmas aos

candidatos e o caso de uso termina.

Fluxo de Excepo [3.1.3]: Funcionrio insere curso invlido

a) O funcionrio insere curso no vlido.

b) O sistema abre uma tela com uma mensagem

de erro e o caso de uso volta ao passo 3.1.2 do
fluxo alternativo formar.

Fluxo de Excepo [3.1.5]: Funcionrio insere nmero de candidatos ou turma invlida

a) O

funcionrio

insere

nmero

candidatos ou turma invlida.

de

b) O sistema abre uma tela com uma mensagem

de erro e o caso de uso volta ao passo 3.1.4 do
fluxo alternativo formar.

Fluxo de Excepo [3.2.3]: Funcionrio informa turma invlida

a) O funcionrio introduz turma invlida

b) O sistema abre uma tela com a mensagem: no

58

existe turma com este nmero. E volta ao passo

3.2.2 do fluxo alternativo editar.
Fluxo de Excepo [3.2.5]: Funcionrio introduz nmero de candidato ou turma invlida
a) O

funcionrio

introduz

nmero

de

b) O sistema abre uma tela com a mensagem:

candidato ou turma invlida.

nmero de candidato ou turma invlida. E volta

ao passo 3.2.4 do fluxo alternativo editar.

Fluxo de Excepo [3.3.3]: Funcionrio informa turma invlida

a) O funcionrio introduz turma invlida.

b) O sistema abre uma tela com a mensagem: no

existe turma com este nmero. E volta ao passo
3.3.2 do fluxo alternativo eliminar.

Regras de Negcio Associados

RN06: o nmero mximo de candidatos numa turma de 30.

Na tabela 10, esto descritos no documento de caso de uso as funes sequenciais

que um actor funcionrio deve executar para inserir nota dos exames realizados.
Tabela 10: Descrio de caso de uso - Inserir Nota.
Nome

Inserir Nota

CSU07

Sumrio

Este caso de uso descreve as etapas necessrias para insero de notas.

CU associados

Nenhum.

Actores Primrios: Chefe da SAERD (funcionrio).

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e funcionrio autenticado.
Ps-condio: nota inserida.
Fluxo Principal
Actor
1. O funcionrio solicita inserir nota no menu
funcionrio.
3. O funcionrio introduz o curso.

Sistema
2. O sistema apresenta uma janela com campo
para introduzir o curso.
4. O sistema abre uma interface com 3 campos: 1
para inserir o nmero do candidato, 2 para
inserir a disciplina e o 3 a nota obtida e uma
tabela vazia.
5. O funcionrio introduz nmero de 6. O sistema preenche a tabela com dados do
candidato e a disciplina.
candidato como seu cdigo, nome, curso,
disciplina inserida e deixa uma coluna vazia de
nota.
7. O funcionrio introduz a nota da disciplina 8. O sistema regista a nota e mostra na tabela
inserida.
referenciada em 4 e 6 conjuntamente com os
outros dados e o caso de uso termina.
Fluxo de Excepo [3]: Funcionrio introduz curso invlido
a) O funcionrio introduz curso invlido.

b) O sistema emite uma mensagem informando

que o curso no existe.

59

c) O sistema volta ao passo 2 do fluxo principal.

Fluxo de Excepo [5]: Funcionrio introduz nmero de candidato ou disciplina invlida
a) O funcionrio introduz nmero do candidato b) O sistema abre uma tela com uma mensagem
ou disciplina invlida.
informando que o candidato ou disciplina
invlida.
c) O sistema volta ao passo 4 do fluxo principal.
Fluxo de Excepo [7]: Funcionrio introduz nota invlida
a) O funcionrio insere nota invlida.

b) O sistema abre uma tela informando que a

nota inserida invlida e volta ao passo 6.
Regras de Negcio Associados

RN07: Nota no intervalo de 0 a 20 valores.

Na tabela 11, esto descritos no documento de caso de uso as funes sequenciais

que um actor funcionrio deve executar para Elaborar Pauta dos exames.
Tabela 11: Descrio de caso de uso - Elaborar Pauta
Nome

Elaborar Pauta

Sumrio

CSU08

Este caso de uso descreve as etapas necessrias para elaborao de

pauta.

Casos

de

uso

associados

Determinar Mdia, Classificar Candidato.

Actores Primrios: Chefe da SAERD (funcionrio).

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e funcionrio autenticado.
Ps-condio: Pauta elaborada.
Fluxo Principal
Actor

Sistema

1. O funcionrio solicita elaborar pauta no

2. O sistema apresenta uma janela com campo

menu funcionrio.
3. O funcionrio introduz o curso.

para introduzir o curso.

4. O sistema abre uma interface com campo para
inserir nmero de vagas disponveis e uma
tabela contendo dados dos candidatos tais como
cdigo, nome, curso, nvel do curso, mdia e
mais uma coluna vazia, de resultado.

5. O funcionrio introduz o nmero de vagas.

6. O sistema classifica (identifica) os candidatos,

inserindo aprovado, suplente ou reprovado,
regista a classificao de cada um no sistema e
mostra na coluna resultado a classificao de

60

cada um. E disponibiliza boto sair e imprimir.

7. O funcionrio selecciona o boto desejado

8. O sistema regista a operao correspondente ao

boto seleccionado e o caso de uso termina.

Fluxo Alternativo [8.1]: Sair

8.1.1.

O funcionrio selecciona em sair.

8.1.2.

O sistema fecha a tela e o caso de uso

termina.

Fluxo Alternativo [8.2]: Imprimir

8.2.1.

O funcionrio selecciona em imprimir.

8.2.2.

O sistema imprime e o caso de uso termina.

Fluxo de Excepo [3]: Funcionrio introduz curso invlido

a) O funcionrio introduz curso invlido.

b) O sistema emite uma mensagem informando

que o curso no existe.
c) O sistema volta ao passo 2 do fluxo principal.

Fluxo de Excepo [5]: Funcionrio introduz nmero invlido

a) O funcionrio introduz nmero negativo.

b) O sistema abre uma tela informando que o

nmero de vagas deve ser positivo.
c) O sistema volta ao passo 4 do fluxo principal.

Regras de Negcio Associados

RN08: O candidato que tiver abaixo de 8 numa das disciplinas reprova.
RN09: Transita o candidato que tiver mdia maior ou igual a 10 valores.

Na tabela abaixo, esto descritos no documento de caso de uso as funes que um

actor funcionrio deve executar para Publicar Pauta dos exames.
Tabela 12: Descrio de caso de uso Publicar Pauta
Nome

Publicar Pauta

Sumrio
Casos

CSU09

Este caso de uso descreve as etapas necessrias para publicar pautas.

de

uso

associados

Nenhum.

Actores Primrios: Chefe da SAERD (funcionrio).

Actores Secundrios: --Pr-condio: O sistema deve estar disponvel e funcionrio autenticado.
Ps-condio: Pauta publicada.
Fluxo Principal
Actor

Sistema

1. O funcionrio solicita publicar pauta no

2. O sistema apresenta uma interface com todas

menu funcionrio.

as pautas e um boto publicar.

61

3. O funcionrio selecciona em publicar.

4. O sistema disponibiliza as pautas para os

candidatos,

envia

um

e-mail

para

os

candidatos que cadastraram seu endereo

electrnico no acto da inscrio informando que
a pauta j esta publicada e o caso de uso
termina.
Regras de Negcio Associados
RN10: Publica-se a pauta s depois de assinada pelo director geral, directora pedaggica, chefe da
SAERD e autorizada pela Inspeco Provincial.

Na tabela 13, esto descritos no documento de caso de uso as funes que o actor
candidato/funcionrio deve executar para Gerir Consultas.
Tabela 13: Descrio de caso de uso - Gerir Consultas.
Nome

Gerir Consultas

Sumrio

CSU10

Este caso de uso descreve as etapas necessrias para gesto de consultas, no

que toca a consulta de turma/listas, resultado, escolas e, salas de exame.

Casos

de

associados

uso
Nenhum;

Actores Primrios: Candidato.

Actores Secundrios: funcionrio.
Pr-condio: O sistema deve estar disponvel.
Ps-condio: turma/lista, resultado, escola e sala de exame consultada.
Fluxo Principal
Actor

Sistema

1. O candidato solicita gerir consultas no menu

2. O sistema apresenta as opes: listas, escolas,

consultas.

salas de exame e resultado.

3. O candidato escolhe uma opo desejada.

4. O sistema regista a operao e o caso de uso

termina.

Fluxo Alternativo [3.1]: Listas

3.1.1.

O candidato clica em listas.

3.1.2.

O sistema apresenta uma janela com

campo para introduzir o nome ou apelido do
candidato e, um boto pesquisar.

3.1.3.

O candidato introduz o nome ou apelido e

clica no boto pesquisar.

3.1.4.

O sistema abre uma interface com dados do

candidato como cdigo, nome, apelido,
instituto/centro a que candidata, local e sala

62

de exame e, um boto sair.

3.1.5.

O candidato faz a leitura dos dados e,

3.1.6.

clica em sair.

O sistema fecha a tela e o caso de uso

termina.

Fluxo Alternativo [3.2]: Escolas

3.2.1.

O candidato escolhe a opo escolas.

3.2.2.

O sistema apresenta uma janela com todas

escolas em forma de menu.

3.2.3.

O candidato selecciona numa escola.

3.2.4.

O sistema visualiza informaes da escola

no tocante a localizao, distribuio de
salas e mais outras informaes.

Fluxo Alternativo [3.3]: Resultado

3.3.1.

O candidato selecciona em resultado.

3.3.2.

O sistema apresenta uma tela com um

campo para inserir nmero do candidato.

3.3.3.

O candidato informa o cdigo dele.

3.3.4.

O sistema abre uma tela com dados do

candidato como nome, nota das duas
disciplinas, mdia, resultado e o caso de
uso termina.

Fluxo de Excepo [3.3.3]: Cdigo invlido

a) O candidato introduz cdigo invlido.

b) O sistema emite uma mensagem informando

que o cdigo no valido.
c) O sistema volta ao passo 3.3.2 do fluxo
alternativo resultado.

3.4.

Diagrama de Classes de Desenho

Diagrama de classes de desenho define e mostra a estrutura das classes

utilizadas pelo sistema, determinando os atributos, mtodos que cada classe tem e,
estabelece como as classes se relacionam e trocam mensagens entre si (GUEDES,
2011). Cada classe tem trs compartimentos: 1 para nome da classe, 2 para
atributos e 3 para mtodos ou operaes da classe. Este diagrama serve de apoio
para a construo dos demais diagramas e, um dos mais utilizados e importantes
da UML, por ser mais rico em termos de notao. Para o presente trabalho foram
identificadas e criadas classes de desenho como forma de realizar os casos de uso,
a ver no anexo 2.

63

3.5.

Diagrama de Sequncia

Diagrama de sequncia um diagrama comportamental que se preocupa com a

ordem temporal em que as mensagens so trocadas entre os objectos envolvidos em
um determinado caso de uso. Baseia-se em um caso de uso definido pelo diagrama
de caso de uso e apoia-se no diagrama de classes para determinar os objectos das
classes envolvidas no caso de uso (GUEDES, 2011). O diagrama de sequncia
ilustra o evento gerador do processo modelado, o actor responsvel por evento e,
determina como o processo deve se desenrolar e ser concludo por meio da
chamada de mtodos disparados por mensagens enviadas entre os objectos. Para o
trabalho foram criados diagramas de sequncia de casos de uso prioritrios, a ver no
anexo 3.
3.6.

Diagrama de Modelo de Dados

Diagrama de modelo de dados representa o modelo de dados, que um modelo

fsico, em forma de tabelas ou entidades relacionadas, cada tabela contendo um
nome, atributos, uma chave primria e, pode ter uma chave estrangeira. Pois, tem o
propsito de mostrar a estrutura e a forma como os dados sero armazenados e o
modo de relacionamento entre as tabelas. O anexo 4 ilustra o diagrama de modelo
de dados do Sistema de Gesto de Concursos.
3.7.

Diagrama de Implantao

Diagrama de implantao um diagrama puramente fsico da UML que, modela a

arquitectura fsica de um sistema, mostrando os artefactos que estaro armazenados
em cada n (representa dispositivo de hardware tais como servidor, impressora, PC
cliente, entre outros dispositivos que suportam o ambiente em tempo de execuo do
sistema), caminhos de comunicao, os relacionamentos entre os componentes de
hardware e software e a distribuio fsica do processamento (BEZERRA, 2007).
Este diagrama tem o propsito de visualizar todo o aparato fsico sobre o qual o
sistema ser implantado e executado em termos de hardware. A figura 14 mostra o
ambiente fsico, que segue a arquitectura cliente-servidor de 4 camadas (o servidor

64

web e de aplicao esto instalados numa nica mquina), onde ser implantado e
executado o SIGECO.

Figura 14: Diagrama de Implantao do SIGECO.

3.8.

Concluso

Neste captulo fez-se anlise e desenho da soluo proposta, a partir de uma

abordagem detalhada da modelao do negcio, identificando-se e descrevendo-se
de forma textual e grfica os casos de uso do negcio que, deram compreenso do
funcionamento actual da SAERD, identificao e soluo proposta do problema e
uma base de entendimento entre o desenvolvedor e os interessados. Na mesma
ordem, fez-se a eliciao dos requisitos, onde se identificou e se descreveu as
funcionalidades e os requisitos no funcionais do sistema. Finalmente, abordou-se
anlise e desenho da soluo proposta, onde se, identificou um conjunto de classes
de anlise para se obter classes de desenho que permitiram representar os
requisitos identificados, e visualizaram-se diferentes diagramas que ilustraram o fluxo
de trabalho, funcionalidades, o ambiente e a arquitectura tecnolgica de forma a
garantir a satisfao de todos requisitos, no desenho da soluo.
65

CAPTULO IV. IMPLEMENTAO

4.1.

Introduo

Neste captulo faz-se a apresentao da aplicao web desenvolvida, visualizando

as interfaces principais, com suas funcionalidades implementadas.
4.2.

Caractersticas Gerais do Sistema

O sistema foi construdo para ser uma aplicao web. Para a sua construo,
baseou-se numa arquitectura cliente-servidor de 4 camadas. O seu desenvolvido foi
concebido

de

forma

permitir

acesso

remoto,

fcil

instalao,

consequentemente a fcil manuteno.

4.3.

Interface do utilizador

O sistema SIGECO tem uma interface fcil de usar, sobretudo interactiva, de modo a
garantir um bom acompanhamento ao utilizador, enquanto est navegando no
sistema. A seguir apresenta-se a interface principal do sistema, onde o candidato ir
navegar (figura 15).

Figura 15: Interface principal do sistema para o candidato.

66

Legenda:
A o menu do sistema, onde o candidato vai interagir para ter acesso s
funcionalidades do sistema que lhe dizem respeito.
B o boto que permite o utilizador-funcionrio abrir a tela de autenticao para ter
acesso a funcionalidades do sistema que lhe dizem respeito(submenu funcionrio). A
figura 16 mostra a interface do funcionrio, depois da sua autenticao, onde
adicionado o submenu funcionrio no menu geral do sistema.

Figura 16: Interface principal do sistema para o funcionrio, depois da autenticao.

Legenda:
C o menu do sistema, depois do funcionrio autenticar-se, onde tem o submenu
funcionrio adicionado.

67

4.3.1. Especificao do Menu Geral do Sistema

Neste subtpico, faz-se a apresentao das funcionalidades contidas em cada
submenu do menu geral do sistema. A figura 17 mostra os submenus identificados
por letras alfabticas e o ambiente de execuo das funcionalidades.

Figura 17: Pgina principal com submenus identificados.

Legenda:
A P. Inicial (Pgina inicial): contm mensagem de boas vindas e uma foto do
CFPSP, conforme mostra a figura 17 no ambiente de execuo.
B Edital: um menu item que contm o edital de inscrio em formato pdf.
seleccionando neste menu item, o sistema mostra o edital e d opes para salvar
ou imprimir, conforme ilustra a figura 18.

68

Figura 18: Edital de inscrio.

C Submenu candidato - contm 3 funcionalidades, a saber: Efectuar e Editar
Inscrio e, baixar formulrio de reclamao. A figura a seguir mostra uma ficha
de inscrio, depois do utilizador seleccionar no menu item efectuar inscrio.

Figura 19: Ficha de inscrio com tab-Dados Pessoais.

69

Legenda:
1. Boto prximo: permite ao utilizador a ir na prxima tela ou tab-documentos,
tudo isso porque a ficha de inscrio est dividida por tipo de dados do
candidato. A figura 20 mostra a tab-documentos e as outras.
2. Boto Cancelar: permite ao utilizador apagar os dados inseridos nos campos
do formulrio na tab-dados pessoais.
3. Boto Sair: permite ao utilizador sair do submenu candidato para a pgina
principal.

Figura 20: Ficha de inscrio com tab-Documentos.

1. Boto anterior: permite ao utilizador voltar para a tab-Dados Pessoais.
2. Boto prximo: permite ao utilizador a ir para a tab-Dados Acadmicos, a ver na
figura 21.
3. Boto cancelar: apaga os dados introduzidos nos campos do formulrio da tabDocumentos.
4. Boto sair: sai do submenu candidato para a pgina principal.

70

Figura 21: Ficha de inscrio com tab-Dados Acadmicos

Legenda da figura 21:
1. Boto anterior: permite ao utilizador a voltar para tab-Documentos (figura 20).
2. Boto prximo: possibilita ao utilizador a ir para tab-Informaes para
Contacto, a ver na figura 22.
3. Boto cancelar: possibilita o utilizador a limpar todos dados introduzidos na
tab-Dados Acadmicos.
4. Boto sair: permite ao utilizador navegar para pgina inicial.
5. Boto anexar: permite ao utilizador anexar documentos.
6. Boto remover: permite ao utilizador apagar documento anexado.

71

Figura 22: Ficha de Inscrio com tab-Informaes para Contacto.

Legenda da figura 22:
1. Boto anterior: volta para tab-Dados Acadmicos (figura 21).
2. Boto salvar: permite ao candidato guardar os dados de inscrio inseridos
em todas tabs (ficha de inscrio) no sistema.
3. Boto cancelar: apaga os dados inseridos na tab-Informaes para Contacto.
4. Boto sair: d possibilidade ao utilizador a sair do submenu candidato para
pgina inicial.
D Submenu consultas - contm quatro funcionalidades nomeadamente:
Consultar Listas, Escolas, Salas de Exame e Resultados. Na figura a seguir
ilustra-se as funcionalidades no sistema.

72

Figura 23: Submenu Consultas enumerado.

Legenda:
1. Menu interno contido no submenu: tem como funcionalidades Consultar listas
provisrias e definitivas, conforme ilustra a figura 23, onde o item 1 tem 1.1 e
1.2. Quando o candidato seleccionar em 1.1 ou 1.2 o sistema mostra a seguinte
tela:

Figura 24: Submenu Consultas com tela de pesquisa.

73

a- Boto pesquisar: permite ao utilizador buscar os candidatos correspondentes ao

nome introduzido. Seleccionando o boto pesquisar o sistema navega para lista
provisria (se o utilizador clicou em 1.1, a ver na figura 25) ou lista definitiva (se o
utilizador clicou em 1.2, a ver na figura 26).

Figura 25: Submenu Consultas com lista provisria.

Figura 26: Submenu Consultas com Lista Definitiva.

74

2. Menu item escolas: permite ao utilizador ver a lista de escolas onde iro se
realizar os exames, e seleccionando em cada groupbox (representa cada item
escola) o sistema visualiza informaes relativas a localizao da escola
correspondente ao seleccionado, conforme ilustra a figura 27.

Figura 27: Tela de Submenu Consultas com lista de escolas.

3. Menu item salas de exame: possibilita ao utilizador a visualizar a lista de salas de
exames de conhecimento. Seleccionando neste menu item o candidato navega
para tela seguinte:

Figura 28: Tela de procura de salas de exame por curso.

75

a- Combobox: permite ao utilizador seleccionar o curso para listar salas de exame

correspondente ao curso seleccionado. Seleccionando por exemplo o curso de
EG-Bsica, o sistema mostra a seguinte tela:

Figura 29: Tela com lista de salas de exame correspondente a ESMI-Bsica.

4. Menu item resultados: permite ao utilizador consultar resultado dos exames de
conhecimentos. A figura 30 mostra a tela depois do utilizador seleccionar no
menu item.

Figura 30: Tela com campo de pesquisa do candidato.

76

Legenda:
a- Campo para introduzir cdigo do candidato.
b- Boto pesquisar: permite ao utilizador buscar o candidato e visualizar o resultado
dos exames. Por exemplo, introduzindo o cdigo do candidato 10011 em a, temse o seguinte resultado:

Figura 31: Tela com resultado dos exames.

E Submenu funcionrio- alberga 8 funcionalidades, que so: apagar e validar
candidato, formar, editar, apagar e publicar turma, inserir nota e, elaborar e
publicar pauta (esto contidos no menu interno Pauta). A figura a seguir mostra as
funcionalidades.

77

Figura 32: Submenu Funcionrio com funcionalidades enumeradas.

Legenda:
1. Menu item apagar candidato: permite ao chefe da seco de assuntos
estudantis a eliminar candidatos no validados.
2. Menu item validar candidato: permite ao funcionrio da seco de assuntos
estudantis a validar inscrio do candidato, mediante um talo de depsito. A
figura 33 ilustra a tela de busca do candidato por cdigo aps de seleccionar
no menu item validar candidato.
3. Menu interno turma - possui 4 funcionalidades, nomeadamente: 3.1, 3.2, 3.3 e
3.4, a figura 32 acima mostra-as. A seguir so descritas as funcionalidades.
3.1.

Menu item formar: possibilita ao chefe da SAERD a formar turmas. A figura

37 visualiza a tela de busca de candidatos por curso e local de realizao
do exame aps do funcionrio seleccionar no menu item formar.

3.2.

Menu item editar: possibilita ao chefe da SAERD a editar as turmas j

formadas. A figura 40 visualiza a tela de busca da turma por editar.

3.3.

Menu item apagar: permite ao chefe da SAERD a eliminar uma turma j

formada ou a tirar um candidato numa determinada turma.

78

3.4.

Menu item publicar: d possibilidade ao chefe da SAERD a disponibilizar

as turmas para os candidatos.

4. Menu item inserir nota: permite ao chefe da SAERD a inserir notas dos
exames no sistema. A figura 39 mostra a tela de pesquisa de candidatos por
curso aps do chefe seleccionar neste menu item.
5. Pauta- um menu interno que tem duas funcionalidades: elaborar e publicar
pauta. A figura 40 ilustra as funcionalidades.

Figura 33: Tela de pesquisa de candidato por cdigo.

a- Campo para o funcionrio introduzir cdigo do candidato que pretende validar a
sua inscrio. A figura a seguir ilustra a tela de pesquisa com cdigo do
candidato a validar.

79

Figura 34: Tela de pesquisa com cdigo do candidato a validar.

b- Boto pesquisar: permite ao funcionrio buscar o candidato correspondente ao
cdigo introduzido. A figura 35 mostra tela de validao depois do funcionrio
seleccionar no boto pesquisar.

Figura 35: Tela de validao do candidato.

80

Legenda:
a- Campo para o funcionrio inserir nmero de talo de depsito, que o candidato
traz.
b- Combobox: permite ao funcionrio seleccionar o local onde o candidato pretende
realizar os exames.
c- Boto validar: valida a inscrio do candidato mediante aos valores de a e b
introduzidos. A figura 36 mostra a tela de validao aps a introduo dos valores
nos campos a e b e, seleccionar-se no boto validar.
d- Boto anterior: volta para tela de pesquisa com o cdigo do candidato a validar
introduzido, ver figura 34 acima.
e- Boto sair: possibilita ao funcionrio a sair para pgina principal do sistema, ver
figura 17 acima.

Figura 36: Tela de validao aps seleccionar-se no boto validar.

81

Figura 37: Tela de busca de candidatos por curso e local de realizao do exame.
Legenda:
a-

um combobox que permite ao chefe seleccionar o curso no qual pretende

formar as turmas.

b- um combobox que permite ao chefe seleccionar o local do exame e buscar

todos candidatos do curso e do local de realizao do exame seleccionado. A
figura a seguir mostra uma tela com lista de candidatos correspondente a busca
realizada.

82

Figura 38: Tela com lista de candidatos do curso de TMG para Pemba.
a- Campo para inserir nmero de candidatos para formar uma turma.
b- Combobox que permite ao chefe escolher uma turma para o nmero de
candidatos inserido. Depois de escolhida a turma o sistema preenche os campos
sala e escola correspondente a turma seleccionada.
c- Boto anterior: permite ao chefe voltar a tela de busca de candidatos por curso e
local de realizao do exame (figura 37).
d- Boto formar: permite ao chefe formar a turma mediante os valores inseridos em
a e b e guardar a turma no sistema. A figura 39 mostra uma tela depois do chefe
introduzir dados nos campos a e b e seleccionar no boto formar.

83

Figura 39: Tela com turma formada.

Figura 40: Tela com campo de pesquisa de turma por editar.

Legenda:
a- Campo para introduzir a turma que pretende editar.
84

b- Boto pesquisar: permite ao chefe buscar a turma que pretende modificar

mediante ao valor introduzido em a. A figura 41 abaixo, visualiza uma tela com
lista de candidatos duma turma por editar.

Figura 41: Tela com lista de candidatos da turma 30.

a- Campo para introduzir cdigo do candidato por transferir.
b- Combobox que possibilita ao chefe escolher a turma onde pretende transferir o
candidato ou candidatos (em caso do chefe pretender transferir todos candidatos,
no preenche o campo a).
c- Boto anterior: permite ao chefe voltar a tela de pesquisa de turma por editar
(figura 40).
d- Boto transferir: permite ao chefe transferir o candidato ou candidatos para turma
seleccionada em b. A figura 42 ilustra uma tela com lista de candidatos
transferidos da turma 30 (mostrada na figura 41) para turma 22.

85

Figura 42: Tela com lista de candidatos transferidos da turma 30 para turma 22.
F Submenu cursos: contm informaes dos cursos leccionados particionados em
nveis, permitindo que o candidato se informe melhor sobre quem pode concorrer em
cada nvel de cada curso, dando assim, melhor viso para melhor escolha do curso.
G Submenu centros de formao: contm informaes dos centros e institutos de
formao de sade de Moambique tais como historial, localizao, fotos, cursos
leccionados, com objectivo de dar uma viso prvia do centro ou instituto onde o
candidato vai ou pretende ir fazer o curso.
H Submenu ajuda: contm informaes de ajuda para o utilizador, quanto s
funcionalidades do sistema para dar suporte ao utilizador, caso necessite.
4.4.

Diagrama de Componentes

Diagrama de componentes um diagrama que identifica componentes que fazem

parte de um sistema, visualizando os diversos componentes de software e suas
dependncias. utilizado como uma forma de documentar como esto estruturados
os arquivos fsicos de um sistema, dando assim, uma melhor percepo dos
86

mesmos, alm de facilitar a reutilizao de cdigo. De referir que um componente

um elemento autnomo de software reutilizvel, bem encapsulado e substituvel,
onde agrupados e relacionados fazem um sistema. Os componentes podem ser
arquivos de cdigo-fonte, arquivos executveis, base de dados, bibliotecas, arquivos
de ajuda (help) e mais outros (Guedes, 2011).
A figura referente ao diagrama de componentes do SIGECO, a ver no anexo 5.
4.5.

Concluso

Neste captulo fez-se a apresentao do sistema, que a proposta da soluo,

dando uma viso antecipada das suas principais funcionalidades atravs das
interfaces postadas. De referir que o sistema traz interfaces amigveis, tornando
assim, fcil interaco para com o utilizador. De seguida fez-se a descrio de
componentes, que visualiza todos arquivos implementados no ambiente de
desenvolvimento e finalmente o desenho de diagrama de componentes do SIGECO.

87

CONCLUSES
O estudo do negcio na Seco de Assuntos Estudantis e Recursos Didcticos, no
Departamento Pedaggico do Centro de Formao de Pessoal de Sade de Pemba
tornou possvel a recolha dos requisitos funcionais e no funcionais para a
construo do sistema web, seguindo-se as recomendaes da metodologia RUP.
Com o uso de RUP possibilitou o desenvolvimento das funcionalidades de forma
interactiva e incremental, orientou na modelao e imediatamente no desenho da
base de dados, mediante nos requisitos recolhidos. Na mesma lgica, com o uso do
sistema de gesto de base de dados MySQL na sua verso 6.0 tornou possvel a
implementao da base de dados.
No desenvolvimento do sistema escolheu-se pelo sistema web utilizando linguagem
de programao Java, Servidor de Aplicao Apache Tomcat, framework ZK, que
permitiu adequar-se s caractersticas do negcio em estudo.
Com as funcionalidades implementadas permitiro SAERD no aprimoramento das
suas actividades, flexibilizando os processos executados, economizando tempo,
recursos materiais e humanos, dando assim apoio na tomada de deciso atravs dos
relatrios produzidos e apresentados.

88

RECOMENDAES
Implementar as restantes funcionalidades e aspectos de segurana como vista a
minimizar possveis ataques.
Fazer testes no sistema durante um perodo considervel para comprovar a
satisfao dos requisitos funcionais implementados.
Adicionar o mdulo pagamento on-line ou conectar o sistema com sistema bancrio
BIM para o pagamento da inscrio, com vista a minimizar as inscries fictcias ou
falsas que avolumam dados desnecessrios na base de dados. Portanto, este
mdulo fortalecer a inscrio on-line.
Uma vez terminada a aplicao e comprovada a sua efectividade, generaliz-la para
demais institutos e centros de formao de sade do pas.

89

BIBLIOGRAFIA
ABRAHAMSSON, P. et al. Agile Software Development Methods: Review and
Analysis. Espoo, 2002, VTT Publications 478.
ANDERSON, C. Software Livre no Grtis! Revista Linux Magazine. Ano I, no 1,
ago. 2004, p. 94.
ANICETO, J. Aplicao Web Apostila ASP.net. Escola Tcnica da Univale (ETEIT).
2009.
BECK, K.; FOWLER, M. Planning Extreme Programming. 1. ed. Addison-Wesley,
2000.
BEZERRA, E. Princpios de Anlise e Projecto de Sistema com UML. 2. ed. Rio
de Janeiro: Elsevier, 2007.
CANTU, C. H. Firebird Essencial. Rio de Janeiro: Cincia Moderna, 2005.
CARVALHO FILHO, J. S. Manual de Direito Administrativo. 25. ed. So Paulo:
Atlas, 2012.
CARVALHO FILHO, J. S. Manual de Direito Administrativo. 7. ed. So Paulo:
Lumen Luris, 2001.
CAVALHEIRO, G. Material de Apoio 14: Framework. Universidade Federal de
Pelotas: 2014.
DA SILVA, A. M. R.; VIDEIRA, C. A. E. UML: Metodologias e Ferramentas Case. 2.
ed. Lisboa: Centro Atlntico, 2005. 1 v.
DA SILVA, A. M. R.; VIDEIRA, C. A. E. UML: Metodologias e Ferramentas Case. 2.
ed. Lisboa: Centro Atlntico, 2008. 2 v.
DEITEL, H. M.; DEITEL, P. J. Java Como Programar. 8. ed. So Paulo: Pearson
Pretence Hall, 2010.

90

DEVMEDIA. Conhea o Apache Tomcat. Disponvel em:

<http://www.devmedia.com.br/conheca-o-apache-tomcat>. Acesso em: 15 abr. 2015.
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed. So Paulo:
Pearson Addison Wesley, 2005.
FOROUZAN, B. A. Comunicao de Dados e Redes de Computadores. 3. ed. So
Paulo: Bookman, 2006.
GAMMA, E. et al. Padres de projectos. Porto Alegre: Bookman, 2006.
GARCIA, R. R. Introduo s Bases de Dados: Relacionamentos Simples
(Abordagem no Convencional). 1. ed. Lisboa: Raul Ressano Garcia, 2010.
GUEDES, G. T. A. UML 2: Uma Abordagem Prtica. 2. ed. So Paulo: Novatec,
2011.
KRUCHTEN, P. The Rational Unified Process: An Introduction. 2. ed. AddisonWesley, 2000.
K19. Relatrios em Java com JasperReports e IReport. Disponvel em:
<http://www.k19.com.br/artigos/relatorios-em-java-jasperreports-e-ireport/>. Acesso
em: 24 dez. 2014.
LUIZ, R. Obtendo Qualidade de Software com o RUP. TCC, Universidade de
Uberaba, 2005.
MACHAVA, A. E. Desenvolvimento de Um Sistema de Gesto de Direco de
Faculdade de Engenharia. 2012. 86 f.. Monografia (Licenciatura em Engenharia
Informtica) Faculdade de Engenharia, Universidade Lrio, Pemba.
MARCORATTI, J. C. Padres de Projecto: O modelo MVC. Disponvel em:
http://www.marcoratti.net/vbn_mvc.htm. Acesso em: 28 dez. 2014.
Mdicos de Medicina Geral e Familiar. Investigao Passo a Passo: Perguntas e
Respostas para a Investigao Clinica. 1. ed. Lisboa: Ncleo de Investigao da
APMCG, 2008.
91

MySQL. Anuncio Publicitrio. Revista Linux Magazine. Ano II, no 6, jan. 2005, p. 2.
Netbeans. Viso Geral de Netbeans IDE. Disponvel em:
<https://netbeans.org/features/index_pt_BR.html>. Acesso em: 9 jan. 2015.
NUNES, M.; ONEILL, H. Fundamental de UML. 2. ed. Lisboa: FCA, 2003.
ORACLE. Why MySQL?. Disponvel em: <http://www.mysql.com/why-mysql>.
Acesso em: 2 out. 2014.
OLIVEIRA, C. H. P. SQL Magazine: Banco de Dados Livre x Pago. Disponvel em:
<http://www.sqlmagazine.com.br/Artigos/Outros/01_BAnco_FreeXPAgo.asp>.
Acesso em: 05 out. 2014.
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7 ed.
Porto Alegre: AMGH, 2011.
SCHILDT, H. Java: A Referencia Completa. 8. ed. Rio de Janeiro: Alta Books, 2013.
SOMMERVILLE, I. Engenharia de Software. 8. ed. So Paulo: Pearson Addison
Wesley, 2007.
TAFULA, J. E. C. Sistema Web de Comrcio Electrnico Baseado em Leilo. 2012.
88 f. Monografia (Licenciatura em Engenharia Informtica) - Universidade Lrio,
Pemba.
Universidade Federal de Santa Catarina. Normas da ABNT: Citaes e Referncias
Bibliogrficas. Disponvel em: <www.leffa.pro.br/textos/abnt.htm>. Acesso em: 10 set.
2014.
Universidade Federal do Panar. Normas para Elaborao de Monografia.
Disponvel em: <www.iar.unicamp.br>. Acesso em: 25 out. 2014.
VAZ, R.; ALVES, S. Introduo aos Sistemas de Gesto de Bases de Dados
Usando o OpenOffice Base: Manual de Apoio. Brasil: Maio de 2005.

92

<http://www.andersonmedeiros.com/postgresql-pratico-ebook-em-portugues>.
Acesso em: 15 set. 2014.
<www.oficinadanet.com.br/apostilas/detalhe/609/manual_de_referencia_mysql_5.4>.

Acesso em: 18 nov. 2014.

Wthressx. <http://www.wthreex.com/rup/process/workflow/busmodel/mdov_bm.htm>.
Acesso em: 30 jul. 2015.
Zkbrasil. O que o ZK. Disponvel em: <http://zkbrasil.blogspot.com/2010/11/o-quee-o-zk.html>. Acesso em: 5 dez. 2014.
<http://bibdig.poliseducacional.com.br/document/?view=66>. Acesso em: 14 jul.
2015.
<http://vaadin.com>. Acesso em: 14 jul. 2015.
<http://www.eclipse.org/birt/?>. Acesso em: 16 jul. 2015.
<http://bibdig.poliseducacional.com.br/document/?view=106>. Acesso em: 16 jul.
2015.

93

ANEXOS
Anexo 1. Diagramas de Actividades

Figura 43: Diagrama de actividades de caso de uso Formar Turma.

Figura 44: Diagramas de actividades dos casos de uso ver Turma e Resultado.

Anexo 2. Diagramas de Classes de Desenho.

Figura 45: Diagrama de classes para CU Efectuar Inscrio.

Figura 46: Diagrama de classes para CU Alterar Inscrio.

II

Figura 47: Diagrama de classes para CU Eliminar Inscrio.

class Gerir Turma
Diagrama de Classes de Desenho de CU Gerir Turma

interface
CITurma

1
+
+
+
+
+

2. mostrarTelaTurma() : void
2.1. formarTurma() : void
2.3. apagarTurma() : void
2.2. editarTurma() : void
2.4. publicarTurma() : void
1

interface
CIpublicarTurma

entidade
CEInscricao

+ 3. mostrarTelaFormarTurma() : void
+ 4. inserirDados(int, int, int) : void

+ 5. mostrarTurmas(List<Turma>) : void
+ 6. publicarTurmas() : void

interface
CIformar

+ 6.1. [existe==true]: List<Candidato>cs= getCandidatos(int, int, int) : List<Candidato>

+ 6. existe = validarDados(int, int, int) : boolean

0..1

1
interface
CIPrincipal

+ 1. gerirTurma() : void

+
1 +
+
+
+

controladora
CCTurma

1
controladora
CCInscricao

salavarTurma(Dado) : void
5. buscarDadosTurma(int) : void
1
6.1.6. apagarTurma(Turma) : void
3.buscarTurmas() : void
7. disponibilizarTurmas(List<Turma>) : void

interface
CIPesquisa_Turma

1 + 5.buscarCandidatos(int, int, int) : List<Candidato>

1
+ 6.1.6. salvarTurma(Dado) : void
+ 6.1.3. showSala(Sala) : void
1

+
+
+
+
+

entidade
CEsala

0..1

0..1
1..*

- nrSala: int
- nomeSala: String
- nrEscola: int

interface
CImessageError
+ 6.2. [existe==false]: showMessageError() : void

+ 6.1.2. Sala s = getSala_Escola() : void

nrSala: int
nomeSala: String
nrCandidato: int
nrEscola: int
GuardarTurma(Dado) : void
6.1 [existe==true]: Turma t =getTurma(int) : Turma
6.1.7. apagarTurma(Turma) : void
4. List<Turma> ts = getTurmas() : List<Turma>
6. existe=validarTurma(int) : boolean

1 + 6.1.1. buscarSala_Escola() : void

+ 3.mostrarTelaPesquisa() : void
+ 4. inserirCodigoTurma(int) : void
+ 5.confirmarApagarTurma() : void

entidade
CEturma

controladora
CCsala

interface
CIDadosTurma
+
+
+
+
+

6.1.1. mostrarDadosTurma(Turma) : void

6.1.2. SetTurma(Turma) : void
6.1.3. validarDadosTurma(Dado) : void 1
6.1.2. apagarTurma(Turma) : void
6.1.5. apagarSim() : void

interface
CIconfirmar
1 + 6.1.3. createConfirmationTela() : void
+ 1.6.4. confirmarApagar() : void

interface
CITurma_Formada
+ 6.1.4. Dadosturma(List<Candidatos>, Sala) : void
+ 6.1.5. salvarTurma(Dado) : void

Figura 48: Diagrama de classe para CU Gerir Turma.

III

Figura 49: Diagrama de classes de CU Elaborar Pauta.

IV

Figura 50: Diagrama de classes de CU Gerir Consultas.

Anexo 3. Diagramas de Sequncia

Figura 51: Diagrama de sequncia de CU Efectuar Inscrio.

Figura 52: Diagrama de sequncia de CU Alterar Inscrio.

VI

Figura 53: Diagrama de sequncia de CU Eliminar Inscrio.

Figura 54: Diagrama de sequncia de CU Gerir Turma Curso Normal.

VII

pkg Frame-Seccao Formar

sd Seccao Formar
Diagrama de Sequncia de Caso de uso Gerir Turma-Seco Formar

:Funcionario SAERD
:CMenuTurma

:CIformar

:CITurma_Formada

:CCInscricao

:CCTurma

:CEInscricao

CCsala

:CEturma

CEsala

2.1. formarTurma()
3. mostrarTelaFormarTurma()

4. inserirDados(codigoCurso, numero1, numero2)

5.buscarCandidatos(codigoCurso, numero1, numero2) :
List<Candidato>
6. existe= validarDados(codigoCurso, numero1,
numero2) :boolean
6.1. [existe==true]: List<Candidatos> lc=
listarCandidatos(codigoCurso, nmero1, numero2) :
List<Candidato>

6.1.1. buscarSala_Escola()
6.1.2.Sala s= carregarSala_Escola() :Sala
6.1.3. showSala(s)
6.2.[existe==false]:createTela()

CImessageError 6.2.1. showMesssageError()

6.1.4. DadosTurma(lc, s)
6.1.5. salvarTurma(dados)

6.1.6. salavarTurma(dados)

dados:
nrCandidato;
nrSala;
nrEscola;
nomeSala;

6.1.7.GuardarTurma(dados)

Figura 55: Diagrama de sequncia de CU Gerir Turma Formar Turma.

VIII

Figura 56: Diagrama de sequncia de CU Gerir Turma Alterar Turma.

Figura 57: Diagrama de sequncia de CU Gerir Turma Publicar Turmas.

IX

Figura 58: Diagrama de sequncia de CU Gerir Turma Apagar Turma.

Figura 59: Diagrama de sequncia de CU Elaborar Pauta.

Figura 60: Diagrama de sequncia de CU Gerir Consultas Curso Normal.

XI

Figura 61: Diagrama de sequncia de CU Gerir Consultas Consultar Resultado.

XII

Figura 62: Diagrama de sequncia de CU Gerir Consultas Consultar Turma.

Anexo 3.6.4. Seco Consultar Escola/Sala

Figura 63: Diagrama de sequncia de CU Gerir Consultas Consultar Escola/Sala.

XIII

Anexo 4. Diagrama de Modelo de Dados

Figura 64: Diagrama de modelo de dados do SIGECO.

XIV

Anexo 5. Diagrama de Componentes

pkg Frame
cmp Diagrama de Componentes
Diagrama de Componentes do SIGECO

Camada de Apresentao

Camada lgica de domnio do negcio

Candidato

pagina web
paginaInicial.zul

pagina web
editarInscricao.zul

pagina web
fichaReclamacao.zul

arquivo
candidatoJpaController.java

pagina web
inscricao.zul
pagina web
idex.zul

arquivo
funcionarioJpaController.java

pagina web
listaDefinitiva.zul

pagina web
escolas.zul

pagina web
header.zul
pagina web
menu.zul

pagina web
listaProvisoria.zul

pagina web
edital.zul
pagina web
resultados.zul

pagina web
formarTurma.zul

pagina web
apagarCandidato.zul
Arquivo de configuracao

pagina web
centrosFormacao.zul
pagina web
ajuda.zul

pagina web
validarCandidato.zul

pagina web
cursoMedioInicial.zul

pagina web
salasExame.zul

pagina web
cursoMedioPromocao.zul

arquivo
loginJpaController.java

Funcionrio

pagina web
cursoBasico.zul

pagina web
cursoEspecializacao.zul

pagina web
publicarTurma.zul

pagina web
login.zul

framework
Hibernate 3.6.10

pagina web
apagarTurma.zul

pagina web
editarTurma.zul

pagina web
inserirNotas.zul

arquivo
persistence.xml

Camada fisica de dados

pagina web
elaborarPauta.zul

pagina web
publicarPauta.zul

base de dados
sigecoBD

Figura 65: Diagrama de componentes do SIGECO.

XV