análise e desenvolvimento do sistema de gerenciamento de plano executivo
DESCRIPTION
Este Relatório foi produzido como parte das atividades do estágio supervisionado, realizada na Secretaria de Estado de Saúde de Mato Grosso (SES), juntamente com a Superintendência de Vigilância em Saúde (SVS), no período de Janeiro a Março de 2013.A atividade de estágio, tinha como finalidade a análise e o desenvolvimento de um sistema capaz de gerenciar os planos executivos criados pela SVS. Atualmente eles são feitos manualmente, utilizando formulários impressos.Na parte de análise para a documentação do aplicativo SGPE, foram empregados o levantamento de requisitos, a modelagem por meio do diagrama de classe, diagrama de sequência, diagrama de atividades e caso de uso. Já, para o banco de dados aplicou-se o mapeamento entidade relacionamento.No desenvolvimento, foi utilizado a IDE NetBeans, com a linguagem de programação PHP, o SGBD MySQL, juntamente com a ferramenta PhpMyAdmin, que serve para gerenciar através de uma interface gráfica, as tabelas do banco de dados, o framework CodeIgniter e padrão de desenvolvimento model-view-controller (MVC), cujo o mesmo, tem a finalidade de tornar o desenvolvimento mais rápido e uniformizado.Como resultado a SVS obteve toda a documentação do aplicativo e um sistema parcial do gerenciamento de plano executivo, com intuito de trazer melhorias no que tange ao acompanhamento das ações planejadas.TRANSCRIPT
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO:
ANÁLISE E DESENVOLVIMENTO DO SISTEMA DE
GERENCIAMENTO DE PLANO EXECUTIVO
BRUNO SANTOS ABDALLA
CUIABÁ – MT
2013
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELÁTORIO DE ESTÁGIO SUPERVISIONADO:
ANÁLISE E DESENVOLVIMENTO DO SISTEMA DE
GERENCIAMENTO DE PLANO EXECUTIVO
BRUNO SANTOS ABDALLA
Relatório apresentado ao Instituto de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Ciência da Computação.
CUIABÁ – MT
2013
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
BRUNO SANTOS ABDALLA
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de
Ciência da Computação como uma das exigências para obtenção do título de
Bacharel em Ciência da Computação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. MsC. Roberto Benedito de Oliveira Pereira
Instituto de Computação
Prof. Dr. Mauricio Fernando Lima Pereira
Instituto de Computação
Prof. Dr. João Paulo Ignácio Ferreira Ribas
Instituto de Computação
DEDICATÓRIA
Primeiramente a Deus, pois sem ele
nada disso seria possível, à minha
família e a minha namorada pelo
apoio em toda a minha caminhada.
AGRADECIMENTOS
Agradeço primeiramente a Deus pelo dom da vida e pela oportunidade de
vencer os obstáculos diários.
Agradeço minha família pelo amor, carinho, dedicação e apoio, em todas as
circunstâncias.
Agradeço aos meus amigos pelo companheirismo e apoio de sempre.
Agradeço a minha namorada pela eterna amizade, apoio e carinho.
Agradeço ao meu orientador Roberto Benedito, pela paciência, dedicação, e
apoio.
Em geral, agradeço a todos os meus professores do IC, pelo tempo de
companheirismo, dedicação, e muito aprendizado.
6
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................................... 8
LISTA DE TABELAS .......................................................................................................................... 9
LISTA DE SIGLAS E ABREVIATURAS ....................................................................................... 11
RESUMO ............................................................................................................................................ 12
INTRODUÇÃO .................................................................................................................................. 13
1 REVISÃO DE LITERATURA ...................................................................................................... 15
1.1 ENGENHARIA DE SOFTWARE ...................................................................................................... 15
1.2 LINGUAGEM DE MODELAGEM UNIFICADA .................................................................................. 15
1.3 BANCO DE DADOS RELACIONAL ................................................................................................. 16
1.4 SERVIDOR WEB APACHE E PHP ................................................................................................ 17
1.5 MYSQL ..................................................................................................................................... 17
1.6 MODEL - VIEW – CONTROLER .................................................................................................... 19
1.7 CODEIGNITER ............................................................................................................................. 21
2 MATERIAIS, TÉCNICAS E MÉTODOS .................................................................................... 25
3 RESULTADOS ................................................................................................................................ 27
3 .1 LEVANTAMENTO DE REQUISITOS .............................................................................................. 27
3.1.1 Requisitos Funcionais ........................................................................................................ 27
3.1.2 Requisitos Não Funcionais ................................................................................................ 36
3.2 CASOS DE USO ........................................................................................................................... 38
3.3 DIAGRAMA DE CLASSE ............................................................................................................... 41
3.4 MODELAGEM ENTIDADE RELACIONAMENTO ............................................................................. 46
3.5 DIAGRAMA DE SEQUÊNCIA......................................................................................................... 51
3.6 DIAGRAMA DE ATIVIDADE ......................................................................................................... 52
3.7 IMPLEMENTAÇÃO ....................................................................................................................... 54
4 DIFICULDADES ENCONTRADAS ............................................................................................. 58
5 CONCLUSÕES ............................................................................................................................... 60
6 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................... 62
APÊNDICES E/OU ANEXOS .......................................................................................................... 63
ANEXO 1 – FORMULÁRIO DE PLANO EXECUTIVO ............................................................................. 63
ANEXO 2 – PARTE DO FORMULÁRIO REFERENTE AO CADASTRO DO PLANO EXECUTIVO .................. 67
ANEXO 3 – PARTE DO FORMULÁRIO REFERENTE AO ACOMPANHAMENTO DO PLANO EXECUTIVO .... 68
ANEXO 4 – PARTE DO FORMULÁRIO REFERENTE AO VINCULO ESTRATÉGICO ................................... 69
7
ANEXO 5 – PARTE DO FORMULÁRIO REFERENTE À INDICAÇÃO DE PRIORIDADE................................ 70
APÊNDICE 1 – CÓDIGO DO CONTROLLER PERMISSÃO.PHP ................................................................ 71
APÊNDICE 2 – CÓDIGO DO MODEL PERMISSAO_MODEL.PHP ........................................................... 72
APÊNDICE 3 – CÓDIGO DA VIEW NOVO_VIEW.PHP ........................................................................... 73
8
LISTA DE FIGURAS
FIGURA 1 - INTERFACE PRINCIPAL DO PHPMYADMIN ........................................................................... 19
FIGURA 2 – ESTRUTURA MVC .............................................................................................................. 20
FIGURA 3 - FLUXO DE DADOS MVC COM CODEIGNITER ....................................................................... 22
FIGURA 4 - ESTRUTURA DO CODEIGNITER ............................................................................................ 23
FIGURA 5 - PASTA APPLICATION DO CODEIGNITER ............................................................................... 23
FIGURA 6 - CASO DE USO DO ADMINISTRADOR DO SISTEMA .................................................................. 38
FIGURA 7 - CASO DE USO DO ASSISTENTE E DO AUXILIAR ..................................................................... 39
FIGURA 8 - CASO DE USO DO TÉCNICO .................................................................................................. 40
FIGURA 9 - CASO DE USO DO COORDENADOR ....................................................................................... 40
FIGURA 10 - CASO DE USO DO SUPERINTENDENTE ................................................................................ 41
FIGURA 11 - VISÃO GERAL DO DIAGRAMA DE CLASSE .......................................................................... 42
FIGURA 12 - DIAGRAMA DE CLASSE ESTRATÉGIA DO PLANO EXECUTIVO ............................................. 43
FIGURA 13 - DIAGRAMA DE CLASSE ACOMPANHAMENTO DO PLANO EXECUTIVO .................................. 44
FIGURA 14 - DIAGRAMA DE CLASSE DO PLANO EXECUTIVO .................................................................. 45
FIGURA 15 - DIAGRAMA DE CLASSE DOS ACESSOS E LOGS .................................................................... 45
FIGURA 16 - DIAGRAMA ENTIDADE RELACIONAMENTO DO SGPE ....................................................... 46
FIGURA 17 - DER ASSOCIADO À ESTRATÉGIA DA SVS .......................................................................... 47
FIGURA 18 - DER ASSOCIADO À ESTRATÉGIA DA SES .......................................................................... 47
FIGURA 19 - DER ASSOCIADO AOS LOGS DO SISTEMA ........................................................................... 48
FIGURA 20 - DER ASSOCIADO AO CONTROLE DE ACESSO ...................................................................... 48
FIGURA 21 - DER ASSOCIADO AOS DADOS GERAIS DO PLANO EXECUTIVO ............................................ 49
FIGURA 22 - DER ASSOCIADO ÀS ETAPAS DO PLANO EXECUTIVO ......................................................... 50
FIGURA 23 - DIAGRAMA DE SEQUÊNCIA DE NOVO PLANO EXECUTIVO .................................................. 51
FIGURA 24 - DIAGRAMA DE ATIVIDADE DE CADASTRO DE UM NOVO PLANO EXECUTIVO ...................... 52
FIGURA 25 - DIAGRAMA DE ATIVIDADE DE ACOMPANHAMENTO DO PLANO EXECUTIVO ....................... 53
FIGURA 26 - TELA DE LOGIN ................................................................................................................. 54
FIGURA 27 - TELA PRINCIPAL PARTE USUÁRIO ...................................................................................... 54
FIGURA 28 - TELA PRINCIPAL DA ESTRATÉGIA DA SVS ......................................................................... 55
FIGURA 29 - TELA PRINCIPAL DA ESTRATÉGIA DA SES ......................................................................... 55
FIGURA 30 - TELA DA PERSPECTIVA DA SVS ........................................................................................ 56
FIGURA 31 - TELA DA NATUREZA DO PLANO EXECUTIVO ...................................................................... 56
FIGURA 32 - TELA DOS LOGS DE ACESSO .............................................................................................. 57
FIGURA 33 - TELA DOS LOGS DE ATIVIDADE ......................................................................................... 57
9
LISTA DE TABELAS
TABELA 1 - REQUISITO FUNCIONAL PARA CADASTRAR PLANO EXECUTIVO .......................................... 27
TABELA 2 - REQUISITOS FUNCIONAL CADASTRO DE ACOMPANHAMENTO DO PLANO EXECUTIVO ......... 27
TABELA 3 - REQUISITO FUNCIONAL PARA RELATÓRIO SIMPLIFICADO DO PLANO EXECUTIVO ............... 28
TABELA 4 - REQUISITO FUNCIONAL DE NÍVEIS DE USUÁRIO DO SGPE .................................................. 28
TABELA 5 - REQUISITOS FUNCIONAL DO RELATÓRIO DETALHADO DE PLANO EXECUTIVO .................... 28
TABELA 6 - REQUISITO FUNCIONAL VINCULO ESTRATÉGICO ................................................................ 29
TABELA 7 - REQUISITO FUNCIONAL DA HOMOLOGAÇÃO DO PLANO EXECUTIVO ................................... 29
TABELA 8 - REQUISITO FUNCIONAL NÚMERO DO PLANO EXECUTIVO .................................................... 29
TABELA 9 - REQUISITOS FUNCIONAL DE GERAR RELATÓRIO EM PDF ..................................................... 29
TABELA 10 - REQUISITO FUNCIONAL CADASTRO PRIORIDADE PLANO EXECUTIVO ................................ 29
TABELA 11 - REQUISITO FUNCIONAL VISUALIZAÇÃO DE ANEXO ........................................................... 30
TABELA 12 - REQUISITO FUNCIONAL DE AUTENTICAÇÃO DE USUÁRIO ................................................. 30
TABELA 13 - REQUISITO FUNCIONAL DA ALTERAÇÃO DO PLANO EXECUTIVO ....................................... 30
TABELA 14 - REQUISITO FUNCIONAL ACOMPANHAMENTO DO PLANO EXECUTIVO ................................ 30
TABELA 15 - REQUISITO FUNCIONAL DA ALTERAÇÃO DO VÍNCULO ESTRATÉGICO ................................ 30
TABELA 16 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA PRIORIDADE DO PLANO EXECUTIVO.............. 31
TABELA 17 - REQUISITO FUNCIONAL DA EXCLUSÃO DE PLANO EXECUTIVO .......................................... 31
TABELA 18 - REQUISITO FUNCIONAL DE CADASTRO DE PARCEIRO ........................................................ 31
TABELA 19 - REQUISITO FUNCIONAL DE EXCLUSÃO DE PARCEIROS ...................................................... 31
TABELA 20 - REQUISITO FUNCIONAL DE CADASTRO DE TIPOS DE RESULTADOS .................................... 31
TABELA 21 - REQUISITO FUNCIONAL DE EXCLUSÃO DE TIPOS DE RESULTADO ...................................... 31
TABELA 22 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE TIPOS DE RESULTADO .................................... 32
TABELA 23 - REQUISITO FUNCIONAL DE CADASTRO DE DESTINAÇÃO DE RESULTADO .......................... 32
TABELA 24 - REQUISITO FUNCIONAL DE EXCLUSÃO DA DESTINAÇÃO DO RESULTADO .......................... 32
TABELA 25 - REQUISITO FUNCIONAL DE ALTERAÇÃO DA DESTINAÇÃO DO RESULTADO........................ 32
TABELA 26 - REQUISITO FUNCIONAL DE CADASTRO DA NATUREZA DA AÇÃO ....................................... 32
TABELA 27 - REQUISITO FUNCIONAL DE EXCLUSÃO DA NATUREZA DA AÇÃO ....................................... 32
TABELA 28 - REQUISITO FUNCIONAL DE ALTERAÇÃO DA NATUREZA DA AÇÃO..................................... 33
TABELA 29 - REQUISITO FUNCIONAL DE FINALIZAÇÃO DO PLANO EXECUTIVO ..................................... 33
TABELA 30 - REQUISITO FUNCIONAL DE CADASTRO DE USUÁRIO ......................................................... 33
TABELA 31 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE DADOS DO USUÁRIO...................................... 33
TABELA 32 - REQUISITO FUNCIONAL DE DESATIVAÇÃO DE USUÁRIO .................................................... 33
TABELA 33 - REQUISITO FUNCIONAL DE GERAR LOGS DE ACESSO ........................................................ 33
TABELA 34 - REQUISITO FUNCIONAL DE GERAR LOGS DE ATIVIDADE .................................................. 34
TABELA 35 - REQUISITO FUNCIONAL DE EXIBIR LOGS ........................................................................... 34
TABELA 36 - REQUISITO FUNCIONAL DE CADASTRO DE SETORES.......................................................... 34
10
TABELA 37 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE SETORES ....................................................... 34
TABELA 38 - REQUISITO FUNCIONAL DE EXCLUSÃO DE SETORES .......................................................... 34
TABELA 39 - REQUISITO FUNCIONAL DE CADASTRO DE GRUPOS RESPONSÁVEIS ................................... 34
TABELA 40 - REQUISITOS FUNCIONAIS DE ALTERAÇÃO DE GRUPOS RESPONSÁVEIS .............................. 34
TABELA 41 - REQUISITO FUNCIONAL DE EXCLUSÃO DE GRUPOS RESPONSÁVEIS ................................... 35
TABELA 42 - REQUISITO FUNCIONAL DO CADASTRO DE ETAPA ............................................................. 35
TABELA 43 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA ETAPA .......................................................... 35
TABELA 44 - REQUISITO FUNCIONAL DA EXCLUSÃO DA ETAPA............................................................. 35
TABELA 45 - REQUISITO FUNCIONAL DO CADASTRO DE SUB ETAPA ...................................................... 35
TABELA 46 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA SUB ETAPA ................................................... 35
TABELA 47 - REQUISITO FUNCIONAL DA EXCLUSÃO DA SUB ETAPA ...................................................... 36
TABELA 48 - REQUISITOS FUNCIONAIS DE CADASTRO DAS ESTRATÉGIAS ADOTADAS ........................... 36
TABELA 49 - REQUISITOS FUNCIONAIS DE EDIÇÃO DAS ESTRATÉGIAS ADOTADAS ................................ 36
TABELA 50 - REQUISITOS FUNCIONAIS DE EXCLUSÃO ESTRATÉGIAS ADOTADAS .................................. 36
TABELA 51 - REQUISITO NÃO FUNCIONAL SERVIDOR WEB .................................................................... 36
TABELA 52 - REQUISITO NÃO FUNCIONAL SISTEMA DE BACKUP ........................................................... 37
TABELA 53 - REQUISITO NÃO FUNCIONAL CONEXÃO COM A INTERNET ................................................. 37
TABELA 54 - REQUISITO NÃO FUNCIONAL INTERFACE AMIGÁVEL ........................................................ 37
11
LISTA DE SIGLAS E ABREVIATURAS
ANSI American National Standards Institute
BSC Balanced Scorecard
CD Compact Disc
CGI Common Gateway Interface
CSS Cascading Style Sheets
DER Diagrama Entidade Relacionamento
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IDE Integrated Development Environment
JDBC Java Database Conectivity
MER Modelo Entidade Relacionamento
MVC Model View Controller
ODBC Open Database Connectivity
OMT Object, Modeling Thechnique
OOSE Object-Orinetd Software Engineering
PDF Portable Document Format
PHP Hypertext Preprocessor
SES Secretaria de Estado de Saúde
SGBD Sistema de Gerenciamento de Banco de Dados
SGPE Sistema de Gerenciamento de Plano Executivo
SQL Structured Query Language
SVS Superintendência de Vigilância em Saúde
UML Unified Modeling Language
12
RESUMO
Este Relatório foi produzido como parte das atividades do estágio
supervisionado, realizada na Secretaria de Estado de Saúde de Mato Grosso (SES),
juntamente com a Superintendência de Vigilância em Saúde (SVS), no período de
Janeiro a Março de 2013.
A atividade de estágio, tinha como finalidade a análise e o
desenvolvimento de um sistema capaz de gerenciar os planos executivos criados pela
SVS. Atualmente eles são feitos manualmente, utilizando formulários impressos.
Na parte de análise para a documentação do aplicativo SGPE, foram
empregados o levantamento de requisitos, a modelagem por meio do diagrama de
classe, diagrama de sequência, diagrama de atividades e caso de uso. Já, para o banco
de dados aplicou-se o mapeamento entidade relacionamento.
No desenvolvimento, foi utilizado a IDE NetBeans, com a linguagem de
programação PHP, o SGBD MySQL, juntamente com a ferramenta PhpMyAdmin,
que serve para gerenciar através de uma interface gráfica, as tabelas do banco de
dados, o framework CodeIgniter e padrão de desenvolvimento model-view-controller
(MVC), cujo o mesmo, tem a finalidade de tornar o desenvolvimento mais rápido e
uniformizado.
Como resultado a SVS obteve toda a documentação do aplicativo e um
sistema parcial do gerenciamento de plano executivo, com intuito de trazer melhorias
no que tange ao acompanhamento das ações planejadas.
13
Introdução
A Superintendência de Vigilância em Saúde da Secretaria de Estado de
Saúde de Mato Grosso, conduz atualmente, os planos executivos, por meio de
formulários manuais. O plano executivo é o planejamento das futuras ações da SVS,
o qual será avaliado pelos coordenadores e pelo superintendente, selecionando os
projetos de acordo com os objetivos e conforme o orçamento do mesmo, além de se
estabelecer uma prioridade de execução.
Dando o fato de ser feito através de formulários tem se o acúmulo de
documentos referentes aos relatórios de cada etapa de execução, onerando o controle
dos planos em vigência e dificultando o processo de auditoria.
Assim a Superintendência de Vigilância em Saúde tinha um trabalho
moroso no que tange ao monitoramento do andamento dos planos executivos e suas
respectivas auditorias sobre as responsabilidades dos técnicos, teve-se a necessidade
de um sistema de informação a fim de se estabelecer uma nova metodologia no que
se refere ao gerenciamento atual.
Mesmo depois de um plano ser aprovado, existe a necessidade de
acompanhar as atividades desenvolvidas em cada etapa do planejamento, pois dessa
maneira permite averiguar se a prática está de acordo com as disposições
estabelecidas no plano executivo e se cada técnico está exercendo as suas obrigações.
Com base nessas premissas e em razão da SVS possuir uma gestão
geograficamente descentralizada, a elaboração de um sistema WEB, utilizando o
padrão de desenvolvimento MVC (Model View Controlle), permitirá a integração de
toda a Superintendência de Vigilância em Saúde, além de dispor de uma ferramenta
que auxiliará na padronização do preenchimento do Plano Executivo.
Dessa maneira a utilização do padrão MVC, na elaboração do sistema de
gerenciamento de plano executivo (SGPE), permite o reaproveitamento de código
tornando a programação mais ágil. Com isso a implantação desse sistema tornará o
gerenciamento mais simples e eficiente, com um melhor custo benefício,
possibilitando um controle eficaz sobre a responsabilidade de cada técnico.
14
Assim, o trabalho de estágio tem como objetivo projetar, documentar e
desenvolver o sistema de informação SGPE, para gerenciar os planos executivos da
Superintendência de Vigilância em Saúde da Secretaria de Estado de Saúde de Mato
Grosso, a fim de estabelecer melhores práticas na administração dos planos
executivos e suas respectivas auditorias.
Os objetivos específicos são:
Analisar os formulários do plano executivo, para um melhor entendimento do
funcionamento.
Levantar os requisitos funcionais e não funcionais do sistema.
Elaborar os diagramas de classe, caso de uso, entidade relacionamento, sequência
e atividade.
Gerar a estrutura do banco de dados.
Implementar o sistema em um ambiente web utilizando o padrão MVC.
Assim este relatório de estágio está organizado em 05 (cinco) capítulos.
O primeiro capítulo contém a revisão de literatura, abordando as teorias sobre o
servidor WEB Apache e PHP, MySQL, CodeIgniter e o MVC. No capítulo seguinte
foram expostos os materiais, as técnicas e os métodos utilizados durante a execução
do plano de estágio. O capítulo três apresenta os resultados obtidos no período da
realização do projeto. No quarto capítulo foram abordadas as dificuldades
encontradas na execução da proposta. No capítulo final foi demonstrada a conclusão
sobre o trabalho realizado.
15
1 REVISÃO DE LITERATURA
Neste capítulo será abordada a fundamentação teórica sobre os principais
conceitos e tecnologias utilizadas durante o período de realização do estágio
supervisionado.
1.1 Engenharia de Software
A cada dia que passa, os sistemas têm se tornados cada vez mais
complexos, e com isso o seu desenvolvimento se tornou mais trabalhoso, nesse
sentido a engenharia de software surgiu para auxiliar no desenvolvimento até a
manutenção do software.
A engenharia de software é a área da computação relacionada com a
produção de um software, “desde os estágios iniciais de especificação do sistema até
a sua manutenção, depois que este entra em operação” (Sammerville, pg 5, 2007).
O engenheiro de software deve aplicar métodos apropriados para cada
etapa da produção de um software, esses métodos devem estar de acordo com as
restrições organizacionais e financeiras.
1.2 Linguagem de modelagem unificada
A linguagem de modelagem unificada, ou Unified Modeling Language
(UML), é uma linguagem visual utilizada para a modelagem de software, durante a
análise, ele é utilizado para definir as características e documentar o sistema.
A primeira versão surgiu em 1995, com a união de três métodos de
modelagem, o método Booch, OMT (Object, Modeling Thechnique) de Jacobson, o
OOSE (Object-Orinetd Software Engineering) de RumBaugh. A versão atual foi
lançada em 2005 e se encora na 2.0.
Alguns dos diagramas utilizados pela UML é o diagrama de caso de uso,
classe, sequência e atividades.
16
O diagrama de caso de uso é um diagrama utilizado na fase de
levantamento e análise de requisitos e serve de base para o desenvolvimento dos
demais diagramas. Ele “é o diagrama mais geral e informal da UML” (Guedes, pg
30, 2011), pois apresenta uma linguagem simples de fácil compreensão pelo cliente.
Esse diagrama procura apontar os atores e as funcionalidades do sistema.
O diagrama de classe irá definir a estrutura das classes do sistema,
determinando os seus atributos e métodos, além de indicar como serão os
relacionamentos entre eles. O diagrama de sequencia serve para demonstrar a ordem
temporal de troca de mensagem entre os objetos. Já o diagrama de atividade descreve
as sequencias a serem desenvolvidas do inicio até o fim de uma atividade especifica.
1.3 Banco de dados Relacional
Atualmente, a maioria dos sistemas que conhecemos utiliza algum tipo
de banco de dados, podemos entender que o banco de dados é um conjunto de dados
que relacionam entre si. No caso do banco de dados relacional os dados são
armazenados em tabelas, o qual é dividido em linhas e colunas, as colunas são os
atributos e as linhas são os dados armazenados.
No banco de dados relacional as tabelas se relacionam e ela ocorre
através de atributos comuns entre as duas tabelas, que são chamados de atributos
chave.
Existem sistemas responsáveis pelo armazenamento, recuperação,
exclusão, segurança e integridade dos dados em um banco de dados, sendo
caracterizados como sistemas de gerenciamento de banco de dados (SGBD).
Para fazer operações no banco de dados são utilizados, na maioria das
vezes, a linguagem SQL, ou Structured Query Language, existem diversos tipos de
padrões SQL e um deles é o ANSI SQL, permitindo a padronização da linguagem de
operações e torna as migrações de SGBDs mais simples.
17
1.4 Servidor WEB Apache e PHP
O Apache é um servidor WEB open source, que pode ser executado nos
sistemas operacionais baseados em Linux, Unix e no Windows, sendo capaz de
suportar vários tipos de linguagens de scripts, como o PHP.
Outras características desse servidor são:
Utiliza o mais recente protocolo HTTP;
Tem suporte para CGI (Common Gateway Interface), responsável por oferecer
recursos como: personalização das variáveis de ambiente e suporte à depuração;
Permite a utilização de Hosts virtuais;
Possui um servidor Proxy integrado;
Possibilita a customização dos logs e status do servidor.
A configuração do servidor Apache é feita através de um arquivo texto
chamado “http.conf” e não possui uma interface gráfica para os administradores.
Já o PHP, é uma linguagem de programação de uso geral do tipo
interpretada, ou seja, ele executa o código conforme lê. “É um software de código
fonte aberto” (Niederauer, pg 24, 2011) e gratuito, muito utilizado em aplicações
web por causa de suas facilidades, em especial pela possibilidade de incorporar com
o código HTML e de gerar HTML como saída.
Em uma aplicação WEB, o navegador do cliente faz as requisições ao
servidor WEB Apache. Esse por sua vez, se houver necessidade de trabalhar com as
informações recebidas, solicita ao PHP para fazê-lo, quando o PHP terminar, gera os
códigos HTML e envia-os para o Apache, o qual retorna para o browser do cliente.
1.5 MySQL
O MySQL é um sistema de gerenciamento de banco de dados (SGBD)
responsável por controlar o acesso ao banco de dados, permitindo que vários usuários
possam trabalhar com os dados simultaneamente, e que o acesso seja feito por apenas
por pessoas autorizadas, além de designar quais os bancos de dados cada usuário
18
poderá acessar, portanto, “o MySQL é um servidor multiusuário” (Welling &
Thomson, pg 27, 2003). Ele é muito utilizado para as aplicações web devido às
características abaixo:
A alta velocidade, “desde os primeiros lançamentos, os desenvolvedores do
MySQL tem com foco no desempenho, mesmo à custa de um conjunto de
recursos reduzida” (Gilmore, pg 478, 2010);
É distribuído sob a licença open source, “GPL license” (Valade, pg 12, 2007), e
existe também uma distribuição com a licença comercial;
Roda em vários sistemas operacionais como o Windows, Linux, Mac OS, Unix e
outros.
Esse SGBD suporta o Open Database Connectivity (ODBC) e o Java
Database Conectivity (JDBC), ambos são um padrão de conjunto de interfaces que
permitem diversas aplicações trabalharem com um mesmo banco de dados,
utilizando os métodos e acessos especializados desse padrão, porém, o JDBC é usado
somente pelos applets Java.
É possível encontrar duas versões do MySQL, a binária a qual cria uma
instalação padrão do banco de dados, e o código fonte, geralmente utilizado para
compilar o MySQL para as plataformas em que não se encontra uma versão binária
disponível, além de “personalizar a instalação do servidor MySQL” (Suehring, pg
35, 2002), possibilitando assim o atendimento das mais diversas realidades.
O MySQL utiliza o ANSI SQL como linguagem de banco de dados,
porém existem aplicativos com interface gráfica para gerenciar o MySQL. O
PHPMyAdmin, mostrado na Figura 01, é um exemplo desse tipo de aplicativo. Ele é
desenvolvido em PHP, permitindo gerenciar o banco de dados, a tabela e os
conteúdos, sem precisar escrever na linguagem SQL, facilitando a administração do
banco de dados.
19
1.6 Model - View – Controler
O padrão de desenvolvimento de software MVC (Model – View –
Controller), propõe a separação da camada lógica de negócio da camada de
apresentação, utilizando três tipos de classes, o qual tem como objetivo organizar a
aplicação em três camadas (modelo, visão e controle) aumentando a flexibilidade e o
reuso de códigos.
Cada camada é bem definida e independente, onde as regras de negócios
e a lógica do controlador são separadas da apresentação, isso facilita a manutenção e
permite a inclusão de novos elementos de visão, sem a necessidade de modificar as
demais classes.
O Model ou modelo é o objeto de aplicação. Esta camada contêm as
regras de negócio que diz como os dados serão trabalhados, um exemplo do modelo
se encontra no apêndice 2, nele é possível observar a lógica de negócio
implementado na classe “Permissao”.
A View ou visão é o objeto de apresentação, esta camada tem a finalidade
de apresentar as informações para os usuários, contudo não tem o conhecimento da
Figura 1 - Interface principal do phpMyAdmin
20
existência do model. No apêndice 3, é demonstrado a visão do formulário de cadastro
de nível de acesso, pode-se notar a existência de marcadores HTML, são eles que
geram o formulário visto pelo usuário.
O Controller ou controlador define como a interface gráfica reage a uma
entrada do usuário, realizando a união do Model com a View. Ele é quem recebe os
pedidos e define qual a visão mostrar e operação a ser realizada. O exemplo do
controlador se encontra no apêndice 1, nele observamos que é feito requisições ao
modelo e envia os dados para a visão.
Dessa forma pode-se entender que:
“Cada peça da arquitetura MVC é bem definida e independente, o
qual é referido como a separação de preocupações. A lógica que
manipula os dados no model, está contido apenas no model, a lógica
que exibe dados é apenas a view, e o código que lida com
solicitações de usuários e de entrada está contida apenas no
controller. Com uma divisão clara entre cada uma das peças, sua
aplicação vai ser mais fácil de manter e estender ao longo de sua
vida, não importa o quão grande ele se tornará.” (Freeman &
Sanderson, pg 64, 2011)
A Figura 2 ilustra o funcionamento do MVC, na qual toda a solicitação
do usuário chega primeiramente ao controller, o qual faz a requisição dos dados para
o model, esse por fim, trabalha os dados e envia a resposta de volta para o controller,
que por sua vez escolhe a view e envia os dados para ela, finalmente a view mostra os
dados para o usuário.
Figura 2 – Estrutura MVC
Fonte: adaptada pelo autor (Freeman & Sanderson, 2011)
21
A utilização do padrão MVC permitirá o reaproveitamento de código,
como por exemplo, vários controllers usando uma mesma classe do tipo view, dessa
forma, tornando o desenvolvimento mais ágil.
1.7 CodeIgniter
Lançado em 2006 pela EllisLab, o framework CodeIgniter encontra-se na
versão 2.1.3. Foi implementado para acelerar a programação de aplicações WEB,
para isso dispõem de conjuntos de “ferramentas” como funções, bibliotecas e
interfaces, os quais facilitam a execução das tarefas mais rotineiras, como conexão
ao banco, manipulação de sessões, entre outras, minimizando a escrita de código e
possibilitando que o programador foque no projeto em si.
Desenvolvido na linguagem PHP, possibilita o funcionamento em
qualquer servidor web, desde que tenha o PHP 4 ou superior instalado. Utiliza o
paradigma Orientado Objeto, permitindo assim a utilização do padrão MVC.
É um framework sob a licença de código aberto, que se tem a autorização
de usar, copiar, modificar e distribuir o software e seus documentos, com ou sem
alterações, para qualquer fim, desde que se cumpra as seguintes condições
(CodeIgniter - Guia do Usuário, 2013):
Deve ter uma cópia da licença incluía na distribuição;
É essencial manter o aviso de copyright em todos códigos fontes distribuídas;
Redistribuições em formato binário devem conter o aviso de copyright na
documentação e/ou outros materiais fornecidos com a distribuição.
Todos os arquivos que alterados devem conter avisos sobre a natureza da
mudança e os nomes de quem fez essas alterações.
Os Produtos derivados do framework deve incluir a informação de que são
provenientes do CodeIgniter em sua documentação e/ou em outros materiais
distribuídos com a distribuição.
Os Produtos resultantes do software não podem ser chamado de
"CodeIgniter" e conter o "CodeIgniter" em seu nome, sem a permissão prévia
por escrito da EllisLab, Inc.
22
Portanto, o CodeIgniter é uma alternativa para o programador que quer
desenvolver uma aplicação WEB de forma ágil, sem ter que se preocupar com o
desenvolvimento de funções de usos rotineiros, como as retratadas anteriormente.
Dessa maneira, o desenvolvedor focaliza na lógica da aplicação evitando a fadiga de
escrever funções usuais.
O CodeIgniter adota o modelo padrão MVC, a Figura 3 apresenta o fluxo
de dados MVC no framework. Nota-se que a camada controller é responsável por
receber, processar e retornar os dados para as views.
Quando um navegador faz uma requisição ao CodeIgniter, este por sua
vez, propaga a requisição para o arquivo “index.php”, que é responsável por
processá-las, em seguida o framework verificará se existe alguma rota
correspondente ao pedido. Se existir, ele disparará o requerimento para o controlador
correspondente, que por sua ver irá requisitar um model e por fim carregar a view.
No framework CodeIgniter é possível criar aplicações inteiras sem
utilizar os models, usando a classe Active Record, mas essa abordagem não é
recomendada, pois dessa maneira não estaria utilizado o padrão MVC.
Figura 3 - Fluxo de dados MVC com CodeIgniter
Fonte:(Gabardo, 2012)
23
Na figura 4 é possível visualizar a estrutura do CodeIgniter, o arquivo
“index.php” é responsável por receber as requisições HTTP e direciona-las. Na pasta
“system” se encontra o código responsável pelo funcionamento do framework, e na
pasta “application” é o local aonde será desenvolvida a nova aplicação.
Dentro da “application” (Figura 5) encontramos diversas pastas e
arquivos. As mais importantes para se iniciar o desenvolvimento, são:
A “config”, responsável pelos arquivos de configuração do
framework;
O “controllers”, contendo os códigos referentes aos
controladores;
O “models” é o local em que serão armazenados os modelos, com
as suas lógicas de negócio do sistema;
A “views” acomodará os arquivos referentes às visões da
aplicação.
Figura 4 - Estrutura do CodeIgniter
Figura 5 - Pasta Application do CodeIgniter
24
Durante a criação das classes do model, deve-se herdar a classe
“Ci_model”, é essa classe que é responsável por informar ao framework que a classe
é do tipo model. O controller tem o funcionamento muito parecido, mas a classe
herdada pelo controller é o “Ci_controller”, já nas visões não é necessário herdar
nenhum tipo de classe, até porque ele conterá poucos códigos em PHP, diferente das
outras duas classes, que contem somente códigos em PHP.
25
2 MATERIAIS, TÉCNICAS E MÉTODOS
A elaboração do SGPE foi dividida em duas etapas: a análise e o
desenvolvimento, durante essas etapas foi utilizado um computador com 4 GB de
memória RAM, com uma CPU Intel Core 2 Duo e um HD de 320GB. O sistema
operacional utilizado foi o Microsoft® Windows 7 Profissional de 64bits.
Antes de iniciar as etapas de produção do sistema, foi necessário estudar
o formulário utilizado pela SVS para gerenciar os seus planos executivos. O
formulário (Anexo 1) é dividido em diversos blocos, o bloco 1 faz referência ao
vinculo estratégico, a metodologia estratégica utilizada pela SES é a Balanced
Scorecard (BSC), a qual divide a estratégia por perspectivas, ou por dimensões. A
estratégia da SES é separada da SVS, isso ocorre, pois, as estratégias adotadas pela
SES estão relacionadas a todas as áreas pertencentes a ela, já as adotadas pela SVS
estão relacionadas somente com a área de vigilância em saúde. Para a SVS não sair
do foco da instituição, foi necessário fazer o relacionamento das estratégias adotadas
pelas duas.
O bloco 2 do formulário, está associado com as informações gerais de
todo o plano executivo, que inclui as etapas pertencentes a ele. O bloco 3 faz
referência a cada etapa de um projeto, nessa parte do formulário será especificado
detalhadamente cada uma das etapas, incluindo as sub etapas e seus resultados. O
último item do formulário, o bloco 4, faz ligação com a prioridade do plano
executivo. A prioridade é dividida em duas, a prioridade de impacto, a qual
estabelece a força de mudança na realidade da instituição, e a prioridade de
execução, que define a necessidade de colocar em ação.
Finalizado o estudo do formulário, iniciou-se a produção do software. O
objetivo da primeira etapa é a análise e documentação do sistema. Para isso, foi
utilizado na modelagem de caso de uso, o software Dia, já no levantamento de
requisitos o Microsoft® Office Word, para o diagrama de classe, de sequência e de
atividade, recorreu-se ao Microsoft® Visio, na elaboração do banco de dados, foi
produzida a modelagem entidade relacionamento, usando a aplicação DBWrench.
Para compor todas as modelagens e diagramas citados acima, foi
necessário conhecer os formulários utilizados para o gerenciamento do plano
26
executivo, e realizar entrevistas com superintendente, coordenadores e técnicos da
superintendência de vigilância em saúde.
Na etapa de desenvolvimento, foi empregado a linguagem de
programação PHP, juntamente com o framework CodeIgniter e o padrão de projeto
MVC. O motivo da escolha do CodeIgniter, foi determinada pela possibilidade de
tornar o desenvolvimento da aplicação menos fatigante. Já a opção que induziu a
utilização do MVC foi pela facilidade do reaproveitamento de códigos, e com isso
tornar a programação mais rápida.
Para auxiliar no desenvolvimento foi utilizado a IDE Netbeans 7.2.1 para
a programação em PHP.
Para a parte visual ou o layout das páginas, foi utilizado o HTML,
juntamente com a folha de estilos CSS e as funções em JavaScript.
No componente de folha de estilos e do JavaScript foi empregado uma
estrutura de front-end, chamada Bootstrap, que consiste de pacotes de estilos CSS e
funções JavaScript. Para utilizá-los, basta colocar o estilo no código HTML, isso
para o CSS, no caso do JavaScript, apenas chamar as funções.
Para o banco de dados, utilizou-se o SGBD MySQL, devido à facilidade
de integração com o PHP. Para o gerenciamento do banco de dados durante o
desenvolvimento, foi usado o software PhpMyAdmin, o qual é uma aplicação,
desenvolvida em PHP para fornecer uma interface gráfica, através de um navegador
web, para o MySQL.
Durante o desenvolvimento do sistema fez-se necessário verificar se o
software está retornando erro, se o sistema está trabalhando conforme o planejado, e
se a parte visual está legível e as funções em JavaScript estão funcionados
corretamente. Para isso foi feita a instalação do servidor Web Apache, no caso
específico a versão 2.2.22, com o interpretador PHP 5.4.3. Por conveniência foi
utilizado o WampServer, pois essa aplicação já dispunha de todos os aplicativos
citados anteriormente, mais o MySQL e o PhpMyAdmin, dessa maneira não seria
preciso instalar cada um deles separadamente.
Apesar de ter os servidores instalados, foi necessário utilizar um browser
para poder acessar o sistema. Durante o desenvolvimento foi utilizado três
navegadores, Firefox 19.0.2, Internet Explorer 9 e o Google Chrome versão 25.0.
27
3 RESULTADOS
Durante as reuniões com o superintendente foi apresentado os
formulários (Anexo 1), utilizados para a elaboração e acompanhamento dos planos
executivos na SVS. A partir desses documentos e das entrevistas realizadas, deu-se
início a análise do sistema.
3 .1 Levantamento de Requisitos
Na análise, foi necessário levantar requisitos funcionais e não funcionais,
para elencar os serviços que estarão presentes no SGPE, além de documentar
também os requisitos do sistema.
3.1.1 Requisitos Funcionais
Depois de um profundo estudo do formulário utilizado atualmente para o
gerenciamento de plano executivo, das diversas entrevistas feitas com os técnicos,
coordenadores e o superintendente, chegou-se aos seguintes requisitos funcionais:
Tabela 1 - Requisito funcional para cadastrar plano executivo
[RF_001] Deve cadastrar o plano executivo:
O cadastro do plano executivo deve ser feita de acordo com o bloco de
Informações Gerais Sobre a Ação, o bloco de Informações Específicas
sobre a ação e o bloco de Informação Orçamentária – Anexo 2 do
formulário do Plano Executivo.
Tabela 2 - Requisitos funcional cadastro de acompanhamento do plano executivo
[RF_002] Cadastrar o acompanhamento de execução do plano executivo:
O cadastro de acompanhamento da execução do plano executivo deve
ser feita de acordo com o Bloco de Resultado da Etapa – Anexo 3 do
28
formulário do Plano Executivo. O sistema deve também cadastrar os
detalhes de cada etapa, permitindo o anexo de documento para cada
etapa.
Tabela 3 - Requisito funcional para relatório simplificado do plano executivo
[RF_003] Apresentar um relatório simplificado:
O sistema deve representar um relatório simplificado dando destaques
para os planos de acordo com a data final de cada um. Por exemplo, se o
plano ultrapassar a data de fim de execução, ele deve aparecer em
vermelho, se estiver a 1 mês do fim do prazo deve aparecer como amarelo,
se estiver muito longe do prazo final, deve aparecer em verde e se a data
de prazo final não estiver definida deve aparecer em cinza.
Tabela 4 - Requisito funcional de níveis de usuário do SGPE
[RF_004] O sistema deve conter vários níveis de usuário:
O sistema deve conter 6 tipos de usuário:
Administrador – poderá ter controle total sobre o sistema, além
de gerenciar os usuários do sistema, visualizar logs e visualizar os
planos executivos “apagados”.
Superintendente – poderá ter controle total sobre o sistema.
Assistente – poderá somente visualizar todos os planos executivos
Coordenador – poderá ter o controle total de todos os planos
executivos que fazem parte daquela coordenadoria.
Auxiliar – poderá visualizar todos os planos executivos que fazem
parte da coordenadoria o qual o auxiliar pertence.
Técnicos – poderá ter controle total dos planos executivos a qual
tem responsabilidade.
Tabela 5 - Requisitos funcional do relatório detalhado de plano executivo
[RF_005] Deve permitir a visualização de um relatório detalhado:
O sistema deve permitir a visualização dos detalhes do plano executivo
selecionado.
29
Tabela 6 - Requisito funcional vinculo estratégico
[RF_006] O cadastro do vínculo estratégico de cada plano executivo:
O cadastro de vinculo estratégico deve ser feita de baseado no Bloco
Vinculo ao mapa estratégico – Anexo 4, adicionando o vínculo estratégico
indicador no formulário. O cadastro deve ser permitido apenas para os
superintendentes e coordenadores.
Tabela 7 - Requisito funcional da homologação do plano executivo
[RF_007] O sistema deve dar a opção de homologar:
O sistema deve permitir que o superintendente da SVS homologue o plano
executivo cadastrado, não permitindo assim que os outros tipos de
usuários modifique os dados gerais do plano executivo homologado.
Tabela 8 - Requisito funcional número do plano executivo
[RF_008] O sistema deve gerar o número do plano executivo:
O número deve ser gerado, após a homologação do mesmo, de acordo
com o ano de cadastro, o número da perspectiva, o número do objetivo, o
número da iniciativa, o número do problema/causa e um número crescente
de acordo com o número do plano criado naquele ano.
Tabela 9 - Requisitos funcional de gerar relatório em pdf
[RF_009] Gerar relatório detalhado no formato pdf do plano executivo:
O sistema tem que permitir a geração de relatório detalhado ou
simplificado e dos logs do sistema no formato pdf do plano executivo,
para que o usuário possa salvar ou imprimir.
Tabela 10 - Requisito funcional cadastro prioridade plano executivo
[RF_010] Deve cadastrar a indicação de prioridade do plano:
O sistema deve permitir o cadastro da indicação de prioridade do plano
executivo de acordo com o bloco de Indicação da Prioridade da Ação –
anexo 5. O cadastro da indicação de prioridade deve ser feita apenas pelo
superintendente e pelos coordenadores.
30
Tabela 11 - Requisito funcional visualização de anexo
[RF_011] Deve permitir a visualização dos anexos de cada etapa:
O sistema deve permitir, durante a visualização do relatório detalhado, a
opção dever os anexos de cada etapa.
Tabela 12 - Requisito funcional de autenticação de usuário
[RF_012] Deve autenticar os usuários antes de acessar o sistema:
O sistema deve autenticar o usuário através do login e da senha, antes de
permitir o acesso somente nas áreas do sistema permitido para aquele tipo
de usuário.
Tabela 13 - Requisito funcional da alteração do plano executivo
[RF_013] O sistema deve permitir a alteração do plano executivo:
O sistema deve permitir a alteração, antes da homologação, do bloco de
informações gerais, de Informações Especificas Sobre a Ação e o bloco de
Informações Orçamentária do plano executivo, anexo 2.
Tabela 14 - Requisito funcional acompanhamento do plano executivo
[RF_014] O sistema deve permitir a alteração do acompanhamento do plano
executivo:
O sistema deve permitir a alteração dos dados de execução do plano
executivo de acordo com o bloco de resultado da etapa do formulário do
Plano Executivo.
Tabela 15 - Requisito funcional da alteração do vínculo estratégico
[RF_015] O sistema deve permitir a alteração do vínculo estratégico:
O sistema deve permitir a alteração do vínculo estratégico de acordo com
o bloco Vínculo ao Mapa Estratégico do formulário do Plano Executivo,
anexo 4. As alterações só podem ser feitas pelos usuários do nível
superintendente e coordenador.
31
Tabela 16 - Requisito funcional da alteração da prioridade do plano executivo
[RF_016] O sistema deve permitir a alteração da indicação de prioridade do plano
executivo:
O sistema deve permitir a alteração da indicação de prioridade do plano
executivo de acordo com a Indicação da Prioridade da Ação do formulário
do Plano Executivo, anexo A. As alterações só podem ser feitas pelos
usuários do nível superintendente e coordenador.
Tabela 17 - Requisito funcional da exclusão de plano executivo
[RF_017] O sistema não irá permitir a exclusão de plano executivo:
O sistema não irá excluir os planos executivos, será permitida apenas a
omissão do mesmo. Os tipos de usuários que poderão usufruir dessa opção
serão os do tipo coordenador e superintendente.
Tabela 18 - Requisito funcional de cadastro de parceiro
[RF_018] O sistema permitirá o cadastro dos parceiros:
O sistema permitirá o cadastro dos nomes dos parceiros separadamente do
cadastro do plano executivo
Tabela 19 - Requisito funcional de exclusão de parceiros
[RF_019] O sistema permitirá a exclusão de parceiros:
O sistema permitirá a exclusão de parceiros desde que não esteja
cadastrado em nenhum plano executivo.
Tabela 20 - Requisito funcional de cadastro de tipos de resultados
[RF_020] O sistema permitirá o cadastro de tipos de resultado:
O sistema permitirá o cadastro dos tipos de resultado separadamente do
cadastro do plano executivo
Tabela 21 - Requisito funcional de exclusão de tipos de resultado
[RF_021] O sistema permitirá a exclusão dos tipos de resultado:
O sistema permitirá a exclusão os tipos de resultado desde que não esteja
cadastrado em nenhum plano executivo.
32
Tabela 22 - Requisito funcional de alteração de tipos de resultado
[RF_022] O sistema permitirá a alteração dos tipos de resultado:
O sistema permitirá a alteração dos tipos de resultado separadamente do
cadastro do plano executivo
Tabela 23 - Requisito funcional de cadastro de destinação de resultado
[RF_023] O sistema permitirá o cadastro da destinação do resultado:
O sistema permitirá o cadastro de destinação do resultado separadamente
do cadastro do plano executivo
Tabela 24 - Requisito funcional de exclusão da destinação do resultado
[RF_024] O sistema permitirá a exclusão da destinação do resultado:
O sistema permitirá a exclusão da destinação do resultado desde que não
esteja cadastrado em nenhum plano executivo.
Tabela 25 - Requisito funcional de alteração da destinação do resultado
[RF_025] O sistema permitirá a alteração da destinação do resultado:
O sistema permitirá a alteração da destinação do resultado separadamente
do cadastro do plano executivo
Tabela 26 - Requisito funcional de cadastro da natureza da ação
[RF_026] O sistema permitirá o cadastro da natureza da ação:
O sistema permitirá o cadastro da natureza da ação separadamente do
cadastro do plano executivo
Tabela 27 - Requisito funcional de exclusão da natureza da ação
[RF_027] O sistema permitirá a exclusão da natureza da ação:
O sistema permitirá a exclusão da natureza da ação desde que não esteja
cadastrado em nenhum plano executivo.
33
Tabela 28 - Requisito funcional de alteração da natureza da ação
[RF_028] O sistema permitirá a alteração da natureza da ação:
O sistema permitirá a alteração da natureza da ação separadamente do
cadastro do plano executivo
Tabela 29 - Requisito funcional de finalização do plano executivo
[RF_029] O sistema permitirá finalizar o plano executivo:
O sistema terá a opção de finalizar o plano executivo. Após a finalização,
não será permitido a alteração de qualquer informação referente ao plano
finalizado e será registrado a data da finalização.
Tabela 30 - Requisito funcional de cadastro de usuário
[RF_030] O sistema permitirá cadastro de usuários:
O sistema permitirá o cadastrar usuários apenas para os usuários de nível
administrador.
Tabela 31 - Requisito Funcional de alteração de dados do usuário
[RF_031] O sistema permitirá alterar dados de usuário:
O sistema permitirá o alterar os dados do usuário apenas para os usuários
de nível administrador.
Tabela 32 - Requisito funcional de desativação de usuário
[RF_032] O sistema permitirá a desativação de usuários:
O sistema permitirá a desativação dos usuários apenas para os usuários de
nível administrador. Os usuários desativados não poderão mais acessar o
SGPE.
Tabela 33 - Requisito funcional de gerar logs de acesso
[RF_033] O sistema irá gerar log de acesso:
O sistema irá gerar automaticamente os logs de acesso de todos os
usuários que acessarem o sistema
34
Tabela 34 - Requisito funcional de gerar logs de atividade
[RF_034] O sistema irá gerar logs de atividade:
O sistema irá gerar automaticamente os logs de atividades de todas
atividades realizadas por cada usuário
Tabela 35 - Requisito funcional de exibir logs
[RF_035] O sistema permitirá a exibição dos logs:
O sistema permitirá a exibição de todos os logs gerado pelo mesmo.
Tabela 36 - Requisito funcional de cadastro de setores
[RF_036] O sistema permitirá a o cadastro de setores:
O sistema permitirá o cadastrar de setores apenas para os usuários de nível
administrador.
Tabela 37 - Requisito funcional de alteração de setores
[RF_037] O sistema permitirá a o alteração de setores:
O sistema permitirá a alteração do nome do setor apenas pelo usuário do
tipo administrador
Tabela 38 - Requisito funcional de exclusão de setores
[RF_038] O sistema permitirá a exclusão de setores:
O sistema permitirá a exclusão do setor apenas pelo usuário do tipo
administrador e se não houver nenhum usuário pertencendo ao setor a ser
excluído.
Tabela 39 - Requisito funcional de cadastro de grupos responsáveis
[RF_039] O sistema permitirá a o cadastro dos grupos responsáveis:
O sistema permitirá a cadastro dos grupos somente pelos usuários
coordenador e superintendente
Tabela 40 - Requisitos funcionais de alteração de grupos responsáveis
[RF_040] O sistema permitirá a alteração dos grupos responsáveis:
O sistema permitirá a alteração dos grupos somente pelos usuários
35
coordenador e superintendente
Tabela 41 - Requisito funcional de exclusão de grupos responsáveis
[RF_041] O sistema permitirá a exclusão dos grupos responsáveis:
O sistema permitirá a exclusão dos grupos somente pelos usuários
coordenador e superintendente
Tabela 42 - Requisito funcional do cadastro de etapa
[RF_042] O sistema permitirá a o cadastro de etapas do plano executivo:
O sistema permitirá o cadastro de etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
Tabela 43 - Requisito funcional da alteração da etapa
[RF_043] O sistema permitirá à alteração de etapas do plano executivo:
O sistema permitirá a alteração das etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
Tabela 44 - Requisito funcional da exclusão da etapa
[RF_044] O sistema permitirá à exclusão de etapas do plano executivo:
O sistema permitirá a exclusão das etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
Tabela 45 - Requisito funcional do cadastro de sub etapa
[RF_045] O sistema permitirá a o cadastro de sub etapas do plano executivo:
O sistema permitirá o cadastro de sub etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
Tabela 46 - Requisito funcional da alteração da sub etapa
[RF_046] O sistema permitirá à alteração de sub etapas do plano executivo:
O sistema permitirá a alteração das sub etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
36
Tabela 47 - Requisito funcional da exclusão da sub etapa
[RF_047] O sistema permitirá à exclusão de sub etapas do plano executivo:
O sistema permitirá a exclusão das sub etapas do plano executivo pelos
usuários do tipo administrador, coordenador e técnico.
Tabela 48 - Requisitos funcionais de cadastro das estratégias adotadas
[RF_048] O sistema permitirá o cadastro das estratégias:
O sistema permitirá o cadastro das estratégias adotadas pela SES e pela
SVS separadamente. As estratégias são compostas de perspectiva,
objetivo, indicadores, metas, iniciativas e problema/causa. O tipo de
usuário responsável pelo cadastro é o superintendente.
Tabela 49 - Requisitos funcionais de edição das estratégias adotadas
[RF_049] O sistema permitirá o editar das estratégias:
O sistema permitirá o editar das estratégias adotadas pela SES e pela SVS
separadamente. O tipo de usuário responsável pela edição é o
superintendente
Tabela 50 - Requisitos funcionais de exclusão estratégias adotadas
[RF_050] O sistema permitirá a exclusão das estratégias:
O sistema permitirá as exclusões das estratégias adotadas pela SES e pela
SVS separadamente. O tipo de usuário responsável pela exclusão é o
superintendente
3.1.2 Requisitos Não Funcionais
Nessa seção serão apresentados os requisitos não funcionais do sistema:
Tabela 51 - Requisito não funcional servidor web
[RNF_001] Ter um servidor web:
O sistema precisará de um servidor web com o Apache, PHP e o MySql
instalados.
37
Tabela 52 - Requisito não funcional sistema de backup
[RNF_002] Ter um sistema de backup:
O servidor a qual estará a aplicação, deverá ter um sistema de backup para
o banco de dados do sistema.
Tabela 53 - Requisito não funcional conexão com a internet
[RNF_003] Ter conexão com a Internet:
O sistema precisará de uma conexão com a Internet.
Tabela 54 - Requisito não funcional interface amigável
[RNF_004] Ter uma interface amigável:
O sistema precisará de uma interface amigável, o qual a utilização do
sistema seja intuitiva.
38
3.2 Casos de Uso
O próximo passo foi os diagramas de caso de uso. Devido a uma grande
quantidade de casos de uso, foi separado por atores de acordo com o número de
atores especificado na Tabela 4.
O primeiro caso de uso a ser apresentado é o do administrador do
sistema, ele será responsável por gerenciar os usuários, o qual implica em cadastrar,
alterar e desativar usuários, conforme está demonstrado na tabela 30, 31 e 32. O
administrador também poderá visualizar os logs do sistema, conforme o requisito
funcional representado na tabela 35, e de todos os planos executivos, incluindo os
que foram escondidos pela aplicação. Conforme mostrado nas tabelas 36, 37 e 38,
além disso, ele será responsável por gerenciar os setores dos usuários, a Figura 06
ilustra o caso de uso do administrador do sistema.
Em seguida serão apresentados os casos de uso do assistente e do auxiliar
(Figura 07), o assistente, conforme a tabela 4 dos requisitos funcionais, terá acesso
Figura 6 - Caso de uso do administrador do sistema
39
apenas a visualização dos planos executivos. Já o auxiliar, é uma especialização do
assistente, ele poderá visualizar somente os planos executivos da coordenadoria a
qual pertence.
O caso de uso dos técnicos, é um pouco mais abrangente, pois eles serão
responsáveis pela criação e acompanhamento dos planos executivos, podendo
também gerar alguns relatórios referentes aos mesmos. A Figura 8 representa os
casos de uso.
Os coordenadores tem o caso de uso parecido com os dos técnicos, pois
eles também serão responsáveis por alimentar os planos executivos. A diferença está
apenas em alguns casos a mais que os coordenadores podem executar, como
gerenciar o vínculo estratégico do plano executivo, definir as suas prioridades e
gerenciar os grupos responsáveis, além disso, poderá também finalizar os planos
executivos. A Figura 9 ilustra o caso citado.
Figura 7 - Caso de uso do assistente e do auxiliar
41
O último ator do sistema é o superintendente, o qual terá um maior controle sobre o
sistema, ele poderá gerenciar e conduzir os planos executivos, poderá também definir
e alterar o vínculo estratégico, a prioridade e os grupos responsáveis, além de
finalizar os planos executivos. Os casos de uso exclusivo do superintendente é o de
homologar o sistema, conforme a tabela 7, e de gerenciar as estratégias atribuídas a
SES e a SVS. A Figura 10 demonstra os casos de uso do superintendente.
3.3 Diagrama de Classe
Esse diagrama tem por objetivo identificar os objetos que fará parte do
sistema, e a partir dele poderemos ter uma perspectiva do aplicativo. A Figura 11
exibe uma visão geral do diagrama de classe do SGPE.
Figura 10 - Caso de uso do superintendente
43
Na Figura 12, exibe mais detalhadamente os objetos relacionados às
estratégias do plano executivo, pode-se observar que todas as classes contém um
atributo chamado local. Ele serve para demonstrar se o item estratégico pertence à
SES ou a SVS.
A Figura 13, está associada ao acompanhamento do plano executivo, nela
pode-se notar que cada etapa está relacionada com diversas sub etapas, e elas por sua
vez, tem apenas um resultado, as classes que fazem parte do controle financeiro são
as classes “ElementoDespesa”, referindo a qual tipo de orçamento, e a classe
“Orcamento”, fazendo referência ao orçamento de cada etapa.
Figura 12 - Diagrama de Classe estratégia do plano executivo
44
A Figura 14 demonstra o diagrama pertencente ao plano executivo, e sua
natureza, parceiros e grupos responsáveis, já a Figura 15, destaca as classes
responsáveis pelos logs, controle e gerenciamento de usuários, sendo que a classe
“Setor” faz referência ao setor em que o usuário está inserido.
Figura 13 - Diagrama de classe acompanhamento do plano executivo
45
Figura 15 - Diagrama de classe dos acessos e logs
Figura 14 - Diagrama de classe do plano executivo
46
3.4 Modelagem Entidade Relacionamento
Após o levantamento de requisitos, foi realizada a modelagem entidade
relacionamento do banco de dados, para se chegar ao fechamento do MER foi
necessário mais entrevistas e estudos do formulário. A Figura 16 mostra uma visão
geral do diagrama entidade relacionamento (DER).
Percebe-se na modelagem a existência de doze entidades parecidas, as
quais fazem parte da estratégia adotada pelas SES, Figura 17, e pela SVS, Figura 18.
As perspectivas estão relacionadas ao cenário da aplicação da ação, os
objetivos se referem ao propósito do plano executivo, os indicadores são guias para
que cada objetivo seja alcançado, as metas são responsáveis por determinar a
Figura 16 - Diagrama Entidade Relacionamento do SGPE
47
finalidade, as iniciativas ou atividade em que o plano executivo fará parte, e o
problema/causa que o plano executivo irá solver.
As entidades estão divididas entre as pertencentes à SES e a SVS, isso
ocorreu porque a estratégia adotada pela SVS é diferente da estratégia adotada pela
SES. A elaboração dessas entidades foi necessária, pois os planos executivos devem
estar de acordo com as estratégias adotadas pela SVS e também pela SES.
Figura 18 - DER associado à estratégia da SES
Figura 17 - DER associado à estratégia da SVS
48
A parte dos logs representando na Figura 19, foi dividida em duas
entidades, a “logs_acesso” responsável por registrar os dados de acesso de cada
usuário, e a “logs_atividade”, que é responsável por registrar as atividades feitas de
cada acesso e em qual plano executivo foram realizadas.
A Figura 20 está associada ao controle de acesso do sistema, o controle
será feito através dos usuários, que pertencem a um setor. As permissões serão feitas
através de níveis de acesso, os quais poderão ter ou não, a permissão de acessar
certos métodos do sistema.
Figura 19 - DER associado aos logs do sistema
Figura 20 - DER associado ao controle de acesso
49
A Figura 21, apresenta os dados gerais do plano executivo, na qual
podemos notar as diversas tabelas, entre elas: a “natureza” especificando a natureza
da ação, “parceiros”, fazendo referência aos membros externos da SVS que
participarão do projeto, “grupo_responsavel” correspondendo ao grupo de trabalho
responsável pelo plano executivo, e o “plano_executivo”, nessa entidade temos o
atributo “homologado”, indicando se o plano foi homologado ou não, há também o
campo “numPlano”, onde será armazenado o número do plano executivo gerado após
a homologação.
Na Figura 22, se encontra as informações referentes as etapas, como as
informações orçamentarias, que possui informações sobre os itens necessários para
executar o plano e seus respectivos custos, e para cada componente existe um tipo de
elemento de despesa, representado pela tabela “elementoDespesa”, as dos técnicos
responsáveis pela execução, e das sub etapas.
Cada sub etapa tem seu resultado, onde conterá uma descrição,
destinação e qual o tipo de elemento obtido.
Figura 21 - DER associado aos dados gerais do plano executivo
51
3.5 Diagrama de Sequência
O diagrama de sequência produzido no período do estágio foi a do
cadastro de novo plano executivo (Figura 23), ele serve para representar a sequência
dos processos durante a criação de um novo plano executivo.
Figura 23 - Diagrama de sequência de novo plano executivo
52
3.6 Diagrama de Atividade
Os diagramas de atividade produzidos durante o estágio foi a do cadastro
de um novo plano executivo e o seu acompanhamento. A Figura 24 representa o
diagrama de atividade do cadastro de um novo plano executivo.
Figura 24 - Diagrama de atividade de cadastro de um novo plano executivo
53
A Figura 25 corresponde ao digrama de atividade do acompanhamento
de um plano executivo.
Essa atividade de acompanhamento, visa conduzir as informações
referentes a cada plano executivo de maneira sistemática, para controle das ações
relativas ao mesmo.
Figura 25 - Diagrama de atividade de acompanhamento do plano executivo
54
3.7 Implementação
Os documentos gerados na análise foram utilizados como apoio para a
implementação. A utilização do framework e do MVC agilizaram o processo, mas
pelo curto prazo de tempo não foi possível a implementação de todo o aplicativo.
A primeira tela que o usuário terá acesso no aplicativo, será de um
formulário de login, pois, somente as pessoas cadastradas poderão acessar o sistema,
a Figura 26 apresenta a imagem da página inicial do sistema.
A área de gerenciamento dos usuários, demonstrado na Figura 27, pode-
se perceber que é possível criar, alterar e desativar um usuário, em concordância com
as tabelas 30, 31 e 32 dos requisitos funcionais.
Figura 26 - Tela de login
Figura 27 - Tela principal parte usuário
55
A etapa da estratégia, incluiu cadastrar, editar e excluir as perspectivas,
objetivos, indicadores, metas, iniciativas e problemas/causa.
As Figuras 28 e 29 exibem a tela aonde se deve selecionar o elemento
estratégico. Na Figura 28 os elementos fazem parte da estratégia da SVS e na Figura
29 fazem parte da estratégia da SES.
Figura 28 - Tela principal da estratégia da SVS
Figura 29 - Tela Principal da estratégia da SES
56
Na Figura 30, o item perspectiva é referente a Superintendência de
Vigilância em Saúde, conforme proposto pela tabela 48, 49 e 50 dos requisitos
funcionais. As telas dos demais itens serão parecidas com a Figura 30, pois elas
possuem os requisitos funcionais semelhantes.
O gerenciamento da natureza da ação, apresentado na Figura 31, está de
acordo com os requisitos funcionais relatados nas tabelas 26, 27 e 28.
Os logs de acesso e de atividade serão exibidos nas Figuras 32 e 33,
servindo para registrar os acessos realizados no sistema e as atividades efetuadas, o
registro do log de admissão será feito após a verificação do usuário e antes de
ingressar no sistema, já o log de atividade é produzido assim que uma função é
requisitada, juntamente com a verificação de permissão.
Figura 30 - Tela da perspectiva da SVS
Figura 31 - Tela da natureza do plano executivo
57
No apêndice 1 é apresentado o código do controlador “permissao”,
podemos observar que contém diversas funções e uma delas é o “index()”, todos os
controllers do CodeIgniter devem ter essa função, pois ela é default, na função
”novo()” existe uma requisição a um método do modelo “permissão_model”
(apêndice 2), o qual faz as conexões ao banco de dados e responde a solicitação para
o controlador, esse por sua vez seleciona uma view e envia os dados recebidos para
serem exibidos, no apêndice 3, temos um exemplo de código da visão “novo_view”,
que é um formulário de cadastro de permissões. Os demais códigos desenvolvidos
durante o estágio estão em um CD anexo ao relatório.
Figura 32 - Tela dos logs de acesso
Figura 33 - Tela dos logs de atividade
58
4 DIFICULDADES ENCONTRADAS
Durante o período de estágio foram encontradas diversas dificuldades na
área de análise e na fase de desenvolvimento do aplicativo, conforme exposto logo
abaixo.
Na análise, as dificuldades surgiram ao compreender o fluxograma e a
estrutura do plano executivo, que foi ocasionado pelo fato de não possuir um
conhecimento prévio na área de planejamento da SVS.
Para solucionar a situação, foram necessárias realizar diversas
entrevistas com o superintendente, técnicos e coordenadores, na tentativa de
possibilitar uma maior clareza de como funcionava a realidade institucional,
adquirindo assim, conhecimentos necessários para entender o fluxo e a estrutura de
um plano executivo.
Outro contratempo encontrado, foi a maneira de organizar o formulário
para exibição, pois os formulários de cadastro e alteração do plano executivo
continham um grande número de campos, o qual se tornaria cansativo para o usuário
o seu preenchimento. Assim sendo, foi imprescindível dividi-los de forma que o
cliente conseguisse preencher pequenas partes e salvá-las para poder continuar em
outro momento.
Na fase das entrevistas, ocorreram momentos em que o responsável pela
explicação do funcionamento do plano executivo, estava em reunião ou executando
ações pertinentes a SES. Por esse motivo houve uma certa morosidade para realizar
os encontros.
Na implementação, a primeira adversidade encontrada foi a de como
realizar o controle de usuário, depois de muitas pesquisas ficou evidente que seria
necessário cadastrar todas as classes e suas respectivas funções, após essa fase, foi
necessário criar grupos de acesso e permitir o ingresso do grupo em funções
especificas de acordo com as permissões pré-estabelecidas.
Com a utilização do CodeIgniter, o desafio posto, foi a de pouco
conhecimento de suas distintas ferramentas, e para suprir tal demanda foi
necessários, acessar e estudar o manual do usuário, disponível no site do
59
desenvolvedor do framework. A partir desse momento foi possível trazer as claras
quais métodos utilizar.
Já com a utilização do MySQL o obstáculo maior, foi referente a
gravação das acentuações no banco de dados, para resolver tal problema foi
necessário definir a codificação dos caracteres, ou colação, como utf8_unicode_ci,
evitando desta maneira a realização de conversões de codificação dos textos
recebidos através de formulários.
No layout da interface gráfica apresentado ao usuário houve uma objeção
quanto à organização das telas, para vencer essa dificuldade, as telas foram
remanejadas de maneira intuitiva e sem muitos objetos, possibilitando um campo
visual mais nítido, limpo e de fácil compreensão.
A dificuldade ocorrida com maior frequência foi a de encontrar pouco
conteúdo na língua portuguesa, a grande maioria está disponível apenas na língua
inglesa. Apesar de se ter um conhecimento mediano nessa língua, ocorreram algumas
dificuldades quanto a tradução e interpretação. Entretanto, a utilização de tradutores
online, dicionários e gramáticas especializadas facilitaram o entendimento.
Todas as diversidades encontradas, foram muito importantes para o
aprendizado, pois é um tipo de conhecimento que não é possível sem ter a execução
da prática e do comprometimento.
60
5 CONCLUSÕES
A realização do estágio, foi de extrema importância para adquirir
conhecimento e experiência no que tange as áreas práticas de análise e
desenvolvimento de software.
Durante o estudo dos formulários do plano executivo, foram realizadas
diversas entrevistas com os técnicos, coordenadores e o superintendente, os quais
foram importantes, pois, complementaram de maneira satisfatória as informações
sobre o formulário, o que possibilitou um melhor entendimento do fluxograma de
funcionamento do plano executivo. Essa etapa foi necessária, pois sem ela seria
impossível realizar a construção do sistema de acordo com as necessidades da SVS, a
partir dessa etapa se teve o fundamentação básica para realizar o projeto do sistema.
Após o entendimento do fluxograma do plano executivo, partiu-se para a
etapa de levantamento de requisitos funcionais e não funcionais do sistema. Foram
utilizados os conhecimentos adquiridos na fase anterior e realizadas mais algumas
entrevistas. Essa etapa influenciou nos demais processos de desenvolvimento, pois os
levantamentos de requisitos informam às necessidades que conterá no sistema.
Finalizado os levantamentos de requisitos, deu início à diagramação do
sistema, durante esse estágio todas as diagramações propostas foram finalizadas, e a
partir da modelagem entidade relacionamento, foi construído o banco de dados do
sistema. Essa fase proporcionou uma documentação e um melhor entendimento do
funcionamento do sistema, o diagrama de classe foi necessário para construir as
classes que fazem parte do modelo, pois é nele que se encontra a lógica de negócio
do sistema. O diagrama de atividade foi importante para compreender o passo a
passo do funcionamento do sistema. O diagrama de sequência proporcionou um
entendimento melhor de como e quando ocorrem às trocas de mensagens entre os
objetos do sistema.
Para a construção do banco de dados, o diagrama de entidade
relacionamento auxiliou na construção do script de criação do banco, sem a
construção do diagrama de entidade relacionamento, a construção do banco de dados
seria uma tarefa trabalhosa.
61
A utilização do framework CodeIgniter tornou a programação mais
acelerada, e a utilização de funções e bibliotecas evitou uma demanda maior de
escrita de códigos. O padrão MVC possibilitou o reaproveitamento de código
tornando eficiente a criação do software. O Apêndice 1 é o exemplo de um
controller, nele é possível observar que solicitou-se diversas vezes ao model para
realizar operações. Após receber os dados do modelo, o controller os envia para a
visão, esse por sua vez se responsabiliza em exibi-los ao usuário. O modelo é
retratado no apêndice 2, nele nota-se que não há nenhum tipo de referência ao
controller ou a view. No apêndice 3 é apresentado uma exemplo de código da view, o
qual é diferente dos demais, pois contém marcadores HTML, esses marcadores serão
interpretados pelo browser, que construirá a tela.
Apesar de utilizar ferramentas e métodos para acelerar o
desenvolvimento do programa, cabe ressaltar que a produção do sistema ainda está
em andamento.
Como proposta futura, a finalização do aplicativo possibilitará o teste e a
implantação do SGPE na SVS, e após a consolidação do sistema, se iniciará o
incremento da próxima versão, tendo em vista, estabelecer melhorias práticas no
gerenciamento dos planos executivos e suas respectivas auditorias.
62
6 REFERÊNCIAS BIBLIOGRÁFICAS
EllisLab, Inc. CodeIgniter User Guide. Disponível por www em
http://ellislab.com/codeigniter/user-guide/ (acessado em 15 de março de 2013).
FREEMAN, A., SANDERSON, S.; 2011. Pro ASP.NET MVC 3 Framework. 3
edição. Nova York: Apress.
GABARDO, Ademir Cristiano; 2012. PHP e MVC com CodeIgniter. 1ª edição. São
Paulo: Novatec.
GILMORE, Jason; 2010. Beginning PHP and MySQL: From Novice to Professional.
4ª edição. Nova York: Apress.
GUEDES, Gilleanes; 2011. UML2: uma abordagem prática. 2ª edição. São Paulo:
Novatec.
KABIR, Mohammed; 2002. Apache Server 2 Bible. 1ª edição. Nova York: Hungry
Minds.
NIEDERAUER, Juliano 2011. Desenvolvendo Websites com PHP. 2ª edição. São
Paulo: Novatec.
SAMMERVILLE, Ian; 2007. Engenharia de software. 8ª edição. São Paulo: Pearson.
SUEHRING, Steve; 2002. MySQL, a Bíblia. 1ª edição. Rio de Janeiro: Campus.
THOMSO, L., WELLING, L.; 2003. PHP e MySQL: Desenvolvimento Web. 2ª
edição. Rio de Janeiro: Campus.
VALADE, Janet; 2007. PHP & MySQL for Dummies. 3ª edição. Indianapolis: Wiley.