UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
PROTÓTIPO DE UM SISTEMA DE
ADMINISTRAÇÃO PARA EVENTOS
RELATÓRIO DO TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À
UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS
CRÉDITOS DE DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE
CIÊNCIAS DA COMPUTAÇÃO - BACHARELADO
CINDY DANIELSKI
BLUMENAU, DEZEMBRO/1999
1999/ 2-06
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
PROTÓTIPO DE UM SISTEMA DE
ADMINISTRAÇÃO PARA EVENTOS
RELATÓRIO DO TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À
UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS
CRÉDITOS DE DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE
CIÊNCIAS DA COMPUTAÇÃO - BACHARELADO
CINDY DANIELSKI
BLUMENAU, DEZEMBRO/1999
1999/ 2-06
ii
PROTÓTIPO DE UM SISTEMA DE
ADMINISTRAÇÃO PARA EVENTOS
CINDY DANIELSKI
ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO FOI JULGADO
ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DO TRABALHO
DE CONCLUSÃO DE CURSO OBRIGATÓRIO PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
__________________________________________________
Prof. Wilson Pedro Carli - Orientador na Furb
__________________________________________________
Prof. José Roque Voltolini da Silva – Coordenador do TCC
BANCADA EXAMINADORA
_________________________________________________
Prof. Wilson Pedro Carli
_________________________________________________
Prof. Oscar Dalfovo
_________________________________________________
Prof. Dalton Solano dos Reis
iii
DEDICATÓRIA
Aos meus pais por me apoiarem em todos os momentos difíceis que eu
passei durante a minha faculdade, dando-me carinho e incentivo para o término do
curso. Ao meu sobrinho que me fez sorrir nas horas em que me sentia abatida e a
minha irmã que foi companheira e conselheira.
À Dalva, que é uma pessoa maravilhosa que soube me ouvir e apoiou-me do
começo ao fim e ao meu irmão por ter tido paciência de ensinar-me a parte técnica.
iv
AGRADECIMENTOS
Aos meus amigos que estiveram em todos os momentos junto comigo
nesta jornada e especialmente aquelas pessoas que sempre tiveram dispostas a me
ajudar nas horas em que eu mais precisava, ensinando-me e passando o carinho de
sua amizade. Valeu!
Não poderia faltar agradecimentos a uma amiga que, mesmo que esteja
longe, sempre estará no meu coração, pois ela me deu o que há mais de bonito em
uma amizade: a sinceridade. Aos professores Oscar Dalfovo pela sua amizade e
Wilson Carli que me deu a oportunidade de realizar este trabalho sob sua
orientação, me incentivando e dando oportunidade para validar meu software num
evento. Eu simplesmente só posso agradecer a todos que me ajudaram.
Obrigada!
v
SUMÁRIO
LISTA DE TABELAS.......................................................................................
viii
LISTA DE FIGURAS .......................................................................................
ix
LISTA DE QUADROS .....................................................................................
xi
LISTA DE TERMOS TÉCNICOS UTILIZADOS ..............................................
xii
RESUMO .........................................................................................................
xiii
ABSTRACT .....................................................................................................
xiv
1 INTRODUÇÃO .............................................................................................
1
1.1 OBJETIVOS ...............................................................................................
1
1.2 ORGANIZAÇÃO DO TRABALHO .............................................................
1
2 ADMINISTRAÇÃO DE EVENTOS ...............................................................
3
2.1 TIPOS DE EVENTOS ................................................................................
3
2.1.1 CONGRESSOS E CONCLAVES ...........................................................
3
2.1.2 SEMINÁRIOS .........................................................................................
4
2.1.3 MESAS REDONDA E SIMPÓSIOS ........................................................
4
2.1.4 FÓRUM ..................................................................................................
5
2.1.5 CONVENÇÕES ......................................................................................
5
2.1.6 CONFERÊNCIAS ...................................................................................
5
2.1.7 FEIRAS ...................................................................................................
5
2.1.8 EXPOSIÇÕES E SALÕES .....................................................................
6
2.1.9 JORNADAS ............................................................................................
6
2.1.10 ENCONTROS E ESTUDOS DE CASOS .............................................
6
2.1.11 PAINÉIS ................................................................................................
6
2.1.12 RODAS DE NEGÓCIO .........................................................................
7
2.1.13 ASSEMBLÉIAS .....................................................................................
7
2.1.14 BRAINSTORMING ...............................................................................
7
2.1.15 DEBATE ...............................................................................................
7
2.1.16 WORKSHOP E OFICINAS ...................................................................
8
2.1.17 COLÓQUIOS ........................................................................................
8
2.2 PLANEJAMENTO ......................................................................................
8
vi
2.3 ESTRATÉGIAS PARA PUBLICIDADE DO EVENTO ................................
10
2.4 RECURSOS ..............................................................................................
10
2.5 RECEPÇÃO E SERVIÇOS AOS PARTICIPANTES .................................
14
2.6 TREINAMENTO ........................................................................................
15
3 OMT – TÉCNICA DE MODELAGEM DE DADOS .......................................
16
3.1 CONCEITOS DE MODELAGEM ...............................................................
16
3.2 VANTAGENS E DESVANTAGENS ...........................................................
18
3.3 ANÁLISE ....................................................................................................
21
3.3.1 MODELAGEM DE OBJETOS .................................................................
21
3.3.1.1 RELACIONAMENTO DE ASSOCIAÇÃO ............................................
22
3.3.1.2 RELACIONAMENTO DE AGREGAÇÃO .............................................
23
3.3.1.3 RELACIONAMENTO DE GENERALIZAÇÃO .....................................
24
3.3.2 MODELAGEM DINÂMICA ......................................................................
24
3.3.3 MODELAGEM FUNCIONAL ...................................................................
27
3.3.3.1 DIAGRAMA DE FLUXO DE DADOS (DFD ) .......................................
28
3.4 PROJETO ..................................................................................................
29
3.4.1 SISTEMAS EM CAMADAS ....................................................................
30
3.5 A DIFERENÇA ENTRE AS METODOLOGIAS .........................................
31
4 AMBIENTE DE DESENVOLVIMENTO ........................................................
33
4.1 FERRAMENTAS CASE .............................................................................
33
4.1.1 FERRAMENTA POWER DESIGNER 6.1 DATA ARCHITECT ..............
34
4.1.2 FERRAMENTA RATIONAL ROSE C++ STUDENTS .............................
35
4.2 AMBIENTE VISUAL DELPHI 3 ..................................................................
36
4.2.1 BANCO DE DADOS ...............................................................................
37
4.2.2 COMPONENTES DO DELPHI ...............................................................
38
5 ESPECIFICAÇÃO DO PROTÓTIPO ............................................................
39
5.1 CARACTERÍSTICAS .................................................................................
39
5.2 DEFINIÇÃO ...............................................................................................
39
5.3 DIAGRAMA DE CONTEXTO .....................................................................
40
5.4 MODELO DE INTERFACE COM O USUÁRIO .........................................
40
5.5 FASE DE ANÁLISE ...................................................................................
40
5.5.1 ANÁLISE DE VERBOS E SUBSTANTIVOS ..........................................
41
vii
5.5.2 MODELO DE OBJETOS DA ANÁLISE – FASE ESTÁTICA ..................
44
5.5.3 USES CASES DE ANÁLISE – MODELO DINÂMICO ............................
44
5.5.3.1 CENÁRIO 1 – FAZER INSCRIÇÃO .....................................................
48
5.5.3.2 CENÁRIO 2 – VERIFICAÇÃO DE FREQÜÊNCIA ..............................
48
5.5.3.3 CENÁRIO 3 – IMPORTAR DADOS .....................................................
48
5.5.3.4 CENÁRIO 4 – FAZER CONSULTA .....................................................
48
5.5.3.5 CENÁRIO 5 – INSCREVER PALESTRA .............................................
49
5.5.3.6 CENÁRIO 6 – GERAR CERTIFICADO ...............................................
49
5.5.4 MODELO FUNCIONAL ..........................................................................
50
5.6 FASE DE PROJETO .................................................................................
51
5.6.1 MODELO DE OBJETO ...........................................................................
51
6 IMPLEMENTAÇÃO ......................................................................................
57
6.1 TELAS .......................................................................................................
57
6.2 RELATÓRIOS ............................................................................................
67
6.3 INTERFACE ..............................................................................................
68
6.4 INTEGRAÇÃO ...........................................................................................
68
7 CONCLUSÃO ...............................................................................................
70
7.1 SUGESTÕES ............................................................................................
71
REFERÊNCIAS BIBLIOGRÁFICAS ...............................................................
72
ANEXOS ..........................................................................................................
74
viii
LISTAS DE TABELAS
TABELA 5.6 : TABELA DE PARTICIPANTES ...............................................
53
TABELA 5.7 : TABELA DE PALESTRAS ......................................................
53
TABELA 5.8 : TABELA DE PRESENÇAS .....................................................
54
TABELA 5.9 : TABELA DE EVENTOS ..........................................................
54
TABELA 5.10 : TABELA DE PERÍODO ...........................................................
54
TABELA 5.11 : TABELA DE PALESTRANTE .................................................
55
TABELA 5.12 : TABELA DE ORGANIZAÇÃO .................................................
55
TABELA 5.13 : TABELA DE ÁREA .................................................................
55
ix
LISTA DE FIGURAS
FIGURA 3.1 : OBJETOS EM POO ..................................................................
16
FIGURA 3.2 : METODOLOGIA OMT ..............................................................
20
FIGURA 3.3 : ASSOCIAÇÃO SIMPLES ..........................................................
22
FIGURA 3.4 : ASSOCIAÇÃO DE MULTIPLICIDADE (1) ................................
22
FIGURA 3.5 : ASSOC. DE MULTIPLICIDADE (1 OU +) .......................
22
FIGURA 3.6 : ASSOCIAÇÃO DE MULTIPLICIDADE OPCIONAL (ZERO OU
MAIS) .......................................................................................
23
FIGURA 3.7 : ASSOCIAÇÃO DE MULTIPLICIDADE (1 OU MAIS) ................
23
FIGURA 3.8 : ASSOCIAÇÃO ESPECIFICADA ...............................................
23
FIGURA 3.9 : AGREGAÇÃO ...........................................................................
23
FIGURA 3.10: GENERALIZAÇÃO ...................................................................
24
FIGURA 3.11 : CENÁRIO ................................................................................
25
FIGURA 3.12 : DIAGRAMA DE EVENTOS .....................................................
26
FIGURA 3.13: DIFERENÇA ENTRE AS TÉCNICAS ......................................
32
FIGURA 3.14: COMO AS TÉCNICAS TRABALHAM ......................................
32
FIGURA 4.1 : TELA PRINCIPAL DO POWER DESIGNER 6.1 ARCHITECT..
34
FIGURA 4.2 : TELA PRINCIPAL DO RATIONAL ROSE C++ .........................
35
FIGURA 5.1 : DIAGRAMA DE CONTEXTO ....................................................
40
FIGURA 5.2 : DIAGRAMA DE CLASSES .......................................................
43
FIGURA 5.3 : MODELO DE OBJETOS DA ANÁLISE .....................................
44
FIGURA 5.4 : DIAGRAMA DE USES CASES .................................................
45
FIGURA 5.5 : DIAGRAMA DE EVENTOS .......................................................
45
FIGURA 5.6 : MODELO DE ENTIDADE-RELACIONAMENTO ......................
50
FIGURA 5.7 : DIAGRAMA DE FLUXO DE DADOS ........................................
51
FIGURA 6.1 : TELA DE SELEÇÃO DE EVENTOS .........................................
57
FIGURA 6.2: TELA PRINCIPAL DO PROTÓTIPO ..........................................
57
FIGURA 6.3 : CADASTRO DE PARTICIPANTES ...........................................
58
FIGURA 6.4 : CADASTRO DE PALESTRAS ..................................................
59
FIGURA 6.5 : IMPORTAÇÃO DE DADOS ......................................................
60
FIGURA 6.6 : CONTROLE DE PRESENÇAS .................................................
60
x
FIGURA 6.7 : TELA DE LOCALIZAR PARTICIPANTE ...................................
61
FIGURA 6.8 : RELATÓRIO DE PARTICIPANTES ..........................................
62
FIGURA 6.9 : RELATÓRIO DE PALESTRAS .................................................
62
FIGURA 6.10 : RELATÓRIO DE PARTICIPANTES X CATEGORIA ..............
63
FIGURA 6.11 : RELATÓRIO DE PRESENÇAS ..............................................
64
FIGURA 6.12 : RELATÓRIO DE ALOJAMENTO ............................................
64
FIGURA 6.13 : RELATÓRIO DE EVENTOS ...................................................
65
FIGURA 6.14 : PREVIEW DO EVENTO ........................................................
66
FIGURA 6.15 : INFORMAÇÕES SOBRE PROTÓTIPO .................................
66
xi
LISTA DE QUADROS
QUADRO 2.1 : LISTA DE MATERIAIS ............................................................
12
QUADRO 4.1 : ARQUIVOS DO DELPHI .........................................................
37
QUADRO 5.1 : QUADRO DE VERBOS ..........................................................
41
QUADRO 5.2 : QUADRO DE SUBSTANTIVOS .............................................
41
QUADRO 5.3 : QUADRO DE OBJETOS ........................................................
42
QUADRO 5.4 : QUADRO DE ATRIBUTOS .....................................................
42
QUADRO 5.5 : QUADRO DE MÉTODOS .......................................................
42
xii
LISTA DE TERMOS TÉCNICOS UTILIZADOS
BD : Banco de Dados
BDE : Banco de Dados Explorer
DER : Diagrama de Entidade-Relacionamento
DFD : Diagrama de Fluxo de Dados
ERI : Escola Regional de Blumenau
FURB : Universidade Regional de Blumenau
MER : Modelo Entidade-Relacionamento
OMT : Object Modeling Technique - Técnica de Modelagem de Objetos
OO : Orientado a Objetos
POO : Programação Orientada a Objetos
SEMINCO : Seminário de Computação (FURB)
BRASESUL : Congresso Sul Brasileiro de Corretores de Seguro
xiii
RESUMO
Esta proposta visa o desenvolvimento de um protótipo de sistema de
Administração para Eventos, fazendo com que tenha-se agilidade, qualidade na
organização e atendimento ao público. Atualmente, as empresas estão expandindose no mercado, obrigando-se a utilizar de técnicas para a realização da pesquisa,
planejamento, organização e controle das atividades na administração de eventos.
O protótipo desenvolvido baseou-se na metodologia de Análise Orientado a
Objetos, utilizando-se de um ambiente de programação visual, para implementação.
xiv
ABSTRACT
This proposal seeks the development of Prototype of a System of
Administration for Events for a quality organization and attendance to the public.
Actually, the companies are expanding in the market, putting under an obligation to
use of techniques for the accomplishment of the research, planning, organization and
control of the activities in the events administrations.
The developed prototype based on the Guided methodology of Analysis to
Objects, being used of an ambient of visual programming, for implement.
1
1 INTRODUÇÃO
O homem está cada vez mais preocupado com seus produtos e serviços por
causa dos avanços tecnológicos. A cada dia que passa, mais uma tecnologia é
apresentada para uma melhor solução do problema, fazendo assim com que haja
mais competitividade no mercado.
Dentro das relações públicas, um evento é a concretização de um
planejamento colocado em prática, visando conseguir um objetivo a fim de enaltecer
a organização de uma empresa junto ao seu cliente por excelência. Os eventos são
realizados para discussões de problemas, tomar decisões num grupo de pessoas e
ficar por dentro das últimas tecnologias do mercado. Eles devem ser bem planejados
pois atraem mais clientes, fazendo assim com que haja um “marketing de boca”
[SOU87].
Para isso, necessita-se de aplicativos que saibam absorver as informações
num modo organizado, para que não haja problemas futuros. Nos eventos na qual
trabalhou-se, como no 53º Congresso Brasileiro de Dermatologia, III Congresso
Brasil Sul de Corretores de Seguro (BRASESUL), Seminário de Computação
(SEMINCO) e entre outros, haviam problemas devido a um sistema que não atendia
às necessidades. Num evento deve-se ter agilidade, educação, cortesia e saber lidar
com diplomacia. Com isso, desenvolveu-se um protótipo visando agilizar o processo
de inscrição dos participantes, atendimento e controle de freqüência do evento,
administração e controle contábil.
Este trabalho fundamentou-se na metodologia de desenvolvimento de
software baseado em objetos, utilizando-se a Técnica de Modelagem de Objetos
(OMT) de Rumbaugh [RUM94], sendo implementado num ambiente visual.
1.1 OBJETIVOS
Este trabalho tem como finalidade agilizar no atendimento aos participantes de
um evento com maior eficiência. Com isso, desenvolveu-se o protótipo que cadastra
e controla a presença dos mesmos, e depois gera certificados àqueles que fizeram
2
parte do evento. No final do evento, o protótipo gera relatórios para controle do
administrador.
1.2 ORGANIZAÇAO DO TRABALHO
Este trabalho está organizado em sete capítulos, que relata, todo o
conhecimento para o TCC.
No primeiro capítulo do trabalho descreve a introdução, objetivos e a
organização do trabalho.
No segundo capítulo são apresentados os conceitos, tipos e o planejamento
de um evento em uma administração.
No terceiro capítulo é apresentado um estudo da metodologia OMT que
consiste em construir um modelo baseado em objetos dentro do protótipo
desenvolvido e para mais tarde ser implementado. Apresenta um estudo a respeito
de orientação a objetos, seus conceitos, vantagens e desvantagens do seu uso em
sistemas e suas características.
No quarto capítulo trata sobre o ambiente de desenvolvimento, na qual foi
utilizado as ferramentas CASE Power Designer 9.1 Architect e Rational Rose C++
Students, e a linguagem visual DELPHI 3 Client/Server, para modelagem dos dados
e implementação, respectivamente.
No quinto capítulo descreve a especificação do protótipo, com suas
características e os diagramas da metodologia OMT necessários para o sistema. É
apresentado os cenários, os modelos de objetos do protótipo.
No sexto capítulo trata sobre a implementação, a visualização das telas do
protótipo, interface e integração do mesmo.
No sétimo capítulo apresenta a conclusão e sugestões para continuação
deste trabalho.
3
2 ADMINISTRAÇÃO DE EVENTOS
Atualmente o mercado vem crescendo a cada dia e é necessário que haja
promoções ou eventos para que os profissionais possam reciclar suas informações e
os representantes mostrarem os seus serviços e/ou produtos. Todo evento bem
elaborado pode trazer muitos benefícios para expansão da empresa e sociedade.
Há vários tipos de eventos que pode-se escolher qual o tipo de “encontro” que
encaixa melhor nos objetivos da empresa. Na fase de planejamento, é necessário
definir o tipo, se o mesmo será aberto ou dirigido, a quantidade de pessoas que
participarão,
recursos
disponíveis
para
realização,
materiais,
infra-estrutura
(equipamentos), transporte, eventos sociais, opção de alimentação e hospedagem,
local, verbas, patrocínios, divulgação, eventos paralelos, objetivo e o retorno
esperado [SOU87].
Cada tipo de evento tem suas estratégias e um tratamento adequado para
aquela ocasião. Vamos conhecer alguns tipos de eventos para que possa adaptarse no objetivo da empresa dentro de suas perspectivas.
2.1 TIPOS DE EVENTOS
Os tipos de eventos apresentados a seguir, são formas mais difundidas, de
acordo com [CES97], [MAG91], [MIY87], e [SOU87].
2.1.1 CONGRESSOS E CONCLAVES
Congressos são eventos de grande porte (acima de 500 pessoas) com uma
duração média de 4 dias no mínimo e tem-se como objetivo transformar trabalhos
em algo conclusivo.
Podem ser definidos como reuniões promovidas por entidades associativas,
para debates sobre o assunto que lhes interessam a um determinado ramo
profissional. Dada a conclusão, é encaminhado às autoridades. Os congressos
podem ser locais, regionais, nacionais ou internacionais. Nos locais, os assuntos são
direcionados a uma determinada área específica. Os regionais são aqueles com
4
público-alvo daquela região, tendo um marketing voltado a ela. Podemos citar aqui
na região sul, a Escola Regional de Informática (ERI). Os nacionais são assuntos
direcionados ao país em que está sendo realizado o evento e os internacionais
direcionados a todos os países.
Conclaves são semelhantes a congressos, voltados para a área religiosa,
onde os participantes trazem temas específicos a serem debatidos.
2.1.2 SEMINÁRIOS
A duração de um seminário é em torno de dois dias e seu porte é menor que a
de um congresso. É mais voltado a área de estudos ou de aprofundamento
profissional. O público participa já com seu conhecimento sobre o assunto através
de grupos de discussões.
O seminário divide-se em 3 partes: exposição, quando alguém realiza
pesquisa e leva ao grupo; discussão, onde debate-se sobre a pesquisa; e a
conclusão, quando o coordenador recomenda o que deve ser feito e o fechamento.
2.1.3 MESA REDONDA E SIMPÓSIOS
É uma reunião clássica, preparada por um coordenador onde vai orientar a
discussão sobre o assunto sem desviar do tema. Os participantes da mesa-redonda,
apresentam seus pontos de vista sobre o assunto em pauta dentro de um tempo
limitado e depois são debatidos entre eles. Em mesa redonda pode-se haver ou não
uma integração com o público através de perguntas orais ou por escrito, cabendo o
coordenador decidir a questão.
Já o simpósio tem como principal objetivo assuntos ligados a pesquisa e
inovação de uma área, contando com a participação de expositores especialistas e
um coordenador que, logo em seguida recebe as perguntas do público para que se
tenha uma troca de informações.
5
2.1.4 FÓRUM
É um evento com temas livres e assuntos de interesse aquele evento. É
direcionado ao público em geral e menos técnico. As discussões são amplas e,
muitas vezes podem gerar eventos posteriores como seminários e simpósios para
sua complementação.
É levantado um problema e as discussões são feitas através da participação
de todos. No final, o coordenador da mesa recolhe as informações e apresenta a
conclusão na maioria das respostas.
2.1.5 CONVENÇÕES
São reuniões fechadas em um determinado grupo, promovidas por entidades
empresariais. Eles expõe problemas e situações onde geram discussões sobre um
assunto juntamente ao coordenador. Normalmente, duram em média dois dias e
podem haver treinamentos.
Temos como exemplo, convenções de vendas que reúnem os elementos
ligados ao setor (representantes, vendedores, e outros) para lançamento de um
produto ao mercado ou apresentação de novos planos de expansão.
2.1.6 CONFERÊNCIAS
Este evento é dividido em duas partes: auditório e o conferencista. É o evento
mais popular e são palestras sobre um assunto específico. Seu público-alvo são
aqueles que já tem alguma familiaridade com o assunto e podem ser abertas à
perguntas do auditório sem confundir com debates.
2.1.7 FEIRAS
São mais voltadas ao comércio, servindo para divulgação dos produtos de
última tecnologia e serviços prestados das empresas. Podem ser abertas ao público
ou direcionado a um grupo especificado de pessoas como por exemplo,
empreendedores. A duração pode variar de 4 até 15 dias e muitas vezes são
6
realizadas junto com congressos.
2.1.8 EXPOSIÇÕES E SALÕES
As exposições são mais informativas, que podem acontecer em locais
menores com uma duração de 3 a 30 dias.
Nos salões, o trabalho é mais voltado a promoção institucional, tendo como
objetivo aumentar uma imagem corporativa. Exemplo: Salão de Automóveis.
2.1.9 JORNADAS
Em jornadas, acontecem simulações de casos, que são realizadas
periodicamente e participam grupos de pessoas com algum conhecimento, para
discutir um ou mais assuntos que não são normalmente discutidos em congressos. É
como se fosse um congresso, mas com menos pessoas e de modo informal.
2.1.10 ENCONTROS E ESTUDO DE CASOS
Nos encontros acontecem discussões de projetos e trabalhos a serem
realizados sem preocupação de um tema e são mais teóricos.
Já em estudo de casos, o caso é colocado em pauta para o grupo, por um dos
participantes e eles procuram uma melhor solução. O caso e a solução são
apresentados ao grupo para serem analisados e criticados.
2.1.11 PAINÉIS
São debates especializados parecidos com a mesa redonda, onde as
discussões são fechadas a um determinado grupo de participantes. Os expositores
debatem entre si o assunto em pauta, tendo o público somente como observador. É
um evento pequeno de poucos especialistas e conta também com um coordenador,
um moderador e o presidente.
7
2.1.12 RODAS DE NEGÓCIO
Reúnem empresas com interesses comuns, dispostas a fazerem um negócio
que pode iniciar compras, vendas ou parcerias de seu produto. Para isso é
necessário um representante inscrito e o negócio que desejam realizar.
Normalmente são realizadas reuniões entre as empresas ou podem estar dentro de
um evento.
2.1.13 ASSEMBLÉIAS
São eventos que reúnem representantes de delegações de grupos, estados,
países e entre outros. São colocados em debate os assuntos de grande interesse
dos representantes.
As assembléias tomam conclusões e depois passa-se por uma votação,
sendo que, se esta for aceita, transformam-se em recomendações da assembléia. O
direito a voto é somente das delegações oficiais, não impedindo que observadores
se inscrevam e ouçam os debates.
2.1.14 BRAINSTORMING
Este evento reúne um grupo de pessoas onde elas podem expor suas idéias
para solução de problemas. As primeiras idéias estimulam outras melhores, tendo
como resultado final uma quantidade de soluções postas pelo grupo. O coordenador
se encarrega de escolher a melhor sugestão para o problema. Este tipo de encontro
é utilizado mais na área publicitária. É feita uma avaliação das idéias primeiramente
pela criatividade, onde não há censura ou críticas à idéia apresentada e depois pela
avaliativa.
2.1.15 DEBATES
O debate acontece entre duas pessoas ou mais que defendem suas opiniões
ou ponto de vista, e explanam de melhor forma para que sejam aceitas. O público
participa apenas com aplausos para confirmação de suas idéias.
8
2.1.16 WORKSHOP E OFICINAS
Workshop são encontros onde há uma parte expositiva e depois demonstram
o produto que gerou este evento. Normalmente é realizado com outros em paralelo.
Oficina é semelhante ao Workshop, sendo que este tipo de evento é mais
utilizado na área educacional e o Workshop é mais na área comercial e empresarial.
Pode-se estar em paralelo à um outro evento maior.
2.1.17 COLÓQUIOS
Neste evento é feito uma reunião fechada que tem como maior objetivo, tomar
e esclarecer decisões, tendo um coordenador para controlar.
2.2 PLANEJAMENTO
O planejamento começa depois de definir o objetivo da empresa e qual será
seu público-alvo. Daí por diante, é necessário coordenar todos os detalhes para que
o trabalho saia de um modo que todos fiquem satisfeitos com o resultado.
Num planejamento é fundamental que se tenha:
a) objetivos: é o que leva a empresa a realizar o evento, podendo ser geral ou
específico;
b) público: qual será o público-alvo desse evento. A quantidade de pessoas
que se espera participar neste evento;
c) estratégias: é uma maneira de chamar a atenção do público para o evento;
d) recursos: todos os recursos necessários para a realização do evento;
e) implantação: é a meta a ser seguida, desde o começo até o término do
evento;
f) fatores condicionantes: são assuntos relacionados ao evento para a sua
realização;
g) acompanhamento e controle: é feito um acompanhamento durante o
evento para que se tenha um controle, evitando um desvio do objeto;
h) avaliação: é realizado no final do evento em forma de relatório para que se
9
possa ver o resultado e a prestação do custo;
i) orçamento: o recurso humano disponibilizará para a empresa contratante o
valor do pagamento a ser efetuado à entidade promotora.
Estes são os principais termos utilizados quando se quer montar um evento
bem organizado. Veremos a seguir os itens principais que devem ser
cuidadosamente analisados e colocados em prática durante o evento:
a) produto: deve ser bem definido, para que possa ser comercializado, pois
ele tem uma grande ligação entre produto-cliente;
b) local: depende muito do produto, pois cada um tem sua maneira de ser
exposto. Deve-se contar com a facilidade ao acesso, turismo na cidade
onde será realizado, ampla rede hoteleira para suportar a hospedagem,
despesas compatíveis aos participantes e o interesse maior dos
patrocinadores do evento. O local deve ser amplo para acomodar o total de
participantes, expositores e instalações em geral. Ele é o rótulo do evento,
pois deve-se trazer conforto aos participantes, fazendo que saia dali com
uma boa imagem e retornem ao próximo;
c) data: deve-se escolher uma data onde todos possam ter acesso ao evento,
observando também o local geográfico, sem que haja outro evento
semelhante pois seria um grande problema;
d) temário: os assuntos devem ser definidos juntamente com os objetivos do
evento para que se faça publicidade antecipadamente, divulgando o
propósito deste com as últimas tecnologias, data da realização e o local;
e) programa: é organizado um cronograma com todas as atividades que serão
seguidas durante o evento, em suas datas e horas marcadas.
Normalmente é colocado um evento cultural e social para que os
participantes possam apreciar a cidade e é uma maneira de aproximar as
pessoas para uma conversa informal. Os horários devem ser bem
definidos, com previsão de tolerância aceitável nos atrasos dentro do
cronograma estipulado.
10
2.3 ESTRATÉGIAS PARA PUBLICIDADE DO EVENTO
A divulgação é muito importante para atrair mais participantes para o evento.
Num evento podem participar como público-alvo profissionais, expositores, agentes
financeiros, convidados especiais, autoridades, imprensa, governo, universidades,
associações de classe, sindicatos e interessados.
A publicidade pode ser feita por propagandas, notícias, cartazes, mala direta,
diálogos pessoais, cartas especiais, outdoor, Internet, jornais, folders.
Os outdoors, propagandas, notícias, cartazes abrangem uma publicidade em
massa, onde podem ser vistos por várias pessoas que passarem por eles. Já os
outros são mais direcionados a uma pessoa ou um grupo menor. No momento, a
Internet não é um ponto forte para publicidade, pois nem todas as pessoas tem
acesso ao computador. A Internet está expandindo-se aos poucos e a tendência no
futuro é ter mais e mais pessoas utilizando esse meio de comunicação. Atualmente,
a Internet está sendo utilizada mais em cadastros de inscrições nos eventos, como
no SEMINCO por exemplo.
A mala direta serve para envio de folders à pessoas ou representantes de
uma empresa, informando e motivando sua presença.
A imprensa é a mais importante, pois ela é quem vai fazer a cobertura e
divulgar o acontecimento, fazendo com que as pessoas tenham mais vontade de
voltar aos próximos e transmitir à outras pessoas do grande sucesso.
2.4 RECURSOS
O controle de entrada e saída do capital das inscrições dos participantes é
muito importante para um planejamento do recursos humanos porque são eles os
responsáveis pelo pagamento das prestações de serviços e materiais. As despesas
devem estar bem claras e escritas para não haver problemas futuros e o montante
disponível deve ser suficiente durante o evento. No final, o evento bem organizado e
trabalhado dentro de suas metas só tendem a ter lucro para a empresa contratante
[CES97].
11
Os recursos visuais devem ter disponibilidade de recursos suficientes para a
realização de palestras e organização do evento, como por exemplo a secretaria
com computadores necessários para o atendimento rápido e preciso. Eles são
divididos em tipos de serviços para que se torne mais fácil o trabalho dos mesmos.
Segue abaixo eles:
a) serviços de imagens:
Estes serviços estão relacionados com a parte visual do evento, fornecendo
videocassetes,
datashows,
projetores
de
slides
e
filmes,
canhão,
computadores e seus periféricos, painéis, telas para projeção, circuito fechado
de TV para controle da administração;
b) serviços de som:
Estes serviços são basicamente todos aqueles recursos ligados a som, como
o microfone para palestras e recados na secretaria, amplificadores, tradutores
para tradução simultânea, pessoal encarregado para controlar a música
ambiente;
c) serviços de gravação:
Estes serviços são mais utilizados em eventos grandes como congressos, que
pedem a um profissional para gravação de palestras e outros eventos. Eles
gravam e fazem cópias da fita para os participantes que estão interessados
em obter este material;
d) serviços de painéis:
Estão relacionados com quadro-negro, flit-chart, tripé para cartazes, painéis
para exibição de um tema, onde serão “rabiscadas” as idéias principais
abordadas no momento presente. São responsáveis
também pelos
apagadores, pincéis mágicos, pincéis atômicos, giz, apontador de laser e
entre outros.
Os recursos de materiais e instalações são responsáveis pela organização de
materiais utilizados no evento, sabendo distribuir os materiais sem desperdício. Os
12
materiais relacionam-se com a secretaria e os participantes, conforme o QUADRO
2.1.
QUADRO 2.1: LISTA DE MATERIAIS
Materiais para secretaria
Materiais para participantes
- Papel para circulares;
- Pasta do participante e do convidado;
- Papel para correspondências;
- Crachá para entrada;
- Papel para impressora;
- Bloco para anotações;
- Tinta para impressora;
- Canetas esferográficas;
- Envelopes;
- Folders do evento;
- Recibos;
- Cronograma do evento.
- Formulários de controle;
- Bloco de anotações;
- Canetas;
- Clipes;
- Grampeador;
- Pranchetas.
A montagem das instalações da secretaria deve ser o mais breve possível,
pois normalmente o atendimento começa antes do previsto, para esclarecimento dos
casos mais urgentes e pendentes.
Depois temos as instalações de Sala de Espera para convidados e
conferencistas, Sala de Imprensa, Sala Vip e SlideDesk (local onde guarda-se os
slides e fitas para palestra).
Além dos serviços da entidade promotora, necessita-se de serviços de
terceiros durante um evento como:
a) serviço de fotografia;
b) serviço de banco;
c) serviço de limpeza;
d) serviço de artes (montagem de folder, cartazes,...);
e) serviço de audivisuais;
13
f) serviço de buffet;
g) serviço de coffee-break;
h) serviço de decoração;
i) serviço de analista de sistemas;
j) serviço de eletricidade;
k) serviço de montadora;
l) serviço de turismo (para acompanhantes num turismo pela cidade).
A entidade promotora é responsável pelo contratação dos serviços de
terceiros e assim, organizar adequadamente com o que se pede. Na secretaria, é
feito o atendimento para as inscrições novas e pré-inscrições, tomando o máximo de
controle sobre o pagamento das taxas.
Os expositores “alugam” um espaço do salão para que ele possa expor seu
produto e/ou serviço. É uma forma de publicidade e oferecem brindes e fazem
anúncios durante os intervalos para atrair mais clientes.
Os anúncios podem ser feitos através do microfone nos intervalos, projeções,
banners, e outros. Eles podem ser sobre propagandas como também uma forma de
anunciar os pontos turísticos da cidade, fazendo com que as pessoas gostem daqui
e retornem com mais conhecidos. Esses tipos de anúncios, culturais e sociais, são
pouco explorados, deixando a desejar aos participantes a cultura da cidade. A falta
de divulgação leva às pessoas acharem que a cidade não tem infra-estrutura e
locais turísticos para visitação.
Os eventos culturais e sociais, podem ser administrados de uma forma onde
os participantes possam fazer um tour histórico pela cidade (museus, monumentos,
centros-históricos, residências de personalidades), conhecer teatros, espetáculos,
concertos da cultura da cidade, universidades, restaurantes, hotéis, confeitarias,
praças de livros, feiras de artesanato e também dispor a ajudá-los a escolher um
local adequado para degustação da gastronomia da cidade [CES97].
O transporte é fundamental para que os participantes possam locomover-se
dos hotéis para o evento, bem como para os encontros sociais sem a preocupação
14
de chegar tarde. Devemos dar uma atenção dobrada pois nem sempre eles se
encontram perto do local. Já o transporte aéreo, pode-se contratar uma empresa
especializada em turismo especialmente para venda de passagens aéreas.
2.5 RECEPÇÃO E SERVIÇOS AOS PARTICIPANTES
A recepção é a “sala de estar” do evento e é o primeiro contato do participante
com o mesmo. Caso não houver um atendimento adequado, ocasionará uma má
impressão do sucesso do mesmo. Eles devem ser atendidos de forma cortês,
educadamente e sempre sorridentes acima de tudo. Digamos que é o fator principal
do evento pois o participante deve sentir-se com grande satisfação.
As recepcionistas devem ter um treinamento adequado ao atendimento rápido
e eficaz, sem que haja demora e evitando atritos com os participantes inquietos.
Com isso, elas terão também todas as informações relacionadas ao evento para
ajudá-los.
É de suma importância analisar a infra-estrutura da cidade para hospedagem
dos participantes durante o evento. Os hotéis devem ser próximos ao local, com
variações de preços para todo tipo de gosto. Eles devem ser informados sobre a
característica do hotel e a procedência de efetuar sua reserva e o prazo para
desistência antes da sua chegada à cidade.
Deve-se elaborar um plano no sentido de criar condições favoráveis ao
desenvolvimento de um clima positivo, através de etapas como:
a) hastear a bandeira que representa o País ou Estado(s) de todos os
participantes;
b) homenagem a Bandeira Nacional no início e término do evento;
c) mensagens especiais aos participantes, dando boas vindas ao evento;
d) recepção e atendimento;
e) atividades sociais e culturais que serão realizados durante o evento.
15
2.6 TREINAMENTO
São feitas seleções de recepcionistas capazes de encaminhar e atender os
participantes do evento, e assim definidas em seus postos com o treinamento
adequado ao seu cargo sem infringir as ditas regras. É essencial fazer uma
simulação de atendimento na secretaria para que não haja problemas durante a
execução das ações [CES97].
Os treinamentos podem ser técnicos (voltados ao computador e sistema
utilizado para cadastro e atendimento a consultas, instalações) e administrativos
(voltados ao atendimento aos participantes). Dentro do treinamento, é relacionado
algumas orientações a serem seguidas como:
a) orientação geral: objetivos gerais do evento e os aspectos históricos e
estágio atual;
b) orientação específica: estrutura organizacional e as funções de cada um;
c) orientação
psicossocial:
formas
de
comunicação
e
atendimento,
relacionamento interpessoal.
Para eventos a longo prazo, é necessário que se tenha um rodízio de pessoas
nos cargos para motivar a continuação do trabalho, pois torna-se cansativo. Sendo
assim, é necessário manter a recepcionista produzindo o melhor de si e preparando
para assumir outros encargos e responsabilidades caso tenha problemas em algum
setor.
16
3 OMT – TÉCNICAS DE MODELAGEM DE OBJETOS
3.1 CONCEITOS DE MODELAGEM
Segundo [RUM94], existem características que serão abordadas a seguir:
a) objeto: um objeto pode ser qualquer coisa, real ou abstrata, no qual são
armazenados os dados e os métodos que os manipulam. Um objeto pode
ser igual ao outro, mas com suas características diferentes. Um exemplo
que temos são os gêmeos, eles são idênticos, mas com suas
características diferentes. Eles tem uma identidade própria;
FIGURA 3.1: OBJETOS EM POO
Um objeto é composto por uma coleção de dados privados e um conjunto de
métodos que atuam sobre estes dados.
Fonte: [BRA99]
b) classe: é o modelo dos objetos, com suas propriedades semelhantes
(atributos),
o
mesmo
comportamento
(operações),
os
mesmos
relacionamentos com outros objetos e a mesma semântica. As operações
são escritas uma vez na classe e depois, os objetos reutilizam esses
códigos. Um objeto é uma instância de sua(s) classe(s) e ele “sabe” a que
classe pertence;
c) identidade: são objetos na qual os dados serão divididos em entidades.
Cada objeto tem identidade própria, ou seja, dois objetos são diferentes,
mesmo que seus dados e suas operações sejam idênticas. Por exemplo,
arquivo de um sistema;
d) abstração: os usuários começam a procurar a desenvolver de forma
17
abstrata, onde ele abstrai um conjunto de classes normais para encontrar a
superclasse. Quando desenvolvendo sistemas, abstrair significa focar em
“o que um objeto é e o que ele faz “;
e) mensagem: é um sinal de solicitação que ativa uma determinada operação
de um objeto ou mais. Para um objeto realizar uma operação, enviamos
um sinal de solicitação que gera uma mensagem. A operação recebe esta
mensagem, executa o método chamado e retorna uma resposta;
f) polimorfismo: significa que a mesma operação pode atuar de diversos
modos em classes diferentes. Uma mesma mensagem pode ser enviada a
várias classes, e cada classe interpreta de uma forma diferente;
g) encapsulamento: é um termo formal que descreve a junção de métodos e
dados dentro de um objeto de maneira que o acesso aos dados seja
permitido somente no meio dos próprios métodos do objeto. O
encapsulamento é a maneira de dar ao objeto seu comportamento do tipo
“caixa-preta”, que é a chave para a eficiência de reutilização e depuração
do sistema [COR95];
h) herança: é o compartilhamento de atributos e operações entre classes com
base em um relacionamento hierárquico. A herança é uma ferramenta para
organizar, construir e utilizar as classes reutilizáveis. Sem a herança, cada
classe seria uma unidade independente, cada uma desenvolvida a partir
do zero. As propriedades de uma superclasse não precisam ser repetidas
em uma subclasse, que automaticamente herda estas propriedades. A
reutilização que isto proporciona é uma das principais características da
orientação a objetos [VIV97];
i) diagrama de objetos: é uma forma de representar a modelagem de objetos
e seus relacionamentos numa notação gráfica. Eles são muito utilizados
para modelagem abstrata e para o projeto de programas reais. Há dois
tipos de diagramas: diagrama de classes (descreve muitas instâncias
possíveis de dados e as classes) e diagrama de instâncias (descreve
instâncias de um objeto, documenta seus cenários e o relacionamento
entre eles num determinado conjunto);
j) atributos: são propriedades denominadas de uma classe, que descreve o
18
valor de um dado guardado pelos objetos da classe. São as características
de um objeto. Um exemplo que temos são as pessoas, cada uma tem sua
idade, peso, altura, mas são diferentes. Estes seriam os atributos de uma
classe (idade, peso, altura) de um determinado objeto (pessoa). Atributo é
um valor relacionado aquele objeto;
k)
operações e métodos: as operações são utilizadas pelos objetos ou por
uma classe. Todos objetos de uma classe compartilham as mesmas
operações. Método é o comportamento dos objetos de uma classe. Um
método não pode acessar diretamente uma estrutura de dados. Sendo
assim, o método envia uma mensagem para o objeto e utiliza essa mesma
estrutura de dados. Métodos são rotinas utilizadas para manipulação das
informações associadas ao projeto. Eles não são eventos, isto é, não são
chamados quando o usuário executa uma ação, mas devem ser
especificados pelo desenvolvedor para compor os eventos. Os métodos
são definidos genericamente quando da definição da classe, e devem
operar sobre qualquer instância dessa classe, sem interferir nas demais;
l) notação de classes de objetos: são descritas em um quadro com seu nome
no topo com mais duas divisórias para classes daquele objeto, com sua
lista de atributos e lista de operações.
A abordagem de desenvolvimento baseado em objetos, faz com que os
desenvolvedores de software trabalhem e pensem em termos de aplicação durante a
maior parte do ciclo de vida da engenharia de software. Quando são identificados,
organizados e compreendidos os detalhes da aplicação, a estrutura de dados e
funções poderão ser tratados com mais eficácia [RUM94].
O desenvolvimento baseado em objetos é um processo conceitual
independente de uma linguagem de programação até as etapas finais.
3.2 VANTAGENS E DESVANTAGENS
Segundo [MAR95], apud [VIV97], as principais vantagens descritas sobre OO,
em relação as técnicas tradicionais, são:
19
a) reusabilidade: classes são projetadas para que possam ser reutilizadas em
outros sistemas sem a necessidade de uma nova criação;
b) confiabilidade: os softwares construídos a partir de classes estáveis,
provavelmente terão um número menor de falhas;
c) integridade: as estruturas de dados poderão ser usadas apenas com
métodos específicos, e isso é extremamente importante quando utiliza-se
em sistemas cliente-servidor e distribuídos;
d) facilidade na programação e manutenção: os programas são construídos
em pequenas peças. No caso de manutenção, geralmente muda-se um
método de uma classe de cada vez, pois cada classe executa sua
operação independente de outras classes;
e) modelagem mais realística: a análise OO modela um sistema de uma
maneira mais próxima da realidade;
f) interoperabilidade: os softwares de vários fornecedores diferentes podem
funcionar juntos;
g) migração: aplicativos existentes ou não OO freqüentemente podem ser
preservados ao encaixá-los em um envoltório OO.
Algumas desvantagens da OO:
a) uma representação da OO pode ser boa para alguns tipos de base de
dados, mas menos adequados para outros tipos. Uma vez que a
especificação de análise contém diferentes tipos de base de dados, a
análise OO apresentará somente uma solução parcial;
b) um dogma no campo da OO parece ser que, se os requerimentos não são
orientados a objetos, eles estão errados. Em muitos casos, as reações dos
usuários sobre o domínio do problema não contribuem para o
desenvolvimento do processo;
c) muitas linguagens e métodos para análise OO são informais;
d) um problema da análise OO é que nem sempre a transição é fácil e
promissora;
e) a modelagem das linguagens deveriam ser adequados para descrever
problemas do mundo real, não somente se preocupar com o que a
20
modelagem da linguagem é capaz de expressar.
Segundo [RUM94], a Técnica de Modelagem de Objetos (OMT) é a
metodologia baseada em objetos que concatena os três tipos de modelagem de
sistemas. O modelo de objetos representa os aspectos estáticos e estruturais de
dados, o modelo dinâmico representa os aspectos temporais e comportamentais de
controle de um sistema e o modelo funcional representa os aspectos relativos às
transformações de funções de um sistema. Podemos ter uma idéia de metodologia
na FIGURA 3.2:
FIGURA 3.2: METODOLOGIA OMT
Análise de Objetos
Declaração do Problema
Modelo Objeto
Modelo Dinâmico
Modelo Funcional
Implementação
Projeto de Objetos
Projeto de Sistemas
Projeto de Objetos
Implementação
FONTE: [VIV97]
a) análise: o analista constrói um modelo, chegando o mais próximo possível
do problema no mundo real. Deve-se trabalhar em conjunto com o usuário
para que possa entender o problema, e assim tentar solucioná-lo. O
modelo de análise é feito para saber o que o sistema deverá ou não fazer.
Os objetos do modelo devem representar conceitos do domínio da
aplicação como a estrutura de dados;
b) projeto do sistema: durante o desenvolvimento do projeto, o projetista de
21
sistemas deve decidir quais as características de desempenho devem ser
otimizadas, escolher a estratégia de ataque ao problema e realizar
alocações experimentais de recursos. O projetista constrói um modelo de
projeto baseado no modelo de análise, mas contendo detalhes de
implementação. O enfoque do projeto de objetos são estruturas de dados e
os algoritmos necessários à implementação de cada classe;
c) implementação: as classes de objetos e os relacionamentos desenvolvidos
durante o projeto de objetos são traduzidos para uma determinada
implementação em uma linguagem de programação, em um banco de
dados ou em hardware. Todas as decisões difíceis devem ser tomadas
durante o projeto para depois fazer a implementação, que é a de menor
importância.
Cada modelo tem uma referência aos outros modelos. O Modelo de Objetos
descreve a estrutura de dados e os modelos dinâmico e funcional atuam sobre ele.
As operações do Modelo de Objetos corresponde a eventos do Modelo Dinâmico e
as funções do Modelo Funcional; e o dinâmico descreve a estrutura de controle de
objetos.
3.3 ANÁLISE DE OBJETOS
3.3.1 MODELAGEM DE OBJETOS
O Modelo de Objetos é utilizado para mostrar a estrutura estática do sistema,
apresentando os objetos e seus relacionamentos, contendo diagramas de objetos.
As classes são organizadas em níveis hierárquicos compartilhando estruturas,
comportamentos e associações a outras classes. Elas definem os valores de
atributos relativos a cada instância de objetos e as operações que cada objeto
executa ou a que se submete.
Cada objeto é desenhado em forma de caixa e estas são conectadas por
linhas que representam relacionamentos entre objetos e podem simbolizar relações
do tipo associação, agregação ou generalização.
22
O Modelo de Objetos é representado graficamente por Diagramas de Objetos,
contendo classes de objetos.
3.3.1.1 RELACIONAMENTOS DE ASSOCIAÇÃO
Uma associação é uma conexão física ou conceitual entre classes ou
instâncias de objetos. Normalmente são implementadas em linguagens de
programação como ponteiros de um objeto para outro. Ponteiro é um atributo de um
objeto, que contém referências explícitas a outro objeto. Na FIGURA 3.3, é
apresentado uma associação.
FIGURA 3.3: ASSOCIAÇÃO SIMPLES
Nome da Associação
Classe A
Classe B
Fonte : [RUM94]
A notação permite que seja identificada a multiplicidade da associação, ou
seja, quantas instâncias de uma classe relacionam-se a uma única instância de uma
classe associada. A multiplicidade restringe a quantidade de objetos relacionados.
Ela muitas vezes é descrita como sendo “uma” (1) ou “muitas” (n), porém ela, de
modo geral, é um subconjunto de inteiros não-negativos. Normalmente o valor de
multiplicidade é um único intervalo, mas pode ser um conjunto de intervalos sem
associação. A FIGURA 3.4 representa uma associação onde a multiplicidade é 1 e a
FIGURA 3.5 representa mais de um relacionamento.
FIGURA 3.4 e 3.5: ASSOCIAÇÃO DE MULTIPLICIDADE
Classe
Fig. 3.4
Fonte: [RUM94]
Classe
Fig. 3.5
23
A FIGURA 3.6 e FIGURA 3.7, representam respectivamente uma associação
com multiplicidade zero ou uma (opcional) e uma ou mais (1+).
FIGURA 3.6 e 3.7: ASSOCIAÇÃO OPCIONAL (ZERO OU UMA) E
ASSOCIAÇÃO DE UMA OU MAIS
1+
Classe
Classe
Fig. 3.6
Fig. 3.7
Fonte : [RUM94]
Uma outra notação que também pode acontecer, é uma associação com
multiplicidade especificada, como mostra a FIGURA 3.8.
FIGURA 3.8: ASSOCIAÇÃO ESPECIFICADA
1-2, 4
Classe
Fonte : [RUM94]
3.3.1.2 RELACIONAMENTOS DE AGREGAÇÃO
Agregação é o relacionamento “parte-todo” ou “uma-parte-de” no qual os
objetos que representam os componentes de alguma coisa são associados a um
objeto que representa a estrutura inteira. Um relacionamento de agregação é
definido como relacionamento de uma classe estrutural a uma classe de
componentes e uma estrutura com muitos tipos de componentes corresponde a
muitos relacionamentos de agregação. É uma forma de reutilizar o código. Ela é
representada como o desenho de uma associação, mas com um losango a mais em
sua estrutura como mostra a FIGURA 3.9.
FIGURA 3.9: AGREGAÇÃO
Classe
Fonte : [RUM94]
Classe
24
3.3.1.3 RELACIONAMENTO DE GENERALIZAÇÃO
Generalização é o relacionamento entre uma classe e uma ou mais versões
da mesma. A classe que estiver em processo de refinamento é chamada de
superclasse e cada versão refinada, é denominada de subclasse. Os atributos e
operações comuns a um grupo de subclasses são incluídos na superclasse e
compartilhados por todas as subclasses. Diz-se que cada subclasse herda as
características de sua superclasse.
Relacionamentos
de
generalização
(superclasse/subclasse)
são
representados, no modelo de objetos, conectando-se a representação da
superclasse a ponta de um triângulo e as subclasses na base do triângulo através
de linhas (FIGURA 3.10).
FIGURA 3.10: GENERALIZAÇÃO
SuperClasse
SubClasse1
SubClasse2
Fonte : [RUM94]
3.3.2 MODELAGEM DINÂMICA
Modelo Dinâmico mostra os aspectos de um sistema que modificam com o
tempo e, especifica e implementa à seqüência de operações. Ele é representado
pelo Diagrama de Estados. Cada um desses diagramas mostra a seqüência de
estados e de eventos permitidos em um sistema para uma classe de objetos.
Abaixo estão relacionados alguns termos utilizados para este tipo de
25
modelagem, segundo [RUM94]:
a) evento e estado: evento transmite um sinal para o objeto de que alguma
coisa aconteceu, como um clique de um botão (gera um evento). Os
valores de atributos e as ligações mantidas por um objeto constituem seu
estado com o tempo, os objetos estimulam uns aos outros, resultando em
modificações denominadas Estados, e o estímulo individual de um objeto
para outro, chama-se Evento;
b) ação: é a operação que acontece em resposta a um determinado evento.
Um tipo de ação é o envio de um evento a outro evento;
c) cenário: é uma seqüência de eventos que ocorrem em uma determinada
execução do sistema. O escopo do sistema pode variar, incluindo todos os
eventos do sistema ou simplesmente associados a determinado
acontecimento.
O próximo passo para a construção do diagrama é fazer a identificação dos
cenários e seus eventos. Utilizou-se da notação de [HAR87] apud [RUM94] para
desenhar os diagramas, como mostra na FIGURA 3.11 um Cenário e na FIGURA
3.12, um Diagrama de Eventos.
FIGURA 3.11: CENÁRIO
- Administrador importa os dados;
- Participante faz inscrição;
- Administrador cadastra participante;
- Participante faz parte do evento;
- Administrador cadastra presença;
- Sistema faz a leitura do cartão magnético;
- Sistema recebe a presença;
- Administrador imprime certificados;
- Administrador gera relatórios.
26
FIGURA 3.12: DIAGRAMA DE EVENTOS
: Interface
: Banco de
Dados
: Participante
Criar (
Inscrever ( )
Grava ( )
Exibir (
As ações de entrada e de saída permitem que as ações sejam associadas
a um estado para indicar todas as transições que entram ou saem daquele estado.
As transições automáticas são disparadas quando suas condições são satisfeitas e
nenhuma atividade no estado de origem tenha terminado.
O Diagrama de Estados relaciona eventos e estados. Quando um evento
é recebido, o estado subseqüente depende do estado corrente e do evento; a
modificação de estados causada por um evento é chamada de transição. O estado é
desenhado como uma figura arredondada contendo um nome opcional. A transição
é desenhada como uma seta que parte do estado recebedor para o estado do
destino; o rótulo da seta é o nome do evento causador da transição [RUM94].
Segundo [RUM94], a aplicação de todos os recursos em um projeto de
software, que a metodologia OMT possui, depende da necessidade de cada
aplicação, isto é válido para o modelo de objetos, modelo dinâmico e modelo
funcional.
As seguintes regras práticas que devem ser seguidas dentro da metodologia
segundo [RUM94] são:
a) construir diagramas de estados somente para classes de objetos com
27
comportamento dinâmico significativo;
b) verificar a consistência dos diversos diagramas de estados relativamente
aos eventos compartilhados para que o modelo dinâmico completo fique
correto;
c) usar cenários para ajudar a iniciar o processo de elaborar diagramas de
estados;
d) considerar apenas atributos relevantes ao definir um estado. Nem todos os
atributos mostram em um modelo de objetos, precisam ser utilizados nos
diagramas de estados;
e) deixar a aplicação fazer a distinção entra atividades e ações. As atividades
ocorrem durante um período de tempo e as ações são instantâneas
comparadas a escala de tempo da aplicação;
f) quando um estado tiver múltiplas transações de entrada e todas elas
provocarem a ocorrência da mesma ação, colocar essas ações dentro de
quadros de estados precedidas por um evento entrada em vez de listá-las
em arcos de transições. Faça de forma semelhante com os eventos de
saída;
g) empregar estados multinivelados quando a mesma transição se aplicar a
muitos estados;
h) procurar fazer com que os diagramas de estados das subclasses sejam
independentes dos Diagramas de Estados das superclasses. Os
diagramas de estados das subclasses devem concentrar-se em atributos
pertencentes unicamente às subclasses;
i) evitar as indesejáveis condições de competição nos Diagramas de
Estados. Essas condições podem ocorrer quando um estado pode receber
eventos provenientes de mais um objeto.
3.3.3 MODELAGEM FUNCIONAL
O Modelo Funcional mostra o processamento dentro de um sistema,
descrevendo como os valores de saída são derivados dos valores de entrada sem
se preocupar com a ordem dos cálculos. O Modelo Funcional é representado por
28
meio de Diagramas de Fluxo de Dados (DFD) que mostram os valores de entrada,
processamento, armazenamento e valores de saída.
O Modelo Dinâmico controla as operações que são executadas e a seqüência
em que são aplicadas, o Modelo de Objetos define a estrutura dos dados sobre os
quais as operações atuam, e o Modelo Funcional atua sobre o modelo de objetos
através do processamento do fluxo de dados.
3.3.3.1 DIAGRAMA DE FLUXO DE DADOS (DFD)
“O Modelo Funcional é composto por múltiplos Diagramas de Fluxo de Dados
que especificam o significado das operações e restrições. Um Diagrama de Fluxo de
Dados mostra relacionamentos funcionais dos valores calculados por um sistema,
incluindo-se valores de entrada e de saída e depósitos internos de dados” [RUM94].
O Diagrama de Fluxo de dados mostra todas as entradas dos dados, os processos
que transformam estes dados para gerar uma saída e os objetos envolvidos no
sistema. Tem-se também os depósitos de dados onde serão armazenados os dados
do sistema.
Podemos concluir que um DFD contém processos que transformam dados,
fluxos de dados que movimentam os dados, objetos atores que produzem e
consumem dados, e objetos de depósitos de dados que armazenam os dados.
Um Diagrama de Fluxo de Dados é um processo de alto nível. Em seguida é
descrito alguns termos utilizados neste diagrama:
a) processos: transformam os dados de entrada. Ele indica o caminho que o
fluxo de dados vai seguir, mesmo tendo mais de um. Os processos são
implementados como métodos de operações em classes de objetos. São
representados por elipses;
b) fluxo de dados: é o caminho que faz a ligação da saída de um objeto (ou
processo) para a entrada de outro objeto (ou processo). O fluxo dos dados
não se modifica, apenas utiliza como um meio entre os objetos (ou
processos). São desenhados como uma flecha entre o produtor e
consumidor do valor dos dados;
29
c) atores: são objetos (ativo) que levam o Diagrama de Fluxo de Dados a
produzir ou consumir valores. Trabalham com os dados de entrada e saída
do sistema. Sempre serão extremidades do diagrama e são desenhados
como um retângulo para mostrar que ele é um objeto;
d) depósitos de dados: é um objeto (passivo) que armazena os dados em um
terminador para serem utilizados no futuro. Ele apenas guarda as
informações, sem que haja modificações entre estes dados. Um depósito
de dados não gera por si mesmo qualquer operação, apenas atende a
solicitação de armazenamento ou acesso aos dados. São desenhados
como um par de linhas paralelas contendo o nome do depósito. As setas
de entrada representam informações ou operações que modificam os
dados armazenados, e as setas de saída indicam recuperação de
informações do depósito;
e) fluxo de controle: o Diagrama de Fluxo de Dados mostra apenas os
caminhos possíveis. As decisões e seqüências são controlados e
especificados no Modelo Dinâmico. O Fluxo de Controle é um valor
booleano que afeta a maneira como um processo é avaliado e está sendo
controlado. Representa-se como uma linha pontilhada que parte de um
processo, produzindo em valor booleano para processo que está sendo
controlado.
3.4 PROJETO
O Projeto do sistema é a parte onde precisa-se pensar no que deve ser feito
depois da análise do problema. O projetista deve tomar cuidados quando organizar,
identificar e implementar um sistema para haver pouco manutenibilidade.
Os sistemas estão cada vez mais complexos e a tendência é aumentar cada
vez mais, tanto em termos funcionais como em fluxo de dados. Uma das
preocupações do projetista é desenvolver sistemas com mais rapidez e qualidade a
um custo baixo, pois a medida que passa o tempo, o usuário pode solicitar mais
mudanças, formando uma teia. As técnicas orientadas a objeto (OO) podem ser
usadas para simplificar o projeto de sistemas mais complexos. Esta técnica
30
vinculada a uma ferramenta case com um gerador de código e a um repositório que
seja ele mesmo orientado a objeto, constituem a melhor maneira de construir a
verdadeira engenharia de software, conforme [MAR96].
3.4.1 SISTEMA EM CAMADAS
Um sistema em camadas é um conjunto ordenado de mundos virtuais, cada
um construído em termos dos que lhes estão abaixo e proporcionando a base da
implementação dos que lhe estão acima. Os objetos em camadas podem ser
independentes, embora muitas vezes haja alguma correspondência entre os objetos
de diferentes camadas [RUM94].
Para um negócio expandir-se com sucesso, é necessário ferramentas da
última tecnologia e desenvolver aplicações para que elas possam se integrar em
qualquer plataforma. A tecnologia multi-tier (multicamadas) “força” a utilização de
novas metodologias para o desenvolvimento de sistemas.
Segundo [HAM99], uma arquitetura de aplicações dita o caminho através do
qual estas são criadas e como seus componentes serão distribuídos através do
sistema. A maioria das aplicações é feita de 3 tipos fundamentais de componentes:
a) interface: é um componente que contém a lógica que apresenta a
informação a uma fonte externa e obtém integradas a esta fonte. Na
maioria dos casos, a fonte externa é um usuário trabalhando num
computador;
b) execução: é um componente que contém a lógica da aplicação que
governa as funções do sistema e os processos executados pela aplicação.
Essas funções e processos são executados ou por um componente de
apresentação, quando um usuário executa uma opção, ou por uma outra
função do sistema;
c) banco de dados: é um componente de acesso a dados que contém a
lógica que fornece à interface um sistema de armazenamento de dados ou
com algum tipo de fonte de dados externos, como uma aplicação externa.
31
Há 3 tipos de camadas de arquiteturas que podem ser implementadas:
a) aplicações de uma camada: que trabalha em um ambiente onde todos os
componentes são combinados num único programa integrado e num único
computador. É mais utilizado em mainframes, pois o
gerenciamento,
controle e garantia de segurança de acesso aos aplicativos são simples e
fáceis, suportando vários usuários;
b) aplicações de duas camadas: permite a manipulação de funções. A
arquitetura cliente/ servidor em 2 camadas divide o processamento entre
uma estação desktop e uma máquina servidora. Não há muita segurança
neste tipo de arquitetura e não suporta muitos usuários;
c) aplicações de multicamadas: junta-se os dois tipos de camadas. Este
modelo multi-tier divide a aplicação nas seguintes camadas: lógica da
apresentação, lógica no sistema e lógica de acesso aos dados. Os
componentes comunicam entre si utilizando uma interface abstrata, que
funciona como um contrato. Tem-se a possibilidade de serviços de
localização, segurança e comunicação entre os componentes da
aplicação.
As vantagens da utilização da aplicação em multicamadas é a reutilização de
objetos por outras aplicações, podendo ser reutilizado ou compartilhado por outros
sistemas, facilidade na manutenção pois modifica-se apenas um módulo e este tipo
de arquitetura, não tem vínculo direto a estruturas de banco de dados e os objetos
individuais trabalham com as suas próprias estruturas de dados, que podem
corresponder ao banco de dados. Quando os objetos na aplicação se comunicam,
passam apenas os parâmetros sem a necessidade de passar os registros de um BD,
diminuindo o fluxo de dados na rede [HAM99].
3.5 A DIFERENÇA ENTRE AS METODOLOGIAS
Um programa desenvolvido em orientação a objetos é organizado como uma
coleção de objetos separados, que incorporam tanto a estrutura quanto o
comportamento dos dados. Já no tradicional temos os dados e suas procedures sem
32
vínculos a eles. Podemos definir que objeto é uma entidade que combina métodos
(procedures) e atributos (dados) de um dado [RUM94]. Abaixo é mostrado na
FIGURA 3.13 e FIGURA 3.14, a diferença entre um programa tradicional e OO.
FIGURA 3.13: DIFERENÇA ENTRE AS TÉCNICAS
Fonte: [BRA99]
Um conceito importante é a não separação dos dados e das funções que
manipulam estes dados.
FIGURA 3.14: COMO AS TÉCNICAS TRABALHAM
Fonte: [BRA99]
33
4 AMBIENTE DE DESENVOLVIMENTO
4.1 FERRAMENTAS CASE
A ferramenta case constrói dentro de si próprio um banco de dados do projeto,
a um nível mais alto do que comandos de linguagens de programação ou definição
de elementos de dados. Este banco de dados do projeto, que chamamos de
Repositório, mantém informações sobre os dados a serem armazenados no sistema,
sobre a lógica dos processos a serem implementados, a diagramação das telas e
relatórios e outras informações relativas aos requisitos dos sistemas e do projeto. O
objetivo principal da tecnologia case é separar o projeto do programa aplicativo da
implementação do código [ECH99].
Segundo [TOL99], alguns especialistas acham que uma ferramenta precisa:
a) variedade de metodologias para desenvolvimento;
b) facilidade de encontrar erros lógicos;
c) execução de animação do diagrama;
d) baixo custo e de fácil utilização;
e) facilidades de implementação nas ligações entre as classes hierárquicas;
f) possibilidade de construções não-lineares de diagramas;
g) prover versões de controle dos diagramas;
h) suportar grupos de trabalho (múltiplos usuários);
i) gerar códigos e diagramas a partir deste;
j) possuir "ganchos" para outras API's de programação.
As ferramentas case orientada a objetos está a ponto de se tornarem um novo
paradigma da programação, análise e projeto de sistemas. Um paradigma que
efetivamente venha de encontro às necessidades do mundo da informática de hoje
[TOL99].
As principais características da ferramenta case são:
34
a) modelagem dos dados do sistema;
b) construção de modelagem a nível de documentação;
c) construção de modelos sem que haja violação das normas da metodologia;
d) geração de scripts dos dados;
e) teste de consistência.
4.1.1
FERRAMENTA
ARCHITECT
CASE
POWER
DESIGNER
DATA
A ferramenta case Power Designer Data Architect (FIGURA 4.1) provê
tradicionais capacidades de modelagem de dados, inclusive banco de dados,
geração, manutenção, reengenharia e documentação para arquitetura de banco de
dados. Permite aos projetistas de banco de dados a criar dados flexíveis, eficientes e
efetivos estrutura para uso pela máquina de banco de dados de uma aplicação. Esta
ferramenta oferece um modelo de dados conceitual, dados físicos gerados
automaticamente pelo modelo.
FIGURA 4.1: TELA PRINCIPAL DO POWER DESIGNER DATA ARCHITECT
35
Nesta ferramenta pode-se trabalhar com as modelagens dos dados e construir
o Diagrama de Entidade-Relacionamento, com as classes e relacionamentos entre
elas, e assim, gerar o banco de dados do sistema.
4.1.2 FERRAMENTA RATIONAL ROSE C++
A Rational Rose (FIGURA 4.2) é uma ferramenta orientada a objetos para
análise, modelagem, projeto e construção de sistemas. Pode-se trabalhar com as
modelagens dos dados, construir os Diagramas de Use Cases, Diagrama de
Classes e Diagrama de Estados para um sistema.
A ROSE é uma das ferramentas mais interativas do mercado, é fácil de se
usar, sua interface é amigável, e pode-se implementar as técnicas de modelagem
existentes no mercado, como a OMT e a UML de forma completa. Gera código para
uma grande variedade de linguagens, como Visual Basic, Java, C++, Delphi e
outras. Possui também uma integração bastante forte com a maioria dos produtos de
engenharia de software para testes, gerenciamento de versões e outras atividades
externas a um case de modelagem [TEC99].
FIGURA 4.2 : TELA PRINCIPAL DA RATIONAL ROSE
36
4.2 AMBIENTE VISUAL DELPHI 3
A linguagem de Programação Delphi 3 foi desenvolvida pela empresa Borland
Internacional Inc. a fim de ajudar os usuários a trabalharem com mais rapidez, e
demonstra uma apresentação de interface mais amigável e prática. Com esta
linguagem pode-se aplicar tanto a programação orientada a objetos como a
estruturada.
O Delphi é a programação Pascal desenvolvida em OO, herdando os
comandos e suas funções básicas, podendo trabalhar com tipos de banco de dados
diferentes. Nesta linguagem pode-se reutilizar os códigos já criados, como units,
packages, functions, procedures do próprio Delphi, e tendo como exemplo a sua
própria implementação.
O código de programação em Delphi, diz ao seu programa como responder
aos eventos como cliques do mouse, que são chamados de procedimentos de
eventos. Um procedimento de evento é um bloco de código executado apenas em
resposta a um evento externo [COR95].
O Delphi tem a capacidade de utilizar algumas funções da API do Windows e
estão disponíveis na Unit WinProcs. Quando um projeto é desenvolvido no Delphi,
são criados alguns arquivos de relacionamentos entre eles para manipulação do
aplicativo. Abaixo segue o quadro (QUADRO 4.1), conforme [VIV97]:
37
QUADRO 4.1: ARQUIVOS DO DELPHI
Elemento
Extensão
Descrição
Formulário
DFM
Definições dos componentes de cada janela do aplicativo,
é criado um arquivo para cada janela.
Unit
PAS
Código fonte do aplicativo, onde são armazenados os
eventos. É criado um arquivo para cada janela.
Projeto
DPR
Faz a comunicação entre todos os componentes de um
projeto e o relacionamento entre eles.
Compilado
DCU
Arquivo resultante da compilação das Unit’s. Será gerado
pela linkedireção dos componentes do projeto.
Executável
EXE
Arquivo que contém os recursos de tela, como ícones,
imagens e cursores que serão utilizados no aplicativo.
Recursos
RES
Arquivos gerados quando são efetuadas as alterações nos
arquivos originais do aplicativo.
Backup
DF, DP,
Arquivos gerados quando são efetuadas alterações nos
arquivos originais do aplicativo.
PA, RE
Fonte : [VIV97]
4.2.1 BANCO DE DADOS
Para uma aplicação voltada à área de eventos, é necessário a utilização de
um banco de dados e de um gerenciador para que possa guardar e manipular os
dados obtidos. Neste trabalho utilizou-se o banco de dados do próprio Delphi, o BDE
para armazenamento dos dados e o PARADOX 7.0 para o gerenciamento destes.
Em geral, as necessidades do usuário de um banco de dados tendem a
aumentar, à medida que o tempo passa. Num primeiro momento, é importante que
se possa criar uma tabela com facilidade e rapidamente, introduzir dados e produzir
relatórios. Estas são as tarefas mínimas que nunca perdem sua importância, e o
sistema de banco de dados deve ser maleável para ampliação, conforme as
necessidades do usuário.
Os dados tendem a aumentar com o tempo e é importante que se possa
38
dividí-los em pequenas tabelas, de fácil manipulação. Em seguida, é necessário que
se possa unir essas tabelas sem dificuldade para consultar os dados em várias
delas. O PARADOX proporciona a capacidade para fazer isto de maneira simples e
rápida e tem compatibilidade com o Delphi [SIM97].
4.2.2 COMPONENTES DO DELPHI
Como o Delphi trabalha com programação OO, os recursos e a interface
utilizados por ele, são objetos que são tratados como um componente desta
linguagem. O Delphi é formado por quatro partes:
a) a janela principal, na parte superior tem-se o menu, as barras de
ferramentas e as paletas contendo os componente visuais (Edit, Label) e
não-visuais (Table, Query, Time) para serem utilizados nos Form’s;
b) o Form é a tela onde o usuário pode trabalhar no desenvolvimento da
interface do protótipo, através de rótulos (labels), botões e outros
componentes;
c) o Code Editor é a área de desenvolvimento das rotinas e procedimentos
(código-fonte) utilizados pelo protótipo, e que o Delphi gerará códigos para
o controle dos componentes utilizados no Form. Alguns códigos o próprio
Delphi são definidos automaticamente, e o usuário pode implementá-los
manualmente;
d) o Object Inspector é uma janela dividida em Properties (Propriedades) e
Events (Eventos), que são utilizados para configuração dos objetos em
tempo de projeto ou até mesmo em tempo de execução. A pasta
Properties contém as propriedades ligadas a cada componente no Form e
Events contém todos os eventos para o controle do componente.
39
5 ESPECIFICAÇÃO DO PROTÓTIPO
5.1 CARACTERÍSTICAS
As características esperadas por este protótipo são:
a) rapidez no atendimento aos participantes;
b) controle eficaz de presenças durante o evento;
c) confiabilidade nos dados;
d) facilidade no uso deste, sendo de uma forma simples e direta.
5.2 DEFINIÇÃO
O protótipo é um aplicativo que pode ser utilizado por qualquer empresa
promotora para a realização do controle dos dados de um determinado evento.
O cadastro dos participantes deve permitir a inscrição com seus dados (nome,
endereço, cidade, por exemplo) e em seguida, é salvo em uma tabela BDE do
PARADOX 7.0. Podemos fazer um novo cadastro e até mesmo uma localização de
uma inscrição para alterar algum erro de digitação. Também é possível o cadastro
do tema das palestras com seus respectivos palestrantes, data e hora de
apresentação.
Pode-se fazer cadastro dos eventos, cadastro da área que o palestrante atua
e cadastro das organizações a qual o palestrante pertence. Esses cadastros devem
permitir incluir um novo cadastro, salvar e localizar um participante específico para
alteração dos dados através das janelas do protótipo.
Com os cadastros, o usuário poderá controlar a presença dos participantes
dentro das salas de palestras, passando o cartão magnético no leitor ou digitando o
número da inscrição para sua confirmação. Pode-se fazer consultas de participantes,
palestrantes com suas respectivas palestras, eventos e organizações, podendo
assim excluir um registro, e emitir recibo e certificado ao participante.
O protótipo dispõe-se de relatórios finais, para que se ter um controle de todo
o evento, e gera um arquivo com todos os participantes inscritos. Antes da
impressão, o usuário pode ter uma visualização do relatório na tela.
40
O protótipo também mostra na tela, um preview do evento, com a quantidade
de participantes inscritos, quantidade de inscritos por categoria e valor pago na
inscrição durante o evento.
5.3 DIAGRAMA DE CONTEXTO
FIGURA 5.1: DIAGRAMA DE CONTEXTO
Participante
Administrador
Cadastra
Relatórios
Presença
Recibo
Sistema de
Administração
Certificado
Consulta Dados
Importa Dados
Organiza Palestras
Recebe Cronograma
5.4 MODELO DE INTERFACE COM USUÁRIO
O modelo de interface com usuário representa um esboço de como será
representado o sistema ao usuário para abertura das telas de acordo com o que se
pede. Após a realização de uma análise de dados e ter um conhecimento do
funcionamento, podemos montar a primeira versão de interface do usuário.
5.5 FASE DE ANÁLISE
O objetivo desta fase é entender os requisitos, explorar o problema e
identificar as classes, objetos e sua relação.
41
5.5.1 ANÁLISE DE VERBOS E SUBSTANTIVOS
Foram relacionados os verbos e substantivos presentes na descrição do
protótipo. Em seguida, foi analisado e escolhido os eventuais candidatos a objetos
(QUADRO 5.1).
QUADRO 5.1: QUADRO DE VERBOS
Incluir
Excluir
Imprimir
Consultar
Salvar
Gerar
Visualizar
Os substantivos encontrados na descrição do protótipo estão no QUADRO 5.2
abaixo:
QUADRO 5.2: QUADRO DE SUBSTANTIVOS
Administrador
Telefone
Sit. Financeira
Categoria
Participante
Palestrante
Organização
Tema
Código Participante
Hora Inicial Palestra
Certificado
Endereço
Código do Evento
Hora Final da Palestra
Data da Palestra
Recibo
Código do Período
Alojamento
Sistema Admin.
Período
Código do Palestrante
Valor Pago
Local do Evento
Estado
Código da Palestra
Nome do Evento
Data do Evento
Área
Código da Organização
Nome do Participante
Hora da Presença
Palestra
Código da Área
Identidade
Observação
Cidade
Os eventuais candidatos a objetos são (QUADRO 5.3):
42
QUADRO 5.3: QUADRO DE OBJETOS
Participante
Presença
Palestras
Palestrante
Área
Organização
Período
Evento
Os eventuais candidatos a atributos são (QUADRO 5.4):
QUADRO 5.4: QUADRO DE ATRIBUTOS
Código da Área
Telefone
Sit. Financeira
Categoria
Código da Palestra
Palestrante
Organização
Tema
Código Participante
Hora Inicial Palestra
Certificado
Endereço
Código do Evento
Hora Final da Palestra
Data da Palestra
Recibo
Código do Período
Alojamento
Cidade
Período
Código do Palestrante
Valor Pago
Local do Evento
Estado
Código da Organização
Nome do Evento
Data do Evento
Área
Observação
Nome do Participante
Hora da Presença
Palestra
Identidade
Os eventuais candidatos a métodos são (QUADRO 5.5):
QUADRO 5.5: QUADRO DE MÉTODOS
Incluir
Salvar
Excluir
Consultar/ Alterar
Imprimir
43
A fase de análise está preocupada com as primeiras abstrações e
mecanismos que estarão presentes no domínio do problema. No Diagrama de
Classes são modeladas as classes e seus relacionamentos. Na FIGURA 5.2,
podemos analisar o Diagrama de Classes.
FIGURA 5.2: DIAGRAMA DE CLASSES
Interface
Gravar( )
Consultar( )
Excluir( )
Exibir( )
Palestrante
CD_PALESTRANTE : INTEGER
NM_PALESTRANTE
Constructor( )
Destructor( )
Consultar( )
1+
1+
Palestra
CD_PALESTRA : INTEGER
DS_TEMA : STRING = 100
NM_PALESTRANTE : STRING = 60
DT_DATA : DATE
HR_INICIAL : TIME
HR_FINAL : TIME
1+
Evento
CD_EVENTO : INTEIRO
DS_EVENTO : TEXTO
DS_LOCAL : STRING = 20
DT_DATA : DATE
Constructor( )
Destructor( )
Constructor( )
Destructor( )
Cadastra Dado( )
1+
Área
CD_AREA : INTEGER = 12
DS_AREA : STRING = 20
Constructor( )
Destructor( )
Período
CD_PERIODO : INTEGER
DS_PERIODO : STRING = 12
Constructor( )
Destructor( )
Cadastra Dados( )
Consultar( )
Presença
DT_DATA : TIME
Constructor( )
Destructor( )
freqüenta( )
Consulta( )
Gera Certificado( )
1+
Organização
CD_ORGANIZACAO : INTEGER = 12
DS_ORGANIZACAO : STRING = 20
1+
Constructor( )
Destructor( )
Imprime( )
1+
Participante
(from Use Case View)
Inscrever( )
Consulta( )
Criar( )
Banco de Dados
Grava( )
Consulta( )
Exclui( )
Cadastra Dados( )
44
5.5.2 MODELO DE OBJETOS DE ANÁLISE – FASE ESTÁTICA
O protótipo tem nesta fase um modelo de objetos (FIGURA 5.3), como é
apresentado a seguir:
FIGURA 5.3: MODELO DE OBJETOS DA ANÁLISE
Palestra
Evento
CD_PALESTRA : INTEGER
NM_PALESTRA : STRING = 100
DT_DATA : DATE
HR_HORA : TIME
CD_EVENTO : INTEGER
NM_EVENTO : STRING = 30
1+
Cons truct( )
Destruct( )
Cons truct( )
Destruct( )
1+
Período
CD_PERIODO : INTEGER
DS_PERIODO : STRING = 12
Construct( )
Des truct( )
1+
Participante
Pres ença
Construct( )
Des truct( )
CD_PARTICIPANTE : INTEGER
NM_PARTICIPANTE : STRING
DS_ENDERECO : STRING = 30
NM_CIDADE : STRING = 20
DS_ESTADO : SORT = 2
CONSTRUCT( )
DESTRUCT( )
5.5.3 USES CASES DE ANÁLISE – MODELO DINÂMICO
De acordo com a Metodologia, os uses cases identificados anteriormente
serão revistos e melhor detalhados. É uma técnica usada para descrever e definir os
requisitos funcionais de um sistema. Os atores são entidades externas e iniciam a
comunicação com o sistema através dos uses cases, que representam uma
seqüência de ações. Na FIGURA 5.4, pode-se analisar o Diagrama de Uses Cases
do protótipo e na FIGURA 5.5, tem-se o Diagrama de Eventos.
45
FIGURA 5.4: DIAGRAMA DE USES CASES
Fazer Inscrição
Participante
Adm inis trador
Importar
Verificar Frequência
Inscrever Palestras
Gerar Certificado
Fazer Consulta
Montar Evento
FIGURA 5.5: DIAGRAMA DE EVENTOS
A) DIAGRAMA DE EVENTOS: INSCRIÇÃO
: Interface
: Banco de
Dados
: Participante
Criar (
Inscrever ( )
Grava ( )
Exibir (
46
B) DIAGRAMA DE EVENTOS: CERTIFICAÇÃO
: Interface
: Presença
: Banco de
Dados
Constructor ( )
Consulta ( )
Gera Certificado ( )
Exibir (
C) DIAGRAMA DE EVENTOS: PRESENÇA
: Interface
: Pres ença
: Participante
: Banco de
Dados
Criar (
Consulta ( )
freqüenta (
Consulta ( )
Grava ( )
Exibir (
47
D) DIAGRAMA DE EVENTOS: CONSULTA
: Interface
: Presença
Constructor ( )
: Banco de
Dados
Consulta ( )
Exibir (
E) DIAGRAMA DE EVENTOS: MONTAGEM
: Interface
: Evento
: Palestra
: Período
: Palestrante
: Banco de
Dados
Constructor ( )
Grava ( )
Cons tructor ( )
Consultar (
Consulta ( )
Consultar (
Consulta ( )
Exibir (
Grava ( )
Exibir (
48
Um cenário é uma instância de um Use Case, onde apresenta-se o caminho
específico de cada ação. Segue os cenários do protótipo:
5.5.3.1 CENÁRIO 1 – FAZER INSCRIÇÃO
Neste cenário o usuário cadastra os participantes com seus respectivos
dados. Caso o número de inscrição esteja cadastrado, aparecerá uma mensagem de
aviso. Pode-se pesquisar uma inscrição caso tenha-se dúvidas, clicando apenas no
botão Localizar. Abre-se uma janela onde pode-se passar o cartão magnético ou
digitar manualmente o número da inscrição, abrindo logo em seguida o cadastro
daquele participante. Faz-se a modificação daquele cadastro e salva-se clicando no
botão Salvar.
5.5.3.2 CENÁRIO 2 – VERIFICAR FREQÜÊNCIA
Neste cenário o participante pode obter sua presença durante o evento,
passando o cartão magnético na leitora e automaticamente registrará a inscrição,
presença, data e hora. Tem-se a opção de digitar manualmente o número do
participante via teclado. Caso o participante já tenha presença, aparecerá uma
mensagem com presença já cadastrada.
5.5.3.3 CENÁRIO 3 – IMPORTAR DADOS
Neste cenário o usuário poderá importar dados de um arquivo com formato
texto (.txt), onde estão armazenados as inscrições dos participantes feitas via
internet. É necessário que neste arquivo tenha o nome do participante e o número
de inscrição separados por vírgula em uma única linha. O usuário abre o arquivo
com estes dados, e clica no botão Leitura dos dados, sendo que, será lido linha a
linha e importa-se para o banco de dados. No término da importação, aparecerá uma
mensagem de conclusão.
5.5.3.4 CENÁRIO 4 – FAZER CONSULTA
Neste cenário o usuário escolhe a opção de consultar participantes por nome
ou por número de inscrição descritos no componente desta janela. Se o usuário
49
colocar a opção por nome, basta digitar o nome do participante, que o protótipo irá
localizar. Caso a opção for por número, pode-se digitar o número da inscrição ou
simplesmente passar o cartão magnético que automaticamente mostrará o nome do
participante. Caso queira excluir um participante, posicione o cursor no nome deste e
clica-se no botão Excluir, que irá pedir confirmação da exclusão.
Durante a digitação dos dados da consulta, o protótipo vai pesquisando
caracter a caracter, mostrando os participantes cadastrados cujos primeiros
caracteres de seus dados para o campo de pesquisa escolhido pelo usuário sejam
coincidentes com os caracteres já informados.
O protótipo permite que o usuário possa fazer uma navegação pelos nomes
através dos botões: primeiro, anterior, próximo e último.
5.5.3.5 CENÁRIO 5 – INSCREVER PALESTRAS
Neste cenário o usuário cadastra as palestras com seus respectivos dados
como palestrantes, data de apresentação, hora inicial e hora de término. Caso a
palestra já estiver cadastrada, mostrará uma mensagem de confirmação.
5.5.3.6 CENÁRIO 6 – GERAR CERTIFICADO
Neste cenário o usuário clica no botão Imprimir, e automaticamente o protótipo
lista os participantes com presença em todos os dias do evento. Logo em seguida,
abre-se uma janela com um preview dos certificados que serão impressos, onde o
usuário pode ter a opção de navegar pelos registros, salvar em um arquivo texto ou
imprimir. Caso houver erro de impressão em um certificado específico, posicione o
cursor no nome do participante e dê um duplo clique que o protótipo pedirá a
confirmação para segunda via de impressão.
O protótipo gera um arquivo em formato texto (nome.txt) no diretório raiz (C:\),
com todos os participantes com as presenças em dia.
50
5.5.4 MODELO FUNCIONAL
Seguindo a metodologia apresentada em [RUM94], as classes identificadas no
modelo de objetos foram convertidas em tabelas. Nas FIGURAS 5.6 e 5.7, tem-se o
Modelo
de
Entidade-Relacionamento
e
Diagrama
de
Fluxo
de
Dados,
respectivamente.
FIGURA 5.6: MODELO DE ENTIDADE-RELACIONAMENTO
Palestrante
código do
palestrante
nome do
palestrante
Área
código da área
descrição da área
Relation_13
0
Palestras
código da palestra
tema da
palestra
data da apresentação
hora inicial da
palestra
hora final da
palestra
Período
código do
período
descrição do
período
i
Presença
data da entrada
hora da entrada
presença
Organização
código da
organização
nome da
organização
Eventos
código do evento
nome do
evento
local do evento
data do evento
Participante
código do
participante
nome do
participante
identidade
endereço
telefone
cidade
estado
categoria
alojament
o
valor pago
situação financeira
observação
51
FIGURA 5.7: DIAGRAMA DE FLUXO DE DADOS
1
Participante
Importação Dados
Dados Pessoais
Inscrever
Organização
Inscrição
Identificador
Inscritos
Inscrito
Palestrante
Período Evento
5
Cadastrar
Palestras
2
Freqüentar
Inscrição da Palestra
Presença
3
Gerar
Certificado
6
Cadastro de Presença
Montar
Evento
Presença
Eventos
Palestras
Eventos
Palestrantes
Período
Palestras
Presença
Palestrantes
Período
Períodos
4
Organização
Consulta
Consultar
Palestrantes
Palestras
Eventos
5.6 FASE DE PROJETO
Nesta fase, o objetivo principal é identificar a arquitetura do sistema, decidir
como implementar o modelo de objetos identificado na fase de análise.
5.6.1 MODELO DE OBJETOS
Conforme [RUM94] existe uma ênfase dos conceitos do domínio da aplicação
para os conceitos do computador. Os objetos descobertos durante a análise, servem
como base para o projeto, mas o projetista de objetos deve escolher entre diferentes
maneiras de implementá-los buscando a minimização do tempo de execução,
52
memória e outras medidas de custo. Novas classes de objetos devem ser
introduzidas para armazenar resultados intermediários durante a execução do
programa e para evitar a necessidade de re-computação.
Para a implementação do protótipo, optou-se
na utilização da ferramenta
case Power Designer 6.1 (Sybase) e Rational Rose C++ (Sybase), para modelagem
dos dados, o DELPHI versão 3.0 – Client/Server para implementação e o PARADOX
7.0, para gerenciar o banco de dados, ambos da Borland Inc.
A seguir, mostra-se todas as tabelas necessárias para o desenvolvimento do
protótipo, com seus campos, tipo e tamanho.
As notações utilizadas são:
a) tipos de chaves:
- *
: chave primária;
- CS : chave secundária;
- CE : chave estrangeira.
b) tipos de dados:
- A : alfa-numérico;
- S : short;
- D : date;
- T : time;
- M : memo;
- $ : money;
- L : logic.
53
TABELA 5.6: TABELA DE PARTICIPANTES
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_EVENTO
Código do Evento
I
CD_PARTICIPANTE
Número de inscrição
A
12
*
CD_IDENTIDADE
Identidade do participante
A
15
CS
NM_PARTICIPANTE Nome do participante
A
60
CS
DS_ENDERECO
Endereço residencial
A
70
NR_TELEFONE
Telefone
A
16
NM_CIDADE
Cidade onde mora
A
20
DS_ESTADO
Estado
A
2
DS_CATEGORIA
Categoria do participante
A
20
DS_ALOJAMENTO
Caso necessite de alojamento
S
VL_VALORPAGO
Valor pago
$
DS_SITFINANCA
Situação está em dia ou não
A
10
DS_OBSERVAÇÃO
Alguma observação
M
60
CD_ORGANIZACAO Código da Organização
*
I
TABELA 5.7: TABELA DE PALESTRAS
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_EVENTO
Código do Evento
I
*
CD_PALESTRA
Código da palestra
I
*
DS_PALESTRA
Tema da palestra
A
CD_PALESTRANTE
Código do palestrante
I
DT_DATA
Data da apresentação
D
HR_INICIAL
Hora do início da palestra
T
HR_FINAL
Hora do término da palestra
T
CD_AREA
Código da Área
I
100
CS
54
TABELA 5.8: TABELA DE PRESENÇAS
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_PARTICIPANTE
Inscrição do participante
A
12
CE
DS_TURNO
Turno da entrada
S
1
CE
DT_DATA
Data da entrada
D
HR_ENTRADA
Hora da entrada
T
DS_PRESENCA
Presença do participante
L
TABELA 5.9: TABELA DE EVENTOS
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_EVENTO
Código do evento
I
*
DS_EVENTO
Nome do evento
A
20
DS_LOCAL
Local a ser realizado
A
20
DT_INICIAL
Data inicial do evento
D
DT_FINAL
Data final do evento
D
DS_IMAGEM
Descrição do logo do evento
A
CS
50
TABELA 5.10: TABELA DE PERÍODO
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CS_PERIODO
Código do período
I
DS_PERIODO
Descrição do período
A
*
12
55
TABELA 5.11: TABELA DE PALESTRANTE
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_EVENTO
Código do evento
I
*
CD_PALESTRANTE
Código do palestrante
I
*
NM_PALESTRANTE Nome do palestrante
A
CD_ORGANIZACAO Código da organização
I
60
CS
TABELA 5.12: TABELA DE ORGANIZAÇÃO
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_ORGANIZACAO Código da organização
I
*
NM_ORGANIZACAO Nome da organização
A
20
NM_CIDADE
Cidade da organização
A
20
DS_ESTADO
Estado da organização
A
2
CS
TABELA 5.13: TABELA DA ÁREA
CAMPO
DESCRIÇÃO
TIPO TAMANHO CHAVE
CD_EVENTO
Código do evento
I
*
CD_AREA
Código da área
I
*
DS_AREA
Descrição da área
A
30
CS
56
6 IMPLEMENTAÇÃO
Neste capítulo, descreve-se como foi desenvolvido o protótipo na linguagem
visual Delphi 3 Client/Server, com o propósito de administrar um evento. Será
mostrado o lay-out das telas e relatórios implementados de uma forma bem clara e
de fácil entendimento aos usuários.
A aplicação tem como objetivo principal cadastrar participantes e controlar sua
presença durante o evento. As telas foram desenvolvidas como um modelo “padrão”
dos eventos na qual trabalhou-se e teve-se a oportunidade de conhecer o processo
de planejamento.
O protótipo foi validado nos eventos: VI CONGRESSO DA FAMESC e no VIII
SEMINCO, a fim de poder ajustá-lo para que seu desempenho melhore cada vez
mais em suas versões.
As telas serão exibidas e descritas de acordo com suas funções. A Tela
Principal do protótipo tem como as opções no menu principal: Inscrição, Controle,
Imprimir, Relatórios e Informações.
6.1 TELAS
Esta seção, serão mostrados algumas telas existentes no protótipo.
Na abertura do protótipo, é mostrado uma tela com uma LISTA DE EVENTOS
cadastrados. Escolhe-se o evento que será administrado, clicando no seu nome e
depois no botão Entrar. Caso o evento não estiver na lista, tem-se a opção de
cadastrar, clicando no botão Cadastrar. Abre-se um janela com os dados do evento,
podendo cadastrar, e depois entrar com este evento. Todas estas operações estarão
dentro deste evento escolhido, mostrando o nome nas janelas abertas e relatórios
em geral (FIGURA 6.1).
57
FIGURA 6.1 : TELA DE SELEÇÃO DE EVENTOS
Abre-se a Tela de Menu Principal, com a escolha do evento, como pode
visualizar-se na FIGURA 6.2.
FIGURA 6.2: TELA PRINCIPAL DO PROTÓTIPO
58
Na tela de Cadastro de Participantes é feito o cadastramento dos
participantes com os campos que identificam os mesmo. A inscrição pode ser feita
através do cartão magnético, passando-o no leitor, que automaticamente, registrará
o número de inscrição no campo. Pode-se localizar um cadastro clicando no botão
Localizar, onde será aberta uma janela para a digitação do número de inscrição a
ser localizado. Logo em seguida, mostrará todos os dados, podendo alterá-lo e
salvá-lo novamente (FIGURA 6.3).
FIGURA 6.3: CADASTRO DE PARTICIPANTES
O cadastramento das palestras é feito na tela Cadastro de Palestras
(FIGURA 6.4), onde é informado o tema da palestra, data, hora inicial e hora final.
Para os demais itens da tela, clica-se no botão para que seja aberta uma lista dos
dados cadastrados, que estão relacionados com sua tabela. Pode-se inserir um
novo cadastro, salvar e cancelar.
59
FIGURA 6.4: CADASTRO DE PALESTRAS
As outras telas de cadastros, como o Cadastro de Organização, Palestrante e
Área, são idênticas a esta, modificando apenas os dados a serem cadastrados de
acordo com o tipo que se deseja, e pesquisados na tabela específica.
Na Tela de Importação dos Dados, o usuário pode importar dados de um
arquivo. Para isso, dá-se um clique no botão Importar e selecione o arquivo com o
nome do participante e sua inscrição. Neste caso, o Centro de Processamento de
Dados disponibilizou a inscrição dos alunos da Computação via Internet, através de
um banco de dados ORACLE, e salvou-se como arquivo de formato texto
(Sem99.txt). Quando é chamado o arquivo, o protótipo visualiza o arquivo para
confirmação do conteúdo a ser importado. Clica-se no botão Leitura dos Dados, e o
protótipo automaticamente vai ler, linha a linha, incluindo as inscrições no banco de
dados da tabela de Participantes. Será mostrado uma mensagem ao encerramento
do processo (FIGURA 6.5).
60
FIGURA 6.5: IMPORTAÇÃO DOS DADOS
Na Tela de Presença, é feita a presença aos participantes que participam do
evento. Nesta tela, é digitado o número de inscrição ou passa-se o cartão magnético
para registro da data e a hora. Será mostrado uma mensagem avisando o sucesso
cadastro. Caso o participante não estiver cadastrado ou já estiver com sua presença,
aparecerá uma mensagem de aviso. Esta mensagem fica exposta durante 3
segundos, e automaticamente se fecha, ficando pronta para o próximo cadastro
(FIGURA 6.6).
FIGURA 6.6: CONTROLE DE PRESENÇA
61
Na Tela de Localizar Participantes, o usuário pode localizar um participante
através de seu nome ou número de inscrição, digitando ou utilizando o cartão
magnético no leitor, como mostra a FIGURA 6.7. Pode-se fazer localização das
palestras e palestrantes, eventos e organização em suas respectivas telas, podendo
navegar através dos registros pelos botões: primeiro, anterior, posterior e último, e
excluir um determinado registro.
FIGURA 6.7: TELA DE LOCALIZAR PARTICIPANTES
No Menu de Emissão, tem-se as opções de Emitir Certificado de acordo com
suas telas. Serão impressos os certificados para os participantes cuja suas
presenças estão nos dias do evento. Caso houver erro de impressão, pode-se
imprimir apenas aquele certificado, pesquisando na tela o nome do participante, e
clica-se duas vezes encima do nome para conclusão desta operação. No Anexo 6,
tem-se um modelo do Certificado impresso pelo protótipo.
No Menu de Relatórios, tem-se como opção, uma lista de relatórios da qual o
usuário pode visualizar em modo preview e assim, imprimí-lo. Na FIGURA 6.8 temos
um modelo do Relatório de Participantes, onde estão todos os participantes
cadastrados do evento.
62
FIGURA 6.8: RELATÓRIO DE PARTICIPANTES
Na FIGURA 6.9 temos um modelo, o Relatório de Palestras, onde mostra
todos as palestras com sua respectiva data e palestrante, daquele evento.
FIGURA 6.9: RELATÓRIO DE PALESTRAS
63
Na FIGURA 6.10 temos um modelo, o Relatório de Participantes X
Categoria, que mostra os participantes com sua respectiva categoria e inscrição.
FIGURA 6.10: RELATÓRIO DE PARTICIPANTES X CATEGORIA
Na FIGURA 6.11 temos um modelo, o Relatório de Presenças, que mostra o
nome do aluno, os dias em que ele participou e a hora. Todos os relatórios do
protótipo dispõe de um preview em tela antes de direcionar o relatório para a
impressora.
64
FIGURA 6.11: RELATÓRIO DE PRESENÇAS
Na FIGURA 6.12 temos um modelo, o Relatório de Alojamento, que mostra
os nomes dos participantes que necessitam de alojamento. Este dado é feito do
Cadastro de Participantes.
FIGURA 6.12: RELATÓRIO DE ALOJAMENTO
65
Na FIGURA 6.13 temos um modelo, o Relatório de Eventos, que mostra
todos os eventos cadastrados no protótipo, com seu código, local, data inicial e data
final do evento.
FIGURA 6.13: RELATÓRIO DE EVENTOS
No Menu de Informações, a Tela de Preview, é mostrado um preview do
evento, de acordo com os dados cadastrados no protótipo. Na FIGURA 6.14, mostra
um preview simplificado.
66
FIGURA 6.14: PREVIEW DO PROTÓTIPO
No Menu de Informações, temos ainda a Tela Sobre o Sistema, com algumas
informações sobre o protótipo, como mostra a FIGURA 6.15.
FIGURA 6.15: INFORMAÇÕES SOBRE O PROTÓTIPO
6.2 RELATÓRIOS
O protótipo gerará uma série de relatórios, como a lista a seguir:
67
a) relatório de participantes;
b) relatório de palestras e palestrantes;
c) relatório de participantes e categorias;
d) relatório de presenças;
e) relatório de alojamento;
f) relatório de eventos.
6.3 INTERFACE
O protótipo foi desenvolvido para ambiente Windows 95 ou superior,
aproveitando os recursos próprios dele, já que os usuários estão mais familiarizado
com este padrão de interface gráfica.
6.4 INTEGRAÇÃO
A partir de problemas vistos em atrasos no atendimento ao público,
desenvolveu-se o protótipo CICON versão 1.0 para agilizar o atendimento e ter
acesso rápido aos dados. Na área de eventos, o mais
importante fator é o
atendimento aos participantes, sem que haja muita demora e assim, buscar
informações para a empresa contratante com precisão.
Logo, o protótipo tem informações como:
a) cadastro das inscrições dos participantes;
b) cadastro das palestras;
c) cadastro de eventos;
d) cadastro de palestrantes;
e) cadastro de organização;
f) cadastro de área de atuação do palestrante;
g) importação dos dados de um arquivo;
h) consultas dos cadastros;
i) controle de presenças.
68
O protótipo disponibilizará informações como:
a) relatórios específicos do evento;
b) lista dos nomes dos participantes;
c) lista dos participantes presentes durante o evento;
d) lista dos temas que serão apresentados;
e) preview do evento.
69
7 CONCLUSÃO
A orientação a objetos é uma área que ainda está sendo pouco explorada
para desenvolvimento e a tendência é que a sua utilização aumente cada vez mais.
O desenvolvimento de sistemas baseados em objetos, permite que haja um
expansão dos sistemas utilizando os objetos já criados, sem que perca tempo na
criação dos mesmos. Pode-se aproveitar todos os objetos feitos dentro da
orientação a objetos.
A técnica OMT veio de uma forma de ajuda para aqueles que procuram
desenvolver um sistema com um baixo índice de manutenibilidade. Para isso, os
passos desta técnica devem ser seguidos, realizando uma análise e documentação
do sistema completo, para que haja sucesso no futuro. Esta metodologia obriga o
analista repensar várias vezes os mesmos pontos do sistema, e entendendo cada
vez mais os problemas, e assim, aproximar muito mais das necessidades reais do
usuário. Um dos problemas dos aplicativos hoje em dia, é que são desenvolvidos
sem muita documentação, fazendo com que a fique impossível de se entender o
sistema.
As ferramentas case auxiliam muito na documentação dos sistemas,
modelando os dados e expondo as idéias principais mais claramente dentro de uma
metodologia. Com ela, pode-se verificar a consistência dos dados e ter uma visão
mais ampla do sistema.
Este protótipo tinha como finalidade atender as necessidades de uma
administração de um evento, com maior agilidade do atendimento. E o resultado da
validação do software, foi que ele atendeu às expectativas esperadas, alcançando
os propósitos organizacionais desejadas.
Em função de pouco tempo para a realização da documentação e
implementação do protótipo, optou-se apenas realizar os processos principais de um
evento, como cadastramento e controle de presenças.
70
Esta parte de administração de eventos é muito ampla, podendo melhorar
cada vez mais o protótipo para a sua utilização em eventos de grande porte,
trabalhando com um fluxo maior de dados e segurança.
7.1 SUGESTÕES
Uma idéia interessante é fazer com que o protótipo possa ser utilizado em um
evento de porte grande, com impressão de códigos de barras e mala direta em rede.
Pode-se incrementar toda a parte financeira de um evento de porte grande,
gerando gráficos para uma análise do andamento do evento e ver se está
caminhando conforme o objetivo do mesmo.
Outra proposta para trabalhos futuros, seria a integração deste protótipo com
a inscrição dos participantes via Internet, cadastrando automaticamente dentro
deste.
71
REFERÊNCIAS BIBLIOGRÁFICAS
[BRA99]
JÚNIOR BRANDI, Vitor. Apostila e textos diversos de apoio à
disciplina, 1999. Endereço eletrônico :
http://200.18.244.167/pessoais/vitor/espap199.htm.
[CES97]
CESCA, Cleusa G. Gimenes. Organização de eventos. São Paulo :
Summus, 1997.
[COR95]
CORNELL, Gary, STRAIN, Troy. Delphi – Segredos e Soluções. São
Paulo : Makron Books, 1995.
[ECH99]
ECHAMENDI, Deise, KAMMER, Renate. Ferramentas CASE para
arquitetura cliente/ servidor. Endereço eletrônico :
http://www.furb.rct-sc.br/~egrahl/complemento/case.htm.
[HAM99]
HAMPSHIRE, Paulo Pereira. Utilizando Java como ferramenta
corporativa. Revista Developers. Junho, 1999.
[MAG91]
MAGALLÓN, Tonatiuh Cravioto. Organización de congresos y
convenciones. México : Trillas, 1991.
[MAR96]
MARTIN, James. Princípios de análise e projeto baseados em
objetos. Rio de Janeiro : Campus, 1996.
[MIY87]
MIYAMOTO, Massahiro. Administração de congressos científicos e
técnicos : Assembléia – Convenção – Painel – Seminário e
Outros. São Paulo : Pioneira : Editora da Universidade de São
Paulo, 1987.
[RUM94]
RUMBAUGH, James et all. Modelagem e projetos baseados em
objetos. Rio de Janeiro : Campus, 1994.
[SIM97]
SIMON, Erôni Carlos. Sistema de apoio ao docente. Blumenau :
Trabalho de Conclusão de Curso apresentado à Universidade
Regional de Blumenau, 1997.
72
[SOU87]
SOUZA, Carlos César. Congressos – como organizar. Florianópolis :
[s.n.], 1987. 28p.
[TEC99]
TECHMARK.
TechMark,
1999.
Endereço
Eletrônico:
http://www.techmark.com.br/prodtec.html
[TOL99]
TOLEDO, Reinaldo Luiz Day de, HENKERLS, Tarcisio. Comparando a
Ferramentas CASE. Endereço eletrônico:
http://www.furb.rct-sc.br/~egrahl/engsoft/complemento/ENGESOFT.htm
[VIV97]
VIVAN, Françoise. Análise/ desenvolvimento de um aplicativo para
controle de ponto eletrônico utilizando a OMT. Blumenau :
Trabalho de Conclusão de Curso apresentado à Universidade
Regional de Blumenau, 1997.
73
ANEXO 1 – MODELO DE CERTIFICADO