UNIVERSIDADE DO SUL DE SANTA CATARINA
MATHEUS RIBEIRO MELIM
THIAGO THIESEN DE SOUZA
DESENVOLVIMENTO DE UM SISTEMA WEB:
CONTROLE DE BOMBEIROS COMUNITÁRIOS
PALHOÇA
2012
MATHEUS RIBEIRO MELIM
THIAGO THIESEN DE SOUZA
DESENVOLVIMENTO DE UM SISTEMA WEB:
CONTROLE DE BOMBEIROS COMUNITÁRIOS
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação, da
Universidade do Sul de Santa Catarina, como requisito
parcial para obtenção do título de Bacharel.
Orientadora: Professora Maria Inés Castiñeira
PALHOÇA
2012
MATHEUS RIBEIRO MELIM
THIAGO THIESEN DE SOUZA
DESENVOLVIMENTO DE UM SISTEMA WEB:
CONTROLE DE BOMBEIROS COMUNITÁRIOS
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação, da
Universidade do Sul de Santa Catarina, como requisito
parcial para obtenção do título de Bacharel.
Palhoça, 15 de junho de 2012.
_____________________________________________________
Prof ͣ. e orientadora Maria Inés Castiñeira, Dra.
Universidade do Sul de Santa Catarina
_____________________________________________________
Prof. Ricardo Villarroel Dávalos, Dr.
Universidade do Sul de Santa Catarina
_____________________________________________________
Anderson Medeiros Sarte, Ten.
Corpo de Bombeiros Militar de Santa Catarina
Dedicamos este trabalho aos nossos pais que
sempre nos ajudaram, incentivaram e apoiaram
as nossas escolhas.
À professora e orientadora Maria
Inés
Castiñera por auxiliar na orientação neste
trabalho.
AGRADECIMENTOS
Agradecemos à nossa família por acreditar em nosso potencial e pelo auxílio nos
momentos difíceis.
A todos os professores que dividiram seu conhecimento conosco durante o curso,
agradecendo especialmente a professora Maria Inés Castiñera, que nos foi uma pessoa de
grande importância para a realização deste trabalho.
Ao Tenente Anderson Medeiros Sarte, representando o Corpo de Bombeiros
Militar de Santa Catarina, pelo incentivo e dedicação em todos os momentos, ficando
disponível para o auxílio da realização deste trabalho.
Às namoradas pela paciência nos momentos de ausência para o desenvolvimento
deste trabalho.
“A vida está cheia de desafios que, se aproveitados de forma criativa, transformam-se em
oportunidades.” (Maxwell Maltz).
RESUMO
No Corpo de Bombeiro Militar de Santa Catarina – CBMSC –, não existe um sistema de
controle de agendamento dos Bombeiros Comunitários na Escala de Serviço. Com isso,
nasceu a idéia de desenvolver um sistema para informatizar este processo, tornando-o mais
prático através da web. Este trabalho tem, como finalidade, planejar e desenvolver um sistema
para informatizar este processo. Como etapas metodológidas, deste trabalho, foram
estipuladas as seguintes: revisão da literatura, através do estudo e pesquisas bibliográficas,
sobre processos de desenvolvimento de software, assim como sobre o Regulamento Geral do
Serviço Voluntário no Corpo de Bombeiros Militar de Santa Catarina e sobre esta entidade;
modelagem do software utilizando o modelo ICONIX, desenvolvimento do sistema, validação
e testes. Optou-se pela arquitetura web, para centralizar o processo, tornando as informações
mais acessíveis à Coordenadoria dos Projetos Comunitários do CBMSC. Após a conclusão
destes tópicos, o desenvolvimento deste trabalho disponibiliza ao Corpo de Bombeiros de
Santa Catarina uma solução de Tecnologia da Informação que agilizará o processo de
agendamento na escala de serviço dos Bombeiros Comunitários de maneira eficiente,
previsível e que atinge as necessidades do negócio, documentado através de diagramas da
UML, que foram desenvolvidos seguindo a metodologia ICONIX. Foi escolhida como
linguagem principal no desenvolvimento do sistema a linguagem Microsoft .NET, juntamente
com o Banco de Dados Microsoft SQL Server 2008.
Palavras-chave: Corpo de Bombeiros Militar de Santa Catarina. Bombeiro Comunitário.
ICONIX. Software de Agendamento. Escala de Serviço.
ABSTRACT
In Military Fire Department of Santa Catarina – CBMSC – there is no scheduling system to
control the schedule of the fire department. Thus was born the idea of developing a system to
computerize this process, making it more practical through the web. This work aimed to
design and develop a system to computerize this process. As methodological steps of this
work, were set as follows: a literature review, through study research literature on software
development processes, as well as on the General Regulation of volunteer Service at the Fire
Station in Santa Catarina and upon this organization, modeling software using the ICONIX
model, system development, validation and testing. We opted for the web architecture to
centralize the process, making information more accessible by the coordinating body of the
community projects in the CBMSC. After the conclusion of topics, the development of this
work include to the Fire Department of Santa Catarina, an information technology solution
which speeds up the scheduling process in an efficient, predictable and achieves the business
needs, documented by UML diagrams, which were developed following the methodology
ICONIX. Was chosen as the main language in the development of the system the language
Microsoft .NET, along with the Database Microsoft SQL Server 2008.
Keywords: Fire Department in Santa Catarina. Firefighter Community. ICONIX. Scheduling
Software.
LISTA DE ILUSTRAÇÕES
FIGURA 1
– LOGO DO CBMSC. .................................................................................... 20
FIGURA 2
– MODELO CASCATA. ................................................................................ 26
FIGURA 3
– MODELO INCREMENTAL. ...................................................................... 26
FIGURA 4
– PROTOTIPAGEM....................................................................................... 27
FIGURA 5
– MODELO ESPIRAL. .................................................................................. 28
FIGURA 6
– VALORIZAÇÃO SEGUNDO AGILE MANIFESTO (2001). ..................... 29
FIGURA 7
– PRINCÍPIOS DOS MÉTODOS ÁGEIS. ...................................................... 30
FIGURA 8
– CICLO RELEASE XP. ................................................................................ 31
FIGURA 9
– DIAGRAMA DE ROBUSTEZ. ................................................................... 34
FIGURA 10 – OBJETOS. ................................................................................................... 35
FIGURA 11 – DIAGRAMA DE CLASSE. ......................................................................... 37
FIGURA 12 – ORGANIZAÇÃO GERAL DOS DIAGRAMAS DE UML 2. ...................... 39
FIGURA 13 – DIAGRAMAS ESTRUTURAIS. ................................................................. 40
FIGURA 14 – DIAGRAMAS COMPORTAMENTAIS...................................................... 40
FIGURA 15 – FLUXOGRAMA COM AS ETAPAS METODOLÓGICAS. ....................... 44
FIGURA 16 – PROPOSTA DO TRABALHO. ................................................................... 45
FIGURA 17 – ATORES DO SISTEMA. ............................................................................ 46
FIGURA 18 – DIAGRAMA DO MODELO DE PROCESSO DO NEGÓCIO ATUAL. ..... 49
FIGURA 19 – DIAGRAMA DO MODELO DE PROCESSO DO NOVO SISTEMA. ........ 52
FIGURA 20 – REQUISITOS FUNCIONAIS DO SISTEMA. ............................................. 53
FIGURA 21 – CASOS DE USO DO SISTEMA. ................................................................ 59
FIGURA 22 – MODELO DE DOMÍNIO PARA CADASTRO DE LOCAL. ...................... 64
FIGURA 23 – MODELO DE DOMÍNIO PARA CADASTRO DE USUÁRIO................... 65
FIGURA 24 – MODELO DE DOMÍNIO PARA CADASTRO DE ESCALA. .................... 65
FIGURA 25 – MODELO DE DOMÍNIO PARA CONFIRMAÇÃO DE SERVIÇO............ 66
FIGURA 26 – DIAGRAMA DE CLASSES PARA CADASTRO DE LOCAL. .................. 67
FIGURA 27 – DIAGRAMA DE CLASSES PARA CADASTRO DE USUÁRIO............... 68
FIGURA 28 – DIAGRAMA DE CLASSES PARA CADASTRO DE ESCALA. ................ 69
FIGURA 29 – DIAGRAMA DE CLASSES PARA GERAÇÃO DE RELATÓRIOS. ......... 69
FIGURA 30 – DIAGRAMA DE ROBUSTEZ PARA CADASTRO DE LOCAL. .............. 70
FIGURA 31 – DIAGRAMA DE ROBUSTEZ PARA CADASTRO DE USUÁRIO. .......... 71
FIGURA 32 – DIAGRAMA DE ROBUSTEZ PARA CADASTRO DE ESCALAS. .......... 72
FIGURA 33 – DIAGRAMA DE ROBUSTEZ PARA GERAÇÃO DE RELATÓRIOS. ..... 73
FIGURA 34 – DIAGRAMA DE ROBUSTEZ PARA CONFIRMAÇÃO DE SERVIÇO. ... 73
FIGURA 35 – DIAGRAMA DE SEQUÊNCIA PARA CADASTRO DE LOCAL. ............ 75
FIGURA 36 – DIAGRAMA DE SEQUÊNCIA PARA CADASTRO DE USUÁRIO. ........ 76
FIGURA 37 – DIAGRAMA DE SEQUÊNCIA PARA CADASTRO DE ESCALA. .......... 77
FIGURA 38 – DIAGRAMA DE SEQUÊNCIA PARA GERAÇÃO DE RELATÓRIOS. ... 78
FIGURA 39 – MODELAGEM DO BANCO DE DADOS. ................................................. 79
FIGURA 40 – TECNOLOGIAS UTILIZADAS. ................................................................ 80
FIGURA 41 – TELA DE LOGIN. ....................................................................................... 86
FIGURA 42 – TELA INICIAL DO SISTEMA. .................................................................. 87
FIGURA 43 – TELA INICIAL DO SISTEMA PARA BOMBEIRO COMUNITÁRIO. ..... 87
FIGURA 44 – TELA DE CONSULTA DE LOCAIS. ......................................................... 88
FIGURA 45 – TELA DE INCLUSÃO/ALTERAÇÃO DE LOCAL. ................................... 88
FIGURA 46 – TELA DE CONSULTA DE USUÁRIOS..................................................... 89
FIGURA 47 – TELA DE INCLUSÃO/ALTERAÇÃO DE USUÁRIO. .............................. 89
FIGURA 48 – TELA DE ALTERAÇÃO DO CADASTRO DO USUÁRIO LOGADO. ..... 90
FIGURA 49 – TELA DE ESCALA DE SERVIÇO PARA AGENDAMENTO. .................. 91
FIGURA 50 – TELA DE ESCALA DE SERVIÇO PARA CONFIRMAÇÃO DE
SERVIÇO............................................................................................................................91
FIGURA 51 – TELA DE CONFIRMAÇÃO DE SERVIÇO. .............................................. 92
FIGURA 52 – TELA DE ESCALA DE SERVIÇO APÓS CONFIRMAÇÃO DE
SERVIÇO.............................................................................................................................92
FIGURA 53 – TELA DE RELATÓRIOS DO SISTEMA.................................................... 93
FIGURA 54 –
TELA
DE
RELATÓRIO
DE
BOMBEIROS
COMUNITÁRIOS
CADASTRADOS. ............................................................................................................... 94
FIGURA 55 – TELA DE RELATÓRIO DE HORAS TRABALHADAS POR BC. ............ 95
LISTA DE QUADROS
QUADRO 1 – REGRAS DE NEGÓCIO DO SISTEMA. .................................................... 57
QUADRO 2 – CASO DE USO 1 - CADASTRO DE LOCAL............................................. 60
QUADRO 3 – CASO DE USO 2 - CADASTRO DE USUÁRIO. ....................................... 60
QUADRO 4 – CASO DE USO 3 - CADASTRO DE ESCALA. ......................................... 61
QUADRO 5 – CASO DE USO 4 - CONFIRMAÇÃO DE SERVIÇO. ................................ 62
QUADRO 6 – CASO DE USO 5 - GERAÇÃO DE RELATÓRIO DE BOMBEIROS
COMUNITÁRIOS CADASTRADOS. ................................................................................ 62
QUADRO 7 – CASO DE USO 6 - GERAÇÃO DE RELATÓRIO DE HORAS
TRABALHADAS POR BOMBEIRO COMUNITÁRIO. ..................................................... 63
LISTA DE SIGLAS
BBM – Batalhão de Bombeiro Militar
BC – Bombeiro Comunitário
CBMSC – Corpo de Bombeiros Militar de Santa Catarina
OBM – Organização de Bombeiro Militar
OMG - Object Management Group
OTM – Object Modeling Technique
PDF – Portable Document Format
TCC – Trabalho de Conclusão de Curso
UML – Unified Modeling Language
UNISUL – Universidade do Sul de Santa Catarina
XP – Extreme Programming
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 16
1.1 PROBLEMÁTICA ...................................................................................................... 17
1.2 OBJETIVOS ............................................................................................................... 17
1.2.1 Objetivo Geral ......................................................................................................... 18
1.2.2 Objetivos Específicos .............................................................................................. 18
1.3 JUSTIFICATIVA ........................................................................................................ 18
1.4 ESTRUTURA DA MONOGRAFIA ............................................................................ 19
2 CORPO DE BOMBEIROS DE SANTA CATARINA .................................................... 20
2.1 O CORPO DE BOMBEIROS MILITAR DE SANTA CATARINA ............................ 20
2.2 O SERVIÇO VOLUNTÁRIO NO CORPO DE BOMBEIROS MILITAR DE SANTA
CATARINA ........................................................................................................................ 21
2.2.1 Regulamento Geral ................................................................................................. 22
2.3 SISTEMAS PARA CONTROLE DE BOMBEIRO COMUNITÁRIO ......................... 23
2.4 CONSIDERAÇÕES FINAIS ....................................................................................... 24
3 DESENVOLVIMENTO DE SOFTWARE ..................................................................... 25
3.1 MODELOS DE DESENVOLVIMENTO DE SOFTWARE......................................... 25
3.2 METODOLOGIAS ÁGEIS ......................................................................................... 28
3.2.1 Modelo Extreme Programming (XP) ..................................................................... 30
3.2.2 Iconix ....................................................................................................................... 32
3.2.2.1 Etapas .................................................................................................................... 33
3.2.2.1.1 Etapa 1: identificar os objetos de domínio do mundo real .................................... 33
3.2.2.1.2 Etapa 2: definir os requisitos comportamentais ................................................... 33
3.2.2.1.3 Etapa 3: análise de robustez ................................................................................ 34
3.2.2.1.4 Etapa 4: alocar comportamento para os objetos .................................................. 35
3.2.2.1.5 Etapa 5: finalizar o modelo estático..................................................................... 36
3.2.2.1.6 Etapa 6: escrever / gerar código .......................................................................... 37
3.2.2.1.7 Etapa 7: executar o sistema e teste de aceitação do usuário ................................ 38
3.2.2.2 Características do ICONIX ..................................................................................... 38
3.3 UNIFIED MODELING LANGUAGE - UML ............................................................. 38
3.4 CONSIDERAÇÕES FINAIS ....................................................................................... 40
4 MÉTODO ...................................................................................................................... 42
4.1 CARACTERIZAÇÃO DA PESQUISA ....................................................................... 42
4.2 CLASSIFICAÇÃO ...................................................................................................... 42
4.3 PLANEJAMENTO ...................................................................................................... 43
4.4 ETAPAS METODOLÓGICAS ................................................................................... 44
4.5 PROPOSTA ................................................................................................................ 44
4.6 DELIMITAÇÕES........................................................................................................ 45
5 MODELAGEM .............................................................................................................. 46
5.1 ATORES ..................................................................................................................... 46
5.2 PROCESSOS DE NEGÓCIO ...................................................................................... 47
5.2.1 Modelagem do processo de negócio ........................................................................ 47
5.2.2 Diagrama do modelo de processo do negócio ......................................................... 49
5.2.3 Modelagem do processo de negócio com o sistema informatizado ........................ 50
5.2.4 Diagrama do modelo de processo com o sistema informatizado ........................... 52
5.3 REQUISITOS FUNCIONAIS ..................................................................................... 53
5.4 REQUISITOS NÃO FUNCIONAIS ............................................................................ 54
5.4.1 Requisitos de Produto ............................................................................................. 54
5.4.2 Requisitos Organizacionais..................................................................................... 55
5.4.3 Requisitos Externos................................................................................................. 55
5.5 REGRAS DE NEGÓCIO ............................................................................................ 55
5.6 CASOS DE USO ......................................................................................................... 58
5.6.1 Diagrama geral dos casos de uso ............................................................................ 58
5.6.2 – Descrição dos casos de uso ................................................................................... 59
5.6.2.1 Caso de Uso 1 - Cadastro de Local ......................................................................... 59
5.6.2.2 Caso de Uso 2 - Cadastro de Usuário ...................................................................... 60
5.6.2.3 Caso de Uso 3 - Cadastro de Escala ........................................................................ 61
5.6.2.4 Caso de Uso 4 - Confirmação de Serviço ................................................................ 61
5.6.2.5 Caso de Uso 5 - Geração de Relatório de Bombeiros Comunitarios Cadastrados. ... 62
5.6.2.6 Caso de Uso 6 - Geração de Relatório de Horas Trabalhadas por Bombeiro
Comunitário ......................................................................................................................... 63
5.7 MODELOS DE DOMÍNIO ......................................................................................... 63
5.7.1 Modelo de domínio para Cadastro de Local .......................................................... 64
5.7.2 Modelo de domínio para Cadastro de Usuário ...................................................... 64
5.7.3 Modelo de domínio para Cadastro de Escala......................................................... 65
5.7.4 Modelo de domínio para Confirmação de Serviço................................................. 66
5.8 DIAGRAMA DE CLASSES ....................................................................................... 66
5.8.1 Diagrama de Classes para Cadastros de Local ...................................................... 67
5.8.2 Diagrama de Classes para Cadastro de Usuário.................................................... 68
5.8.3 Diagrama de Classes para Cadastro de Escala ...................................................... 68
5.8.4 Diagrama de Classes para Geração de Relatórios ................................................. 69
5.9 DIAGRAMA DE ROBUSTEZ .................................................................................... 70
5.9.1 Diagrama de Robustez para Cadastro de Local .................................................... 70
5.9.2 Diagrama de Robustez para Cadastro de Usuários ............................................... 71
5.9.3 Diagrama de Robustez para Cadastro de Escalas ................................................. 71
5.9.4 Diagrama de Robustez para Geração de Relatórios .............................................. 72
5.9.5 Diagrama de Robustez para Confirmação de Serviço ........................................... 73
5.10 DIAGRAMA DE SEQUÊNCIA .................................................................................. 74
5.10.1 Diagrama de Sequência para Cadastro de Local ................................................... 74
5.10.2 Diagrama de Sequência para Cadastro de Usuário ............................................... 75
5.10.3 Diagrama de Sequência para Cadastro de Escala ................................................. 76
5.10.4 Diagrama de Sequência para Geração de Relatórios ............................................ 77
5.11 MODELAGEM DO BANCO DE DADOS DO SISTEMA .......................................... 78
5.12 CONSIDERAÇÕES FINAIS ....................................................................................... 79
6 DESENVOLVIMENTO................................................................................................. 80
6.1 FERRAMENTAS E TECNOLOGIAS......................................................................... 80
6.1.1 C# ............................................................................................................................. 81
6.1.2 Microsoft .NET........................................................................................................ 81
6.1.3 JavaScript................................................................................................................ 81
6.1.4 CSS .......................................................................................................................... 82
6.1.5 Microsoft SQL Server ............................................................................................. 82
6.1.6 Microsoft Visual Studio .......................................................................................... 83
6.1.7 Crystal Report ......................................................................................................... 83
6.1.8 Enterprise Architect................................................................................................ 84
6.2 HISTÓRICO DO DESENVOLVIMENTO .................................................................. 84
6.3 PROBLEMA E SOLUÇÕES ....................................................................................... 85
6.4 APRESENTAÇÃO DO SISTEMA .............................................................................. 86
6.5 VALIDAÇÃO E TESTES ........................................................................................... 95
6.6 CONSIDERAÇÕES FINAIS ....................................................................................... 96
7 CONCLUSÃO E TRABALHOS FUTUROS ................................................................. 97
7.1 ALCANÇANDO OS OBJETIVOS .............................................................................. 97
7.2 RESULTADOS ........................................................................................................... 98
7.3 TRABALHOS FUTUROS .......................................................................................... 98
REFERÊNCIAS ................................................................................................................ 100
16
1
INTRODUÇÃO
Percebe-se que, ao longo do tempo, vem aumentando o interesse das pessoas por
participar em algum tipo de serviço voluntário. No Brasil, o serviço voluntário foi
regulamentado através da Lei 9.608 de fevereiro de 1998, conhecida como “lei do
voluntariado”, (BRASIL, 1998). Nas conformidades do Artigo 1º desta Lei, considera-se
serviço voluntário a atividade não remunerada, prestada por pessoa física a Entidade Pública
de qualquer natureza ou Instituição Privada de fins não lucrativos, que tenha objetivos cívicos,
culturais, educacionais, científicos, recreativos ou de assistência social.
Entre as diversas instituições que oferecem um serviço voluntário, encontra-se o
Corpo de Bombeiros Militar de Santa Catarina – CMBSC. Dessa forma, é possível ser um
voluntário dessa entidade, tornando-se um Bombeiro Comunitário. O controle desses
voluntários é feito pelos Bombeiros Militares. Cada Organização de Bombeiro Militar –
OBM– possui sua coordenação, mas estas não possuem um sistema informatizado de controle
dos voluntariados.
A proposta do presente projeto é desenvolver um sistema web que auxilie os
Bombeiros Militares do Estado de Santa Catarina no controle de agendamento de escala de
serviços dos Bombeiros Comunitários, visando a melhorar esse gerenciamento que atualmente
é feito manualmente.
O sistema consiste basicamente de ferramentas de cadastro e gerenciamento de
usuários, horas trabalhadas e emissão de relatórios.
Para o desenvolvimento de sistemas informatizados é recomendável seguir um
modelo de processo de software (PRESSMAN, 2006).
Com o intuito de desenvolver um aplicativo segundo as diretrizes aprendidas no
curso de graduação, decidiu-se escolher o modelo ICONIX. Ele propõe uma modelagem
guiada pelos casos de uso, com a utilização de alguns dos diagramas da UML. Além disso, é
um modelo iterativo e incremental que propicia a rastreabilidade (ROSENBERG, 2005).
As características citadas, anteriormente, influenciaram a escolha dessa
metodologia.
17
1.1
PROBLEMÁTICA
O Corpo de Bombeiros Militar do Estado de Santa Catarina possui um projeto que
adere o serviço voluntário à corporação. Esse projeto é chamado de Bombeiro Comunitário.
Desde o seu início, não possui um sistema de informações acessível a todos os interessados. O
controle de escalas de serviços desses voluntários é realizado de forma manual em um livro de
escala. Com isso, percebeu-se a necessidade de agrupamento dessas informações em um único
sistema, que permita acesso de forma descentralizada.
A situação atual não satisfaz as necessidades dos Bombeiros Militares, fazendo
com que o gerenciamento dos dados seja feito manualmente em planilhas que não são
publicadas para todos os envolvidos, nem com versão consistente para os que as possuem.
Atualmente, não existe o compartilhamento das informações referentes aos
Bombeiros Comunitários entre cada OBM. A solução dos autores é elaborar um aplicativo no
qual todas as informações estarão disponíveis em um único local, que ficará acessível a todos
os interessados via web. Esse sistema possibilitará o controle sobre todos os Bombeiros
Comunitários cadastrados no Estado, permitindo a visualização das horas prestadas por cada
voluntário e emissão de relatórios. O aplicativo também poderá servir como um facilitador
para tomada de decisões estratégicas, como promoções de Bombeiros Comunitários.
Diante desse desafio, o presente estudo tem como objetivo responder a
problemática acima desenvolvendo um sistema web.
1.2
OBJETIVOS
A seguir, serão apresentados os objetivos do estudo que estão subdivididos em
geral e específicos.
18
1.2.1 Objetivo Geral
Desenvolver um sistema web que permita o gerenciamento centralizado da escala
de serviços e o controle das horas trabalhadas, bem como a administração dos Bombeiros
Comunitários de Santa Catarina.
1.2.2 Objetivos Específicos
a) Documentar os requisitos e regras de negócio dos processos envolvidos
utilizando a metodologia ICONIX;
b) desenvolver um aplicativo desde o levantamento de requisitos até a
implementação, congregando de forma prática o conhecimento adquirido nas
diversas disciplinas do curso de graduação.
1.3
JUSTIFICATIVA
O sistema web para cadastro de Bombeiros Comunitários foi escolhido visando a
utilizar o conhecimento adquirido ao longo do Curso de Sistemas de Informação – UNISUL.
Neste projeto, serão aplicadas diversas teorias e tecnologias aprendidas durante o curso de
graduação em suas diversas disciplinas. Assuntos referentes às metodologias ágeis serão
utilizados das aulas de engenharia de software, assim como a modelagem do sistema com
UML, segundo as boas práticas do ICONIX. Das aulas de banco de dados, será usado o
conhecimento para a criação de esquemas necessários para viabilizar o sistema. Integrando
com as aulas de modelagem de processos, será obtida uma boa estratégia para desenvolver um
sistema que atenda às necessidades administrativas dos Bombeiros Comunitários de Santa
Catarina.
19
Segundo o Regulamento Geral da entidade (SANTA CATARINA, 2011), o
serviço voluntário no CBMSC tem por fim fazer com que membros da comunidade tenham
condições de apoiar diretamente esse serviço público, oportunizando a formação de cultura
preventiva e reativa, aumentando a interação do CBMSC com a comunidade.
A criação de um sistema web para o controle das atividades administrativas visa a
uma melhora no desempenho das atividades administrativas e atividades descritas
anteriormente dos Bombeiros Comunitários, organizando e automatizando a manipulação dos
dados com muito mais segurança. Dessa forma, o sistema dará apoio a um serviço de grande
importância para a comunidade, do qual um dos autores é participante como Bombeiro
Comunitário.
1.4
ESTRUTURA DA MONOGRAFIA
Este trabalho está organizado como descrito a seguir.
Inicialmente, foi descrito o tema, objetivo geral e objetivos específicos seguidos
da justificativa.
Nos capítulos 2 e 3, é apresentada a revisão da literatura, abordando a
conceituação dos assuntos relacionados ao domínio do problema, baseados em uma revisão
bibliográfica sobre o Corpo de Bombeiros de Santa Catarina e sobre desenvolvimento de
software, com foco nas metodologias ágeis.
No capítulo 4, método, é apresentada a classificação do tipo de pesquisa realizada,
as atividades que compõem a proposta da solução e as delimitações do projeto.
No capítulo 5, é apresentado o processo administrativo e controle dos Bombeiros
Comunitários do Estado de Santa Catarina, seguido da modelagem do sistema.
No capítulo 6, é apresentado o desenvolvimento do sistema, as validações e
tecnologias utilizadas.
Para finalizar, o capítulo 7 descreve as conclusões e futuros desdobramentos deste
Trabalho de Conclusão de Curso.
20
2
CORPO DE BOMBEIROS DE SANTA CATARINA
Neste capítulo, é apresentada a história do Corpo de Bombeiros Militar do Estado
de Santa Catarina - CBMSC, sendo descrito também a origem e o funcionamento do serviço
voluntário dessa entidade.
2.1
O CORPO DE BOMBEIROS MILITAR DE SANTA CATARINA
Figura 1 – Logo do CBMSC.
Fonte: Santa Catarina, 2005.
De acordo com o artigo 108 da Constituição do Estado de Santa Catarina
(SANTA CATARINA, 1989), o Corpo de Bombeiros Militar é uma força auxiliar e reserva
do exército, estando subordinado ao governo do Estado e fazendo parte do Sistema Nacional
de Segurança Pública. Consequentemente, o Corpo de Bombeiros Militar deve seguir o
Regulamento Interno do Ministério do Exército (BRASIL, 1984).
Conforme o site do CBMSC (SANTA CATARINA, 2005), o Corpo de
Bombeiros de Santa Catarina surgiu no dia 26 de setembro de 1926 com a inauguração da
Seção de Bombeiros da Força Pública, denominado hoje como Corpo de Bombeiros Militar
de Santa Catarina. Até a data da Ementa Constitucional nº 33, em 13 de junho de 2003, ele foi
subordinado ao comando da Polícia Militar do Estado de Santa Catarina, tornando-se, após
essa data, uma organização independente. O CBMSC tem como visão prover e manter
21
serviços profissionais e humanitários que garantam a proteção da vida, do patrimônio e do
meio ambiente, visando a proporcionar qualidade de vida à sociedade.
Segundo Schmitt (2011), o Corpo de Bombeiros foi criado inicialmente para atuar
apenas na área de combate a incêndios, porém, com o passar do tempo, outras atividades
como resgate de pessoas e animais, auxílio em tragédias, trabalhos de prevenção, atividades
aquáticas, entre outras, foram agregadas.
2.2
O SERVIÇO VOLUNTÁRIO NO CORPO DE BOMBEIROS MILITAR DE SANTA
CATARINA
Conforme Masnik (2008), o serviço voluntário no Corpo de Bombeiros Militar foi
viabilizado através do Projeto Bombeiro Comunitário, sendo pioneiro no Estado de Santa
Catarina. No dia 18 de dezembro de 1996, a primeira Organização de Bombeiro Comunitário
foi implantada no Estado de Santa Catarina, mais precisamente na cidade de Ituporanga,
sendo composta por sete Bombeiros Militares e dezessete Bombeiros Comunitários.
Por ter atingido bons resultados nesse projeto inicial, a implantação dos
Bombeiros Comunitários foi estimulada em todas as regiões do Estado. O projeto foi tão bem
aceito, que, até março de 2008, mais de 70% dos municípios atendidos pelo serviço dos
Bombeiros Militares do Estado de Santa Catarina já possuíam o projeto implantado.
Por conta do sucesso, no Brasil, o projeto já é realidade em vários estados.
Atualmente, o CBMSC possui 12 Batalhões ativos, que abrangem os 293
municípios do Estado de Santa Catarina, no qual 96 possuem bases operacionais do CBMSC.
Desses, 93 municípios já possuem o projeto Bombeiro Comunitário implantado. Até o
momento, foram realizados 333 cursos, formando 9018 Bombeiros Comunitários no estado de
Santa Catarina.1
1
Tenente Anderson Medeiros Sarte, Coordenador dos Projetos Sociais do Corpo de Bombeiros Militar do
Estado de Santa Catarina. Comunicação oral em 15 de Junho de 2012.
22
2.2.1 Regulamento Geral
De acordo com o Regulamento Geral (SANTA CATARINA, 2011), artigo
sétimo, o prestador de serviço voluntário no CBMSC possui uma relação formal de voluntário
para com a corporação, nas conformidades da Lei Federal de número 9.608, sendo uma
atividade não remunerada, sem vínculo empregatício e isenta de qualquer obrigação
trabalhista, previdenciária ou afim (BRASIL, 1998).
O artigo terceiro do Regulamento Geral (SANTA CATARINA, 2011) define que
o serviço voluntário na corporação tem por fim propiciar a membros da comunidade a
condição de apoiarem diretamente o serviço exercido pela corporação, fazendo com que
membros da comunidade tenham conhecimentos básicos nas áreas de prevenção e reação em
casos de emergência, incêndios e acidentes diversos em que existam vítimas em situação de
perigo.
O serviço voluntário no CBMSC visa, através de cursos e treinamentos de
capacitação, a multiplicar os conhecimentos e cuidados básicos para membros da
comunidade, tornando menores os efeitos desastrosos de primeiros atendimentos realizados
por pessoas leigas.
Ao ingressar, como voluntário no CBMSC, todo Bombeiro Comunitário deve
afirmar que prestará o compromisso de honra, manifestando a sua disposição de cumprir seus
deveres e funções. O Bombeiro Comunitário irá atuar sempre em apoio aos Bombeiros
Militares, auxiliando às equipes de socorro à comunidade, realizando atendimentos
emergenciais e auxiliando em prevenções. (SANTA CATARINA, 2011).
Conforme descrito no Regulamento Geral (SANTA CATARINA, 2011), cada
OBM possui uma equipe de coordenação do Serviço Voluntário, sendo que o coordenador
será sempre um Bombeiro Militar da OBM. A coordenação deverá manter os Bombeiros
Comunitários sempre motivados, dando apoio logístico para a manutenção do serviço
voluntário, como na manutenção dos uniformes, equipamentos e os demais materiais
necessários, sendo também responsável por realizar o controle dos serviços prestados pelos
Bombeiros Comunitários, bem como o controle de requisitos regulamentares para levantar os
voluntários que estão aptos para promoção.
O Bombeiro Comunitário que deixar de cumprir os direitos e os deveres listados
no Regulamento Geral (SANTA CATARINA, 2011) responderá um processo administrativo,
23
tendo direito à defesa e ao contraditório, como previsto no Inciso LV do Artigo 5º da
Constituição Federal. Ao ser finalizado, o processo administrativo poderá resultar na
aplicação de sansões de advertência, suspensão temporária ou definitiva conforme Artigo 41
do Regulamento Geral (2011).
Por outro lado, os Bombeiros Comunitários que realizarem atos, ações ou
atividades de destaque terão sua conduta avaliada pela coordenação, podendo resultar em
referências elogiosas publicadas em boletim interno, condecoração, podendo até se tornar uma
promoção, desde que sejam satisfeitas as normas de promoção previstas no Regulamento
Geral. (SANTA CATARINA, 2011).
Cada Bombeiro Comunitário deve prestar, no mínimo, 24 horas por mês de
serviço voluntário, sendo que é possível requerer ao Coordenador do Serviço Voluntário, de
forma documental e justificada a redução das horas a serem cumpridas em até 50%. Ao estar
em dia com suas obrigações, o Bombeiro Comunitário terá direito de afastamento para
descanso com duração de 30 dias por ano, sendo dispensado da realização das funções de
Bombeiro Comunitário sem prejuízo da sua situação de ativo. A qualquer momento, o
Bombeiro Comunitário pode solicitar formalmente de forma escrita o seu afastamento, como
pode também ser excluído da corporação. Em ambos os casos, o indivíduo deixará de ser um
prestador de serviço voluntário no CBMSC, tornando-se um Bombeiro Comunitário
Certificado. Após a solicitação de afastamento, o Bombeiro Comunitário poderá ser
reintegrado, desde que não tenha passado um ano após a data da solicitação de afastamento,
sendo submetido a um estágio operacional. A exclusão se dará sempre que um Bombeiro
Comunitário deixar de cumprir suas obrigações por três meses consecutivos ou por seis meses
alternados, quando se candidatar a cargo eletivo e não se afastar a pedido no período de 180
dias antes do pleito eleitoral ou quando vier a ser condenado por crime de qualquer natureza
(SANTA CATARINA, 2011).
2.3
SISTEMAS PARA CONTROLE DE BOMBEIRO COMUNITÁRIO
Até o desenvolvimento deste projeto, não existiu um sistema de informação que
faça o mesmo ao sistema proposto.
24
2.4
CONSIDERAÇÕES FINAIS
Neste capítulo, foi exposto o que é o Corpo de Bombeiros, bem como seu
surgimento e a história do Corpo de Bombeiros Militar do Estado de Santa Catarina. Foi
apresentado o regulamento geral deste projeto que viabiliza o serviço voluntário no Corpo de
Bombeiros, sendo descrito como foram os primeiros passos do serviço voluntário no CBMSC.
25
3
DESENVOLVIMENTO DE SOFTWARE
Este capítulo apresenta uma revisão bibliográfica sobre o processo de
desenvolvimento de software e os seus modelos, com destaque para os modelos ágeis, a
metodologia ICONIX e a linguagem UML (Unifield Modeling Language). Os modelos
tradicionais podem ser também denominados de modelos prescritivos ou de modelos dirigidos
a planos. (SOMMERVILLE, 2011).
3.1
MODELOS DE DESENVOLVIMENTO DE SOFTWARE
Atualmente, os modelos de processo de desenvolvimento de software podem ser
classificados em modelos tradicionais e modelos ágeis. (PRESSMANN, 2006). Este trabalho
irá abordar algumas das mais conhecidas metodologias tradicionais e ágeis, como o modelo
cascata, incremental, evolucionário, espiral, XP e com maior ênfase no modelo ICONIX.
Existem as metodologias consideradas mais tradicionais. Entre elas, podem ser
mencionadas o modelo cascata, o incremental e o evolucionário. (SOMMERVILLE, 2011).
Segundo Pressman (2006), o modelo cascata tem um ciclo de vida único, definido
por cinco etapas, sendo que uma etapa só começa quando a anterior terminou.
A primeira etapa do modelo cascata é denominada de comunicação. É nessa etapa
que se dá inicio do projeto e é feito o levantamento de requisitos. A segunda etapa é o
planejamento, quando são feitas as estimativas de tempo, custo, cronogramas e se dá inicio ao
monitoramento do projeto. A terceira etapa é a modelagem, na qual é feita a análise do
projeto. Logo depois vem a construção, que é a parte de desenvolvimento de linhas de código
e testes. Por fim, a etapa de implantação, em que é feita a entrega e manutenção.
(PRESSMAN, 2006).
Conforme Pressman (2006), os documentos são gerados a cada etapa finalizada. O
modelo não é flexível para aceitar mudanças de requisitos quando o projeto já está em
andamento, sendo mais aconselhado para projetos em que todos os requisitos estão bem
definidos. A figura, a seguir, representa as cinco etapas desse modelo.
26
Figura 2 – Modelo cascata.
Fonte: Adaptado de PRESSMAN, 2006.
O modelo incremental é dividido em partes chamadas incrementos, que
correspondem a um conjunto de funcionalidades a ser implementadas, começando pela que
tem mais prioridade no projeto. Cada iteração gera um software funcional fazendo com que o
cliente possa usufruir do sistema, mesmo não estando completo. A figura, a seguir, mostra o
funcionamento do modelo incremental:
Figura 3 – Modelo incremental.
Fonte: adaptada de SOMMERVILLE, 2011.
27
O modelo evolucionário parte de uma versão inicial para mostrar ao usuário. São
feitas atualizações e melhorias nas próximas versões, partindo de novos requisitos levantados
com o cliente para gerar a versão final.
De acordo com Sommerville (2011), algumas práticas utilizadas no modelo
evolucionário são:
Prototipagem: o protótipo é feito para ajudar no processo de identificação dos
requisitos. O protótipo pode ser utilizado de duas formas:
• como desenvolvimento exploratório, que é o caso em que o cliente participa do
desenvolvimento e o protótipo é implementado e incorporado no sistema final;
• pode ser apenas um protótipo descartável, a fim de revelar alguns requisitos
que não foram identificados anteriormente.
Figura 4 – Prototipagem.
Fonte: adaptada de SOMMERVILLE, 2011.
Dentro do modelo evolucionário, ainda, existe o modelo espiral. É uma
combinação de prototipagem (iteração) com o modelo cascata. O projeto é desenvolvido
através de uma série de versões evolucionárias, utilizando protótipos com a finalidade de
identificar e reduzir os riscos, conforme afirma Pressman (2006).
28
Figura 5 – Modelo espiral.
Fonte: adaptada de SOMMERVILLE, 2011.
Esse modelo é iterativo e guiado pela monitoração dos riscos.
3.2
METODOLOGIAS ÁGEIS
Segundo Sommerville (2011), hoje em dia, a quantidade de informações e a
velocidade em que elas viajam pelo mundo fazem com que as empresas de software
necessitem de um ambiente muito mais flexível, que suporte o desenvolvimento de softwares
mais rapidamente a fim de obter proveito das novas oportunidades e responder às pressões
corporativas.
Utilizar as metodologias tradicionais para desenvolvimento de softwares que
sofrem constantes mudanças de requisitos ao longo do projeto torna-se muito demorado e o
projeto geralmente acaba perdendo seus prazos definidos no início. (SOMMERVILLE, 2011).
Foi justamente a partir da insatisfação dos métodos tradicionais que surgiu uma
proposta, na década de 1990, que abordava os conceitos dos métodos ágeis. Esse paradigma
29
se baseia em uma abordagem incremental para a especificação, o desenvolvimento e a entrega
do software. (SOMMERVILLE, 2011).
A filosofia dos métodos ágeis (AGILE MANIFESTO, 2001) é refletida no
manifesto ágil, que foi acordado por muitos dos principais desenvolvedores desses métodos.
Conforme o Agile Manifesto (2001), “estamos descobrindo melhores maneiras de
desenvolver softwares, fazendo-o e ajudando outros a fazê-lo”. Através desse trabalho, é
valorizado mais:
Figura 6 – Valorização segundo Agile Manifesto (2001).
Fonte: Autores, 2011.
Ou seja, os indivíduos e iterações são mais valorizados do que processos e
ferramentas. Software em funcionamento é mais valorizado do que documentação abrangente.
Colaboração do cliente é mais valorizada do que negociação de contrato, e respostas a
mudanças são mais valorizadas do que seguir um plano.
Sommerville (2011) diz que todos os métodos ágeis têm em comum a noção de
desenvolvimento e entrega incremental, porém as diferentes metodologias propõem diferentes
processos para alcançar tal objetivo. No entanto, todos compartilham um conjunto de
princípios que podem ser vistos na figura abaixo.
30
Figura 7 – Princípios dos métodos ágeis.
Fonte: adaptada de SOMMERVILLE, 2011.
3.2.1 Modelo Extreme Programming (XP)
O modelo Extreme Programming foi desenvolvido por Kent Beck e apresentado
na conferência internacional de orientação a objetos em 2000, foi uma metodologia bastante
controversa. O nome XP vem de eXtreme Programming.
Muitos dos profissionais gostaram e muitos foram contra. Como qualquer
metodologia, o XP não foi feito para atender todos os casos possíveis. Existem projetos nos
que o XP se encaixa melhor, assim como outros nos quais o uso do XP pode não ser o mais
apropriado. Por exemplo, para equipes muito grandes ou para projetos nos quais o cliente não
se dispõe a participar de forma mais ativa no desenvolvimento do projeto. (SOARES S,
2004).
31
Figura 8 – Ciclo Release XP.
Fonte: adaptada de SOMMERVILLE, 2011.
A Programação Extrema é embasada em doze práticas (KENT BECK 2006):
1 - PLANEJAMENTO – O cliente escreve histórias (user stories) sobre as
funcionalidades que o sistema deve ter. Os programadores interagem com o
cliente e discutem e experimentam diferentes tecnologias e arquiteturas para o
sistema, estabelecendo então as estimativas de prazo e prioridades de cada tarefa.
2 - FASES PEQUENAS – Cada fase é chamada de iteração e serve para
produzir um sistema simples e 100% funcional. Assim, mais versões funcionais
são liberadas em um curto período de tempo.
3 - METÁFORA – A equipe de programadores deve evitar termos técnicos ao
conversar com o cliente e estudar os termos específicos da área em que o sistema
será desenvolvido.
4 - DESIGN SIMPLES - O sistema deve ser projetado o mais simples possível.
Qualquer esforço extra, fora do escopo, deve ser eliminado.
5 - TESTES - os programadores escrevem continuamente os testes de unidade,
que devem funcionar como um guia para o desenvolvimento.
6 - REFATORAÇÃO – Melhorar o código fonte sem alterar as funcionalidades
do sistema.
7 - PROGRAMAÇÃO EM PARES – Dois programadores sentam juntos em
uma mesma máquina. Um digita e o outro presta atenção em erros e procura
maneiras de melhorar o código.
8 - PROPRIEDADE COLETIVA – O código pertence ao grupo de
programadores, que podem alterar o código a qualquer momento, rodando testes
para que não danifique nenhuma outra parte do sistema.
32
9 - INTEGRAÇÃO CONTÍNUA – Toda funcionalidade nova deve ser testada
antes de ser implementada, sem esquecer-se de avisar a alteração para todos os
atores envolvidos.
10 - SEMANA DE 40 HORAS – Programação é uma tarefa exaustiva. O tempo
máximo que um programador deve trabalhar são quarenta horas semanais, para
que os efeitos do cansaço não gerem erros no código.
11 - CLIENTE PRESENTE – O cliente deve estar presente e sempre disponível
para responder as perguntas dos desenvolvedores.
12 - PADRONIZAÇÃO DO CÓDIGO – os programadores escrevem todo o
código de acordo com as regras adotadas pelo grupo inteiro.
3.2.2 Iconix
Segundo Rosenberg, Stephens e Collins – Cope (2006) –, o ICONIX surgiu
alguns anos antes da Unified Modeling Language – UML – como uma síntese e destilação das
melhores técnicas das metodologias originais que formaram a UML: Object Modeling
Technique (OMT) de Jim Rumbaugh, Objectory Method de Ivar Jacobson e Booch Method de
Grandy Booch.
A mescla das diferentes técnicas foi feita, porque seus pontos fortes e fracos
pareciam se complementar. A OMT foi útil para modelagem do domínio do problema
(problem domain, no nível de análise), mas não era forte para a modelagem da solução
(Solution Space, ou design detalhado). Enquanto que o método de Booch era forte para o
design detalhado, mas não-intuitivo para o nível de análise.
Melhor que pegar o conjunto completo de três diferentes livros de quatrocentas
páginas de metodologias, abrangendo tudo sobre tudo, o ICONIX prefere focar-se no
subconjunto do núcleo das técnicas para remover as redundâncias e sobrepor-se às notações.
(ROSENBERG, STEPHENS E COLLINS-COPE, 2006, tradução nossa).
A seguir, apresentam-se as etapas do ICONIX conforme Doug Rosenberg, Matt
Stephens e Mike Collins - Cope (2006, tradução nossa).
33
3.2.2.1 Etapas
As sete fases principais que constituem a metodologia são descritas, a seguir,
conforme Rosenberg (2006).
3.2.2.1.1 Etapa 1: identificar os objetos de domínio do mundo real
A principal tarefa dessa etapa é identificar os objetos de domínio, como eles se
relacionam e começar a desenhar o diagrama de classe de alto nível. Nessa etapa, pode-se
também fazer um rápido protótipo do sistema para ajudar a organizar as finalidades do
sistema.
Provavelmente, a parte mais importante do projeto é a primeira etapa. É nela que
será estabelecida uma fundação sólida sobre a qual é construído todo o resto (requerimentos,
design, código, etc.) do projeto.
Ao finalizar essa etapa, dever-se-á ter um modelo de domínio o qual se apresenta
para todos os envolvidos no desenvolvimento uma documentação sobre os objetos do
domínio. O primeiro modelo criado nunca é perfeito. Continuará a crescer durante o
desenvolvimento do projeto, sendo melhorado conforme os problemas vão sendo entendidos e
as ambiguidades forem identificadas.
Existem algumas técnicas para identificar os objetos que devem fazer parte do
modelo de domínio. Uma delas é reunir todo material coletado e grifar os substantivos e
verbos, que, muito provavelmente, tornar-se-ão classes e atributos.
3.2.2.1.2 Etapa 2: definir os requisitos comportamentais
No ICONIX, os requisitos comportamentais são definidos pelos casos de uso,
partindo dos requerimentos de alto nível. Esses requisitos irão definir como o sistema irá se
34
comportar nos casos de interação com o usuário. Esse procedimento pode ser subdividido nos
seguintes passos:
Passo 1: identificar os casos de uso usando diagramas de caso;
Passo 2: organizar os casos de uso em grupos;
Passo 3: alocar requerimentos funcionais para os casos de uso e objetos de
domínio. Esse passo é opcional, para usá-lo, deve-se analisar a complexidade do projeto;
Passo 4: escrever descrição para os casos de uso.
O projetista sabe que terminou de modelar os casos de uso quando seus casos de
uso abrangem todas as funcionalidades do sistema desejado, e todos os casos de uso têm
descrições claras e coesas e cursos alternativos.
3.2.2.1.3 Etapa 3: análise de robustez
Essa etapa serve para identificar a ambiguidade dos casos de uso e identificar
falhas no modelo de domínio. É a última etapa de análise do projeto e consiste em realizar a
análise de robustez. A figura, a seguir, apresenta um exemplo desse tipo de diagrama.
Figura 9 – Diagrama de robustez.
Fonte: adaptada de ROSENBERG, 2006.
A análise de robustez envolve trabalhar com os textos dos casos de uso para
descobrir os objetos que não foram incluídos, e se há a necessidade de adicionar objetos.
35
A análise de robustez pode ser subdividida nos seguintes passos:
Passo 1: desenhar diagramas de robustez para cada caso de uso, que são:
a) identificar os objetos realizados no primeiro cenário utilizando estereótipos de
objetos da UML;
b) atualizar o diagrama de classe do modelo de domínio com os novos objetos e
atributos conforme forem descobertos;
c) atualizar e eliminar as ambiguidades dos textos dos casos de uso para que
entrem em conformidade com o diagrama de robustez.
Passo 2: finalizar a atualização do diagrama de classe para que reflita a fase de
análise do projeto.
Segundo Doug Rosenberg (2006), Ivar Jacobson introduziu o conceito de análise
de robustez para o mundo da orientação de objetos em 1991. Esse conceito envolve analisar a
descrição de cada caso de uso, identificar o primeiro conjunto de objetos e classificar os
objetos em três tipos:
a) objetos de limite (Boundary objects) que os atores usam para se comunicar
com o sistema;
b) objetos entidade (Entity objects) que geralmente são objetos do modelo de
domínio;
c) objetos de controle (Control objects), que servem de “cola” entre os objetos de
limite e objetos de entidade.
A figura, a seguir, exemplifica esses tipos de objetos.
Figura 10 – Objetos.
Fonte: adaptada de ROSENBERG, 2006.
3.2.2.1.4 Etapa 4: alocar comportamento para os objetos
36
Essa etapa é aquela na qual começa o design do projeto. É aqui que se começa a
fazer o diagrama de sequência, podendo ser utilizados também diagramas adicionais como
diagrama de estado, diagrama de atividade, conforme for a necessidade do projeto.
Esse passo é subdividido para cada caso de uso, como:
a) identificar a mensagem que precisa ser passada entre os objetos e os métodos
associados para serem invocados;
b) desenhar o diagrama de sequência com o texto do caso de uso no lado esquerdo
de baixo e a informação de design na direita;
c) continuar a atualizar os diagramas de classes com atributos e operações
conforme vão surgindo.
Todo diagrama de classe deverá ter operações alocadas, e cada caso de uso deverá
ter um diagrama de sequência. Na visão dos autores do modelo ICONIX (ROSENBERG,
2006), com a utilização da política de apenas dois parágrafos para o texto dos casos de uso, é
possível colocar tudo em um diagrama de sequência.
3.2.2.1.5 Etapa 5: finalizar o modelo estático
O modelo estático é feito de um ou mais diagramas de classe. O procedimento é
subdividido em dois passos:
Passo 1: adicionar informação detalhada de design (ex. valores de visibilidade e
padrões);
Passo 2: verificar com o time se o design satisfaz todos os requerimentos
identificados anteriormente.
A figura, na continuação, apresenta um exemplo de um diagrama de classe.
37
Figura 11 – Diagrama de classe.
Fonte: adaptada de ROSENBERG, 2006.
O modelo estático é uma versão mais detalhada do modelo de domínio e contém
mais detalhes de implementação.
3.2.2.1.6 Etapa 6: escrever / gerar código
Essa é a etapa em que os programadores, a partir do design, começam a escrever o
código. O ideal é que os programadores estejam presentes nas etapas de design para que
tenham uma melhor idéia da realidade em que o sistema será implementado.
Essa etapa pode ser subdividida em dois passos:
Passo 1: escrever / gerar o código;
Passo 2: executar o sistema e fazer testes de integração.
38
3.2.2.1.7 Etapa 7: executar o sistema e teste de aceitação do usuário
Nessa etapa, um grupo de pessoas que não sejam os programadores do aplicativo
executa o sistema e fazem o teste de aceitação do usuário, utilizando casos de uso como caixapreta.
3.2.2.2 Características do ICONIX
Borillo (2000) destaca três características fundamentais no ICONIX:
- iterativo e incremental: várias iterações ocorrem entre o desenvolvimento do
modelo de domínio e a identificação dos casos de uso;
- rastreabilidade: cada passo referencia para os requisitos de alguma forma. Dessa
forma, pode-se determinar qual impacto das alterações há em todo o projeto;
- aerodinâmica da UML: a metodologia oferece o uso “aerodinâmico” da UML
(OMG, 2001) como: os diagramas de casos de uso, diagramas de sequência e colaboração,
diagramas de robustez.
3.3
UNIFIED MODELING LANGUAGE - UML
A modelagem de software consiste em construir modelos gráficos que abrangem
suas exigências e requerimentos. Uma forma comum de modelagem é através da linguagem
unificada UML. (VARGAS, 2011).
A primeira versão da UML foi feita em 2004 e publicada pelo Object
Management Group – OMG – em 1997 com o nome de UML v1.1.
Conforme o website do OMG (2001), a Linguagem de Modelagem Unificada
ajuda a especificar, visualizar e documentar modelos de sistemas de software, incluindo sua
estrutura e design de uma maneira que atenda a todos os requerimentos. Usando a UML,
39
pode-se modelar praticamente qualquer tipo de aplicação, rodando em qualquer tipo de
hardware em qualquer sistema operacional.
Conforme GUEDES (2004), os diagramas da UML 2.0 são treze, que são
divididos em três categorias. Seis deles representam a estrutura estática da aplicação, três
representam tipos gerais de comportamentos e quatro representam diferentes aspectos de
interações, que são:
a) diagramas de estrutura incluem Diagrama de Classe, Diagrama de Objeto,
Diagrama de Componente, Diagrama de Estrutura Composta, Diagrama de
Pacotes e Diagrama de Implantação;
b) diagramas de comportamento incluem Diagrama de Caso de Uso, Diagrama de
Atividade e Diagrama de Estado da Máquina;
c) diagramas de interação incluem Diagrama de Comportamento, Diagrama de
Sequência, Diagrama de comunicação, Diagrama de Tempo e Diagrama de Visão
Geral de Interação.
A figura abaixo mostra a estrutura das categorias, utilizando a notação de
diagrama de classes.
Figura 12 – Organização Geral dos Diagramas de UML 2.
Fonte: Vargas, 2011.
Os diagramas estruturais tratam o aspecto estrutural tanto do ponto de vista do
sistema quanto das classes, conforme a especificação OMG (VARGAS, 2011).
40
Existem itens para representar abstrações como classes, interfaces, colaborações e
componentes os quais compõem as estruturas “relativamente estáveis” do sistema.
Figura 13 – Diagramas Estruturais.
Fonte: Vargas, 2011.
Os diagramas de comportamento, ilustrados na figura a seguir, descrevem a
modelagem dinâmica do sistema, ou seja, as partes que sofrem modificações mais constantes,
conforme a especificação OMG (VARGAS, 2011).
Figura 14 – Diagramas comportamentais.
Fonte: Vargas, 2011.
3.4
CONSIDERAÇÕES FINAIS
A engenharia de software é um processo muito importante na hora de se fazer um
projeto que resultará em um software. Mesmo não seguindo apenas uma das técnicas
41
existentes, o conhecimento delas proporciona um melhor entendimento dos processos que
envolvem o desenvolvimento, desde a parte de escolha de tecnologia até a preparação de
layout de telas.
A metodologia escolhida para este projeto foi o ICONIX, por isso ela foi descrita
com maior ênfase.
42
4
MÉTODO
Este capítulo apresenta aspectos acerca da metodologia utilizada no projeto.
4.1 CARACTERIZAÇÃO DA PESQUISA
Conforme Demo (1996), pesquisa é, de forma resumida, procurar respostas para
indagações propostas. Ele insere a pesquisa como atividade cotidiana considerando-a como
uma atitude, um “questionamento sistemático crítico e criativo, mais a intervenção
competente na realidade, ou o diálogo crítico permanente com a realidade em sentido teórico
e prático”.
Para Silva e Menezes (2001), pesquisa é um conjunto de ações, propostas para
encontrar a solução para um problema, que tem por base procedimentos racionais e
sistemáticos. A pesquisa é realizada quando se tem um problema e não se tem informações
para solucioná-lo.
4.2
CLASSIFICAÇÃO
A pesquisa pode ser dividida, segundo a classificação apresentada a seguir:
Conforme a sua natureza: Pode ser básica ou aplicada. A básica envolve interesses
universais, sem aplicação prática prevista. A aplicada envolve interesses locais, dirigida a
problemas específicos. (SILVA e MENEZES, 2001).
Esta pesquisa é classificada como aplicada, visto que está voltada ao
desenvolvimento de um sistema para sanar um problema específico do corpo de bombeiros.
Conforme a sua forma de abordagem, a classificação pode ser quantitativa ou
qualitativa. A classificação quantitativa considera tudo o que pode ser mensurado em
números. Envolve recursos estatísticos (percentagem, média, moda, mediana etc.). A
43
classificação qualitativa considera que há uma relação entre o mundo real e o sujeito, que não
pode ser traduzida em números, é descritiva. (SILVA e MENEZES, 2001).
Esta pesquisa está classificada como qualitativa, visto que o sistema desenvolvido
visa a melhorar a relação entre o mundo real e o sujeito, sendo que os dados utilizados pelos
bombeiros comunitários são a fonte de informação para resolver o problema específico de
administração.
Conforme seus objetivos, para Gil (2002), as pesquisas podem ser classificadas
em três grandes grupos:
a) pesquisa exploratória: visa a proporcionar maior familiaridade com o
problema. Assume, em geral, as formas de pesquisas bibliográficas e estudos de
casos;
b) pesquisa descritiva: assume, em geral, forma de levantamento. Utiliza técnicas
de coleta de dados, questionário e observação sistemática;
c) pesquisa explicativa: visa a identificar os fatores que determinam ou
contribuem para a ocorrência dos fenômenos. Aprofunda o conhecimento da
realidade, pois explica a razão, o “porquê” das coisas.
Esta pesquisa é classificada como pesquisa exploratória, pois faz referência a
artigos, a estudos e a livros referentes ao assunto abordado. E também será realizado um
estudo de caso sobre a gestão dos Bombeiros Comunitários.
4.3 PLANEJAMENTO
Para Silva e Menezes (2011), o planejamento de uma pesquisa se dá em três
etapas:
a) fase decisória: referente à escolha do tema, à definição e à delimitação do
problema de pesquisa;
b) fase construtiva: referente à construção de um plano de pesquisa e à execução
da pesquisa propriamente dita;
c) fase redacional: referente à analise de dados e a informações obtidas na fase
construtiva. É a organização das idéias visando à elaboração de um relatório final.
44
4.4 ETAPAS METODOLÓGICAS
As etapas deste trabalho são as seguintes:
a) revisão bibliográfica e estudo do ICONIX;
b) explanação sobre as leis, deveres e obrigações dos bombeiros comunitários de
Santa Catarina;
c) levantamento de requisitos, modelagem e implementação utilizando o
ICONIX;
d) validação e testes;
Estas etapas são apresentadas na forma de um fluxograma na figura a seguir:
Figura 15 – Fluxograma com as etapas metodológicas.
Fonte: Autores, 2011.
4.5 PROPOSTA
Este trabalho apresenta a proposta de desenvolver um sistema web para o corpo de
bombeiros Militar de Santa Catarina, visando a aplicar a tecnologia apropriada para melhorar
a administração dos bombeiros comunitários.
45
Figura 16 – Proposta do trabalho.
Fonte: Autores, 2011.
4.6
DELIMITAÇÕES
O produto deste trabalho tem a finalidade de auxiliar na administração interna do
Corpo de Bombeiros Militar de Santa Catarina, oferecendo transparência e facilidade de
acesso às informações dos Bombeiros Comunitários.
Como delimitações deste trabalho, podem ser destacadas as seguintes:
• o sistema será apenas um módulo administrativo, não possuindo acesso à
usuários externos;
• o foco deste trabalho não é o desenvolvimento e a criação de novas
tecnologias;
• não está contemplado o treinamento para os usuários do sistema.
46
5
MODELAGEM
Este capítulo descreve a modelagem do sistema.
5.1
ATORES
O ator representa os diferentes papéis que o usuário pode desempenhar no
sistema.
Seguindo a hierarquia do corpo de bombeiros, os atores podem ser: Administrador
do sistema, Administrador de local, sendo que os diferentes locais são: Batalhão, Companhia,
Pelotão ou Grupamento de Bombeiro Militar, Coordenador dos Bombeiros Comunitários,
Chefe de socorro e Bombeiro Comunitário.
A figura, a seguir, mostra os atores do sistema:
uc Actors
Administrador do
Sistema
Administrador de Local
Coordenador
Bombeiro Comunitario
Chefe de Socorro
Figura 17 – Atores do sistema.
Fonte: Autores, 2012.
O Administrador do Sistema é responsável por manter o sistema funcionando
corretamente. Deve ter um conhecimento médio em informárica, ser um Bombeiro Militar do
Estado de Santa Catarina e deve possuir acesso a todas as funcionalidades do sistema. A
frequência de uso do sistema é mensal.
O Administrador de Local é responsável pelo local em que se encontra cadastrado,
este pode apenas fazer a manutenção de usuários que estão cadastrados no seu mesmo local e
nos que estão hierarquicamente abaixo do seu. Este usuário serve para a situação em que o
Coordenador dos Bombeiros Comunitários do local seja alterado, também para caso exista a
necessidade de cadastrar/inativar um Chefe de socorro por qualquer motivo. Deve ser um
47
Bombeiro Militar e ter um conhecimento médio em informárica. A frequência de uso do
sistema é semanal.
O Coordenador é responsável por administrar os Bombeiros Comunitários
cadastrados para o seu local. Cabe a ele a verificação do cumprimento das regras que estão no
Regulamento Geral do Serviço Voluntário no Corpo de Bombeiros Militar de Santa Catarina.
Deve ter um conhecimento médio em informárica e ser um Bombeiro Militar do Estado de
Santa Catarina. A frequência de uso do sistema é semanal.
O Bombeiro Comunitário é o principal ator do sistema. Este é o usuário que
utilizará o sistema para efetuar seu agendamento na escala de serviço do local em que se
encontra cadastrado. Isto é, ele escolhe e agenda, através do sistema, os dias e horários nos
quais irá realizar o seu serviço. Deve ter um conhecimento médio em informárica. Este
usuário tem como seu grau de escolaridade, ensino médio ou superior. A frequência de uso do
sistema é semanal.
O Chefe de Socorro é responsável por concretizar o agendamento feito pelo
Bombeiro Comunitário. Deve ser um Bombeiro Militar, responsável pela Guarnição de
Serviço do dia, no local em que se encontra cadastrado. Ele pode apenas efetuar a
confirmação do horário agendado, quando já prestado o serviço pelo Bombeiro Comunitário.
Deve ter um conhecimento médio em informárica. A frequência de uso do sistema é diária.
5.2
PROCESSOS DE NEGÓCIO
A seguir, são descritos os processos de negócio atual e os processos de negócio do
novo sistema.
5.2.1 Modelagem do processo de negócio
Ao formar uma nova turma de Bombeiros Comunitários, a OBM encaminha ao
seu Batalhão todas as informações sobre cada novo BC. Com isso, no Batalhão – local onde
48
se concentram as informações de todos os BC de sua circunscrição – é solicitado à
Coordenadoria dos Projetos Sociais do CBMSC a numeração para a emissão do certificado do
BC. Cria-se então na Seção de Instrução, Ensino e Operações (B3) do respectivo Batalhão,
uma pasta contendo todas as informações do BC, bem como todas as documentações que
foram sendo geradas ao longo da sua permanência na OBM. Após a conclusão da escola que
formou o BC, o Comandante da OBM efetua a liberação do mesmo para que ele possa ser
escalado no serviço operacional da OBM.
Para efetuar serviço no CBMSC, o BC deve ir até a OBM em que está vinculado
ou ligar, para que a sargenteação – setor administrativo localizado em um quartel ou
organização militar – efetue o agendamento ou cancelamento do serviço. O agendamento ou
cancelamento do horário deve ser efetuado em até dois dias antes o dia do serviço. Esse
agendamento é feito provisoriamente em uma planilha pela sargenteação, sendo que esse
horário constará juntamente na escala da Guarnição de Serviço dos Bombeiros Militares que
estarão trabalhando no dia do serviço agendado. O Bombeiro Comunitário somente poderá
efetuar serviço, caso seu nome conste na escala de serviço do dia.
Após o Bombeiro Comunitário concluir o serviço agendado, o Chefe de Socorro –
Bombeiro Militar responsável pela Guarnição de Serviço do dia – confirma a presença do
Bombeiro Comunitário, e registra no livro de anotações do Chefe de Socorro, as possíveis
alterações.
Para requisitar informações sobre suas horas trabalhadas, o BC deve efetuar uma
solicitação na sua OBM. O BC não tem acesso fácil a essas informações, visto que as mesmas
são registradas nos livros de parte, preenchidos a cada serviço realizado, o que dificulta a
elaboração de relatórios contendo um espelho da quantidade de horas que cada BC realizou.
Para fazer um balanço dos Bombeiros Comunitários que estão ativos, e/ou quantas horas estão
sendo trabalhadas mensalmente por todos os BC, o comando geral do CBMSC deve solicitar
para cada OBM essas informações.
O processo aqui descrito pode ser visualizado na figura a seguir.
49
5.2.2 Diagrama do modelo de processo do negócio
act Modelo de Processo - Modelo Atual
Início
Escola de Formação
Formar nov a Turma
Bombeiro
Comunitário
Aprovado?
[não]
[sim]
Liberação para Agendar
Serv iço
«datastore»
Pasta de Dados do
Bombeiro Comunitário
«datastore»
Dados do Bombeiro
Comunitário
Dados Env iados ao
Batalhão
Agendar / Cancelar Serv iço
Data Maior
que 2 Dias?
Operação Não Permitida
[não]
[sim]
«datastore»
Planilha de
Agendamento
InserirDdados na Planilha
de Agendamento
Nome Consta na Planilha?
Efetuar Serv iço
[não]
[sim]
Bombeiro Comunitário
Liberado para Serv iço
Chefe de Socorro Confirma
Presença
Registro da Presença
«datastore»
Observ ações
Fim
Figura 18 – Diagrama do modelo de processo do negócio atual.
Fonte: Autores, 2012.
50
5.2.3 Modelagem do processo de negócio com o sistema informatizado
Ao formar uma nova turma de Bombeiros Comunitários, o Coordenador dos
Bombeiros Comunitários da OBM efetua o cadastro de cada novo BC da sua OBM. O
cadastro é feito como inativo, pois o BC somente poderá acessar o sistema quando ativo. A
partir desse momento, cada BC possui um login e senha de acesso ao sistema. Após a
conclusão da escola que formou o BC, o Comandante da OBM efetua a liberação dos BCs
para que ele possa efetuar serviço, com isso, o Coordenador dos BCs altera a situação dos
mesmos para ativo, onde, então, poderão acessar ao sistema para efetuar agendamento de
horário e gerar relatórios.
Para efetuar serviço no CBMSC, o BC deve acessar o sistema e efetuar o
agendamento em até dois dias antes do dia do serviço. Após o agendamento do horário, o
mesmo já é constado na escala de serviço, podendo, então, ser cancelado pelo BC em até dois
dias antes do horário do serviço. O sistema não permite o agendamento ou cancelamento do
horário depois de dois dias antes do horário do serviço.
Com a escala dos BCs pronta, a Sargenteação da OBM (São os usuários
Administrades do local) efetua a leitura dessa escala, e inclui os horários escalados na escala
da Guarnição de Serviço dos Bombeiros Militares que estarão trabalhando no dia do serviço
agendado. O Bombeiro Comunitário somente poderá efetuar serviço, caso seu nome conste na
escala de serviço do dia.
Após o Bombeiro Comunitário efetuar o serviço agendado, o Chefe de Socorro
deve acessar ao sistema e efetuar a confirmação do horário do Bombeiro Comunitário. Ao
confirmar o horário, o Chefe de Socorro irá colocar a nova situação do horário. A nova
situação do horário poderá ficar como “Compareceu”, “Compareceu com horário alterado” ou
“Não compareceu”. Quando a situação for “Compareceu”, o Chefe de Socorro pode informar
possíveis observações sobre o BC. Quando a situação for “Compareceu com horário
alterado”, deve ser informado o novo horário realizado, sendo preenchida a nova data e hora
de entrada e a nova data e hora de saída, sendo obrigatório o preenchimento de observações.
A situação do horário poderá ficar também como “Não compareceu”, nesse caso, o Chefe de
Socorro poderá incluir alguma observação, como, por exemplo: não compareceu por motivo
de doença.
51
Para acessar as informações sobre suas horas trabalhadas, o BC deve acessar o
sistema para emitir o relatório de suas horas trabalhadas. Para saber os Bombeiros
Comunitários que estão ativos, e/ou quantas horas estão sendo trabalhadas mensalmente por
cada BC, o Coordenador dos Bombeiros Comunitários, o Administrador da OBM ou o
Administrador do Sistema devem acessar ao sistema para emitir o relatório de Horas
Trabalhadas por BC.
A figura apresentada na continuação, descreve o processo apresentado com o
sistema proposto.
52
5.2.4 Diagrama do modelo de processo com o sistema informatizado
act Modelo de Processo - Modelo Nov o Sistema
Início
Escola de Formação
Formar Nov a Turma
«datastore»
Cadastro de Bombeiro
Comunitário Inativ o
Bombeiro
Comunitário
Aprovado?
Alteração Estado do
Bombeiro Comunitário
[sim]
[não]
«datastore»
Cadastro de Bombeiro
Comunitário Ativ o
Agendar / Cancelar
Serv iço
Cadastro de
Bombeiro
Comunitário
Ativo?
Data Maior que 2 Dias?
Operação Não Permitida
[não]
[sim]
[não]
[sim]
«datastore»
Escala de Serv iço
Bombeiro
Comunitário Consta
na Escala de
Serviço?
Incluir Horários
Escalados na Escala da
Guarnição de Serv iço dos
Bombeiros Comunitários
Efetuar Serv iço
Bombeiro Comunitário
Liberado para Serv iço
[sim]
Chefe de Socorro Confirma
Presença
Registro do
Comparecimento
«datastore»
Registro de não Comparecimento e
Observ ações
«datastore»
Registro do Comparecimento
«datastore»
Registro do Comparecimento com
Horário Alterado. Nov a Data e Hora de
Entrada e Saída
Fim
Figura 19 – Diagrama do modelo de processo do novo sistema.
Fonte: Autores, 2012.
53
5.3
REQUISITOS FUNCIONAIS
Para Bezerra (2002), requisitos funcionais dizem sobre a funcionalidade do
sistema.
A seguir, são apresentados os requisitos funcionais do sistema na figura 20:
req Requisitos Funcionais
RF 1 Cadastro de
local
RF 2 Cadastro de
Usuário
RF 3 Cadastro de
Escala
RF 4 Aprovação
de Serviço
RF 5 Relatórios
RF 6 O usuário
logado poderá
alterar
informações do
seu cadastro de
usuário.
Figura 20 – Requisitos funcionais do sistema.
Fonte: Autores, 2012.
A seguir, a descrição desses requisitos:
a) RF 1 - Cadastro de local: o administrador do sistema ou o administrador de
local poderão cadastrar/alterar locais, isto é, os diferentes Batalhões,
Companhias, Pelotões ou Grupamentos;
b) RF 2 - Cadastro de usuário: o administrador do sistema ou o coordenador do
grupamento poderão cadastrar bombeiros comunitários;
c) RF 3 - Cadastro de escala: o administrador do sistema, o coordenador do
grupamento ou o bombeiro comunitário poderão cadastrar as escalas, ou seja,
realizar o agendamento do serviço de um Bombeiro Comunitário para algum
horário;
d) RF 4 - Aprovação de serviço: o usuário Chefe de Socorro poderá realizar a
confirmacão de servico com o status de “compareceu”, “compareceu com o
horário alterado” e “não compareceu”;
e) RF 5 – Relatórios: o administrador do sistema, o administrador do local, o
coordenador dos Bombeiros Comunitários e o Bombeiro Comunitário poderão
gerar relatório de horas trabalhadas por BC e de Bombeiros Comunitários
Cadastrados.
54
f) RF 6 – Meu cadastro: o usuário logado poderá alterar informações do seu
cadastro de usuário.
5.4
REQUISITOS NÃO FUNCIONAIS
“Os requisitos não funcionais, como o nome sugere, são aqueles que não dizem
respeito diretamente às funções específicas fornecidas pelo sistema”. (SOMMERVILLE,
2003). Eles podem ser classificados em três grandes grupos: requisitos de produto, requisitos
organizacionais e requisitos externos.
Bezerra (2002) adiciona, também, que os requisitos não funcionais declaram as
características de qualidade que o sistema deve possuir e que estão relacionadas às suas
funcionalidades.
As subseções seguintes apresentam os requisitos não funcionais do sistema.
5.4.1 Requisitos de Produto
Descrição dos requisitos não funcionais de produto:
a) RNF 01: portabilidade: o sistema deve funcionar nos browsers mais utilizados;
b) RNF 02: confiabilidade: o sistema não permitirá a entrada de dados não
consistentes;
c) RNF 03: usabilidade: padronização das interfaces para facilitar na usabilidade
do sistema.
55
5.4.2 Requisitos Organizacionais
a) RNF 04: Será utilizada a linguagem .NET. (versão Framework 4.0);
b) RNF 05: O sistema gerenciador de Banco de Dados será o SQL Server 2008
(versão 10.50.1617.0);
c) RNF 06: O pacote de programa de desenvolvimento de software será o
Microsoft Visual Studio 2010 Professional (versão 10.0).
5.4.3 Requisitos Externos
a) RN7: segurança: o usuário deverá estar logado no sistema para que possa
utilizar o sistema.
5.5
REGRAS DE NEGÓCIO
Uma regra de negócio é uma declaração que define ou restringe algum aspecto do
negócio. Destina-se a afirmar estrutura do negócio ou controlar ou influenciar o
comportamento do negócio. As regras de negócio que abrange o escopo do projeto são
atômicas - isto é, elas não podem ser subdivididos. (BRG, 2012).
Bezerra (2002) diz que as regras de negócio são documentadas no chamado
modelo de regra de negócio. Nesse modelo, as regras são categorizadas. Cada regra
normalmente recebe um identificador que permite que a regra seja facilmente referenciada
nos demais artefatos do processo de desenvolvimento.
No quadro a seguir, são apresentadas as regras de negócio.
56
RN01
RN02
RN03
RN04
RN05
RN06
RN07
RN08
RN09
RN10
RN11
RN12
RN13
RN14
RN15
RN16
RN17
RN18
RN19
RN20
RN21
RN22
RN23
RN24
RN25
RN26
RN27
RN28
Regras de negócio do Sistema
Sem estar logado, ao acessar qualquer tela interna pela URL, não permitir o acesso e
redirecionar para a tela de login.
O usuário deve estar logado no sistema para ter acesso às funcionalidades.
Ao acessar a tela de login, colocar o foco no campo login.
Na tela de login, ao apertar a tecla <enter>, simular um clique no botão acessar.
O sistema permite logar apenas usuários ativos.
O usuário Administrador do sistema deve ter todas as permissões durante a
utilização do sistema.
O sistema deve exibir apenas funções compatíveis com o tipo do usuário que está
logado.
Campos de preenchimento obrigatório devem ter a sua descrição em vermelho.
Campos de preenchimento de CPF devem conter máscara ao colocar o foco.
Campos de preenchimento de data devem conter máscara ao colocar o foco.
Campos de preenchimento de telefone devem conter máscara ao colocar o foco.
Campos de e-mail devem validar se o valor informado é um e-mail válido.
Campos de CPF devem validar se o valor informado é um CPF válido.
Campos de data devem validar se o valor informado é uma data válida.
Regras de negócio do Cadastro de Usuários
No menu “Meu cadastro”, somente permitir alterar os dados do endereço, nome, email, CPF, data de nascimento, telefone e senha.
Ao incluir um novo usuário, o sistema deve validar se o campo “Login” já existe
com aquele que foi preenchido.
O campo “Login” não deve permitir espaços.
Após a inclusão de um usuário, a informação do campo “Login” não pode mais ser
alterada.
O campo “Senha” deverá ser obrigatório apenas no cadastro de um novo usuário.
O campo “Senha” deve ser informado pelo usuário 2 vezes, e validado pelo sistema
quando o cadastro for salvo.
O campo “Data de cadastro” deve ser exibido somente na alteração de usuário. Na
inclusão do usuário o campo fica oculto e deve salvar na base de dados a data do
momento da inclusão do usuário.
O campo “Tipo”, seguindo a hierarquia dos atores, deve listar apenas tipos de
usuários que estão abaixo do tipo do usuário que está efetuando o cadastro, isto é,
logado.
O campo “Graduação” deve ser exibido somente quando o “Tipo” selecionado for
“Bombeiro Comunitário”.
Só é possível excluir usuários que não possuem nenhum agendamento em escala.
Regras de negócio do Cadastro de Locais
Quando um local for do tipo “Batalhão”, não se informa o “Local pai”.
Quando um local for do tipo diferente de “Batalhão”, deve ser informado o “Local
pai”.
No campo “Local pai” devem ser disponibilizados apenas os locais que são do tipo
acima hierarquicamente do “Tipo” selecionado.
Um local pode permitir o agendamento de BC´s ou não. Caso o local permita o
agendamento, deve ser informado quantos BC´s podem estar de serviço
simultaneamente.
57
RN29
RN30
RN31
RN32
RN33
RN34
RN35
RN36
RN37
RN38
RN39
RN40
RN41
RN42
RN43
RN44
RN45
RN46
RN47
RN48
RN49
Um local pode estar ativo ou inativo.
O campo “Data de cadastro” deve ser exibido somente na alteração de um local. Na
inclusão, o campo fica oculto e deve salvar na base de dados a data do momento da
inclusão do local.
Não é possível excluir um local quando o mesmo estiver sendo utilizado para algum
agendamento de escala, ou quando tiver algum usuário cadastrado para o local.
Regras de negócio da Escala
Um agendamento somente é feito quando a data do serviço a ser prestado for maior
que dois dias da data atual.
No agendamento, o sistema só permite a data de saída, maior que a data de entrada.
O sistema só permite agendamento de serviço na escala quando o usuário for um BC
ativo, Administrador do Local, Administrador do sistema ou Coordenador.
O sistema somente permite agendar escalas para usuários do tipo Bombeiro
Comunitário que estão na situação ativo.
Somente administrador e coordenador podem agendar horário para outro usuário,
desde que o agendamento seja para mesmo local do usuário logado.
Um BC pode ser agendado somente no local em que está cadastrado.
O sistema deve permitir agendamento de serviço somente em locais que permitem
escala.
Ao carregar a escala de serviço, deve aparecer a escala do dia atual, para o local do
usuário logado.
O sistema permitirá fazer pesquisa de escala por ano, mês e dia.
Somente o administrador do sistema, administrador de local e coordenador poderão
filtrar a escala por diferentes usuários.
Regras de negócio de Confirmação do Serviço
Apenas usuário “Chefe de socorro” pode efetuar a confirmação de serviço,
informando o comparecimento ou não do Bombeiro Comunitário agendado na
escala.
Ao efetuar a confirmação do serviço, o usuário deve incluir uma observação sobre o
serviço prestado.
Ao efetuar a confirmação do serviço, o usuário deve informar a nova situação do
horário agendado para “compareceu”, “compareceu com o horário alterado” e “não
compareceu” do Bombeiro Comunitário.
Quando a nova situação for “compareceu com horário alterado”, deve ser informada
data e hora de entrada e saída do período realizado.
Um horário já confirmado não pode mais ser alterado.
Na pesquisa de escala, caso o horário já tenha sido confirmado com a situação
“compareceu com horário alterado”, o sistema deve mostrar a data de entrada e
saida e também a observação dada em um tooltip na imagem na coluna situação.
Regras dos Relatórios
O relatório de Bombeiro Comunitário disponibilizará filtro de local, cidade e
situação do bombeiro comunitário.
O relatório de horas por bombeiro comunitário disponibilizará filtro de local, ano,
mês e bombeiro comunitário.
Quadro 1 – Regras de negócio do sistema.
Fonte: Autores, 2012.
58
5.6
CASOS DE USO
De acordo com Object Management Group (2011), os casos de uso são um meio
para especificar os usos necessários de um sistema. Normalmente, são usados para capturar os
requisitos de um sistema, isto é, o que um sistema é suposto fazer.
A seguir, são apresentados os casos de uso referentes ao sistema, iniciando com o
diagrama geral.
5.6.1 Diagrama geral dos casos de uso
A figura, a seguir, apresenta o diagrama geral de casos de uso.
59
uc Use Case Model
CSU 1 - Cadastro de
Local
Administrador do
Sistema
Relatorios
CSU 5 - Geração de
Relatório de Bombeiros
Comunitários
Cadastrados
Administrador de Local
CSU 2 - Cadastro de
Usuário
CSU 6 - Geração de Relatório de
Horas Trabalhadas por Bombeiro
Comunitário
Coordenador
CSU 3 - Cadastro de
escala
Bombeiro Comunitario
CSU 4 - Confirmação
de Serv iço
Chefe de
Socorro
Figura 21 – Casos de uso do sistema.
Fonte: Autores, 2012.
5.6.2 – Descrição dos casos de uso
A seguir, pode-se destacar a descrição de cada caso de uso.
5.6.2.1 Caso de Uso 1 - Cadastro de Local
Inicialmente, na continuação, pode ser verificada a descrição do caso de uso referente ao
cadastro de local.
60
Caso de uso 1: Cadastro de Local
Descrição: Este caso de uso descreve a realização do cadastro de um local no sistema.
Ator: Gestor do sistema.
Pré-condições:
1. O gestor do sistema deve estar logado no sistema.
2. O gestor do sistema deverá ter permissão para esta funcionalidade do sistema.
Fluxo de eventos:
1. O gestor do sistema informa ao sistema os dados necessários para a realização do cadastro
do local.
2. O gestor do sistema envia solicitação de cadastro.
3. O sistema realiza as validações necessárias.
4. O sistema retorna uma mensagem “Cadastro efetuado com sucesso.”.
Fluxo alternativo:
Caso o gestor do sistema não tenha preenchido os campos obrigatórios, o sistema retorna uma
mensagem “Favor preencher todos os campos.”.
Quadro 2 – Caso de uso 1 - Cadastro de Local.
Fonte: Autores, 2012.
5.6.2.2 Caso de Uso 2 - Cadastro de Usuário
Na continuação, pode-se observar a descrição do caso de uso referente ao cadastro de usuário.
Caso de uso 2: Cadastro de Usuário
Descrição: Este caso de uso descreve a realização do cadastro de um usuário no sistema.
Ator: Gestor do sistema, administrador do local, coordenador.
Pré-condições:
1. O gestor do sistema, administrador do local ou coordenador deve estar logado no sistema;
2. O gestor do sistema, administrador do local ou coordenador deverá ter permissão para esta
funcionalidade do sistema.
Fluxo de eventos:
1. O gestor do sistema, administrador do local ou coordenador informa ao sistema os dados
necessários para o cadastro do usuário.
2. O gestor do sistema, administrador do local ou coordenador envia solicitação de cadastro.
3. O sistema realiza as validações necessárias.
4. O sistema retorna uma mensagem “Cadastro efetuado com sucesso.”.
Fluxo alternativo:
Caso o gestor do sistema, administrador do local ou coordenador não tenha preenchido os
campos obrigatórios, o sistema retorna uma mensagem “Favor preencher todos os campos.”.
Quadro 3 – Caso de uso 2 - Cadastro de Usuário.
Fonte: Autores, 2012.
61
5.6.2.3 Caso de Uso 3 - Cadastro de Escala
No quadro a seguir, pode-se observar a descrição do caso de uso referente ao cadastro de
escala.
Caso de uso 3: Cadastro de Escala
Descrição: Este caso de uso descreve a realização do cadastro dos horários de trabalho para
um oficial dos bombeiros comunitários no sistema.
Ator: Gestor do sistema, administrador do local.
Pré-condições:
1. O gestor do sistema ou o administrador do local deve estar logado no sistema.
2. O gestor do sistema ou o administrador do local deverá ter permissão para esta
funcionalidade do sistema.
Fluxo de eventos:
1. O gestor do sistema ou o administrador do local informa ao sistema os dados necessários
doados pelo comandante do pelotão dos bombeiros comunitários.
2. O gestor do sistema ou o administrador do local envia solicitação de cadastro.
3. O sistema realiza as validações necessárias.
4. O sistema retorna uma mensagem “Cadastro efetuado com sucesso.”.
Fluxo alternativo:
Caso o gestor do sistema ou o administrador do local não tenha preenchido os campos
obrigatórios, o sistema retorna uma mensagem “Favor preencher todos os campos.”.
Quadro 4 – Caso de uso 3 - Cadastro de Escala.
Fonte: Autores, 2012.
5.6.2.4 Caso de Uso 4 - Confirmação de Serviço
A seguir, pode ser verificada a descrição do caso de uso referente à confirmação de serviço,
realizada pelo usuário chefe de socorro.
Caso de uso 4: Confirmação de Serviço
Descrição: Este caso de uso descreve o procedimento de confirmação de serviço que o chefe
de socorro realiza na escala do dia.
Ator: Chefe de Socorro.
Pré-condições:
1. O usuário deve estar logado no sistema.
2. O usuário deverá ter permissão para esta funcionalidade do sistema.
Fluxo de eventos:
1. O usuário seleciona as escalas a serem confirmadas.
2. O usuário envia a solicitação das escalas.
3. O sistema exibe as escalas selecionadas.
4. O usuário altera o status das escalas selecionadas.
62
5. O usuário salva as informações.
6. O sistema exibe mensagem “Deseja realmente salvar? As informações não poderão mais
ser alteradas.”.
6. Se o usuário confirmar a mensagem anterior, o sistema retorna uma memsagem “Operação
realizada com sucesso.”.
Fluxo alternativo:
Caso o usuário não altere alguma escala selecionada, o sistema retorna uma mensagem “Favor
alterar os dados das escalas escolhidas.”.
Quadro 5 – Caso de uso 4 - Confirmação de Serviço.
Fonte: Autores, 2012.
5.6.2.5 Caso de Uso 5 - Geração de Relatório de Bombeiros Comunitarios Cadastrados.
Na continuação, pode ser verificada a descrição do caso de uso referente à geração de
relatório.
Caso de uso 5: Geração de Relatório de Bombeiros Comunitarios Cadastrados
Descrição: Este caso de uso descreve a geração de relatórios dos bombeiros comunitários
cadastrados no sistema, exibindo seu local de trabalho, cidade e situação.
Ator: Gestor do sistema, comandante do batalhão dos bombeiros comunitários, comandante
da companhia dos bombeiros comunitários, comandante do pelotão dos bombeiros
comunitários, comandante do grupamento dos bombeiros comunitários e bombeiro
comunitário.
Pré-condições:
1. O usuário deve estar logado no sistema.
2. O usuário deverá ter permissão para esta funcionalidade do sistema.
Fluxo de eventos:
1. O usuário filtra os dados necessários para solicitar a geração do relatório.
2. O usuário envia a solicitação do relatório.
3. O sistema realiza os filtros necessários.
4. O sistema disponibiliza um link onde é possível salvar o relatório no formato Portable
Document Format - PDF.
Fluxo alternativo:
Caso não existma dados cadastrados para o filtro solicitado, o sistema retorna uma mensagem
“Nenhum registro encontrado.”.
Quadro 6 – Caso de uso 5 - Geração de Relatório de Bombeiros Comunitários Cadastrados.
Fonte: Autores, 2012.
63
5.6.2.6 Caso de Uso 6 - Geração de Relatório de Horas Trabalhadas por Bombeiro
Comunitário
A seguir, pode-se observar a descrição do caso de uso referente à geração de relatório.
Caso de uso 6: Geração de Relatório de Horas Trabalhadas por Bombeiro Comunitário
Descrição: Este caso de uso descreve a geração de relatórios das escalas cumpridas pelos
Bombeiros Comunitários, exibindo local, ano, mês e bombeiro Comunitário.
Ator: Gestor do sistema, comandante do batalhão dos bombeiros comunitários, comandante
da companhia dos bombeiros comunitários, comandante do pelotão dos bombeiros
comunitários, comandante do grupamento dos bombeiros comunitários e bombeiro
comunitário.
Pré-condições:
1. O usuário deve estar logado no sistema.
2. O usuário deverá ter permissão para esta funcionalidade do sistema.
Fluxo de eventos:
1. O usuário filtra os dados necessários para solicitar a geração do relatório.
2. O usuário envia a solicitação do relatório.
3. O sistema realiza os filtros necessários.
4. O sistema disponibiliza um link onde é possível salvar o relatório no formato PDF.
Fluxo alternativo:
Caso não existam dados cadastrados para o filtro solicitado, o sistema retorna uma mensagem
“Nenhum registro encontrado.”.
Quadro 7 – Caso de uso 6 - Geração de Relatório de Horas Trabalhadas por Bombeiro Comunitário.
Fonte: Autores, 2012.
5.7
MODELOS DE DOMÍNIO
Para OMG (2011b), o modelo de domínio explica a relação entre ocorrências e
comportamentos.
A seguir, são apresentados os modelos de domínio referentes ao sistema.
64
5.7.1 Modelo de domínio para Cadastro de Local
Na figura 22 a seguir, pode-se observar a figura do modelo de domínio para
Cadastro de Local.
class Modeo de Dominio - Cadastro de Local
Corpo_de_Bombeiros
Administrador_do_Sistema
Local
Usuario
Administrador_de_Local
Cadastro_de_Local
Figura 22 – Modelo de domínio para Cadastro de Local.
Fonte: Autores, 2012.
5.7.2 Modelo de domínio para Cadastro de Usuário
Na continuação, pode-se verificar a figura do modelo de domínio para Cadastro de
Usuário.
65
class Modeo de Dominio - Cadastro de Usuário
Corpo_de_Bombeiros
Administrador_do_Sistema
Local
Usuario
Administrador_de_Local
Coordenador
Cadastro_de_Usuario
Figura 23 – Modelo de domínio para Cadastro de Usuário.
Fonte: Autores, 2012.
5.7.3 Modelo de domínio para Cadastro de Escala
Na figura 24, pode-se observar o modelo de domínio para Cadastro de Escala.
class Modeo de Dominio - Cadastro de Escala
Corpo_de_Bombeiros
Administrador_do_Sistema
Local
Usuario
Cadastro_de_Escala
Figura 24 – Modelo de domínio para Cadastro de Escala.
Fonte: Autores, 2012.
Coordenador
Administrador_de_Local
Bombeiro_Comunitario
66
5.7.4 Modelo de domínio para Confirmação de Serviço
A seguir, encontra-se a figura do modelo de domínio para Confirmação de
Serviço.
class Modeo de Dominio - Confirmação de Serv iço
Corpo_de_Bombeiro
Chefe_de_Socorro
Local
Usuario
Confirmacao_de_Serv ico
Figura 25 – Modelo de domínio para Confirmação de Serviço.
Fonte: Autores, 2012.
5.8
DIAGRAMA DE CLASSES
O diagrama de classe é um modelo lógico do sistema. As classes geralmente têm
relação direta com o código-fonte ou artefatos de outros softwares que podem ser agrupados
em componentes executáveis (OMG, 2001).
A seguir, são apresentados os diagramas de classes do sistema.
67
5.8.1 Diagrama de Classes para Cadastros de Local
A figura a seguir faz a representação das classes presentes no cadastro de local.
class Diagrama de Classes - Cadastro de Local
GestorDoSistema
AdministradorDeLocal
-
sNmGuerra: char
nNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
+
+
GestorDoSistema() : void
Finalize() : void
+
+
AdministradorDeLocal() : void
Finalize() : void
Batalhao
+
+
Batalhao() : void
Finalize() : void
+
+
Companhia() : void
Finalize() : void
Usuario
usa
-
nCdCidade: int
nCdGraduacao: int
nCdLocal: int
nCdSituacao: int
nCdUsuarioTipo: int
nNrLogradouro: int
sCdUsuario: char
sDsEmail: char
sDsSenha: char
sNmBairro: char
sNmGuerra: char
sNmLogradouro: char
sNmUsuario: char
sNrCPF: int
sNrMatricula: int
sNrTelefone: int
sNrTelefoneSecundario: int
tDtCadastro: date
tDtFormatura: date
tDtNascimento: date
+
+
Usuario() : void
Finalize() : void
Companhia
Local
-
nCdLocal: int
+
+
Local() : void
Finalize() : void
CorpoDeBombeiros
+
+
Pelotao
+
+
Pelotao() : void
Finalize() : void
CadastroLocal
«interface»
CadastroLocal
+
IncluirDados() : void
Validar
-
Mensagem: char
+
+
Validar() : void
Finalize() : void
executa
-
bFlPermiteEscala: boolean
nCdCidade: int
nCdLocal: int
nCdLocalPai: int
nCdLocalTipo: int
nCdSituacao: int
nNrLogradouro: int
nQtComunitariosSimultaneos: int
sNmBairro: char
sNmLocal: char
sNmLogradouro: char
sNrTelefone: char
sSgLocal: char
tDtCadstro: date
+
+
CadastroLocal() : void
Finalize() : void
Figura 26 – Diagrama de Classes para Cadastro de Local.
Fonte: Autores, 2012.
Grupamento
+
+
Grupamento() : void
Finalize() : void
CorpoDeBombeiros() : void
Finalize() : void
68
5.8.2 Diagrama de Classes para Cadastro de Usuário
A figura, na continuação, faz a representação das classes presentes no cadastro de
usuários.
class Diagrama de Classes - Cadastro de Usuário
GestorDoSistema
AdministradorDeLocal
Batalhao
Coordenador
-
sNmGuerra: char
nNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
+
+
GestorDoSistema() : void
Finalize() : void
+
+
AdministradorDeLocal() : void
Finalize() : void
+
+
Coordenador() : void
Finalize() : void
+
+
Batalhao() : void
Finalize() : void
+
+
Companhia() : void
Finalize() : void
Companhia
Usuario
usa
-
sNmGuerra: char
sNrMatricula: int
+
+
Usuario() : void
Finalize() : void
Local
-
nCdLocal: int
+
+
Local() : void
Finalize() : void
CorpoDeBombeiros
+
+
CorpoDeBombeiros() : void
Finalize() : void
Pelotao
executa
«interface»
CadastroUsuario
+
IncluirDados() : void
Validar
-
Mensagem: char
+
+
Validar() : void
Finalize() : void
+
+
CadastroUsuario
-
nCdCidade: int
nCdGraduacao: int
nCdLocal: int
nCdSituacao: int
nCdUsuarioTipo: int
nNrLogradouro: int
sCdUsuario: char
sDsEmail: char
sDsSenha: char
sNmBairro: char
sNmGuerra: char
sNmLogradouro: char
sNmUsuario: char
sNrCPF: char
sNrMatricula: char
sNrTelefone: char
sNrTelefoneSecundario: char
tDtCadastro: date
tDtFormatura: date
tDtNascimento: date
+
+
CadastroUsuario() : void
Finalize() : void
Pelotao() : void
Finalize() : void
Grupamento
+
+
Grupamento() : void
Finalize() : void
Figura 27 – Diagrama de Classes para Cadastro de Usuário.
Fonte: Autores, 2012.
5.8.3 Diagrama de Classes para Cadastro de Escala
A figura, a seguir, descreve as classes presentes no cadastro de escala.
69
class Diagrama de Classes - Cadastro de Escala
GestorDoSistema
AdministradorDeLocal
Coordenador
Batalhao
BombeiroComunitario
-
sNmGuerra: char
nNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
+
+
GestorDoSistema() : void
Finalize() : void
+
+
AdministradorDeLocal() : void
Finalize() : void
+
+
Coordenador() : void
Finalize() : void
+
+
BombeiroComunitario() : void
Finalize() : void
+
+
Batalhao() : void
Finalize() : void
+
+
Companhia() : void
Finalize() : void
Companhia
Usuario
-
usa
Local
sNm Guerra: char
sNrMatricula: int
+
+
Usuario() : void
Finalize() : void
-
nCdLocal: int
+
+
Local() : void
Finalize() : void
CorpoDeBombeiros
+
+
CorpoDeBombeiros() : void
Finalize() : void
Pelotao
CadastroEscala
executa
«interface»
CadastroEscala
+
IncluirDados() : void
-
nCdEscala: int
nCdEscalaSituacao: int
nCdLocal: int
sCdUsuario: char
sCdUsuarioAgendado: char
sCdUsuarioalteracao: int
sDsObservacao: char
tDtAgendamento: date
tDtAlteracao: boolean
tDtEntrada: date
tDtEntradaRealizada: date
tDtSaida: date
tDtSaidaRealizada: int
+
+
CadastroEscala() : void
Finalize() : void
+
+
Pelotao() : void
Finalize() : void
Grupamento
+
+
Grupamento() : void
Finalize() : void
Validar
-
M ensagem: char
+
+
Validar() : void
Finalize() : void
Figura 28 – Diagrama de Classes para Cadastro de Escala.
Fonte: Autores, 2012.
5.8.4 Diagrama de Classes para Geração de Relatórios
A figura, na continuação, representa as classes presentes na geração de relatórios.
class Diagrama de Classes - Cadastro de Escala
GestorDoSistema
AdministradorDeLocal
Coordenador
Batalhao
BombeiroComunitario
-
sNmGuerra: char
nNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
-
sNmGuerra: char
sNrMatricula: int
+
+
GestorDoSistema() : void
Finalize() : void
+
+
AdministradorDeLocal() : void
Finalize() : void
+
+
Coordenador() : void
Finalize() : void
+
+
BombeiroComunitario() : void
Finalize() : void
+
+
Batalhao() : void
Finalize() : void
+
+
Companhia() : void
Finalize() : void
Companhia
Usuario
-
usa
+
+
Local
sNm Guerra: char
sNrMatricula: int
Usuario() : void
Finalize() : void
-
nCdLocal: int
+
+
Local() : void
Finalize() : void
CorpoDeBombeiros
+
+
Pelotao
«interface»
GeracaoDeRelatorio
+
IncluirDados() : void
executa
GeracaoDeRelatorio
+
+
+
+
GeracaoDeRelatorio() : void
Finalize() : void
Pelotao() : void
Finalize() : void
Grupamento
Validar
-
Mensagem: char
+
+
Validar() : void
Finalize() : void
Figura 29 – Diagrama de Classes para Geração de Relatórios.
Fonte: Autores, 2012.
+
+
Grupamento() : void
Finalize() : void
CorpoDeBombeiros() : void
Finalize() : void
70
5.9
DIAGRAMA DE ROBUSTEZ
Um diagrama de robustez é uma imagem objeto de um caso de uso. O diagrama
de robustez e o texto do caso de uso tem que corresponder com precisão, de modo que o
diagrama de robustez obriga a amarrar o texto do caso de uso aos objetos (ROSENBERG,
STEPHENS, 2007).
A seguir, são representados os diagramas de robustez do sistema.
5.9.1 Diagrama de Robustez para Cadastro de Local
Na figura a seguir, representa-se o diagrama de robustez referente ao cadastro de
local.
obj ect Diagrama de Robustez - Cadastro de Local
Solicitar Cadastro de Local
interface de Cadastro
de Local
Administrdor de
Local
Local Cadastrado
Validar Dados
Cadastrar Local
<<erro>>
Mensagem de Erro
Mensagem de Erro
Figura 30 – Diagrama de robustez para Cadastro de Local.
Fonte: Autores, 2012.
Validar Dados
71
5.9.2 Diagrama de Robustez para Cadastro de Usuários
Na figura, a seguir, descreve-se o diagrama de robustez referente ao cadastro de
usuários.
obj ect Diagrama de Robustez - Cadastro de Usuário
Solicitar Cadastro de Usuário
Interface de Cadastro
de Usuário
Administrador do
Sistema
Usuário Cadastrado
Validar Dados
Cadastrar Usuário
<<erro>>
Mensagem de Erro
Mensagem de Erro
Validar Dados
Figura 31 – Diagrama de robustez para Cadastro de Usuário.
Fonte: Autores, 2012.
5.9.3 Diagrama de Robustez para Cadastro de Escalas
Na figura, a seguir, o diagrama de robustez referente ao cadastro de escalas.
72
obj ect Diagrama de Robustez - Cadastro de Escalas
Solicitar Cadastro de Escala
Interface de Cadastro
de Escalas
Administrador do
Sistema
Escala Cadastrada
Validar Dados
Cadastrar Escala
<<erro>>
Mensagem de Erro
Mensagem de Erro
Validar Dados
Figura 32 – Diagrama de robustez para Cadastro de Escalas.
Fonte: Autores, 2012.
5.9.4 Diagrama de Robustez para Geração de Relatórios
Na figura, a seguir, apresenta-se o diagrama de robustez referente à geração de
relatórios.
73
obj ect Diagrama de Robustez - Geração de Relatórios
Solicitar Geração de Relatório
Interface de
Solicitação de
Relatório
Administrador do
Sistema
Relatório Gerado
Validar Dados
Gerar Relatório
<<erro>>
Mensagem de Erro
Mensagem de Erro
Validar Dados
Figura 33 – Diagrama de robustez para Geração de Relatórios.
Fonte: Autores, 2012.
5.9.5 Diagrama de Robustez para Confirmação de Serviço
Na figura, a seguir, representa-se o diagrama de robustez referente à confirmação
de serviço.
obj ect Diagrama de Robustez - Cnfirmação de Serv iço
Solicitar Confirmação de Serviço
Interface de
Confirmação de
Serviço
Chefe de Socorro
Serviço Confirmado
Validar Dados
Confirmar Serviço
<<erro>>
Mensagem de Erro
Mensagem de Erro
Figura 34 – Diagrama de robustez para Confirmação de Serviço.
Fonte: Autores, 2012.
Validar Dados
74
5.10 DIAGRAMA DE SEQUÊNCIA
O diagrama de sequência tem a ênfase na ordem temporal das mensagens trocadas
entre os objetos (BEZERRA, 2002).
A seguir, são apresentados os diagramas de sequência do sistema.
5.10.1 Diagrama de Sequência para Cadastro de Local
O diagrama de sequência referente ao cadastro de local é apresentado na figura a
seguir.
75
sd Diagrama de Sequencia - Cadastro de Local
Usuário com Permissão
1. Usuário
com
Permissão
abre
Interface de
Cadastro de
Local()
Interface de
Cadastro de Local
Mensagem
Validar
Local Cadastrado
2.
Cadastra
Dados do
Local()
3. Mostra
dados na
Interface()
4. Usuário com
Permissão envia
os Dados
Cadastrados()
5. Dados salvos
com sucesso no
Banco de Dados()
6.
Cadastrar
Local no
Sistema()
7. Dados
Cadastrados()
8. Mensagem
de Cadastro
Realizado
com Sucesso()
9. Retorna a
Tela de Locais()
Figura 35 – Diagrama de Sequência para Cadastro de Local.
Fonte: Autores, 2012.
5.10.2 Diagrama de Sequência para Cadastro de Usuário
O diagrama de sequência relacionado ao cadastro de usuário é apresentado na
figura a seguir.
76
sd Diagrama de Sequencia - Cadastro de Usuário
Usuário com Permissão
Interface de
Cadastro de
Usuário
Mensagem
1. Usuário com
Permissão abre
Interface de
Cadastro de
Usuário()
3. Mostra
Dados na
Interface()
Validar
Usuário
Cadastrado
2.
Cadastra
Dados do
Usuário()
4. Usuário com
Permissão
envia Dados
Cadastrados()
5. Dados Salvos
com sucesso no
Banco de Dados()
6. Cadastrar
Usuário no
Sistema()
7. Dados
Cadastrados()
8. Mensagem
de Cadastro
Realizado com
Sucesso()
9. Retorna a
Tela de
Cadastro()
Figura 36 – Diagrama de Sequência para Cadastro de Usuário.
Fonte: Autores, 2012.
5.10.3 Diagrama de Sequência para Cadastro de Escala
O diagrama de sequência do cadastro de escala encontra-se na figura a seguir.
77
sd Diagrama de Sequencia - Cadastro de Escala
Usuário com Permissão
Interface de
Cadastro de Escala
Mensagem
1. Usuário com
Permissão Abre
Interface de
Cadastro de Escala()
Validar
Escala Cadastrada
2. Cadastra Dados
de Escala()
3. Mostra
dados na
Interface()
4. Usuário com Permissão
Envia Dados Cadastrados()
5. dados salvos com
sucesso no Banco de
Dados()
6. Cadastrar
Escala no
Sistema()
7. Dados
Cadastrados()
8. Mensagem Dados
Cadastrados com
Sucesso()
9. Retorna
a Tela de
Escalas()
Figura 37 – Diagrama de Sequência para Cadastro de Escala.
Fonte: Autores, 2012.
5.10.4 Diagrama de Sequência para Geração de Relatórios
O diagrama de sequência referente à geração de relatórios é apresentado na figura
a seguir.
78
sd Diagrama de Sequencia - Geração de Relatórios
Usuário com Permissão
Interface de
Geração de
Relatório
Mensagem
Validar
Relatório Gerado
1. Usuário com
Permissão abre Interface
de Geração de Relatório()
2. Informa Dados Filtrados()
3. Gera Relatório()
4. Exibe Relatório na
Interface de Relatório()
Figura 38 – Diagrama de Sequência para Geração de Relatórios.
Fonte: Autores, 2012.
5.11 MODELAGEM DO BANCO DE DADOS DO SISTEMA
A seguir, é apresentada a figura 39 que representa a estrutura do banco de dados
do sistema.
79
dm Modelagem do banco de dados
USUARIO_SITUACAO
«column»
*PK nCdSituacao: numeric
*
sNmSituacao: varchar
sDsImagem: varchar
«PK»
+
PK_USUARIO_SITUACAO(numeric)
USUARIO_TIPO
«column»
*PK nCdUsuarioTipo: numeric
sDsUsuarioTipo: varchar
sSgUsuarioTipo: varchar
«PK»
+
PK_USUARIO_TIPO(numeric)
USUARIO_GRADUACAO
«column»
*PK nCdGraduacao: numeric
*
sNmGraduacao: varchar
sDsImagem: varchar
nCdUsuarioTipo: numeric
«PK»
+
PK_USUARIO_GRADUACAO(numeric)
USUARIO
«column»
*PK sCdUsuario: varchar
sNrMatricula: varchar
sNmUsuario: varchar
sNmGuerra: varchar
sNrCPF: varchar
tDtNascimento: datetime
tDtFormatura: datetime
tDtCadastro: datetime
*FK nCdSituacao: numeric
*FK nCdUsuarioTipo: numeric
FK nCdGraduacao: numeric
*FK nCdLocal: numeric
*
sDsSenha: varchar
sNmLogradouro: varchar
nNrLogradouro: numeric
sNmBairro: varchar
FK nCdCidade: numeric
sNrTelefone: varchar
sNrTelefoneSecundario: varchar
sDsEmail: varchar
«PK»
+
PK_USUARIO(varchar)
PERMISSAO
PERFIL_PERMISSAO
«column»
*FK nCdPerfil: numeric
*FK nCdPermissao: numeric
«column»
*PK nCdPermissao: numeric
*
sNmPermissao: varchar
«FK»
+
FK_PERFIL_PERMISSAO_PERFIL(numeric)
+
FK_PERFIL_PERMISSAO_PERMISSAO(numeric)
«PK»
+
PK_PERMISSAO(numeric)
PERMISSAO_FUNCIONALIDADE
«column»
*FK nCdPermissao: numeric
*FK nCdFuncionalidade: numeric
PERFIL
«column»
*PK nCdPerfil: numeric
*
sNmPerfil: varchar
«FK»
+
FK_PERMISSAO_FUNCIONALIDADE_FUNCIONALIDADE(numeric)
+
FK_PERMISSAO_FUNCIONALIDADE_PERMISSAO(numeric)
«PK»
+
PK_PERFIL(numeric)
«FK»
+
FK_USUARIO_CIDADE(numeric)
+
FK_USUARIO_LOCAL(numeric)
+
FK_USUARIO_USUARIO_GRADUACAO(numeric)
+
FK_USUARIO_USUARIO_SITUACAO(numeric)
+
FK_USUARIO_USUARIO_TIPO(numeric)
FUNCIONALIDADE
CIDADE
USUARIO_PERFIL
«column»
*PK nCdCidade: numeric
*
sNmCidade: varchar
*
sCdEstado: varchar
«column»
*FK sCdUsuario: varchar
*FK nCdPerfil: numeric
(nCdLocalPai
= nCdLocal)
«PK»
+
PK_CIDADE(numeric)
«FK»
+
FK_USUARIO_PERFIL_PERFIL(numeric)
+
FK_USUARIO_PERFIL_USUARIO(varchar)
«column»
*PK nCdFuncionalidade: numeric
*
sDsFuncionalidade: varchar
*
nCdModulo: numeric
«PK»
+
PK_FUNCIONALIDADE(numeric)
(nCdMenuPai
= nCdMenu)
LOCAL
LOCAL_TIPO
«column»
*PK nCdLocalTipo: numeric
*
sDsLocalTipo: varchar
nCdLocalTipoPai: numeric
«PK»
+
PK_LOCAL_TIPO(numeric)
LOCAL_SITUACAO
«column»
*PK nCdSituacao: numeric
*
sDsSituacao: varchar
«column»
*PK nCdLocal: numeric
FK nCdLocalPai: numeric
*FK nCdLocalTipo: numeric
*
sNmLocal: varchar
*
sSgLocal: varchar
*
sNmLogradouro: varchar
*
nNrLogradouro: numeric
*
sNmBairro: varchar
*FK nCdCidade: numeric
sNrTelefone: numeric
*
bFlPermiteEscala: numeric
nQtComunitariosSimultaneos: numeric
*
tDtCadastro: datetime
*FK nCdSituacao: numeric
«PK»
+
PK_LOCAL(numeric)
«FK»
+
FK_LOCAL_CIDADE(numeric)
+
FK_LOCAL_LOCALPAI(numeric)
+
FK_LOCAL_LOCAL_SITUACAO(numeric)
+
FK_LOCAL_LOCAL_TIPO(numeric)
«PK»
+
PK_LOCAL_SITUACAO(numeric)
ESCALA
«column»
*PK nCdEscala: numeric
*FK nCdEscalaSituacao: numeric
*FK sCdUsuario: varchar
*FK sCdUsuarioAgendamento: varchar
*FK nCdLocal: numeric
*
tDtAgendamento: datetime
tDtEntrada: datetime
tDtSaida: datetime
FK sCdUsuarioAlteracao: varchar
tDtAlteracao: datetime
tDtEntradaRealizada: datetime
tDtSaidaRealizada: datetime
sDsObservacao: varchar
«PK»
+
PK_ESCALA(numeric)
«FK»
+
FK_ESCALA_ESCALA_SITUACAO(numeric)
+
FK_ESCALA_LOCAL(numeric)
+
FK_ESCALA_USUARIO(varchar)
+
FK_ESCALA_USUARIO1(varchar)
+
FK_ESCALA_USUARIO2(varchar)
MENU
«column»
*PK nCdMenu: numeric
FK nCdMenuPai: numeric
FK nCdFuncionalidade: numeric
*
sDsMenu: varchar
sDsArquivoPagina: varchar
*
bFlVisivel: numeric
«PK»
+
PK_MENU(numeric)
«FK»
+
FK_MENU_FUNCIONALIDADE(numeric)
+
FK_MENU_MENU(numeric)
ESCALA_SITUACAO
«column»
*PK nCdEscalaSituacao: numeric
*
sDsEscalaSituacao: varchar
«PK»
+
PK_ESCALA_SITUACAO(numeric)
Figura 39 – Modelagem do banco de dados.
Fonte: Autores, 2012.
5.12 CONSIDERAÇÕES FINAIS
Este capítulo apresentou a modelagem do sistema para agendamento de escalas
dos Bombeiros Comunitários de Santa Catarina. Os diagramas apresentados, de caso de uso,
sequência, robustez, de classe e banco de dados, assim como a descrição dos requisitos
funcionais, não funcionais e regras de negócios, foram de vital importância para o bom
entendimento das necessidades que deveriam ser atendidas pelo sistema a ser implementado.
80
6
DESENVOLVIMENTO
Este capítulo apresenta as ferramentas, tecnologias utilizadas e o sistema
desenvolvido.
6.1
FERRAMENTAS E TECNOLOGIAS
A seguir, são destacadas as ferramentas e tecnologias utilizadas no
desenvolvimento do sistema.
Figura 40 – Tecnologias utilizadas.
Fonte: Autores, 2012.
81
6.1.1 C#
Segundo Microsoft (2012b), o C# é uma linguagem orientada a objetos que
permite aos desenvolvedores criarem uma variedade de aplicativos seguros e robustos que são
executados no .NET Framework. Considerada uma linguagem elegante, fortemente tipada e
de compatibilidade com o Microsoft Visual Studio, foi a escolhida para o desenvolvimento
desse projeto.
6.1.2 Microsoft .NET
Conforme Microsoft (2012b), o Microsoft .NET, conhecido como .NET
Framework, é um componente do Sistema Operacional Windows que inclui um sistema de
execução virtual juntamente com um conjunto unificado de biblioteca de classes. Permite a
construção e desenvolvimento de aplicações web de forma integrada e unificada, capaz de
executar mais de 33 diferentes linguagens de programação. A versão atual deste Framework é
a 4, versão escolhida para o desenvolvimento deste projeto.
6.1.3 JavaScript
Para JavaScript Passo a Passo Lite (2001), JavaScript é uma linguagem de script
que se aloja dentro de um programa HTML. É necessário um browser para executar um
JavaScript, que é uma linguagem interpretada, com base em objetos, o que significa que o
programador pode usar objetos predefinidos ou criar novos objetos de acordo com sua
necessidade.
O autor também afirma que o código-fonte da linguagem JavaScript é um tipo de
hóspede dentro de um programa HTML. No mesmo arquivo em que estão os comandos
82
básicos de HMTL, o código JavaScript é inserido de maneira a ser interpretado quando a
página é carregada ou quando o usuário realiza alguma operação.
O JavaScript foi escolhido para fazer parte do projeto por se apresentar uma ótima
ferramenta, com bastante referência para pesquisa e muito popular em projetos web.
6.1.4 CSS
Denominadas folhas de estilo em cascata, a ideia por trás do CSS é fornecer o
grau de controle de projeto oferecida por numerosas extenxões da HTML, aumentar um
pouco mais o controle do projeto e separá-lo da HTML em si, conforme Lemay. (1998).
Para Lemay (1998), o conceito de estilo é muito simples. Primeiramente, as regras
de estilo definem o layout, a tipografia e os recursos de projeto de um documento, separados
da definição da estrutura do documento. Assim, a estrutura de um documento é definida
através da utilização da HTML padrão.
O CSS permite que o estilo das várias páginas seja alterado sem que precise ser
feita a alteração manual em cada uma delas.
As folhas de estilo em cascata foram adotadas no trabalho por antecipar a
mudança de layout que ocorre durante o projeto a fim de atender os padrões de boas práticas e
o gosto do usuário final do sistema.
6.1.5 Microsoft SQL Server
Segundo a Microsoft (2012c), o Microsoft SQL Server é o serviço principal para
armazenamento, processamento e segurança de dados. O Mecanismo de Banco de Dados
fornece acesso controlado e processamento rápido de transações para atender aos requisitos
dos aplicativos de consumo de dados mais exigentes.
83
Os altos níveis de disponibilidade, segurança, rapidez e a garantia de uma visão
geral dos dados do sistema, juntamente com a compatibilidade com a linguagem .NET, foram
essenciais na escolha do Miscosoft SQL Server 2008 para fazer parte deste projeto.
6.1.6 Microsoft Visual Studio
Conforme Microsoft (2012a), o Microsoft Visual Studio é um pacote de
programas para desenvolvimento de software dedicado ao .NET Framework e às linguagens
Visual Basic – VB, C, C++, C# e J#. Voltado para aplicações Windows Forms e Web, foi o
escolhido para o desenvolvimento deste projeto, juntamente com a linguagem de
desenvolvimento C#. O escolhido para o desenvolvimento deste projeto foi o Microsoft
Visual Studio 2010.
6.1.7 Crystal Report
O software Crystal Repost é uma ferramenta que permite a criação de relatórios,
pertencente à SAP BusinessObjects. Os desenvolvedores podem criar e integrar relatórios a
suas aplicações .NET sem sair do ambiente de desenvolvimento do Visual Studio.
A facilidade de se conectar a praticamente qualquer fonte de dados e a poderosa
combinação de dados que o software proporciona, foi à chave na escolha deste produto para
fazer parte deste projeto. Com ele foi possível criar relatórios com aparência profissional,
integrando-o com o aplicativo de desenvolvimento .NET.
84
6.1.8 Enterprise Architect
O Enterprise Architect (EA) é uma ferramenta de modelagem desenvolvida pela
Sparx System. O software permite a criação de diagramas, modelos e classes de forma visual
que facilitam no entendimento do sistema modelado utilizando a motodologia ICONIX.
O Enterprise Architect foi escolhido para este projeto por fazer parte do
aprendizado das aulas
A versão utilizada para este projeto foi a 7.5.845 versão para uso de teste de 30
dias. O download pode ser feito em http://sparxsystem.com.
6.2
HISTÓRICO DO DESENVOLVIMENTO
A seguir, apresenta-se uma descrição do histórico do desenvolvimento do sistema.
Primeiramente, identificou-se um problema que poderia ser resolvido por meio do
conhecimento que vinha sendo adquirido no curso de graduação da faculdade. O aluno Thiago
Thiesen de Souza é Bombeiro Comunitário e sentiu a necessidade de melhorar a forma em
que os processos de controle dos Bombeiros Comunitários, e a maneira em que o
agendamento de serviço era efetuado, dessa forma, pensou-se em alguma estratégia que
permitisse melhorar essas condições de controle. Foi decidido, então, que o sistema seria feito
para agilizar esse processo, e juntamente com o aluno Matheus Ribeiro Melim, deu-se início a
uma jornada que resultaria em um Sistema de Cadastro e Controle das Horas Trabalhadas dos
Bombeiros Comunitários do Estado de Santa Catarina.
Depois de apresentados os objetivos e as justificativas no capítulo 1, foi feito um
levantamento das leis e regulamentos que regem o comportamento dos Bombeiros
Comunitários em Santa Catarina apresentados no capítulo 2. Essa revisão da literatura teve
como base a constituição brasileira, o regulamento interno e dos serviços gerais do exército
brasileiro, e artigos encontrados na internet. Ela serviu para fazer um apanhado das
informações que poderiam ser valiosas para ajudar no desenvolvimento do sistema proposto.
Inicialmente, foram apresentadas algumas metodologias de desenvolvimento de
software ágeis existentes juntamente com suas características, qualidades e a justificativa para
85
a escolha do ICONIX para este projeto. Encontrou-se bastante material sobre as
metodologias, e isso guiou a escolha, de forma clara, para que se pudesse aplicar de forma
correta o ICONIX no processo de desenvolvimento. A metodologia foi adaptada para melhor
atender a execução deste projeto. Adotaram-se as melhores práticas e aderiram-se algumas
práticas de outras metodologias que deram resultados melhores para os objetivos, como
exemplo, foi utilizado uma caracteristica do XP, citada no capítulo 3, a qual se refere à
realização de pequenas fases, denominadas iterações para produzir um sistema simples e
100% funcional conforme novas versões funcionais são adicionadas. Essa é uma
característica, também, encontrada no modelo incremental. Esse uso integrado das
metodologias permitiu trilhar um caminho diferenciado, mais voltado ao usuário final.
No capítulo 5, apresenta-se a modelagem do sistema, consistente no Modelo de
Caso de Uso, Modelo de Domínio, Diagrama de Classe, Análise de Robustez, Diagrama de
Sequência e Modelo do Banco de Dados, seguindo a metodologia escolhida. Também foram
documentados os Atores, Requisitos Funcionais, Requisitos não Funcionais e Regras de
Negócio do sistema.
Verificou-se que o modelo ICONIX possui fases de desenvolvimento que
possibilitam extrair requisitos detalhados e utilizá-los na documentação utilizando diagramas
da UML.
O desenvolvimento e a apresentação do sistema, juntamente com uma breve
descrição das ferramentas utilizadas, fazem-se presentes no capítulo 6.
6.3
PROBLEMA E SOLUÇÕES
Durante o desenvolvimento, houve a troca do banco de dados MySQL para o SQL
Server 2008. De acordo com o conhecimento dos membros do projeto, foi constatado que o
gerenciamento do MySQL, não seria o mais simples para o desenvolvimento. Portanto, a
equipe, resolveu utilizar um gerenciador de banco de dados mais familiarizado, o SQL Server
2008.
Essa alteração no banco de dados, fez com que levasse-mos mais tempo para o
desenvolvimento, pois tivemos que reconstruir a estrutura do banco de dados, dentro do SQL
86
Server 2008, bem como adaptar a parte do sistema, que estava compatível apenas com o
banco de dados MySQL.
6.4
APRESENTAÇÃO DO SISTEMA
A figura, a seguir, demonstra a tela de login do sistema. Para acessar ao sistema, o
usuário deve informar usuário e senha para que o sistema confirme a autenticidade do usuário
e permita o seu acesso.
Figura 41 – Tela de Login.
Fonte: Autores, 2012.
Caso o sistema não valide a autenticidade do login informado, o usuário recebe
uma mensagem de erro.
Após a confirmação de autenticidade do usuário, o mesmo é redirecionado para a
tela inicial do sistema. A figura 42 representa a tela inicial do sistema, exibindo o nome do
usuário logado para usuário e os menus aos quais este tem a permissão de acesso, contendo
também a opção de se desconetar do sistema.
87
Figura 42 – Tela inicial do sistema.
Fonte: Autores, 2012.
O sistema habilita os menus de acordo com a permissão de acesso de cada
usuário. Por exemplo, na imagem anterior estão disponíveis os menus para usuário
administrador, enquando que na próxima figura aparecem os menus disponíveis para o
usuário Bombeiro Comunitário.
Figura 43 – Tela inicial do sistema para Bombeiro Comunitário.
Fonte: Autores, 2012.
A figura, na continuação, representa a tela de consulta de locais, sendo que a partir
dela é possível incluir, alterar ou excluir um local. Para a consulta, é possível filtrar pela sigla
88
ou cidade do local. É exibido em baixo do nome do usuário logado, o local do sistema em que
o usuário está.
Figura 44 – Tela de consulta de Locais.
Fonte: Autores, 2012.
A seguir, a figura representa a tela de cadastro de local. Nela, os dados
obrigatórios estão com a descrição em vermelho.
Figura 45 – Tela de inclusão/alteração de Local.
Fonte: Autores, 2012.
A seguir, a figura 46 ilustra a tela de consulta de usuários, sendo que a partir dela
é possível incluir, alterar ou excluir um usuário. Nela, é possível filtrar a consulta por nome de
guerra e/ou matrícula do usuário.
89
Figura 46 – Tela de consulta de Usuários.
Fonte: Autores, 2012.
A imagem, a seguir, exibe a tela de inclusão/alteração de usuário, e em vermelho
os campos que são obrigatórios para efetuar a ação com sucesso.
Figura 47 – Tela de inclusão/alteração de Usuário.
Fonte: Autores, 2012.
90
A seguir, na figura 48, verifica-se a tela na qual o usuário efetua a alteração no seu
cadastro. Nela, é possível alterar somente algumas informações.
Figura 48 – Tela de alteração do cadastro do usuário logado.
Fonte: Autores, 2012.
Na continuação, segue a tela de escala de serviço. Nela, o usuário Bombeiro
Comunitário tem permissão de agendar horário na escala e consultar, por período, os horários
já cadastrados para o local no qual o usuário logado está cadastrado. Nesta tela, o Bombeiro
Comunitário também pode cancelar seu horário agendado.
91
Figura 49 – Tela de Escala de serviço para agendamento.
Fonte: Autores, 2012.
A figura, na continuação, demonstra a tela escala de serviço para usuário Chefe de
Socorro. Nela, é possível alterar a situação do horário agendado.
Figura 50 – Tela de Escala de serviço para confirmação de serviço.
Fonte: Autores, 2012.
Após o usuário Chefe de Socorro clicar em cima da descrição da situação
“Agendado”, é exibida a tela de confirmação de serviço, apresentada a seguir. Nela, são
exibidas as informações do agendamento, sendo disponibilizados campos para a informação
da nova situação da escala, com a data e hora do serviço realizado, juntamente com as
92
observações do acontecido durante o período em que o Bombeiro Comunitário estava
presente junto à guarnição de serviço.
Figura 51 – Tela de Confirmação de serviço.
Fonte: Autores, 2012.
A seguir, está a tela de escala de serviço para o usuário Chefe de Socorro. Pode se
observar que o horário da escala já sofreu a confirmação de serviço. Nota-se que, quando a
situação do horário foi alterada, esse campo deixa de ser um link e, nele, é exibida uma
imagem ( ), a qual, ao ter o mouse colocado acima, exibe a justificativa informada na
confirmação de serviço.
Figura 52 – Tela de Escala de serviço após confirmação de serviço.
Fonte: Autores, 2012.
93
Na sequência, a tela de relatórios do sistema.
Figura 53 – Tela de Relatórios do sistema.
Fonte: Autores, 2012.
Na tela, a seguir, está o Relatório de Bombeiros Comunitários Cadastrados, nele,
são listados todos os Bombeiros Comunitários cadastrados no sistema, sendo possível filtrar
os dados por cidade, local e/ou situação do Bombeiro Comunitário, sendo que os resultados
são agrupados por local. Essa funcionalidade permite, também, salvar o relatório no formato
PDF, como demonstrado a seguir.
94
Figura 54 – Tela de Relatório de Bombeiros Comunitários Cadastrados.
Fonte: Autores, 2012.
Na tela, a seguir, está o Relatório de Horas Trabalhadas por Bombeiro
Comunitário. Observa-se que os dados, total de horas trabalhadas para cada Bombeiro
Comunitário, são agrupados por local e período, sendo possível filtrar os dados por Local,
Bombeiro Comunitário, Ano e/ou Mês. Devido à essa funcionalidade, é possível salvar o
relatório no formato PDF, como demonstrado na sequeência.
95
Figura 55 – Tela de Relatório de Horas Trabalhadas por BC.
Fonte: Autores, 2012.
6.5
VALIDAÇÃO E TESTES
Após a conclusão da primeira versão da implementação do sistema, foi realizada
uma validação do software com o objetivo de identificar possíveis falhas. Essas falhas foram
corrigidas e o sistema foi novamente validado pelos autores.
Após a validação inicial dos autores, o sistema foi, então, apresentado para o 10º
Batalhão de Bombeiro Militar – BBM de Santa Catarina, sendo que o mesmo foi validado
pelo Bombeiro Militar responsável pelos Projetos Comunitários. Ao utilizar o sistema, o
usuário navegou pelo sistema sem a necessidade de maiores explicações. Foi destacada a
simplicidade e a objetividade de como as informações estão dispostas e a facilidade de
cadastro, exclusão e alteração de dados.
Como sugestões, foi considerada a possibilidade de criação de um módulo, pelo
qual seja controlada a quantidade de vagas masculinas e femininas disponíveis no alojamento
de cada local, para que, ao Bombeiro Comunitário efetuar o agendamento, o sistema verifique
96
a disponibilidade no alojamento. Destacou-se, também, a possibilidade de adaptação do
sistema para que o mesmo seja utilizado, também, para o controle de Guarda-Vidas Civis do
Estado de Santa Catarina.
Ao término da validação, o usuário concluiu que o sistema é de extrema
importância para o controle dos Bombeiros Comunitários do Estado de Santa Catarina, pois
atualmente o controle é feito em cada quartel, não tendo uma unificação das informações.
Ressaltou, também, que a modalidade de agendamento de serviço pelo próprio Bombeiro
Comunitário é uma inovação de grande utilizadade e agilidade.
6.6
CONSIDERAÇÕES FINAIS
O resultado do desenvolvimento é um aprendizado das boas práticas de
programação de software, aperfeiçoamento da aplicação das técnicas de levantamento de
requisitos adquiridas a partir do contato com o usuário final do sistema, e a experiência de
utilizar as técnicas e as ferramentas que tivemos conhecimento ao longo do curso, para
transformar o projeto em um produto de uso contínuo pelo Corpo de Bombeiros Militar do
Estado de Santa Catarina.
A mais importante vantagem do sistema é sua aplicação via web, ou seja, o
usuário final pode acessar ao sistema a partir de qualquer local onde tenha um ponto de acesso
à internet.
97
7
CONCLUSÃO E TRABALHOS FUTUROS
Este capítulo apresenta os resultados obtidos no desenvolvimento do sistema web,
utilizando a metodologia ICONIX, para controle dos Bombeiros Comunitários do CBMSC.
Esse aplicativo visa a melhorar a administração do cadastro dos Bombeiros Comunitários,
juntamente com o controle de agendamento de horários da escala de serviço.
7.1
ALCANÇANDO OS OBJETIVOS
Através deste trabalho, pode-se acompanhar a evolução do objetivo principal que
era planejar e desenvolver um sistema web para o CBMSC.
Os passos para atingir este objetivo foram descritos nos objetivos específicos.
Primeiramente havia o objetivo de desenvolver o sistema para controle de
cadastro de Bombeiros Comunitários centralizado. A arquitetura web foi escolhida, pois com
ela é possível atingir esse objetivo.
A familiarização dos integrantes do projeto com a linguagem .NET pemitiu maior
agilidade no desenvolvimento. Além disso, a robustez dessa linguagem também foi uma
característica que auxiliou no processo de desenvolvimento. Isso está presente no capitúlo 6, o
qual faz referência às ferramentas e tecnologias escolhidas para este projeto.
Para conquistar o objetivo de definir e documentar os requisitos e regras de
negócios dos processos envolvidos utilizando a metodologia ICONIX, foi realizado um
estudo do conhecimento sobre a administração dos Bombeiros Comunitários, visando
identificar os objetos de domínio do mundo real, através de uma pesquisa bibliográfica
presente no capitulo 2, no qual analisou-se o Regulamento Geral do Serviço Voluntário no
Corpo de Bombeiros Militar de Santa Catarina, para que fosse aplicado no sistema, as regras
impostas pelo mesmo. Com o conhecimento do negócio, estudou-se o processo de
desenvolvimento de software e seus modelos, conforme apresentados no capítulo 3, para que
a documentação ficasse de acordo, permitindo então o início da modelagem do software.
O capitulo 5 deste trabalho apresenta toda a modelagem através de diagramas da
UML e os requisitos em forma de tabela.
98
A partir da evolução e do cumprimento dos objetivos específicos, foi possível
desenvolver o sistema web que permite o gerenciamento da escala de serviços e controle de
horas trabalhadas, bem como a administração dos Bombeiros Comunitários de Santa Catarina
citado como objetivo geral.
7.2
RESULTADOS
O resultado do trabalho, é um estudo geral sobre o processo de agendamento na
escala de serviços dos Bombeiros Comunitários, atuantes no CBMSC. Com base no estudo,
pode-se desenvolver um software para utilização dos Bombeiros Comunitários, para que
efetuem o agendamento na escala de serviço, bem como, os Bombeiros Militares possam
efetuar a administração da escala, e dos Bombeiros cadastrados no sistema.
Para o desenvolvimento do software, contamos com o apoio de diversos
coordenadores dos Bombeiros Comunitários, das várias Organizações de Bombeiros Militar
do estado de Santa Catarina, permitindo, que o sistema aderisse às diferentes maneiras de
trabalho de cada OBM, até então existentes, gerando um produto completo para todos.
As idéias dos diferentes locais, permitiram que efetuássemos melhorias na
usabilidade do sistema, não deixando de cumprir com as regras estabelecidas no Regulamento
Geral do Serviço Voluntário do Corpo de Bombeiros.
A mais importante vantagem, na utilização do sistema, é a sua aplicação web, ou
seja, o usuário final poderá acessar o sistema, a partir de qualquer computador com acesso a
internet.
7.3
TRABALHOS FUTUROS
Como o software resultado deste trabalho de conclusão de curso é um novo
sistema, existem alguns módulos que ainda podem ser desenvolvidos para a evolução do
mesmo. Os usuários terão participação direta no desenvolvimento dos novos módulos, pois
99
serão evoluções que irão colaborar com o gerenciamento dos Bombeiros Comunitários do
CBMSC.
Como sugestão dos avaliadores, para cada local cadastrado, o sistema poderia
permitir o cadastro de alojamentos, de forma tal que fosse delimitada a quantidade de vagas
disponíveis por sexo, para cada local. Com isso, essa condição também poderia ser validada
no ato do agendamento.
Muito utilizado pela Coordenação dos Bombeiros Comunitários de cada Local, o
Mural de Recados poderia ser incorporado ao sistema, da forma que, quando o Bombeiro
Comunitário efetuasse o login no sistema, ele visualizasse como tela inicial o Mural de
Recados do seu Local.
Outra funcionalidade de grande importância e agilidade seria permitir que o
Bombeiro Comunitário solicitasse algumas ações como “afastamento temporário” e “pedido
de transferência” via sistema, criando, com isso, um controle de solicitações, que seriam
aceitas ou rejeitadas por cada Coordenador do local em que o BC está associado.
Prevê-se o desenvolvimento de um novo módulo pelo qual sejam controladas as
escolas de formação de Bombeiros Comunitários do Estado de Santa Catarina. Dessa forma
os Coordenadores de cada local poderão utilizar o sistema para facilitar também esse processo
administrativo inicial. A partir do momento em que o edital for lançado, os candidatos
deveriam efetuar sua matrícula on-line diretamente no sistema, o qual faria a gestão dessa
turma de formação de Bombeiros Comunitários. Como ponto positivo, pode-se destacar que o
sistema contará com informações de cada Bombeiro Comunitário, desde o momento da
matrícula, até após a sua formação, pois, a partir desse momento, ele irá utilizar o sistema
para efetuar seu agendamento de serviço.
100
REFERÊNCIAS
AGILE MANIFESTO, 2001. Disponível em: http://www.agilemanifesto.org. Acessado em
07 de outubro 2011.
BECK, Kent. Extreme Programming
Massachusetts: Ed. Addison-Wesley, 2000.
Explained:
Embrace
change.
Reading,
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de
Janeiro: Campus, 2002.
BORILLO, Dante.
The ICONIX approach, setembro, 2000. Disponível em:
http://pst.web.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/UCDOM_
summary.html. Acessado em: 07 de outubro 2011.
BRASIL. Exército Brasileiro. Regulamento Interno e Dos Serviços Gerais (RISG) R-1. 1ª
Edição, 1984.
BRASIL. Lei nº 9.608, de 18 de fevereiro de 1998.
BRG
Business
Rules
Group.
Disponível
em:
<http://www.businessrulesgroup.org/first_paper/br01c1.htm> Acessado em: 26 de Maio de
2011.
DEMO, Pedro. Pesquisa e construção de conhecimento. Rio de Janeiro: Tempo Brasileiro,
1996.
GIL Antonio Carlos. Como elaborar projetos de pesquisa. 4ª Ed. São Paulo: Atlas, 2002.
GUEDES, Gilleanes T. A. UML – Uma Abordagem Prática. São Paulo: Novatec, 2004.
JAVASCRIPT PASSO A PASSO LITE. São Paulo: Makron Books, 2001.
LEMAY, Laura. Aprenda em 1 semana HTML 4. Rio de Janeiro: Campus, 1998.
MASNIK, Cel. BM José Luiz. O Serviço Voluntário nos Corpos de Bombeiros Militares.
Artigo retirado do site da Associação de Oficiais Militares de Santa Catarina, publicado
101
2008?. Disponível em: <http://www.acors.org.br/index.php?mod=pagina&id=693> Acessado
em 20 de setembro 2011.
MICROSOFT.
Edições
do
Visual
Studio
2010.
Disponível
em:
<http://www.microsoft.com/visualstudio/pt-br/products/2010-editions>. Acessado em 09 de
maio 2012a.
MICROSOFT. Introdução à linguagem C# e o .NET Framework. Disponível em:
<http://msdn.microsoft.com/pt-br/library/z1zx9t92.aspx>. Acessado em 09 de maio 2012b.
MICROSOFT.
Manuais
online.
SQL
Server
2008.
Disponível
em:
<http://msdn.microsoft.com/pt-br/library/ms130214(v=sql.100).aspx>. Acessado em 30 de
maio de 2012c.
OMG. Object Management Group - Unified Modeling Language: Specification (2.0),
2001. Disponível em: <http://www.omg.org>. Acessado em: 07 de outubro 2011.
OMG. Unified Modeling Language: Superstructure. 2011b. Disponível
<http://www.omg.org/spec/UML/2.4/Superstructure>. Acessado em: 17 de maio 2012.
em:
PRESSMAN, R. Engenharia de Software. 6ª ed. - São Paulo: McGraw-Hill 2006.
ROSENBERG, Doug. STEPHENS, Matt. Use Case Driven Object Modeling with UML.
Theory and Practice. Ed. APRESS 2007.
ROSEMBERG, Doug. STEPHENS, Matt. COLLINS-COPE, M. Agile Development With
ICONIX Process: People, Processes and Pragmatism. Ed.APRESS 2006.
SANTA CATARINA. ASSEMBLÉIA LEGISLATIVA DO ESTADO DE SANTA
CATARINA.
Constituição
Estadual.
Disponível
em:
<http://www.alesc.sc.gov.br/portal/legislacao/constituicaoestadual.php>. Acessado em 11 de
setembro 2011.
SANTA CATARINA. Constituição do Estado de Santa Catarina. Florianópolis: Imprensa
Oficial, 1989.
SANTA CATARINA. Corpo de Bombeiros Militar de Santa Catarina. CBMSC. Histórico do
Corpo de Bombeiros Militar do Estado de Santa Catarina: Florianópolis, 2005.
102
Disponível em: <http://www.cbm.sc.gov.br/ccb/arq_html/historico.php> Acessado em 11 de
setembro 2011.
SANTA CATARINA. Corpo de Bombeiros Militar de Santa Catarina. Regulamento Geral
do Serviço Voluntário no Corpo de Bombeiros Militar de Santa Catarina. Portaria nº
395/GEREH/DIAP/SSP/2003. Atualizado em 06 de setembro de 2011.
SCHMITT, Moisés Nazareno. Fatores que influenciam o estado psicológico dos
Bombeiros no desempenho de sua atividade. Trabalho de Conclusão de Curso de Pós
Graduação em Administração de Pessoas, UNIASSELVI, Palhoça, 2011.
SILVA, E. L. da MENEZES, E.M. Metodologia da Pesquisa e Elaboração de Dissertação.
Florianópolis
2001.
Disponível
em:
<http://projetos.inf.ufsc.br/arquivos/Metodologia%20da%20Pesquisa%203a%20edicao.pdf>.
Acesso em 20 de outubro. 2011.
SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e Scrum para o
Desenvolvimento de Software. In: Revista Eletrônica de Sistemas de Informação, 2004 v.3
n.1. Disponível em <http://revistas.facecla.com.br/index.php/reinfo/article/view/146/38>
Acessado em 25 de agosto 2011
SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. - São Paulo: Pearson, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. - São Paulo: Addison Wesley, 2003.
VARGAS Souza de Clair Thânia. A história de UML e seus diagramas. Disponível em:
<http://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf>. Acessado em 18 de
outubro 2011.