sati - sistema de atendimento técnico de informática
DESCRIPTION
O desempenho de uma empresa prestadora de serviços depende fortemente da capacidade profissional de seu quadro de colaboradores, de seus conhecimentos técnicos e também da sua infra-estrutura para apoiar as atividades profissionais.Nesse sentido propomos um sistema de apoio ao atendimento e acompanhamento de solicitação de serviços, direcionado a empresas prestadoras de serviço de manutenção de computadores e equipamentos de informática, que possa lhe atribuir eficiência e organize as tarefas desenvolvidas em um roteiro previamente definido.TRANSCRIPT
FACULDADE ALVORADA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
TIAGO MARTINS SILVA E HÉLIO ALVES DOS SANTOS
SATI - Sistema de Atendimento Técnico de Informática
Brasília – DF,
Dezembro de 2011
ii
TIAGO MARTINS SILVA E HÉLIO ALVES DOS SANTOS
SATI - Sistema de Atendimento Técnico de Informática
Monografia apresentada à Coordenação de Sistemas de Informação da Faculdade Alvorada para a obtenção do título de Bacharel em Sistemas de Informação.
Orientadores: Prof. Elias Freitas da Silva
Profa. Mestra Elizabeth d´Arrochella Teixeira
Brasília – DF,
Dezembro de 2011
iii
EPÍGRAFE
“A primeira regra de qualquer tecnologia utilizada nos negócios é que a automação aplicada a uma
operação eficiente aumentará a eficiência. A segunda é que a automação aplicada a uma operação
ineficiente aumentará a ineficiência.”
Bill Gates
“A vida é uma escola; seria a morte um certificado de conclusão de curso?”
Wagner Larini
iv
DEDICATÓRIA
Dedicamos este trabalho aos nossos familiares, amigos e irmãos que nos auxiliaram
de forma direta e indireta na conclusão desta monografia, pois mesmo com ventos
profanos, estávamos alicerçados em nossos objetivos e quem se não eles para nos
apoiarem nos momentos de pesquisa e sofrimento, aos professores Elias Freitas e
Elizabeth d´Arrochella nossos orientadores que nos deram um direcionamento e luz
no que tange a realização deste trabalho com dedicação à orientação.
v
AGRADECIMENTOS
Agradecemos a Deus, por ter nos concedido ânimo para prosseguirmos ante
as adversidades e habilidades de abstração que foram decisivas em cada etapa do
trabalho.
A todos nossos familiares, amigos que nos apoiaram em momentos difíceis.
Aos orientadores Elias Freitas e d’Arrochella, que foram essenciais ao nos
conceder a direção que nos norteou rumo à conclusão deste trabalho.
vi
RESUMO
O desempenho de uma empresa prestadora de serviços depende fortemente
da capacidade profissional de seu quadro de colaboradores, de seus conhecimentos
técnicos e também da sua infra-estrutura para apoiar as atividades profissionais.
Nesse sentido propomos um sistema de apoio ao atendimento e
acompanhamento de solicitação de serviços, direcionado a empresas prestadoras
de serviço de manutenção de computadores e equipamentos de informática, que
possa lhe atribuir eficiência e organize as tarefas desenvolvidas em um roteiro
previamente definido.
PALAVRAS-CHAVE: Eficiência. Qualidade. Controle e Planejamento.
vii
ABSTRACT
The performance of a service company depends heavily on the professional
competence of its workforce, their technical expertise and also through its infra-
structure to support professional activities.
In this sense we intend to propose a system to support the care and
monitoring of service requests, aimed at companies providing maintenance service
on computers, which can effectively assign and organize the tasks performed in a
previously defined.
KEYWORDS: Efficiency. Quality. Control and Planning.
viii
LISTA DE FIGURAS
Organograma da Empresa 19
Estrutura do Processo – Duas dimensões 24
Disciplinas em uma iteração do RUP 30
Elementos do RUP 31
Diagramas da UML 2.0 34
Processo de execução de um programa Java 40
Diagrama de Casos de Uso 62
Diagrama de classes 74
Diagrama de casos de Uso implementado 75
Diagrama Entidade Relacionamento 76
Fluxo de navegação 81
Interface de Login 82
Layout principal do sistema 83
Tela de consulta de Cliente 83
Tela de Cadastro de Clientes 84
Cadastro de Equipamento 84
Ordem de serviço 85
Consulta de OS 85
Retorno da consulta 86
Consulta uma OS 86
Elaboração de Orçamento 87
Resumo de orçamento 87
ix
LISTA DE TABELAS
Cronograma de Desenvolvimento da Monografia TCC1 22
Lista dos UC's . 62
UC001 Login 63
UC002 Manter Cliente 63
UC003 Manter Ordem de serviço 66
UC004 Manter Orçamento 68
UC005 Faturamento 69
UC006 Manter Fornecedor 70
UC007 Manter Usuário 72
Regras de Negócio 72
Lista de Mensagens 73
Especificação da tabela 01 pessoa 77
Especificação da tabela 02 Tipo de Pessoa 77
Especificação da tabela 03 Ordem de Serviço 78
Especificação da tabela 04 Equipamento 78
Especificação da tabela 05 Tipo de Equipamento 79
Especificação da tabela 06 Orçamento 79
Especificação da tabela 07 Peças 79
Especificação da tabela 08 Serviços 80
Especificação da tabela 09 Status 80
Especificação da tabela 10 Perfil 80
Especificação da tabela 11 Sexo 80
Especificação da tabela 12 UF 81
x
LISTA DE ABREVIATURA
ABNT Associação Brasileira de Normas Técnicas
API Application Programming Interface
ASM Automatic Storage Managentement
DBA DataBase Administrator
CCTA Central Computing and Telecommunications Agency
GoF Gang off Four
IEEE Institute of Electrical and Electronic Engineers
IEC International Electrotechnical Commission
IMAP Internet Message Access Protoco
ISAM Inered Seqüencial Access Method
ITIL Information Tecnology Infrastructure Library
ISO International Organization for Standardization
J2ME Java 2 Mobile Edition
J2SE Java 2 Standard Edition
JDK Java Development Kit
JRE Java Run Edition
JSF JavaServer Faces
JSP JavaServer Page
JVM Java Virtual Machine
MSF Microsoft Solutions Framework
NNTP Network News Transfer Protocol
OBCD Open Data Base Connectivity
OGC Office of Government Commerce
OMG Object Mangement Group
PC Personal Cumputer
PHP Hypertext PreProcessor
POP3 Post Office Protocol 3
RAM Randomic Acess Memory
RUP Rational Unified Process
SATI Sistema de Atendimento Técnico de Informática
SCM Software Configuration Management
xi
SDK Standard Development Kit
SEI Software Engineering Institute
SGBD Sistema de Gerenciamento de Banco de Dados
SMS Short Message Service
SNMP Simple Network Management Protocol
SQA Software Quality Assurance
SQL Structured Query Language
TI Tecnologia da Informação
UML Unified Modeling Language
XML Extensible Markup Language
XP eXtreme Programming
12
SUMÁRIO
1. INTRODUÇÃO ......................................................................................................................................14
1.1. TEMA ...................................................................................................................................................... 15
1.2. JUSTIFICATIVA ....................................................................................................................................... 15
1.3. FORMULAÇÃO DO PROBLEMA ............................................................................................................... 15
1.4. OBJETIVOS ............................................................................................................................................ 16
1.5. GERAL.................................................................................................................................................... 16
1.6. ESPECÍFICOS ......................................................................................................................................... 16
1.7. ORGANIZAÇÃO DO TRABALHO ............................................................................................................... 17
2. ANÁLISE INSTITUCIONAL .................................................................................................................18
2.1 EMPRESA E O SEU NEGÓCIO ................................................................................................................ 18
2.2 ORGANOGRAMA DA EMPRESA .............................................................................................................. 18
2.3 DESCRIÇÃO DAS NECESSIDADES .......................................................................................................... 19
2.4 SISTEMA DE INFORMAÇÃO EXISTENTE NA EMPRESA ........................................................................... 20
2.5 NORMAS DE FUNCIONAMENTO .............................................................................................................. 20
2.6 AMBIENTE TECNOLÓGICO EXISTENTE .................................................................................................. 20
3. CRONOGRAMA ...................................................................................................................................22
4. REFERENCIAL TEÓRICO ..................................................................................................................23
4.1 RUP - RATIONAL UNIFIED PROCESS .................................................................................................... 23
4.1.1 As Fases ...................................................................................................................................... 25
4.1.2 Disciplinas .................................................................................................................................... 27
4.1.3 Desenvolvimento Iterativo e Incremental ................................................................................ 30
4.2 UML - UNIFIED MODELING LANGUAGE ..................................................................................... 31
4.2.1 Elementos Básicos do Modelo .................................................................................................. 32
4.2.2 Relacionamentos ........................................................................................................................ 33
4.2.3 Diagramas .................................................................................................................................... 34
4.3 JAVA ..................................................................................................................................................... 39
4.4.1 ServLets e JSP ............................................................................................................................ 41
4.5 PHP - HYPERTEXT PREPROCESSOR ................................................................................................... 43
4.6 DESENVOLVIMENTO AGIL ............................................................................................................. 44
4.7 BANCO DE DADOS ........................................................................................................................... 47
4.7.1 Modelo de dados......................................................................................................................... 47
4.7.2 SGBD ............................................................................................................................................ 49
4.7.3 MYSQL ......................................................................................................................................... 51
4.7.4 SQL ( Strutured Query Language) ........................................................................................... 52
13
4.7.5 ORACLE ....................................................................................................................................... 53
4.7.6 ORACLE 10G EXPRESS EDITION ......................................................................................... 57
5. PROPOSTA DO NOVO SISTEMA ......................................................................................................59
5.1 DESCRIÇÃO DO SISTEMA PROPOSTO ................................................................................................... 59
5.2 RESULTADOS ESPERADOS .................................................................................................................... 59
5.3 RESTRIÇÕES DO SISTEMA PROPOSTO ................................................................................................. 60
5.4 ANÁLISE DE VIABILIDADE ECONÔMICA DO NOVO SISTEMA .................................................................. 60
5.5 ÁREAS AFETADAS PELO NOVO SISTEMA ............................................................................................. 60
5.6 IMPLEMENTAÇÕES FUTURAS ................................................................................................................. 60
6. DOCUMENTOS DE ANALISE ............................................................................................................61
6.1 VISÃO MACRO DOS ATORES ................................................................................................................. 61
6.2 IDENTIFICAÇÃO DOS ATORES ................................................................................................................ 61
6.3 TABELA DE CASOS DE USO ................................................................................................................... 61
6.4 DIAGRAMA DE CASOS DE USO .............................................................................................................. 62
6.5 DESCRIÇÃO DETALHADA DOS CASOS DE USO ..................................................................................... 63
6.6 DIAGRAMA DE CLASSE ........................................................................................................................... 73
6.7 ESCOPO DO PROTÓTIPO ........................................................................................................................ 75
6.8 BANCO DE DADOS ................................................................................................................................. 75
6.8.1 Modelo Entidade Relacionamento ........................................................................................... 75
6.8.2 Especificação das tabelas ......................................................................................................... 76
6.9 ÁRVORE DO SISTEMA ............................................................................................................................ 81
6.10 ESPECIFICAÇÕES FÍSICA ....................................................................................................................... 82
6.10.1 Layout das Principais Telas da Aplicação ............................................................................... 82
6.11 SEGURANÇA FÍSICA E LÓGICA .............................................................................................................. 88
6.12 NORMA DE SEGURANÇA FÍSICA ............................................................................................................ 88
6.13 NORMAS DE SEGURANÇA LÓGICA ........................................................................................................ 88
7. PLANO DE IMPLANTAÇÃO ...............................................................................................................89
7.1 HARDWARE ............................................................................................................................................ 89
7.2 SOFTWARE ............................................................................................................................................ 89
8. CONCLUSÃO .......................................................................................................................................90
9. REFERENCIAS BIBLIOGRÁFICAS ...................................................................................................91
14
1. INTRODUÇÃO
Segundo MORIMOTO (2010), o surgimento de novos equipamentos e o
aprimoramento dos existentes, ocasionado pela constante evolução tecnológica,
aliado a queda de preços e às facilidades de financiamento, está proporcionando um
aumento significativo no consumo de equipamentos de informática, mesmo com a
queda de seus preços, estes ainda representam um desembolso muito grande para
a maioria das pessoas.
Segundo BALMMER (2010), presidente da Microsoft, o Brasil será nos
próximos três anos, o 3º maior mercado de computadores do mundo. Confirmada tal
expectativa, este mercado demandará cada vez mais de técnicos e prestadores de
serviços de manutenção de equipamentos de informática, visto que estes
equipamentos apresentam defeitos e a simples substituição dos mesmos ainda está
fora do alcance da maioria dos consumidores, assim sendo, a manutenção estará
presente nesse mercado por muito tempo.
Segundo VASCONCELOS (2010), faz-se necessária a capacitação,
qualificação e o aprimoramento dos prestadores de serviços, tendo em vista que o
aquecimento do mercado ocasionará o acirramento da concorrência com a criação
de muitas empresas para explorar este mercado e, permanecerão aquelas que se
mostrarem eficientes, prestarem um serviço de qualidade e com um custo acessível.
Vindo ao encontro destas demandas, vislumbramos a necessária da criação
de um sistema que possa conferir a estas prestadoras de serviço, agilidade, controle
e acompanhamento eficiente das ordens de serviço de uma forma automatizada,
sem o preenchimento de formulários físicos (papel), que são passíveis de perda,
erros formais e acréscimo de custos desnecessários.
Propomos neste trabalho apresentar uma solução de baixo custo, pois trata-
se de um aplicativo de distribuição gratuita, que contemple o cadastramento de
clientes e fornecedores, para a geração de ordens de serviço, emissão de
orçamento e acompanhamentos de serviços.
15
1.1. Tema
Desenvolver um protótipo de software para o registro de ordens de serviços,
geração de orçamento, acompanhamento, interação com clientes e colaboradores.
Atribuir agilidade e facilitar as tarefas inerentes ao trabalho de manutenção de
equipamentos de informática.
1.2. Justificativa
Segundo KAPLAN (1997), às empresas da era da informação são exigidas
agilidade e confiabilidade. Em um mercado cada vez mais competitivo não se pode
conduzir as atividades sem um processo claro e bem estruturado com atribuições
bem definidas e tarefas sequenciadas.
Para auxiliar pequenas empresas a alcançar este grau de excelência,
propomos um sistema para reger rotinas e procedimentos e acima de tudo um
controle sobre a recepção e destinação dos equipamentos recebidos para
manutenção, garantir qualidade e agilidade às demandas dos clientes.
1.3. Formulação do Problema
Segundo a (ANSI/IEEE STD 100_1984), a heurística trata de métodos ou
algoritmos exploratórios para solução de problemas. As soluções são buscadas por
aproximações sucessivas, avaliando-se os progressos alcançados, até que o
problema seja resolvido.
Em nossas visitas à empresa de manutenção de equipamentos de
informática SHIFT Computadores (empresa fictícia), para acompanharmos as rotinas
de atendimento. Mesmo com todo o desenvolvimento heurístico dos processos no
decorrer dos anos, constatou-se que não há um procedimento definido para a
recepção de equipamentos, elaboração de orçamentos, controle do equipamento em
fase de manutenção e entrega ao cliente, gerando instabilidade no fluxo do processo
local, perda de prazos nas devoluções dos equipamentos e insatisfação dos clientes.
16
Com base na reunião dos fatores existentes na SHIFT Computadores
atualmente, surgiu a necessidade da criação de uma ferramenta que viesse gerir
todos esses processos e aspectos até então arcaicos e que pudesse contribuir para
uma melhora considerável na rotina de trabalho dos funcionários e um melhor
atendimento ao cliente, diminuindo assim a entropia dentro da empresa e
aumentando a sua capacidade de competir em um mercado cada vez mais exigente
seletivo.
1.4. Objetivos
Abaixo estão descritos os objetivos: geral e específicos cujo
desenvolvimento do sistema pretende suprir.
1.5. Geral
Desenvolver uma ferramenta para o registro de equipamentos recebidos no
atendimento e chamadas para manutenção, gerando orçamentos e encaminhá-los
aos clientes.
1.6. Específicos
Os objetivos específicos do trabalho são:
a) Criar através de um sistema informatizado, uma rotina para
recebimentos de equipamentos e atendimentos aos clientes;
b) Possibilitar a geração de orçamentos de forma online e repassá-lo ao
cliente, por e-mail;
c) Manter um controle dos estágios das ordens de serviço de forma que em
uma consulta ao sistema possa-se obter a informação precisa de um
equipamento específico;
d) Obter relatórios dos serviços prestados em um período e confrontá-los
com as entradas no caixa da empresa;
e) Cadastro de clientes e fornecedores.
17
1.7. Organização do Trabalho
Este trabalho está organizado da seguinte forma:
O primeiro capítulo descreve de uma forma geral o tema proposto com um
breve relato do processo, a justificativa da escolha do tema e o problema que vai ser
resolvido.
O segundo capítulo aborda toda a análise institucional da empresa, o
organograma da empresa, descrevendo as necessidades do sistema, os métodos
adotados atualmente na empresa e o ambiente tecnológico existente onde o sistema
será implantado.
O terceiro capítulo detalha o cronograma das atividades realizadas no
decorrer do projeto: levantamento teórico, análise, projeto.
No quarto capítulo encontra-se o referencial teórico, no qual são abordadas
as tecnologias e processos envolvidos neste trabalho.
O quinto capítulo é utilizado para apresentar o sistema proposto e suas
motivações.
O sexto capítulo aborda a documentação de análise do sistema.
O sétimo capítulo é utilizado para descrever o plano de implantação do
sistema, no qual é descrito o conjunto de tarefas necessárias para instalar e testar o
produto desenvolvido de modo que ele possa ser efetivamente transferido com
sucesso ao cliente, garantindo uma implantação bem sucedida para o novo sistema
com o mínimo de impacto.
O oitavo capítulo é utilizado para conclusão do trabalho e por fim são
relacionadas as referências bibliográficas no último capítulo.
18
2. ANÁLISE INSTITUCIONAL
Segue abaixo a visão detalhada do ramo, negócio e aspectos históricos da
SHIFT Computadores.
2.1 Empresa e o Seu Negócio
Atualmente a SHIFT Computadores, uma empresa fictícia, que vem se
consolidando no mercado como prestadora de serviços técnicos em informática para
diversos tipos de clientes, desde clientes comuns até empresas privadas de
pequeno porte e órgãos públicos, sua sede e principal área de atuação está situada
em Brasília abrangendo recentemente cidades do entorno como Luziânia e Águas
Lindas de Goiás.
No que se refere ao negócio, ela presta serviços relacionados a infra-
estrutura de redes cabeadas e wireless, link de internet via radio, montagem,
manutenção e configuração de microcomputadores e servidores em diversas
plataformas , além de suporte a usuários, help desk e fornecedora de peças de
hardware.
A SHIFT Computadores, é uma empresa com mais de 12 anos de mercado,
vem atuando como apoio e suporte para diversas empresas de pequeno porte e
micro empresas que desejam se estruturar, visando sempre um atendimento de
qualidade e satisfação do cliente.
2.2 Organograma da Empresa
Abaixo na figura 1, segue o organograma que num modo holístico
representa toda a estrutura hierarquia da SHIFT Computadores, composta de 20
funcionários, com as seguintes funções: Gerente, sócio majoritário da empresa, que
exerce a administração financeira e negocial, responsável pela relação comercial da
empresa com os clientes institucionais; Técnicos de campo, tem a missão de efetuar
o atendimento local aos clientes institucionais, são capacitados em manutenção de
equipamentos de informática e infra-estrutura de rede de computadores; Técnicos
19
de loja, são os responsáveis pela manutenção dos equipamentos entregues nas loja,
são capacitados em manutenção de equipamentos de informática; Atendentes,
prestam serviço na loja e são responsáveis pelo atendimento dos clientes no
ambiente da empresa e através dos contatos telefônicos.
Figura 1- Organograma da Empresa
2.3 Descrição das Necessidades
Segundo PRESSMAN (1995), o escopo definido para o software proporciona
uma direção, mas uma definição detalhada do domínio da informação e da função
do software é necessária antes que o trabalho se inicie.
A SHIFT Computadores hoje, necessita de uma ferramenta que cuide da
gestão de seus processos mais simples no que tange ao controle dos equipamentos
que entram e que saem da empresa, com um padrão elevado de otimização,
eficiência e eficácia no resultado final. Tendo um controle mais concreto por parte
das gerencias da empresa, através de alimentação de dados pelo usuário, busca,
edição, recuperação dos dados, geração de relatórios personalizados e agilidade na
comunicação com o cliente sobre seu equipamento.
Desta forma o SATI objetiva a otimização dos processos, como uma forma de
total gestão e apoio a empresa em questão.
20
2.4 Sistema de Informação Existente na Empresa
Atualmente na SHIFT Computadores, todos os procedimentos que são
realizados, são dados em papel para documentos fiscais, ordem de serviços e os
demais do gênero, relatórios são realizados usando o aplicativo Microsoft Office
Excel 2007. Não há nenhum controle sobre as comunicações entre os setores da
empresa, há apenas a passagem física de uma das vias da ordem de serviço do
atendimento ao responsável pelo serviço.
2.5 Normas de Funcionamento
Com base na análise feita, constata-se que serão necessárias algumas
exigências e restrições mínimas para que o sistema tenha pleno funcionamento e
opere de modo estável, sendo estes alguns dos principais requisitos: é
imprescindível que o usuário tenha acesso a intranet da empresa e acesso ao
sistema através de login e senha, para que possa efetuar a inserção dos dados na
base em tempo real. Deverá existir segregação de funções, sendo que o usuário de
nível gerencial terá acesso a funções ocultas a usuários comuns (técnicos e
atendentes), com a finalidade de exercer o controle dos processos e a obtenção de
relatórios analíticos de desempenho e gestão.
2.6 Ambiente Tecnológico Existente
A SHIFT Computadores compreende um ambiente tecnológico com
computadores instalados e configurados em uma rede local, uma central de
processamento, onde nela abriga os mais diversos tipos de servidores convenientes
ao negócio da empresa como: servidor de aplicativos para os técnicos, servidor de
roteamento de internet para os clientes utilizando o S.O Microtik (sistema baseado
em Linux), organizando-se através de uma aerovia (grande intranet), plataforma
Linux, Máquinas virtuais além de 10 máquinas com Windows 7 profissional.
O hardware dos servidores é configurado com processadores Intel core i5
450m, 4GB de memória RAM e 1T de HD, já as maquinas que possuem Windows,
21
são configuradas com 2GB de memória RAM, AMD Semprom e 300 GB HD além de
6 impressoras multifuncionais HP DeskJet F4480.
22
3. CRONOGRAMA
Na tabela 1 é ilustrado o cronograma de planejamento deste trabalho,
dando-se do inicio ao fim, como uma forma de prever e nos situarmos em relação ao
tempo necessário para a realização desta monografia.
Tabela 1 - Cronograma de Desenvolvimento da Monografia TCC1
23
4. REFERENCIAL TEÓRICO
Neste capítulo descreveremos o processo de engenharia de software RUP,
a linguagem para modelagem de sistemas UML, as linguagens de programação
JAVA e PHP, o processo de desenvolvimento AGIL, os conceitos de Banco de
dados e os SGBDs MySGL e ORACLE, e o embasamento teórico que servirão de
arcabouço para o desenvolvimento do sistema proposto.
4.1 RUP - Rational Unified Process
Segundo KRUCHTEN (2003), RUP é um processo de engenharia de
software desenvolvido e comercializado pela Rational Software, bastante utilizado no
desenvolvimento de software de alta qualidade e corresponde a um modo
disciplinado de ordenar de gerenciar tarefas e responsabilidades em uma empresa
de desenvolvimento. O objetivo desse processo é produzir, dentro de prazo e
orçamento previstos, software de alta qualidade que satisfaça às necessidades de
seus usuários finais.
O RUP é um processo de desenvolvimento de software iterativo e
incremental. É descrito em vários livros e artigos. Uma das maiores fontes de
informações é o próprio produto IBM RUP, que contém guias detalhados, exemplos
e modelos cobrindo todo o ciclo de vida do software;
Segundo KRUCHTEN (2003) o RUP é um processo de engenharia de
software bem definido e bem estruturado. O RUP define claramente quem é
responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP
também provê uma estrutura bem definida para o ciclo de vida de um projeto,
articulando claramente os marcos essenciais e pontos de decisão.
Segundo a IBM Rational (2001), o RUP é também um produto de processo
que oferece uma estrutura de processo customizável para a engenharia de software.
O produto IBM RUP suporta a customização e autoria de processos, e uma
variedade de processos, ou configuração de processos, podem ser montadas nele.
24
Essas configurações do RUP podem ser criadas para suportar equipes grandes e
pequenas e técnicas de desenvolvimento disciplinadas ou menos formais. O produto
IBM RUP contém várias configurações e visões de processos prontas que guiam
analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de
configuração, analistas de dados, e outros membros da equipe de desenvolvimento
em como desenvolver o software. Ele tem sido utilizado por muitas companhias em
diferentes setores da indústria.
Para KRUCHTEN (2003), por ser flexível e configurável, o RUP pode ser
utilizado em projetos de pequeno, médio e grande porte, o RUP pode ser utilizado
em um projeto de uma semana com uma equipe de uma pessoa.
Para KENDALL (2004), o Processo Unificado é um conjunto de atividades
executadas segundo uma arquitetura robusta e regras bem definidas, para
transformar os requisitos do cliente em um produto de software, neste contexto o
RUP é uma versão especializada do Processo Unificado. O RUP faz uso extensivo
da Unified Modelin Languagen (UML), e seus modelos contextualizam o processo de
desenvolvimento de software, concebendo uma simplificação da realidade que ajuda
a entender alguns aspectos complexos inerentes a sistemas de software..
Para KRUCHTEN (2003), RUP é uma guia para uso efetivo da UML para
modelar. A figura 2 apresenta a arquitetura global do RUP, onde pode ser
observadas suas dimensões ou estruturas.
Figura 2 Estrutura do Processo – Duas dimensões.
Fonte: Kruchten - 2004
25
4.1.1 As Fases
Segundo KRUCHTEN (2003) O RUP é composto de 04 fases
compreendidas em:
Iniciação: Refere-se basicamente a definição do escopo; estimar o custo geral e os
riscos em potencial. As atividades desenvolvidas são: definir os critérios de sucesso
de projeto, riscos, recursos necessários e data de realização das principais etapas,
delimitar o escopo do projeto, identificar os atores que interagem com o sistema,
identificar as interações dos atores com o sistema (casos de uso). Os resultados
(artefatos) esperados nesta fase são: documento de visão (visão geral dos
requisitos, características e restrições essenciais do projeto); modelo inicial de casos
de uso; glossário do projeto; definição de objetivos e viabilidade do projeto, critérios
de sucesso, e prognóstico financeiro; avaliação inicial de riscos; plano de projeto,
com fases e interações; modelo de negócios, se necessário; um ou vários protótipos.
É também nesta fase que se obtêm a concordância quanto à definição de escopo,
estimativa de custos e cronograma;
Elaboração: Retrata como fazer; qual arquitetura será utilizada; em que ambiente a
aplicação será executada; como os testes serão executados, é nesta fase que são
analisados os riscos de requisitos, ricos tecnológicos, ou seja, a capacidade das
ferramentas disponíveis, riscos de habilidade dos integrantes do projeto, objetivando
minimizá-los. Construir protótipos executáveis, em uma ou mais interações; atacar
os casos de uso críticos, que expõe os maiores riscos técnicos; construir protótipos
evolucionários ou descartáveis, com objetivo de analisar custos-benefícios,
demonstrar para investidores, clientes e usuários. Os resultados (artefatos)
esperados são: modelo de casos de uso; requisitos não funcionais; descrição da
arquitetura do software; protótipos arquiteturais executáveis; revisão da visão de
negócios e lista de riscos; plano detalhado de desenvolvimento do projeto, com
interações e critérios de avaliação; plano de processo de desenvolvimento; manual
de usuário preliminar. É nesta fase que algumas questões devem ser respondidas,
tais como: A visão do produto é estável? A arquitetura é estável? A demonstração
executável mostrou que os elementos de maior risco foram abordados
satisfatoriamente? O plano de desenvolvimento está suficientemente detalhado e
26
preciso? O plano é consistente e coerente? Todos os interessados concordam
quanto à coerência entre visão, plano e arquitetura? Os custos planejados e
executados são aceitáveis? Ao final desta fase a engenharia é considerada
completa, por isso esta é considerada a fase mais crítica;
Construção: Contempla o desenvolvimento ou a construção do software em si.
Incluem-se nesta fase também, o desenvolvimento de versões demonstrativas ou
beta. O principal objetivo da fase de construção é desenvolver de modo iterativo e
incremental um produto completo que esteja pronto para a transição. Isso implica
descrever os casos de uso restantes e outros requisitos, incrementar o projeto,
concluir a implementação e testar o software. Essas atividades são baseadas na
arquitetura definida na fase de elaboração e podem ser executadas com um certo
paralelismo. O paralelismo pode acelerar bastante as atividades de
desenvolvimento; mas também aumenta a complexidade do gerenciamento de
recursos e da sincronização dos fluxos de trabalho. Uma arquitetura sofisticada é
essencial para atingir um paralelismo significativo e pode ser obtidos com a
aplicação dos padrões de requisitos, análise e projeto;
Transição: Consiste na implantação da versão final do software ou produto. Nesta
fase, o software é disponibilizado aos usuários. Após ter sido colocado em uso,
surgem novas considerações que vão demandar a construção de novas versões
para permitir ajustes do sistema, corrigir problemas ou concluir algumas
características que foram postergadas. É importante realçar que dentro de cada
fase, um conjunto de iterações, envolvendo planejamento, levantamento de
requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma
iteração para outra e de uma fase para a próxima, a ênfase sobre as várias
atividades muda, a fase de transição concentra-se nos testes, visando garantir que o
sistema possui o nível adequado de qualidade. Além disso, os usuários devem ser
treinados, características ajustadas e elementos esquecidos adicionados.
Segundo KRUCHTEN (2003), cada fase tem uma ou mais iterações, com foco
em disponibilizar os produtos e documentos necessários para alcançar seus
objetivos.
27
4.1.2 Disciplinas
Segundo KENDALL (2004), para usufruir das principais características do
processo de desenvolvimento com o RUP devem ser observadas suas disciplinas:
Modelagem do Negócio: Avalia a estrutura e a dinâmica da organização; identifica
os problemas e respectivas melhorias e documentar os seus processos. Estes são
documentos do modelo de Casos de Uso do Negócio (Business Use Cases). O
objetivo desta disciplina é assegurar um entendimento comum entre todos os
interessados a respeito de qual processo empresarial precisa receber apoio na
organização. Os casos de uso do negócio são analisados para se entender como o
negócio deve apoiar os processos empresariais. Muitos projetos podem não utilizar
as atividades de modelagem do negócio no seu processo, principalmente nos casos
em que o domínio do negócio já é muito bem conhecido por todos os participantes
do projeto (principalmente os engenheiros) ou então, quando o negócio é simples e
pequeno;
Requisitos: Apura-se as necessidades do cliente para o projeto; define-se os limites
do sistema. As atividades desta disciplina são realizadas a fim de se descrever o
que o sistema deve fazer, assim como permitir aos desenvolvedores e clientes
avaliarem esta descrição. Tais atividades englobam identificar, organizar, e
documentar as funcionalidades exigidas, assim como rastrear e documentar
mudanças e decisões. Assim como a Modelagem do Negócio, existe maior
concentração de esforços para a realização das atividades inerentes a esta
disciplina nas duas primeiras fases do processo, Concepção e Elaboração. Um
documento de Visão é criado e a partir deste, são definidas as necessidades dos
interessados no sistema e identificados os atores. Ao longo do projeto, cada caso de
uso é descrito em detalhes, mostrando interação com atores e suas funcionalidades,
assim como os fluxos das regras do negócio. São descritas exigências não-
funcionais em especificações adicionais. Os casos de uso vão funcionar como um
guia ao longo de todo o ciclo de desenvolvimento do produto de software;
Análise e Design: Traduz os requisitos ou necessidades do projeto em um modelo
de arquitetura de software. As atividades da disciplina de Análise & Projeto são
28
executadas para demonstrar como o sistema será concebido na fase de
implementação. O projeto de um sistema deve garantir que o sistema a ser
construído execute as tarefas e funções especificadas nos casos de uso, contemple
requisitos não-funcionais, e seja flexível às mudanças. As atividades desta disciplina
resultam em um Modelo de Projeto e opcionalmente em um Modelo de Análise. O
modelo de projeto serve como uma abstração do código fonte: um guia ou mapa de
como o código deve ser estruturado e escrito. Todas as soluções de análise e
projeto do sistema devem levar em conta a arquitetura do sistema, foco principal das
primeiras iterações do ciclo de vida do sistema. Desde o início, deve-se estabelecer
uma arquitetura robusta de forma que se possa projetar um sistema que seja fácil de
manter, construir e evoluir. Deve-se então ajustar o projeto de forma que se adapte
ao ambiente de implementação, projetando o sistema para apresentar bom
desempenho, ser robusto, escalável, e ser facilmente testável, entre outras
qualidades. O objetivo do projeto, por outro lado, é adaptar os resultados da análise
às restrições impostas pelos requisitos não funcionais, pelo ambiente de
implementação, pelos requisitos de desempenho, e assim por diante. O projeto é,
portanto, um refinamento da análise e objetiva a otimização do projeto do sistema ao
mesmo tempo em que garante a cobertura total dos requisitos;
Implementação: As atividades desta disciplina compreendem definir a organização
do código em subsistemas, implementar e testar componentes, e integrar os
resultados, formando um sistema executável. O RUP propõe a prática de
reutilização de componentes existentes, acelerando a produtividade. Componentes
são estruturados em subsistemas da implementação, podendo ser heterogêneos
(produzidos com diferentes tecnologias);
Testes: Executar os testes do software; identifica e documenta as possíveis falhas
encontradas; valida a construção do sistema de acordo com a arquitetura proposta.
Esta atividade e responsável por verificar as funcionalidades do sistema, a
integração de objetos e componentes, a validade dos requisitos implementados,
assim como, assegurar que os defeitos encontrados sejam solucionados. De acordo
com a abordagem iterativa proposta pelo RUP, os testes são realizados ao longo de
todo ciclo de vida do software, e não apenas no final. Isto permite encontrar defeitos
tão logo quanto possível, reduzindo custos de eventuais correções posteriores. Os
29
testes são executados considerando as seguintes dimensões de qualidade:
confiabilidade, funcionalidade, e desempenho da aplicação e do sistema. Uma
prática importante quando se usa uma abordagem iterativa é a automatização de
testes, pois permite regressão ao fim de cada iteração, assim como, validar cada
nova versão do produto por meio de critérios estabelecidos;
Implantação: esta disciplina agrupa as atividades relacionadas ao lançamento e
implantação do software, tais como: produzir lançamentos externos (para o cliente);
"empacotar", distribuir e instalar o software, e; oferecer ajuda e assistência aos
usuários. Em muitos casos, a disciplina também inclui atividades como planejar e
gerenciar testes beta; migração de software ou dados existentes e, condução à
aceitação formal do software pelos interessados;
Gerência de Mudanças e Configuração: Controla os artefatos e códigos-fontes
produzidos no projeto; controla as versões; controla as mudanças solicitadas pelo
cliente. Esta disciplina engloba o controle dos diferentes artefatos produzidos em um
projeto. Em conjunto com a disciplina de Ambiente, ela contém as atividades
referentes ao gerenciamento de versão e configuração do software: base de
conhecimentos, repositórios de dados e informações, e controle de mudanças do
projeto;
Gerência do Projeto: Realiza o planejamento e controle das atividades do projeto;
realiza também o acompanhamento das atividades dos envolvidos no projeto e
indica ao cliente o andamento do projeto. Esta disciplina inclui atividades como
balancear objetivos, gerenciar riscos e contornar problemas a fim de que se possa
entregar um software com sucesso. O Processo Unificado da Rational oferece
alguns recursos para a realização das atividades: um framework de Gerência de
Projetos, com diretrizes para planejar, alocar pessoal, executar e monitorar projetos,
e; um framework de Gerência de Riscos. A disciplina não é uma receita para
sucesso, mas apresenta uma abordagem que pode melhorar a tarefa;
Ambiente: Mantém o ambiente de desenvolvimento de software disponível e
adequado às necessidades. E também define como o RUP foi configurado para ser
utilizado no projeto.
30
4.1.3 Desenvolvimento Iterativo e Incremental
Para KENDALL 2004, a construção com RUP é iterativa e incremental onde
o projeto é dividido em pequenas fases ou “iterações”, conforme a figura 3. Portanto,
as disciplinas destacadas na figura 3 serão executadas em um ciclo ou iterações. Ao
final da execução de cada iteração é gerada uma versão do sistema, ou seja,
algumas funcionalidades do sistema são liberadas para o uso e a cada nova iteração
são oferecidos incrementos funcionais ao sistema.
Figura 3 Disciplinas em uma iteração do RUP Fonte: Kruchten – 2004
Para a execução de todo o processo, o RUP estabelece cinco elementos
conforme figura 4: papel, atividades, artefatos, fluxos de trabalho e as disciplinas,
descritas anteriormente.
Papel: Indica as responsabilidades a serem desempenhadas pelos indivíduos
envolvidos no projeto;
Atividade: Um trabalho a ser executado pelo indivíduo de acordo com o papel
atribuído a ele;
Artefatos: Um conjunto de documentos de entrada e saída para o apoio aos
indivíduos na condução de suas atividades no projeto.;
31
Fluxos de Trabalho: Sequência lógica das atividades desempenhada pelos
indivíduos.
Figura 4 Elementos do RUP Fonte: Kruchten – 2004
Na próxima seção faremos uma breve descrição da UML - Unufied Modeling
Languagem.
4.2 UML - Unified Modeling Language
Segundo GUEDES (2004), a “UML (Unified Modeling Language ou
Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar
sistemas computacionais por meio do paradigma de “Orientação a Objetos.”, a
modelagem visual é o processo de se obter informação a partir do modelo e exibi-las
graficamente, usando um conjunto de padrões de elementos gráficos. Para se atingir
o objetivo primordial da modelagem visual, que é a comunicação, e usufruir de seus
benefícios, é de fundamental importância a existência de padrões definidos e
difundidos.
32
Segundo DEBONI (2003), esta comunicação poderia ser feita de forma não
visual (textual), mas, em geral, o processo visual permite a observação das
informações de forma mais simplificada, precisa e rápida. Ao que parece, as
pessoas conseguem compreender melhor a complexidade quando é apresentada
visualmente, e não escrita ou textualmente. Ao gerar modelos visuais de um
sistema, pode-se mostrar como ele funciona em diversos níveis. Podem ser
modeladas as interações entre os usuários e o sistema, as interações dos objetos
dentro de um sistema e, até mesmo, as interações entre sistemas, se necessário.
MELO (2004) afirma, “uma imagem vale mais que mil palavras”, seguindo
esta afirmação a imagem de uma bicicleta é mais expressiva que a descrição de
suas partes componentes algo que poderia ser extenso e confuso, entretanto uma
imagem não pode ser simples em demasia para não perder sua expressividade,
nesse sentido baseia-se a modelagem de software.
Segundo GUEDES (2004), a UML foi uma fusão, em 1996, de três métodos
de modelagem o método Booch de Grady Boch, o método OMT de Ivar Jacobson e
o método OOSE de James Rumbaugh, o trabalho dos três metodologista de
modelos ficou conhecido popularmente com “ Os três amigos” , que resultou no
lançamento da primeira versão da UML e em 1997 foi adotada pela OMG (Object
Managemente Group).
Segundo MELO (2004) a estrutura da UML conduz à criação e leitura de
seus modelos mas não estabelece quando nem quais deles devem ser criados,
deixando essa responsabilidade para o processo de desenvolvimento. Desta forma
a UML torna-se independente de processos, pois qualquer um deles pode usá-la.
Segundo MELO (2004), para modelar um sistema a UML trabalha com:
elementos básicos do modelo, relacionamentos, diagramas e regras de formação.
4.2.1 Elementos Básicos do Modelo
MELO (2004), cita alguns elementos:
Ação: unidade básica de especificação de comportamento;
33
Artefato: pedaço físico de informação que é usado ou produzido por um
processo de desenvolvimento;
Atividades: é a especificação de um comportamento parametrizado,
expresso como um fluxo de execução;
Caso de Uso: representa a funcionalidade provida por um sistema;
Classe: a descrições de um conjunto de objetos que compartilham dos
mesmos atributos;
Classes Ativas: representa uma atividade de controle;
Colaboração: indica as instâncias e cooperação de elementos envolvidos na
mesma tarefa;
Componente: parte significativa de um sistema modularizado;
Estado: condição durante a vida de um objeto;
Interação: é um padrão de comunicação com o objetivo de realizar algum
propósito;
Interface: especifica as operações externamente visíveis de uma classe ou
componente;
Nota: símbolo gráfico contendo uma informação;
Pacote: é o agrupamento de elementos de modelo;
4.2.2 Relacionamentos
Segundo MELO (2004), os relacionamentos realizam a ligação, entre si, dos
elementos do modelo, são eles:
Dependência: é um relacionamento entre dois ou mais elementos de modelagem,
que indica que uma mudança em um elemento afetará o outro;
Associação: é um relacionamento entre dois ou mais classificadores que envolvem
conexões entre suas instâncias;
Generalização: é um relacionamento entre um elemento mais genérico e outro mais
específico. O elemento mais específico pode conter apenas informações adicionais
que o distingue do genérico.
34
Realização: é um relacionamento entre uma especificação e sua implementação.
4.2.3 Diagramas
Segundo GUEDES (2004) a UML é composta de 13 diagramas que
objetivam fornecer múltiplas visões dos sistemas a serem modelados, analisando-o
e modelando-o sob diversos aspectos e de forma complementar. Cada um destes
diagramas analisa o sistema sob uma determinada ótica. A utilização destes
diagramas permite que falhas sejam detectadas, diminuindo assim a possibilidade
de erros futuros e minimizando os riscos e os custos do desenvolvimento do
sistema. Os diagramas da UML 2.0 dividem-se em Diagramas Estruturais e
Diagramas Comportamentais, sendo que estes últimos possuem ainda uma
subdivisão representada pelos Diagramas de Interação, conforme visto na Figura 4.
Segundo MELO (2004), os diagramas estruturais apresentam as
características imutáveis do sistema, são também conhecidos como diagramas
estáticos, já os comportamentais ou dinâmicos mostram como os sistemas
respondem às requisições ou como o mesmo evolui durante o tempo.
Figura 5 Diagramas da UML 2.0 Fonte: GUEDES, 2004, p.35
35
4.2.3.1 Diagrama de Classe
Segundo GUEDES (2004), as classes são matrizes de objetos e descrevem
um conceito abstrato do domínio do problema enquanto um objeto representa um
elemento desse conceito, que é utilizado no sistema, de forma concreta. O diagrama
de classe serve de base para os outros tipos de diagramas. No Diagrama de
Classes, cada classe é representada por um retângulo no qual são descritos o nome
da classe, os atributos e as propriedades. Os relacionamentos entre as classes
podem ser definidos como:
Dependência: corresponde ao relacionamento mais fraco entre duas classes. É
representada por uma seta tracejada ligando as classes e partindo da classe
dependente para a classe independente. A dependência não indica como ocorre
essa dependência, mas serve para indicar que essas classes devem participar
juntas do sistema;
Associação: as associações aparecem quando há um nível maior de envolvimento,
e bem mais definido que na dependência entre as classes. Na associação, as
classes estão ligadas semanticamente umas às outras, ou seja, as classes são
independentes, mas guardam algum tipo de significado na sua relação. Essa relação
permite a troca de mensagens entre as classes na ajuda para o cumprimento de
suas responsabilidades. A representação da associação é uma linha que interliga as
classes, onde a linha pode possuir uma seta indicando a direção da associação;
Agregação: alguns tipos de associação podem exigir um aumento no grau de
envolvimento entre as classes, o que cria a agregação. A agregação é equivalente à
associação, mas indica que as classes possuem uma dependência existencial, ou
seja, uma classe só existe em conjunto com suas agregadas. A classe todo é
composta pelas classes parte. A agregação é representada por uma seta unindo as
classes com um losango indicando a classe todo. Pode-se considerar a agregação
como um caso especial da associação devido ao maior vínculo entre as classes
Herança: caracteriza-se por criar uma hierarquia entre as classes do sistema. Nessa
hierarquia, as superclasses servem de matrizes para a criação de outras classes, as
36
subclasses, que especializam as superclasses originais. Ao se especificarem, as
subclasses aproveitam tudo das superclasses, o que inclui atributos, operações e
relacionamentos da classe mãe, mas podem modificar o material herdado,
sobrescrevendo os atributos e as operações ou criando novos atributos e operações;
4.2.3.2 Diagrama de Objeto
Segundo GUEDES (2004), o diagrama de objeto é um complemento do
diagrama de classe, sendo bastante dependente deste. Fornece uma visão dos
valores armazenados pelos objetos de um diagrama de classe em um determinado
momento da execução de um processo de software.
4.2.3.3 Diagrama de implementação
Segundo MELO (2004), o diagrama de implantação determina as
necessidades de hardware do sistema, as características físicas como servidores,
estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico
sobre o qual o sistema deverá ser executado. O Diagrama de componentes e o de
Implantação estão intrinsecamente associados e, portanto, é possível representá-los
em conjunto.
4.2.3.4 Diagrama de Estrutura Composta
Segundo GUEDES (2004), o diagrama de estrutura composta, descreve a
estrutura interna de um classificador, como uma classe ou componente, detalhando
as partes internas que o compõem, como estas se comunicam e colaboram entre si.
Também é utilizado para descrever uma colaboração onde um conjunto de
instâncias cooperam entre si para realizar uma tarefa. Este é um dos três novos
diagramas propostos pela UML 2.0.
4.2.3.5 Diagrama de Componentes
Segundo GUEDES (2004), o diagrama de componentes está amplamente
associado à linguagem de programação utilizada parar codificar o sistema
37
modelado. Esse diagrama representa os componentes do sistema implementado em
termos de módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda,
módulos executáveis etc. e determina como esses componentes estarão
estruturados e interagirão para que o sistema funcione de maneira adequada.
4.2.3.6 Diagrama de Pacotes
Segundo MELO (2004), o diagrama de pacotes tem por objetivo representar
os subsistemas englobados por um sistema a fim de determinar as partes que o
compõem. Pode ser utilizado de forma independente ou em conjunto com outros
diagramas.
4.2.3.7 Diagrama de Casos de Uso
Segundo GUEDES (2004), o diagrama de casos de uso é o diagrama mais
geral e informal da UML, é utilizado nas fases de levantamento e analise de
requisitos, mostra as interações entre os casos de uso que tem processos
automatizados e seus atores. Basicamente, o diagrama de casos de uso mostra os
atores que iniciam os casos de uso e que recebem informações deles, enfim, os
requisitos do sistema.
4.2.3.8 Diagrama de Atividades
Segundo GUEDES (2004), o diagrama de atividades preocupa-se em
descrever os passos a serem seguidos para a conclusão de uma atividade
específica, muitas vezes, representada por um método com certo grau de
complexidade e não de um processo completo, como no caso do Diagrama de
Sequência. Em outras palavras, o diagrama de atividades concentra-se na
representação do fluxo de controle de uma atividade.
4.2.3.9 Diagrama de Máquina de Estado
Segundo GUEDES (2004), este diagrama normalmente se baseia em um
Caso de Uso definido e faz uso das classes especificadas no Diagrama de Classes.
38
Além disso, é utilizado em geral para acompanhar os estados por que passa uma
instância de uma classe, podendo ainda ser utilizado para representar os dados de
um caso de uso ou mesmo os estados gerais de um subsistema ou de um sistema
completo.
4.2.3.10 Diagrama Sequencia
Segundo GUEDES (2004), este diagrama tem como principal objetivo
observar a ordem temporal em que as mensagens são trocadas entre os objetos
envolvidos em um determinado processo. Normalmente baseia-se em um Caso de
Uso definido no Diagrama de Casos de Uso e se apoia no Diagrama de Classes
para determinar os objetos das classes envolvidas em um processo. Um Diagrama
de Sequência costuma identificar o evento gerador do processo modelado, bem
como o ator responsável por este evento e determina o desenrolar do processo e a
conclusão do mesmo a partir da chamada de métodos disparados por mensagens
enviadas entre os objetos.
4.2.3.11 Diagrama Geral de Interação
Segundo MELO (2004), este diagrama é uma variação do diagrama de
atividades que mostra de uma forma geral o fluxo de controle e interação dentro de
um sistema ou processo de negocio. Cada atividade dentro do diagrama pode ter
outro diagrama de interação. Este diagrama só foi integrado a UML a partir da
versão UML 2.0
4.2.3.12 Diagrama de Comunicação
Segundo MELO (2004), este diagrama é o antigo diagrama de colaboração,
que mostra objetos, seus inter-relacionamentos e o fluxo de mensagens entre
eles.Segundo GUEDES (2004), este diagrama complementa o diagrama de
sequência apresentando um enfoque diferente, sua informações são, com
frequência, praticamente as mesmas, entretanto o no diagrama de comunicação não
há a preocupação com a temporalidade do processo e sim com a forma como os
objetos estão vinculados e quais mensagens trocam entre si durante o processo.
39
4.2.3.13 Diagrama de Tempo
Segundo GUEDES (2004), o Diagrama de Tempo descreve a mudança no
estado ou condição de uma instância de uma classe ou seu papel durante um
tempo. Tipicamente utilizada para demonstrar a mudança no estado de um objeto no
tempo em resposta a eventos externos. É um diagrama introduzido na segunda
versão de UML, classificado como diagrama de interação. Este diagrama modela
interação e evolução de estados.
Na próxima seção faremos uma descrição da linguagem de JAVA.
4.3 JAVA
Segundo DEITEL H. e DEITEL P. (2005), com a revolução dos
microprocessadores, vieram inúmeros benefícios para o cenário evolutivo dos
computadores pessoais no mundo todo, juntamente com uma crença de grande
impacto nos dispositivos inteligentes destinados ao usuário final. Reconhecendo
isso, a Sun Microsystem financiou uma pesquisa corporativa interna liderada por
James Gosling e outros desenvolvedores com o codinome Green em 1991.
Já segundo CADENHEAD & LEMAY (2005), sendo este, um projeto de TV
interativa com inicio em meados da década de 1990, Gosling teria se frustrado com
a linguagem utilizada no projeto, C++, uma linguagem de programação orientada a
objetos desenvolvida por Bjarne Stroustrup na AT&T Bells Laboratories, cerca de 10
anos antes como uma extensão da linguagem C. Gosling trancou-se em seu quarto
e criou uma nova linguagem de programação adequada ao projeto em questão que
focalizava o suprimento de suas frustrações em relação à linguagem utilizada
anteriormente.
Para DEITEL H. e DEITEL P. (2005), Gosling apelidou a linguagem criada
de Oak, em homenagem a uma arvore de carvalho que tinha a vista de seu
escritório na Sun, quando mais tarde descobriu-se que já havia uma linguagem de
mesmo nome e foi quando a equipe da Sun visitou uma cafeteria local e por
sugestão, resolveram atribuir o nome da linguagem de Java (cidade de origem de
40
um tipo de café importado). Passando por maus momentos o projeto encontrou
dificuldades no prosseguimento, devido a uma baixa no mercado específico, mas em
compensação em 1993 a Word Wilde Web, entrou em evidencia, onde
imediatamente a Sun viu potencial para Java e através dela, podemos adicionar
conteúdos dinâmicos e iterativos as paginas web.
DEITEL H. e DEITEL P. (2003), usa como argumento a máxima que com
JAVA: “Escreva uma vez e rode em qualquer lugar (WORA)-Write Once, Run
Anywhere”, esse desde o inicio foi o lema defendido pela tecnologia. Java é uma
linguagem de programação orientada a objetos, baseada em C++, com a diferença
de que as estruturas complexas existentes no C++ foram removidas, onde nasce o
Java, simples e altamente poderoso, isso é possível pela existência da JVM (Java
Virtual Machine), impedindo que os programas Java rodem diretamente no sistema
nativo, fazendo com que eles sejam compilados e interpretados, mas passando por
cinco fases básicas que são ilustrados na figura 6.
Figura 6 Processo de execução de um programa Java
Fonte: DEITHEL 2005
Para DEITEL H. e DEITEL P. (2005), programas Java são compostos de
classes e essas por sua vez contem métodos, onde esses realizam tarefas ao
concluir. Os programadores Java detêm o poder de desenvolver suas classes e
métodos, assim como também a capacidade de manusear e aproveitar as coleções
existentes de classes internas da biblioteca Java , que são as chamadas APIs do
41
Java (Application programming Interface), assim criam-se dois aspectos para se
adentrar no mundo Java que são: o aprendizado da linguagem em se, a criação dos
próprios métodos e classes e o aprendizado das APIs que seria o reaproveitamento
dessas classes prontas para utilização.
Para CADENHEAD & LEMAY (2005), as facilidades de uma linguagem é
fator determinístico nas disputas entre programadores, afirma também que Java foi
projetada para ser mais fácil que C++, principalmente no que se refere aos aspectos
de que a JVM (Java virtual Machine) cuida automaticamente da alocação e
desalocação de memória, liberando os programadores de tal tarefa tediosa e
complexa, além de possuir apenas seis comandos que são: dois de decisão, três de
repetição e um para proteção do código, Java não utiliza ponteiros, um recurso
complexo usado por programadores experientes que facilmente pode ser mal
empregado; Java não aborda herança múltipla, apenas única em orientação a
objetos, sendo estes alguns recursos vantajosos que Java obtém para total robustez
e segurança.
4.3.1 ServLets e JSP
A internet está mudando a maneira como os negócios são feitos. As pessoas
se beneficiam profundamente quando procuram melhores preços e produtos,
comunidades de interesse especial podem permanecer em contato entre si. Os
pesquisadores podem se tornar instantaneamente cientes dos últimos avanços.
(DEITEL H. e DEITEL P. 2005).
Focando especialmente no relacionamento cliente e servidor, onde o cliente
solicita alguma ação e logo em seguida o servidor responde, sendo esta a base para
o nível mais alto de redes no Java, os Servlets e JSP (JavaServer Page), onde um
servlet nada mais que é do que um extensão do servidor web que prover as paginas
com base no protocolo HTTP, os dois pacotes básicos que dispõe das classes e
interfaces dos servlets são: javax.servlet e javax.servlet.http.
Pacotes como javax.servlet.jsp e javax.servilet.jsp.tagext, fornecem classes
referente ao JSP(JavaServer Page), usando um sintaxe especial, emula dentro da
42
aplicação web as funcionalidade do Java real como encapsulamento de
funcionalidade e conceitos concernentes a linguagem no que se refere orientação a
objetos , ou seja, através do JSP e possível usar todas as propriedades de Java2SE,
para o ambiente web. JSP simplifica o fornecimento do conteúdo dinâmico
reutilizando componentes predefinidos e interagindo com scripts que seguem ao
lado do servidor, onde existem quatro componentes primordiais para JSPs que são:
as diretivas, ações, elementos de scripts e bibliotecas de tags. (DEITEL H. e DEITEL
P. 2005).
As diretivas são enviadas para o contêiner de JSP, um componente do
servidor web que executa a JSP;
As ações detêm o encargo de encapsular as tags predefinidas.
Os elementos de script permitem a inserção do código Java que venha
interagir com o JSP;
As bibliotecas de tags permitem o programador criar tags suas próprias tags.
Pela gama de atributos e fatores que Servlets e JSPs oferecem no tange a
derivação e extensão de toda estrutura da linguagem Java, fatores imprescindíveis,
como segurança, portabilidade, otimização e robustez, não podem ser desprezados
no que tange o desenvolvimento de uma aplicação web, sendo este e todos os
outros fatores estabelecidos e constatados logo acima, sendo o motivo maior da
escolha de Servlets e JSP para o desenvolvimento do SATI (Sistema de
atendimento técnico em informática), para que o mesmo venha herdar todas as
inúmeras vantagens cruciais de JAVA e ter o status relevante de uma aplicação
JSP.
Segundo PINHEIRO (2011), com negociações em um prazo de uma semana
o gigante Oracle investiu nas ações da Sun Microsystem assim dando inicialmente
oferta de sete bilhões, mas fechando a nove bilhões de dólares, fazendo desta
junção um conjunto de novidades para o mundo da TI e de todo o mundo, onde
surgiu o JDK 7 Developer Preview, uma versão para que desenvolvedores testem as
novas funcionalidades ate então, ultima versão do Java, que com toda portabilidade
tem grande influencia nos mundos de Server Programming, aplicações de e-
commerce, e-business, aplicações para acesso via Internet, intranet entre outras,
43
com recursos incríveis além de novas APIs, que permitem o manuseio da linguagem,
sendo as melhorias inovadoras causa das maiores disputas no mercado de trabalho,
onde tivemos melhorias nos quesitos de separador de dígitos em literais
numéricos,literais binários,variáveis do tipo string em comandos switch, inferência
na criação de objetos de tipos genéricos além de outros que ainda serão publicados.
Na próxima seção faremos uma breve descrição da linguagem de
programação PHP, que será utilizada na implementação do sistema proposto.
4.4 PHP - Hypertext Preprocessor
Segundo WELLING (2005), a linguagem PHP surgiu em 1994 como um
projeto pessoal de Rasmus Lerdorf com o intuito de controlar os acessos a sua
página WEB. Esta linguagem é fortemente baseada nas linguagens C, Java e Perl e
ainda pode ser vista como uma combinação de linguagem de programação e
servidores de aplicações. Permite criar sites WEB dinâmicos, fornece forte suporte
para o acesso a banco de dado. O lançamento do PHP4 ocorreu em maio de 2000,
onde trouxe como uma das principais novidades o suporte a sessões, com o intuito
de identificar o cliente que solicitou determinada informação.
Segundo WELLING (2005), além das mudanças referentes à sintaxe e aos
novos recursos de programação, o PHP4 trouxe também um recurso chamado
Zend, que permite a execução otimizada de scripts PHP. Ainda assim, essa
linguagem possui código aberto, e é o resultado de contribuições de uma
comunidade de programadores interessados, contribuindo gratuitamente e estando
disponível em um grande número de plataformas.
Segundo MORAZ (2005), o código PHP é embutido no HTML, ou seja, ele
pode ser escrito no meio de uma página HTML que será interpretada pelo servidor.
O PHP é executado no servidor, sendo enviado para o cliente apenas HTML puro.
Desta maneira é possível interagir com bancos de dados e aplicações existentes no
servidor, com a vantagem de não expor o código fonte ou as regras de negocio para
o cliente.
44
Segundo MORAZ (2005), PHP é multiplataforma, pois, apesar de
tipicamente ser utilizado em conjunto com o Linux/FreeBSD e o Apache, roda em
Solaris e Windows. Com relação à eficiência: consome pouco recurso do servidor,
é mais rápido e evita chamada externa, tornando-o mais eficiente; tem acesso a
Banco de Dados: acessa qualquer banco de dados, diretamente ou por meio do
ODBC; é capaz de processar imagens: criando imagens dinâmicas e enviando ao
browser do usuário; lê também informações padrão XML, processa arquivos,
manipula variáveis complexas, utiliza funções, classes e gera código JavaScript,
manipula e-mails e gerencia documentos PDF.
Segundo DALL'OGLIO (2009), uma das principais vantagens do PHP é o
suporte nativo a um grande número de bancos de dados, como dBase, Interbase,
mSQL, mySQL, Oracle, Sybase, PostgreSQL, além disso, tem suporte a outros
serviços através de protocolos como IMAP, SNMP, NNTP, POP3 e, logicamente,
HTTP. Pode-se utilizar sockets e interagir com outros protocolos. Em sua versão 5.0
o PHP ofereceu suporte completo a orientação a objeto.
Segundo MORAZ (2005), PHP também realiza várias funções para Internet
como: tratamento de cookies de comercio eletrônico, e em geral realiza funções
matemáticas, exploração de cadeias de datas, correção ortografia e compressão de
ficheiros. No campo do e-commerce, podemos utilizar funções especificas para
Cybescash, CyberMUT e outros, que são práticos para sistemas de pagamento
online.
Assim como a linguagem JavaServer Pages (JSP), o PHP pode ser pré-
compilado para aumentar a sua performance. A pré-compilação é feita através do
uso de um módulo acelerador (também disponível como software livre).
Na próxima seção faremos uma breve descrição dos métodos de ágeis.
4.5 DESENVOLVIMENTO ÁGIL
Segundo BECK (2000), devido às exigências do mercado, grande
competitividade e importância maior no que tange prazos, justamente por isso que
45
as empresas precisam desenvolver projetos com um tempo cada vez mais reduzido,
para permitir isso se tem os métodos ágeis que englobam um conjunto de atividades
baseadas nas melhores práticas de metodologias ágeis.
Já segundo WILLIAN (2008), os métodos ágeis surgiram no final da década
passada, em fevereiro de 2001, um grupo de dezessete metodologistas criou o
manifesto ágil, ou mesmo a Agile software Development Alliance, o que os métodos
ágeis buscam não é como conter as mudanças mais cedo em um projeto de
software, mas a melhor maneira de tratar mudanças inevitáveis ao longo de seu
ciclo de vida. O manifesto ágil foca alguns conceitos que serão abordados logo
abaixo:
Indivíduos e interações ao invés de processos e ferramentas;
Software operante ao invés de documentação abrangente;
Colaboração do cliente ao invés de negociações de contratos;
Respostas rápidas a mudanças ao invés de seguir um plano.
Para WILLIAN (2008), o processo ágil não rejeitar, as negociações,
documentações ou mesmo o planejamento, apenas mostra que todo isso tem
aplicação secundária no que se referem aos conceitos chaves do manifesto.
Dentre os processos ágeis existem várias metodologias como: XP (Extreme
programming), SCRUM, DSDBM, Crystal dentre outros. Citam-se logo abaixo os
mais importantes:
XP (Extreme Programming) – Segundo KNIBERG (2007), XP é um método ágil
baseado em requisitos vagos e instancias que são altamente dinâmicas, o que se
destaca desta metodologia é a forte comunicação entre o cliente, a programação,
pareada (programação a dois), há um diferencial no requisito treinamento, enquanto
que no desenvolvimento tradicional a falta de treinamento influencia diretamente no
prazo de um projeto, na metodologia XP um dos integrantes da dupla vai sendo
treinado ao longo do desenvolvimento de maneira transparente para o projeto. É
uma metodologia que encoraja a equipe a enfrentar as mudanças, como algo
natural, sendo importante se adaptar aos contratempos que acontecem no projeto,
46
contornando assim as dificuldades do modo mais simples possível sem perder o
foco básico: produzir um produto de qualidade, almejando excelência.
SCRUM – Para KNIBERG (2007). Baseado em princípios relativamente
semelhantes ao XP, o SCRUM divide-se em iterações, ou SPRINTs, de trinta dias,
onde equipes pequenas, de até dez pessoas, são formadas entre programadores,
engenheiros de software e analistas e cada equipe trabalha focado numa SPRINT,
sendo este formado em três fases principais que são elas : pré-planejamento (pré-
game phase), desenvolvimento (game-phase) e pos-desenvolvimento (pos-game
phase). É uma metodologia com o foco no gerenciamento da equipe, preocupada
naorganização dos processos, no modo como as atividades devem ser executadas,
deixando a cargo dos participantes do projeto escolher a melhor maneira de concluir
com sucesso essas etapas. Os requisitos do software são levantados e organizados
em uma lista de funcionalidades, chamada product backlog, que contém todo o
escopo do projeto definido juntamente com o cliente, e suas respectivas prioridades
de desenvolvimento, sendo que o product backlog dever ser constantemente
revisado, validado e atualizado. O desenvolvimento é dividido em iterações,
chamado de sprints, de duração entre duas a quatro semanas. Cada sprint é
composta de uma lista de tarefas, funcionalidades com prioridades retiradas do
product backlog, chamada de sprint backlog. Definido as atividades a serem
realizadas em cada sprint, a equipe foca o desenvolvimento de mais um ciclo que
se repete ao longo do projeto. Após o encerramento das sprints é realizada a sprint
retrospective, uma das mais importantes práticas dentro da Scrum, que são
discutidos os pontos positivos e os negativos;
MSF Agile – Segundo Willian (2008), como uma compilação da Microsoft o
Microsoft solution Framework, surgindo em 1994, como um conjunto de boas
práticas, a partir de sua experiência de desenvolvimento de software e consultoria,
sendo este framework também dinâmico e disposto a dar respostas rápidas no que
tange a problemas recorrentes no desenvolvimento de softwares.
Na próxima seção faremos uma descrição de Banco de Dados, Sistemas
Gerenciadores de banco de Dados (SGBD), os SGBDs MySQL e ORACLE e a
linguagem SQL.
47
4.6 BANCO DE DADOS
Segundo a KORTH (1995), a finalidade básica dos bancos de dados é
armazenar os dados de forma organizada. Isso faz com que os dados fiquem
disponíveis para serem usados ou atualizados por todos que tenham acesso a estas
informações.
Segundo DATE (2004), um SGBD (Sistema Gerenciador de Banco de
Dados) é um conjunto de dados que associados a um conjunto de programas
proporcionam o acesso a esses dados. Como o banco de dados possui estrutura
conhecida, o sistema que o armazena possui diversas ferramentas poderosas para
prolongar sua utilização, e mecanismos para a manipulação dos dados
armazenados.
4.6.1 Modelo de dados
Segundo KORTH (1995) sob a estrutura do banco de dados está o modelo
de dados: um conjunto de ferramentas conceituais usadas para descrever dados,
relacionamento entre dados, semântica e regras de consistência. Os modelos
podem ser classificados em três grupos:
Modelos Lógicos com Base em Objetos;
Modelos Lógicos com Base em Registros;
Modelos Físicos.
4.6.1.1 Modelo Lógico com Base em Objeto
Segundo KORTH (1995), estes modelos são usados na descrição de dados
no nível lógico e de visões. Possuem recursos de estruturação bem mais flexíveis e
viabilizam a especificação explícita das restrições dos dados. Vários modelos
integram esta categoria, alguns já são bem conhecidos, como:
Modelo entidade-relacionamento: Tem por princípio a percepção do mundo real
como conjunto de objetos básicos, chamados de entidades e do relacionamento
entre eles;
48
Modelo orientado a objeto: Assim como o modelo entidade-relacionamento, tem
por base um conjunto de objetos, onde um objeto contém valores armazenados em
variáveis instâncias, contendo também um conjunto de códigos que operam esse
objeto;
Modelo semântico de dados: Têm como objetivo a representação de determinada
parte do mundo real, sendo assim, o que se busca é que o modelo produzido
traduza de maneira mais próxima possível os objetos que ele representa. Segundo
DATE( 2004), por ter como base um contexto e a semântica que cada objeto tem
para um determinado grupo de usuário dentro desse contexto, um determinado
objeto no mundo real pode muito bem ser considerado uma entidade por algumas
pessoas e propriedades por outras e ainda associação por outras. Uma das metas
da modelagem semântica é suportar tal flexibilidade de interpretação.
Modelo funcional de dados: esse modelo de dados é baseado em atributos, onde
as entidades são valores de atributos e cada atributo pode ter vários valores. O
Modelo Funcional de Dados também é um tipo de modelo semântico de dados.
4.6.1.2 Modelos Lógicos com Base em Registros
Ainda segundo KORTH (1995), são utilizados para descrever os dados no
nível lógico e de visões. Contrastando com o modelo com base em objetos, este tipo
de modelo é usado tanto para especificar a estrutura lógica do banco quanto para
programar uma descrição de alto nível. Este grupo também se divide em:
Relacional: Representa dados e relacionamentos entre dados através de um
conjunto de tabelas, cada uma tendo um número de colunas com nomes únicos,
este modelo oferece a possibilidade de expressar consultas e manipulações sobre a
base de dados usando linguagens independentes de sistemas, baseadas em
álgebra relacional e em cálculo relacional;
Hierárquico: Neste tipo de gerenciador os dados ficam representados em forma de
árvore, composto por uma hierarquia de registros de dados onde cada um dos
seguimentos inferiores depende hierarquicamente dos segmentos superiores.
49
Rede: Este por sua vez representa os dados como registros vinculados uns aos
outros formando um conjunto comum de dados. O modelo de rede é semelhante ao
modelo hierárquico. Podendo até mesmo dizer que o modelo de rede é a
generalização do modelo hierárquico.
4.6.1.3 Modelos Físicos
Ainda segundo KORTH (1995), este modelo é utilizado para descrever os
dados em nível mais baixo, contrastando com os modelos lógicos. Há poucos
modelos físicos de dados sendo utilizados hoje. Dois destes modelos são
conhecidos:
Modelo unificado (unifying model); consiste num modelo simples que organiza
registros de dados com uma única chave, chamada de chave de agrupamento, que
pode ser de três tipos: Logical valued key, Hash key e Relative location key.
Modelo de partição de memória (frame-memory model): esse modelo fornece uma
visão do armazenamento secundário que pode ser implementado, de modo a
fornecer um suporte razoável para o armazenamento e acesso aos registros de
dados de um sistema. Foi projetado de forma que suas características operacionais
possam ser facilmente manipuladas por desenvolvedores de sistemas ou
programadores.
4.6.2 SGBD
Para ELMASRI (2005), um SGBD ou sistema gerenciador de banco de
dados é uma coleção de programas que permite aos usuários criar e manter um
banco de dados, sendo este um sistema de software de propósito geral que vem
facilitar os processos de definição, construção, manipulação e compartilhamento de
banco de dados entre diferentes tipos de usuários e aplicações diferentes.
Ainda para ELMASRI (2005), no que tange a construção de um banco de
dados, o fator essencial se da no processo de armazenamento de dados em uma
mídia apropriada, gerenciada pelo SGBD, sendo que a manipulação dos dados é
feita através de funções principais como pesquisa no banco de dados para
50
recuperação de dados convenientes, atualização do banco para que a modificações
sejam refletidas no minimundo e assim gere a gama de dados informacionais
desejados, além de permissão de múltiplos usuários e programas acessar em
concorrência o banco de dados através de compartilhamento, onde o SGBD aborda
também, funções de proteção e manutenção do banco, senso a proteção referente a
falhas de funcionamento (crashes) no hardware ou mesmo software, além da
segurança contra acessos maliciosos ou não autorizados.
O banco de dados foi criado para permanecer sob um ciclo de vida extenso,
assim os SGBDs vêm como uma forma de estender ainda mais a durabilidade
tornando possível a manutenção em todos os casos, mas principalmente no que se
refere à evolução dos requisitos que se alteram ao longo do tempo.
Já segundo GALANTE (2007), um SGBD tem particularidades e
propriedades que facilitam os processos de definição, construção e manipulação de
dados, abaixo descrevemos as principais características de um SGBD:
Controle de redundância - são construídas regras de gerenciamento mais eficaz,
impedindo a duplicação de dados e economizando espaço em disco;
Restrição a acesso não autorizado – Cada usuário, independentemente do seu
nível hierárquico obtém uma senha de acesso no que lhe é permitido, tornando o
SGBD eficaz em sua função;
Garantia de armazenamento persistente – a partir de um SGBD é possível se
armazenar dados de uma forma organizada;
Garantia de armazenamentos de estruturas para o processamento eficiente de
consultas: quesito muito relevante nas qualidades de um SGDB, pois o mesmo
prover mecanismos inteligentes de buscas, inserções e atualizações dos dados;
Compartilhamento de dados – os SGBDs multiusuários devem fornecer um
controle no que tange o paralelismo e a concorrência, para assegurar que as
atualizações simultâneas resultem em modificações corretas e seguras;
51
Fornecimento de múltiplas interfaces – com a exigência de vários tipos de
usuários diferentes, o SGBD deve fornecer variedades de interfaces para cada um;
Representação de relacionamentos complexos entre dados - uma base de
dados pode ter variedades de dados, onde o SGBD deve ser capaz de gerenciar a
variedade de relacionamentos complexos entre dados, tal como recuperar e
modificar tais dados relacionados de maneira fácil e eficiente;
Backup e restauração – A garantia de backup e restauração é fator essencial para
qualquer SGBD que se preze, onde seja qual for a falha proveniente de hardware ou
software , deve-se manter a integridade dos dados;
Restrições de integridade – com o SGBD é possível impor restrições onde
diminuem ainda mais as probabilidades de um usuário causar algum erro.
4.6.3 MYSQL
Segundo WELLING (2004) o Mysql surgiu como ferramenta para atender a
uma necessidade interna. Com o funcionamento lento do MSQL em relação a
ligações de tabelas através das suas rotinas ISAM, Inered Seqüencial Access
Method (método de acesso sequencial indexado), os autores trabalharam buscando
uma solução, tendo como resultado o Mysql, com muito mais recursos que o MSQL
e muito mais rápido. O MySQL apresenta um bom desempenho em todas as
plataformas, por essa razão sua popularidade tem crescido nos últimos anos. É um
gerenciador de banco de dados que implementa um subconjunto da linguagem SQL,
sendo suficiente para a maioria das aplicações. O Mysql utiliza o modelo de dados
relacional, suportando banco de dados que consistem em um conjunto de dados e
relacionamentos entre si.
4.6.3.1 Descrição do MYSQL
Segundo DATE (2004) o MySQL é um gerenciador de banco de dados, que
suporta múltiplas linhas de execução, que se refere à capacidade de dividir um
serviço em pequenas partes, sendo que cada parte é chamada de tria (linha de
52
execução ou sub-processo), que pode operar de maneira independente em relação
a outras. Quando um aplicativo usa linhas de execução controladas pelo Kernel em
uma máquina com várias CPUs, ele pode distribuir o trabalho entre elas para que o
executem simultaneamente.
Segundo WELLING (2004), o MySQL possui um conjunto de API que
suporta várias linguagens de programação, entre elas o C, C++, Java, Perl e PHP
entre muitas outras. A API vem do inglês Application Programing Interface (Interface
de programação de aplicativos), e pode ser escrita para qualquer tipo de servidor ou
sistema operacional. A API do MySQL fornece uma lista reduzida de rotinas que
podem ser chamadas de dentro de um programa para interagir com o banco de
dados. O MySQL faz uso índices, que são tabelas especiais, que tem por
finalidade possibilitar a pesquisa por dados sem ter que percorrer linha por linha de
uma tabela.
O MySQL usa um sistema de privilégios e senha baseado em tabelas de
sistema. Esse sistema é flexível e por isso exige um pouco de conhecimento para
implementar regras mais complexas.
4.6.4 SQL ( Strutured Query Language)
Segundo RAMALHO (1999), SQL tem representado o padrão para
linguagem de banco de dados relacionais. Existem muitas versões de SQL, mas a
versão original foi desenvolvida pela IBM no laboratório de San Jose (atualmente o
centro de pesquisa Almaden). Seu nome original era Sequel foi evoluindo e
modificado para SQL. Houve esforço conjunto da ANSI (American National
Standards Institute) e da ISO (International Standards Organization) para a
padronização da linguagem SQL em 1986, como resultado deste esforço conjunto
foi lançada a primeira versão do padrão da linguagem o SQL-86.
Segundo GUIMARÃES (2003), os bancos de dados comerciais necessitam
de uma linguagem de consulta que possibilite uma maior facilidade para os usuários.
Refere-se à linguagem SQL como uma linguagem de consulta, porém ela possui
vários outros recursos. A linguagem SQL é uma linguagem de banco de dados
53
abrangente. Ela possui comandos para definição de dados, consultas e atualizações
(tem ambas as linguagens DDL e DML). Possui também regras para embutir os
comandos SQL em linguagens de programação genéricas: Java, Cobol ou C/C++.
Ainda segundo GUIMARÃES (2003), SQL usa os termos tabela, linha e
coluna, em vez dos termos relação, tupla e atributo, respectivamente, para o modelo
relacional formal. O principal comando SQL para definição de dados é o CREATE,
que pode ser usado para criar esquemas, tabelas, domínios e restrições. Um
esquema SQL agrupa tabelas e outros construtores que pertencem à mesma
aplicação de BD. É identificado por um nome de esquema e inclui uma identificação
de autorização, que indica o usuário ou a conta ao qual o esquema pertence. Os
elementos de esquema incluem tabelas, restrições, permissões, domínios e outros
construtores.
Segundo COSTA (2006), o SQL se tornou a linguagem padrão para lidar
com bancos de dados relacionais, e por ser padrão é aceita por quase todos os
produtos existentes no mercado.
4.6.5 ORACLE
Antigamente a Oracle era basicamente uma empresa de banco de dados
relacional, além do que ela não tinha aplicativos enlatados, já hoje ela dispõe de um
quadro totalmente diferente, sendo uma empresa com valor estimado em bilhões de
dólares, com uma gama de produtos, serviços e aplicativos grandes, onde
inicialmente ela era uma empresa que trabalhava com banco de dados relacionais,
sendo que os mesmo na época eram um novo modo de se pensar em relação a
como os dados seriam armazenados e estruturados. Apostando na ideia de um perfil
de banco que pudesse resistir ao teste do tempo e levar em conta uma estrutura
onde apenas os dados fossem alterados ao invés da própria estrutura, sendo
justamente estes alguns dos motivos pela qual a Oracle resolveu investir em
estratégias relacionais, assim suplantando as estratégias tradicionais, tais perfis de
banco de dados, anteriores aos relacionais que eram regidos por arquivos mestres
ao invés de tabelas como conhecemos hoje convencionalmente, ABREY E COREY
(1997).
54
Ainda para ABBEY E COREY (1997), a Oracle System Corporation, sediada
em Redwood Shores, Califórnia produz software e distribui serviços para o
gerenciamento eletrônico de informações, a mesma faz parte da corrida sem fim
para trazer um produto de qualidade e que satisfaça seus usuários, a Oracle fabrica
um conjunto de produtos que giram em torno de seu Oracle Server o que é um
ambiente de gerenciamento de informação, sendo um depósito para grandes
quantidades de dados possibilitando o usuário o acesso a tais dados com grande
velocidade e agilidade. O Oracle Server como um poderoso SGBD dispõe de
compartilhamento de dados entre aplicativos, as informações são armazenadas em
um lugar e usadas por muitos sistemas, esta característica possibilita ao Oracle
Server suportar as configurações a seguir:
Baseado em hospedeiro – os usuários são conectados diretamente onde reside o
banco de dados;
Cliente/Servidor - os usuários acessam o banco, a partir de seu computador
pessoal (cliente), por meio de uma rede, já o banco de dados em um computador
separado (servidor) enviará as respostas;
Processamento distribuído – usuários acessam os dados em servidores
fisicamente separados, onde está distribuído em mais de uma máquina e seus
usuários não tem conhecimento onde estão situados os dados acessados.
Já segundo RAMALHO (1999), Oracle Server é um sistema de
gerenciamento de banco de dados, de uma instância de servidor Oracle. Um banco
de dados Oracle tem uma estrutura física e lógica, como essas estruturas no
servidor são separadas o armazenamento físico dos dados pode ser gerenciado
sem afetar os acessos as estruturas lógicas de armazenamento.
Estrutura física – essa estrutura é determinada pelos arquivos do sistema
operacional que o compõe, onde cada banco de dados Oracle é composto por três
tipos de arquivos sendo: um ou mais datafiles, dois ou mais arquivos de registro
redo e um ou mais arquivos de controle, sendo estes arquivos que fornecem
informações do Oracle em um armazenamento físico;
55
Estrutura lógica- estrutura determinada por um ou mais tablespaces, espaços
lógicos de armazenamento, também pelos objetos de esquemas (coleções de
objetos que se igualam a estruturas lógicas que se referem diretamente aos dados
do banco).
Para RAMALHO (1999), o Oracle gerencia e permite o controle rígido do
espaço usado em disco por meio das estruturas lógicas de armazenamento,
incluindo os blocos de dados, as extensões e os segmentos. Os dados no Oracle
são armazenados em blocos de dados, onde um bloco corresponde a um numero
especifico de bytes em um disco. As extensões são o próximo nível do espaço lógico
além de ser um número especifico de blocos de dados contíguos, obtido em uma
alocação simples. O nível de armazenamento lógico sucessor e que esta acima da
extensão é o segmento, sendo um conjunto de extensões alocado para uma
determinada estrutura lógica.
Ainda segundo RAMALHO (1999), no SGBD Oracle existe atributos que
permanecem intactos no que tange sua substituição sendo aplicável apenas a sua
evolução, onde o mesmo aloca dinamicamente o espaço quando extensões
existentes de um segmento ficam cheias, ocorrendo isso o Oracle aloca outra
extensão para aquele segmento, conforme sua necessidade. No que se refere à
estrutura física fazem parte dela os datafiles, os arquivos de registro redo e os
arquivos de controle descrito nos tópicos abaixo.
Datafiles – todo e qualquer banco de dados Oracle tem um ou mais datafiles, onde
nesses datafiles contem todos os dados desse banco de dados, já os dados de
estruturas lógicas, como tabelas e índices são armazenados fisicamente nos
datafiles alocados;
Arquivos de registro redo – chamado de registro redo multiplexador, é constituído
de cópias do arquivo de registro redo online localizados em discos separados;
Arquivos de controle - Havendo início em uma instancia Oracle, o arquivo de
controle é usado para identificar os arquivos redo e do banco, o qual deve ser aberto
para que a operação de continuidade.
56
Para ABBEY E COREY (1997), existem fatores e recursos que tornam
determinísticos que levaram a Oracle no seu patamar de excelência que está hoje,
sendo estes os mesmo que vem acompanhando até hoje as versões mais atuais
como: Mecanismos de segurança, cópia e recuperação(Backup), gerenciamento de
espaço, conectividade aberta, ferramentas de desenvolvimento. No que se refere
aos componentes do Oracle Server temos:
Opção procedural - sendo esta na versão 7.0, é adquirida separadamente do
Server, já nas 7.1 é acoplada sem custo adicional. A essência dessa opção é a
linguagem de programação da Oracle, chamada de PL/SQL podendo com essa
opção, implementar procedimentos armazenados, que são segmentos de códigos
que ficam armazenados no banco de dados e executam funções centrais para sua
instalação, além de implementar também gatilhos de banco de dados, que são
código armazenados no banco de dados, disparados por eventos que ocorrem no
aplicativo, juntamente com os pacotes que agrupam procedimentos e armazenam o
código com uma única unidade de programa no banco de dados;
Opção Distribuída – usuários de diferentes lugares fisicamente acessam dados,
onde não tem ciência de sua localização sendo a utilização do mesmo banco de
dados;
Opção de servidor paralelo – permite que o Oracle opere com mesma
configuração em se tratando de computadores agrupados, cada um com sua
memória;
Opção de consulta paralela - permite que usuários façam consultas paralelas em
computadores com mais uma unidade central de processamento.
Segundo OLIVEIRA (2005), sendo a Oracle uma grande fornecedora de
produtos que gerenciam dados e informações, chegou a um patamar tal que seu
produto ate então sempre com um potencial exuberante, nunca deixaram a desejar
no quesito qualidade, sendo que um de seus produtos mais recentes e interessantes
e a maquina virtual Oracle - Oracle VM, com uma interface super amigável e
intuitiva, melhorando a vida daqueles que necessitam trabalhar com VMs, provando
assim mais uma vez a competência da Oracle Corporation.
57
4.6.6 ORACLE 10G EXPRESS EDITION
Segundo NOVELLI (2005), o Oracle 10G representa grandes mudanças,
muitas foram as modificações nesta versão. Oracle 10G Express Edition, onde o G é
uma abreviação do obscuro conceito de GRID que representa às sinergias que
podem ser alcançadas alinhando as tecnologias Oracle às capacidades de hardware
existentes e futuras, a partir dessas novidades podemos nos beneficiar dos
componentes para o GRID por meio do Oracle real application Cluster, Automatic
storage managentement (ASM) e Ultra-Large Data Files. Compartilhar informações
independentemente da localização - Esse conceito é suportado por meio dos novos
recursos de espaço de tabelas transportáveis, Oracle Streams (exemplo -
Replication), tabelas externas e consultas SQL distribuídas, além de Agendar
recursos no Grid - Os novos recursos do Oracle Sheduler e do Oracle Database
Resource Manager ajudam o DBA a efetivamente aproveitar melhor o GRID. O
DBUA é uma interface gráfica projetada para atualizar o banco de dados Oracle para
Oracle Database 10g, também se pode iniciar o DBUA do Oracle Universal Installer
(OUI) ao instalar o Oracle Database 10g.
Segundo OLIVEIRA (2005), em relação à linguagem, pode-se observar
mudanças relevantes como:
Novos tipos de dados do IEEE;
Expressões regulares;
Operações em grupos em tarefas aninhadas;
Inserção de caracteres especiais definidos pelo usuário;
Modificações na sintaxe do comando FORALL.
Segundo ABBEY E COREY (1997), SQL*PLUS do Oracle e um SQL padrão
dotado de alguns acessórios específicos do Oracle, onde antigamente era chamado
de UIF (interface amigável de usuario-user friendly interface).
Para OLIVEIRA (2005), o SQL*PLUS que esta disponível em praticamente
todas as versões do Oracle, sendo um programa que permite criar desde SQL
58
simples ate subprogramas, ele envia informações ao servidor e então e
correspondido. Eis as principais funções que SQL*PLUS desempenha:
Criar, editar, recuperar e executar comandos SQL;
Criar relatórios simples;
Criar, editar, armazenar, recuperar e executar blocos PL/SQL;
Verificar informações de tabelas;
Enviar e receber mensagens de usuário;
Administrar o banco de dados Oracle.
Segundo a documentação Oracle, o Oracle 10G e um bando de dados
gratuito, por esse motivo têm limitações como limite de quatro gigabytes de banco
de dados, um processador por maquina e tem um limite de um gigabyte de memória
RAM, não sendo estas limitações relevantes para um uso permanente do banco, já
que o mesmo e passível de atualização para versão paga de forma simples, além de
ter interação com as principais linguagens de programação do mercado.
59
5. PROPOSTA DO NOVO SISTEMA
Um controle eficiente, automatizado e otimizado dos procedimentos e
padrões no que se refere ao processo de entrada e saída de equipamentos da
empresa, com foco na qualidade e agilidade no atendimento e comunicação com o
cliente.
O Sistema de atendimento técnico em informática SATI, objetiva esses
fatores que julgamos ser essencial para um bom relacionamento com o cliente.
5.1 Descrição do Sistema Proposto
O Sistema de atendimento técnico em informática SATI, vem sugerir
melhores práticas para os processos rotineiros da SHIFT Computadores a partir de
um gerenciamento compatível com todos os níveis hierárquicos da empresa, com
foco no nível mais baixo do organograma que é o técnico, onde o sistema o apoiará
com diversas funções e facilidades que garantem a agilidade no seu trabalho. Desde
a entrada do equipamento até sua devolução ao cliente, do atendimento inicial ao
final, trazendo um eficiente sistema de comunicação com o cliente, pois as ordens
de serviços já orçadas são registradas no sistema com um alerta para que o
atendimento contate o cliente e obtenha a aprovação para a execução dos serviços,
assim como as OS autorizadas são emitidos alertas para a equipe técnica
possibilitando assim um acompanhamento dos serviços, não permitindo que
equipamentos sejam esquecidos nas prateleiras sem o devido atendimento e
também possibilita que os gestores acompanhe o desempenho da equipe.
5.2 Resultados Esperados
Com uma interface totalmente amigável e através da intranet os funcionários
poderão navegar pelo sistema de acordo com os papeis que desempenhar na
empresa, assim como o gestor poderá acompanhar o andamento das ordens de
serviço. Neste momento não está previsto nenhuma conexão com a internet, pois as
atividades para a qual o sistema se propõe são apenas internas. Espera-se do
sistema um funcionamento pleno e íntegro de todas suas funcionalidades, assim
como uma robustez em todas as funções básicas.
60
5.3 Restrições do Sistema Proposto
Apesar de o SATI ser um sistema desenvolvido para plataforma web, não
disporá de acessos externos.
5.4 Análise de Viabilidade Econômica do Novo Sistema
O sistema proposto terá sua distribuição gratuita, com código aberto, não
haverá patentes ou registro de propriedade do mesmo. Portanto a análise de
viabilidade econômica fica a cargos das empresas que se dispuser a utilizar o
sistema, visto que terão que adquirir equipamentos e formar a infraestrutura para a
correta utilização, além de treinamento dos usuários, entretanto vale salientar que as
mudanças de rotina da equipe de trabalho, conferindo mais agilidade e controle
sobre as ordens de serviço e orçamento, eliminação do transito de papeis, vai
possibilitar a redução de prazos, melhor comunicação com clientes e gestão mais
eficiente dos recursos.
5.5 Áreas Afetadas Pelo Novo Sistema
A implantação do novo sistema terá impacto primordialmente na adaptação
dos procedimentos que até então eram analógicos e manuais, mudando as rotinas,
e até mesmo gerando uma nova política de segurança aos funcionários, sendo
assim indispensável que os mesmo tenham treinamento adequado para uma melhor
desenvoltura ao operar o sistema.
5.6 Implementações Futuras
Já na fase de análise foram identificados requisitos, os quais, podem ser
implementados futuramente adicionando melhorias ao sistema tais como:
possibilidades da comunicação com o cliente através de email ou dos serviços de
SMS, com o objetivo de notifica-los da conclusão do preço e do prazo de
orçamentos, obtenção de autorização para execução de serviços, e da conclusão
dos mesmos.
61
6. DOCUMENTOS DE ANÁLISE
Será relacionada a documentação produzida para o desenvolvimento, que
viabilizará possíveis melhoramentos no sistema ora proposto.
6.1 Visão Macro dos Atores
Segundo DEBONI (2003), os atores representam as pessoas, as entidades,
ou os sistemas que fornecem informações ao sistema ou as recebem dele, definem
suas necessidades na forma de objetivos a serem cumpridos pelo sistema, os quais
são capturados pelos casos de uso.
6.2 Identificação dos Atores
No sistema proposto teremos 03 tipos de atores, são eles:
Atendente: é o profissional responsável pelo contato inicial com o cliente,
responsável pelo cadastramento do cliente, equipamento e de gerar a ordem de
serviço, é responsável também por estabelece todos os contatos com os clientes;
Técnico: é o profissional que em vista da ordem de serviço recepciona o
equipamento e após o diagnostico do defeito elabora o orçamento no sistema;
Administrador: é o Gerente da empresa responsável pelo controle e
acompanhamento das ordens de serviços e orçamento é o responsável por manter o
cadastramento de fornecedores, funcionários, peças, serviços e seus respectivos
preços além de solicitar os relatórios de faturamento mensal.
6.3 Tabela de Casos de Uso
A seguir na tabela 02 ilustram-se os casos de uso e suas principais
funcionalidades e suas principais descrições.
62
Tabela 2 - Lista dos UC's Caso de Uso Função/Caso de Uso
UC 01 Manter Login Permite o cadastramento dos usuários do sistema, seus perfis e
identifica o usuário permitindo-o acessar ao sistema.
UC 02 Manter Cliente Permite ao profissional do atendimento incluir, alterar e consultar
cliente.
UC 03 Manter Ordem de
Serviço
Permite ao atendente incluir, alterar e consultar ordens de
serviço e cadastrar equipamentos.
UC 04 Manter
Orçamento
Permite ao técnico de manutenção a inclusão, alteração,
conclusão e consulta de orçamentos e aos atendentes a
consulta.
UC 05 Manter
Faturamento
Permite ao gerente a elaboração dos relatórios de faturamento
segundo um período de competência.
UC 06 Manter
Fornecedor
Permite ao gerente a inclusão, alteração, consulta e exclusão de
Fornecedores.
UC 07 Manter Usuário Permite exclusivamente aos gerentes a inclusão, alteração e
exclusão de usuários.
6.4 Diagrama de Casos de Uso
Na figura 07 apresentamos o Diagrama de Casos de Uso do sistema
proposto.
Figura 7 Diagrama de Casos de Uso
63
6.5 Descrição Detalhada dos Casos de Uso
A tabela 3 é usada para detalhar o caso de uso UC001 – Login.
Tabela 3 - UC001 Caso de Uso Login
Nome UC001 – Login
Objetivo Obter acesso ao sistema por meio dos perfis previamente definidos
Atores Atendente, Técnico e Administrador
Dados Consumidos Login e senha
Dados Produzidos Acesso ao sistema
Prioridade Alta
Pré-condições Perfil de acesso e autorização previamente concebida.
Pós-condições NA
Fluxo Principal
Este caso de uso se inicia quando o ator inicia o aplicativo.
Ator Sistema
Abre a pagina inicial do sistema. Exibe tela de acesso ao sistema.
Preenche os campos de “usuário” e “senha” e
clica em “entrar"
O sistema valida os dados inseridos.
Permite acesso ao sistema
FE01 - Fluxo Exceção
Digitação da senha ou usuários incorretos
Ator Sistema
Digita a senha ou a ID incorreto Emite [MA17].
Confirma a mensagem Retorna ao fluxo principal
FE02 - Fluxo Exceção
Ator erra senha ou login mais de três vezes [RN07]
Ator Sistema
Emite [MA 17], mais de três vezes.
Confirma a mensagem Emite [MA21] e retorna ao fluxo principal
A tabela 4 é usada para detalhar o caso de uso UC003 – Manter Cliente.
Tabela 4 – UC002 Manter Cliente
Nome UC003 – Manter Cliente
Objetivo Permite inclusão, alteração, exclusão e consulta de clientes.
Atores Atendente, técnico, Administrador.
Dados Consumidos Código, Nome, CPF, CNPJ, Data de nascimento, rua, Numero, bairro, município, UF,
64
Telefone residencial, Telefone comercial, Telefone Celular, E-mail.
Dados Produzidos Dados cadastrais do novo cliente.
Prioridade Alta
Pré-condições O ator estar logado no sistema.
Pós-condições NA
Fluxo Principal
O UC003, manter cliente, se inicia quando um ator acessa o módulo cliente e efetua a consulta de cliente
através do CPF ou CNPJ.
É apresentada a tela de manutenção de clientes com a listagem e visualização do cliente já cadastrado
com aquele CPF ou CNPJ, com as seguintes opções: Inserir novo cliente[FA01],alterar cliente[FA02],
Consultar cliente [FA03], Excluir cliente[FA04].
Ator Sistema
Acessa a tela de menu cliente Abre uma tela com uma lista com registros dos clientes
Visualiza registros
Clica em um dos Fluxos alternativos descritos Valida a ação e redireciona para tela requisitada.
FA01 - Fluxo Alternativo
O [FA01], ”inserir novo cliente”, se inicia quando é consultado um cliente não cadastrado.
Ator Sistema
Acessa a tela de manutenção de clientes Exibe o formulário com campos específicos de
cadastramento de novos clientes.
Preenche campos obrigatórios
Clica em “Enviar dados” Recebe dados.
Retorna[MA15].
Cadastra o cliente.
FA02 - Fluxo Alternativo
O [FA02], “alterar cliente”, ocorre quando há atualização em algum dado cadastral do cliente.
Ator Sistema
Acessa a tela de manutenção de clientes Exibe tela requisitada
Entra com o dado do cliente no campo de “pesquisa” e clica em alterar.
Busca cliente pelo código inserido pronto para edição
Altera os dados necessários e clica em no botão: “concluir”
Valida a integridade dos dados
Retorna[MA03]
Clica no botão “Voltar” Retorna para fluxo principal.
FA03 - Fluxo Alternativo
O [FA03], ”consultar cliente”, ocorre quando há necessidade de se verificar a existência ou algum respec-
tivo dado de um cliente.
Ator Sistema
Abre a tela de manutenção de clientes Exibe a tela requisitada
Entra com o código do cliente no campo
65
pesquisa
Clica em “consultar” Busca cliente informado no banco de dados
Retorna os dados do cliente
FA04 - Fluxo Alternativo
O [FA04],” Excluir cliente”, se inicia quando há necessidade de exclusão de um registro cliente.
Ator Sistema
Abre a tela de manutenção de clientes Exibe a tela requisitada
Entra com o código do cliente a ser excluído
Clica no botão excluir. Busca cliente informado no bando de dados
Emite [MA24]
Confirma mensagem Exclui cliente.
FE01 - Fluxo Exceção
Dados obrigatórios do cliente não informados
Ator Sistema
Exibe a mensagem [MA19]
Confirma mensagem
Retorna o [FA01].
FE02 - Fluxo Exceção
Não preenche o campo pesquisa com o dado do cliente e clica em alterar
Ator Sistema
Exibe a mensagem [MA20]
Confirma mensagem
Retorna o [FA02].
FE03 - Fluxo Exceção
Cliente não localizado
Ator Sistema
Exibe a mensagem [MA16]
Confirma mensagem
Retorna o [FA03].
FE04 - Fluxo Exceção
Não preenche o campo com o código do cliente a ser excluído e clica em excluir
Ator Sistema
Exibe a mensagem [MA20]
Confirma mensagem
Retorna o [FA04].
66
A tabela 5 é usada para detalhar o caso de uso UC003 – Manter Ordem de serviço.
Tabela 5 – UC003 Manter Ordem de serviço
Nome UC004 – Manter Ordem de serviço
Objetivo Permite gerar, alterar, registrar autorização de execução, cancelar e finalizar
ordem de serviço.
Atores Atendente, técnico, Administrador.
Dados Consumidos Numero OS, Data, Responsável, data e hora de inicio, data e hora término,
dados do equipamento, defeito reclamado, observações e acessórios
Dados Produzidos Nova ordem de serviço
Prioridade Alta
Pré-condições O ator estar logado no sistema.
Pós-condições NA
Fluxo Principal
O UC004,manter ordem de serviço, se inicia quando há necessidade do concerto de um equipamento por
Parte do cliente.
É apresentada a tela de manutenção de OS com listagem e visualização inicial das OSs já cadastradas
que inclui as seguintes opções: Gerar nova ordem de serviço[FA01],Alterar Ordem de serviço [FA02],
Cancelar Ordem de serviço [FA03] e Finalizar Ordem de serviço[FA04].
Ator Sistema
Acessa a tela de menu Ordem de serviço Exibe uma tela com a listagem das OSs.
Visualiza registros
Clica em um dos Fluxos alternativos descritos Valida a ação e redireciona para tela requisitada.
FA01 - Fluxo Alternativo
O [FA01], ”Gerar nova ordem de serviço”, ocorre quando se inicia todo o processo cadastral inicial.
Ator Sistema
Acessa a tela de manutenção de OSs Exibe Listagem das OSs e seus Níveis críticos.
Preenche campos obrigatórios
Clica em “Gerar Ordem de serviço”. Recebe dados.
Retorna[MA25].
Gera Ordem de serviço.
Clica em “imprimir ordem de serviço” Executa a impressão.
FA02 - Fluxo Alternativo
O [FA02], “Alterar Ordem de serviço”, ocorre quando há atualização no status, mantimento de peças,
Tempo, Atividades
Ator Sistema
Acessa a tela de manutenção de clientes Exibe tela requisitada
Entra com o Numero da OS no campo de “pesquisa” e clica em alterar.
Busca a OS no banco de dados com s dados editáveis
Altera os dados necessários e clica em “concluir” Valida a integridade dos dados
67
Retorna[MA03]
Clica no botão “Voltar” Retorna para fluxo principal.
FA03 - Fluxo Alternativo
O [FA03], ”Cancelar Ordem de serviço”, ocorre quando há desistência por parte do cliente em relação a
Manutenção do equipamento.
Ator Sistema
Abre a tela de manutenção de clientes Exibe a tela requisitada
Entra com o Numero da OS no campo pesquisa Busca na tabela OS do banco de dados a ordem de
serviço a ser cancelada
Clica em “Cancelar OS” Busca informada na tabela OS do banco de dados
Emite [MA06]
Confirma mensagem
Cancela OS, se torna inativa.
FA04 - Fluxo Alternativo
O [FA04],” Finaliza OS”, se inicia quando no o processo e finalizado.
Ator Sistema
Abre a tela de manutenção de clientes Exibe a tela requisitada
Entra com o Numero da OS
Clica no botão Clica em “Finalizar”. Busca OS informada no bando de dados
Emite [MA26]
Confirma mensagem Finaliza OS
FE01 - Fluxo Exceção
Dados obrigatórios do cliente não informados e clica em Gerar Ordem de serviço
Ator Sistema
Exibe a mensagem [MA19]
Confirma mensagem
Retorna o [FA01].
FE02 - Fluxo Exceção
Não preenche o campo pesquisa com o Numero OS e clica em “Alterar Ordem de serviço”.
Ator Sistema
Exibe a mensagem [MA20]
Confirma mensagem
Retorna o [FA02].
FE03 - Fluxo Exceção
Não preenche o campo pesquisa com o Numero OS e clica em “Cancelar Ordem de serviço”.
Ator Sistema
Exibe a mensagem [MA20]
Confirma mensagem
Retorna o [FA03].
68
FE04 - Fluxo Exceção
Não preenche o campo pesquisa com o Numero OS e clica em “Finalizar Ordem de serviço”.
Ator Sistema
Exibe a mensagem [MA20]
Confirma mensagem
Retorna o [FA04].
A tabela 6 é usada para detalhar o caso de uso UC004 – Manter Orçamento.
Tabela 6 – UC004 Manter Orçamento
Nome UC005 – Manter Orçamento
Objetivo Permite inclusão, alteração, consulta e exclusão, liberação de orçamento
Atores Técnicos, atendentes, Gerentes.
Dados Consumidos Ordem de serviço, peças necessárias à manutenção, serviço a executar e
valores de serviço.
Dados Produzidos Demonstrativo com o valor dos serviços e peças consumidas no reparo.
Prioridade Alta
Pré-condições O usuário deve está autenticado no sistema
Pós-condições NA
Fluxo Principal
O caso de uso se inicia quando o ator acessa uma ordem se serviço com o status aberta.
É apresentada uma tela com os dados básicos do cliente as características do equipamento, defeito e
observações. [FA01] Seguir Analise, [FA02] Voltar, [FA03] Enviar, [FA04] Limpar, [FA05] Voltar.
Ator Sistema
Acessa ao modulo Ordem de Serviço Apresenta as ordens de serviço com status de aberta
e autorizada[RN01]
Seleciona uma OS Apresenta os dados do cliente, equipamento e defeito
FA01 - Fluxo Alternativo
Seguir Analise
Ator Sistema
Seleciona uma OS conforme o status e suas atribuições
Apresenta os dados do cliente, equipamento e defeito
Clica no botão seguir analise Abre os campos para inserir os dados das peças e
serviços a executar[RN02]
Insere os dados das peças e serviços a executar e clica no botão concluir
Recebe os dados e calcula o valor do
orçamento[RN03,] apresenta o resumo do
orçamento[MA01]
Confirma os dados e clica em Confirmar Apresenta a mensagem[MA02], retorna ao fluxo princi-
pal
69
FA02 - Fluxo Alternativo
Voltar
Ator Sistema
Acessa o botão “Voltar” Retorna a tela de consulta de orçamentos
FA03 - Fluxo Alternativo
Enviar
Ator Sistema
Após preencher peças e serviços a executar
aciona o botão enviar para enviar o orçamento
ao atendimento.
Exibe resumo do orçamento[RN05]
FA04 - Fluxo Alternativo
Limpar
Ator Sistema
Limpa os dados do orçamento para efetuar
correções, antes de enviar
Apaga os dados incluídos no fluxo FA03,
FA05 - Fluxo Alternativo
Voltar
Ator Sistema
Aciona o botão “Voltar” Retorna ao fluxo principal
FE01 - Fluxo Exceção
Alterar
Ator Sistema
O gerente acessa um orçamento específico
através do menu consulta OS, opção alterar
Apresenta a OS solicitada [RN05]
Altera os dados clica em salvar Grava os novos dados na tabela ordem de serviço
[MA03]
A tabela 7 é usada para detalhar o caso de uso UC005 – Faturamento.
Tabela 7 – UC005 Faturamento
Nome UC006 – Faturamento
Objetivo Permite a consulta ao faturamento da loja, por período
Atores Gerente
Dados Consumidos NA
Dados Produzidos Relatório com os orçamentos realizados no período e o valor faturado
Prioridade Média
Pré-condições O usuário deve está autenticado no sistema
Pós-condições NA
Fluxo Principal
70
Este caso de uso inicia quando o ator seleciona a opção Faturamento
Ator Sistema
Clica na opção “Faturamento” no menu principal Exibe a tela de com as opções para consulta:
1 dia, mês, intervalo de datas.
Preenche campos: com o período que quer consultar Recebe os dados inseridos
Clica no botão “Confirmar” Exibe uma tela com os orçamentos concluídos e
Faturados no período.
Clica no botão nova consulta Exibe a tela inicial da consulta
Clica em “Sair” Retorna ao menu principal
FA01 - Fluxo Alternativo
Consultar Orçamento
Ator Sistema
Seleciona um orçamento especifico para visualizar Exibe a tela com os dados completos do
Orçamento selecionado
Clica no botão “Voltar” Retorna para a tela anterior
A tabela 8 é usada para detalhar o caso de uso UC006 – Manter Fornecedor.
Tabela 8 – UC006 Manter Fornecedor
Nome UC003 – Manter Fornecedor
Objetivo Permite a inclusão, alteração, consulta e exclusão de cadastrado de Fornecedores
Atores Gerente
Dados Consumidos Dados referentes aos fornecedores
Dados Produzidos Dados dos fornecedores
Prioridade Alta
Pré-condições NA
Pós-condições NA
Fluxo Principal
Este caso de uso se inicia quando o ator seleciona no menu principal a opção Fornecedor
É apresentada a tela inicial do modulo fornecedor, com as opções com um campo para digitar o nome ou
CNPJ do fornecedor.
Ator Sistema
Insere o nome do fornecedor ou um CNPJ Procura na base de dados um registro com o valor
informado
Retorna o resultado do filtro para geração da grid
Seleciona um fornecedor Apresenta os dados do fornecedor
O ator escolhe uma das opções: incluir[FA01], alterar[FA02], excluir[FA03].
Exibe as opções de incluir[FA01], alterar[FA02], excluir[FA03].
FA01 - Fluxo Alternativo
71
Incluir Fornecedor
Ator Sistema
Clica no botão “Incluir” Abre o formulário para cadastramento de fornecedor
Preenche os campos e clica na opção Recebe os dados
Clica em “Salvar” Armazena os dados na tabela fornecedor[MA09]
Clica no botão “Voltar” Retorna para o fluxo principal
FA02 - Fluxo Alternativo
Alterar Fornecedor
Ator Sistema
Clica no fornecedor a será alterado Seleciona o fornecedor
Clica no botão “Alterar” Exibe os dados do fornecedor
Realiza as alterações desejada Recebe os novos dados
Clica no botão “Salvar” Armazena os dados na tabela fornecedor[MA10]
Confirmar mensagem Retorna para o fluxo principal
FA03 - Fluxo Alternativo
Excluir Fornecedor
Ator Sistema
Clica no fornecedor Seleciona o fornecedor a ser excluído
Clica no botão “Excluir” Exibe mensagem [MA11]
Confirma mensagem Exibe mensagem [MA12]
Confirma mensagem Retorna para o fluxo principal
FE01 - Fluxo Exceção
Campo “Nome do fornecedor ou CNPJ” não preenchido
Ator Sistema
Não preenche campo “Nome do fornecedor ”
Clica em consultar
Exibe mensagem [MA13]
Confirma mensagem Sistema passa ao Fluxo Alternativo [FA01]
Cancela Retorna para o fluxo principal
FE02 - Fluxo Exceção
Campo “Nome do Fornecedor ou CNPJ” preenchido, fornecedor não localizado
Ator Sistema
Informa um fornecedor que não foi ainda
Cadastrado
Exibe mensagem [MA14] [MA13]
Confirma mensagem Sistema passa ao Fluxo Alternativo[FA01]
Cancela Retorna para o fluxo principal
A tabela 9 é usada para detalhar o caso de uso UC007 – Manter Fornecedor.
72
Tabela 9 – UC007 Manter Usuário
Nome UC007 – Manter Usuário
Objetivo Habilitar os funcionários a acessar aos recursos do sistema.
Atores Atendente, Técnico e Administrador
Dados Consumidos ID, Login e senha
Dados Produzidos Acesso ao sistema
Prioridade Alta
Pré-condições Perfil de acesso e autorização previamente concebida.
Pós-condições Haver cadastro no sistema
Fluxo Principal
Este caso de uso se inicia quando o ator administrador acessa ao cadastro de funcionários, para habilitá-lo a acessar ao SATI.
Ator Sistema
Acessa ao menu cadastro e seleciona funciona
rio
Exibe o formulário de cadastramento de fun-
cionário
Preenche todos campos do formulário e aciona
o botão salvar
Armazena os dados na tabela fornecedor[MA10]
Permite acesso ao sistema
A tabela 10 foi usada para listar as regras relacionadas às funcionalidades do sistema
proposto.
Tabela 10 - Regras de Negócio
REGRAS DE NEGOCIO
RN01 Ordens de Serviços Abertas são aquelas que ainda não foram orçadas, autorizadas são
aquelas que já foram autorizadas pelos cliente.
RN02 Apenas os técnicos de manutenção podem Incluir orçamentos
RN03 O orçamento é calculado segundo uma tabela de preço das peças adquiridas nos fornecedores, e os serviços pelo grau de complexidade, hora técnica estabelecida em
tabela.
RN04 Orçamentos ativos são aqueles que foram executados
RN05 Apenas o gerente pode alterar e cancelar orçamentos
RN06 Apenas atendentes podem gerar novas ordens de serviço.
RN07 Cada ator tem direito a três tentativas de inserção de login e senha caso contrario a
a senha é bloqueada, em caso de técnico ou atendente, podem recorrer ao administrador.
para reconstituir a senha, em caso de administrador terá toda uma medida de segurança
para recuperação de senha.
A tabela 11 foi usada para listar as mensagens exibidas pelo sistema ao usuário, sejam
mensagens de erro, informativas e questionamentos.
73
Tabela 11 - Lista de Mensagens
LISTA DE MENSAGENS
MA01 Confirma?
MA02 Orçamento Concluído
MA03 Alteração Concluída
MA04 Confirma o Envio do Orçamento?
MA05 Orçamento enviado
MA06 Confirma Cancelamento?
MA07 Orçamento Cancelado
MA08 Confirma Período?
MA09 Fornecedor Cadastrado
MA10 Confirma Alterações?
MA11 Confirma Exclusão de Fornecedor
MA12 Fornecedor Excluído
MA13 Deseja incluir um fornecedor?
MA14 Fornecedor não Localizado
MA15 Dados incluidos com sucesso
MA 16 Registro nao encontrado
MA17 Senha ou login inválidos
MA18 Alteração realizada com sucesso.
MA19 Preencha os campos obrigatórios
MA20 Insira um registro para consulta.
MA21 Entre em contato com o administrador para requerimento de Login.
MA22 Selecione um registro
MA23 Dados alterados com sucesso
MA24 Confirma exclusão?
MA25 Ordem de serviço gerada com Sucesso.
MA26 Finalizar Ordem de serviço?
6.6 Diagrama de classe
A figura 08 apresenta o diagrama de classe do sistema, são apresentadas
todas as classes do sistema SATI
74
Figura 8 - Diagrama de classes
75
6.7 Escopo do protótipo
Para atender aos requisitos do projeto (CRUD) foi definida a implementação
de apenas cinco casos de uso abaixo, haja vista as restrições de tempo e recursos,
figura 9.
Figura 9 Diagrama de casos de Uso implementado
6.8 Banco de Dados
Será apresentada a descrição e especificação das principais tabelas do
banco de dados proposto para o sistema.
6.8.1 Modelo Entidade Relacionamento
Na figura 10 apresentamos o modelo de entidade relacionamento proposto.
76
Figura 10 Diagrama Entidade Relacionamento
6.8.2 Especificação das tabelas
Abaixo são apresentadas as especificações das tabelas do modelo de
entidade e relacionamento do sistema.
77
A tabela 12 é usada para especificar as características da tabela Pessoa
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os dados das pessoas cadastradas no sistema.
Tabela 12 – Especificação da tabela 01 pessoa
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
CPF_CNPJ_01 varchar(18) primária Registra-se o CPF ou CNPJ da Pessoa
OS_03_NUMOK_03 integer(12) estrangeira Número da ordem de serviço
PF_PJ_02_IDPF_PJ02
integer estrangeira Identifica se pessoa física ou jurídica
UF_12_IDUF_12 integer estrangeira Identificador da Unidade da Federação
SEXO_11_11 integer estrangeira Identificador do sexo da pessoa
PERFIL_10_IDPERFIL_10
Iiteger estrangeira Identifica o perfil da pessoa
RG varchar(10) Número do RG da pessoa
NOME varchar(80) Registro do nome da pessoa sem
abreviaturas
ENDEREÇO varchar(80) Registro do endereço, Rua, quadra,
conjunto, bloco.
NÚMERO varchar(6) Registro do número da porta do
endereço.
BAIRRO varchar(40) Nome do bairro.
TEL_CELULAR varchar(20) Número do telefone celular
TEL_RESIDENCIAL varchar(10) Número do telefone residencial
TEL_COMERCIAL varchar(10) Número do telefone comercial
EMAIL varchar(80) Endereço de e-mail
USER_LOGIN varchar(20) Nome de usuário do funcionário
USER_PASSWORD varchar(30) Senha do funcionário
PRODUTO varchar(30) Nome do produto fornecido, para o cadastro de fornecedores
VENDEDOR varchar(30) Nome do vendedor para o cadastro de fornecedores
DT_NASCI date Data de nascimento da pessoa física
A tabela 13 é usada para classificar o tipo de pessoa se uma pessoa física
ou uma pessoa jurídica.
Tabela 13 – Especificação da tabela 02 Tipo de Pessoa
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDPF_PJ_02 integer primária Identificador do tipo de pessoa
NO_PF_PJ_02 varchar(15) Armazena o identificador Pessoa Física ou pessoa Jurídica
78
A tabela 14 é usada para especificar as características da tabela Ordem de
Serviço, existente no modelo de entidade e relacionamento do sistema, utilizada
para armazenar os dados da ordem de serviço.
Tabela 14 – Especificação da tabela 03 Ordem de Serviço
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
NUMOS_03 integer(12) primária Identificador, registra o número da ordem de serviço, incremento automático sequencial.
EQUIPAMENTO_04_IDEQUIPAMENTO-04
integer estrangeira Identificador do equipamento registrado na OS
DH_ABETURA timestap Registra a data e hora de abertura da
OS
DH_FECHAMENTO timestap Registra a data e hora de fechamento
da OS
DEFEITO varchar(500) Campo texto para registrar o defeito
informado pelo cliente.
OBSERVAÇÕES varchar(500) Campo texto para registrar as
observações se houver
DESCRIÇÃO_SERVIÇO
varchar(500)
Campo texto para o técnico de
manutenção descrever os serviços a
executar
VLIDADE_OS varchar(10) Registra a data de validade da OS
VALOR varchar(50) Registro do valor dos serviços
FUNCIONARIO varchar(15) Registra o código do funcionário que
abriu a OS
GARANTIA_OS bool Identifica se equipamento está coberto
por garantia ou não
A tabela 15 é usada para especificar as características da tabela
Equipamentos, existente no modelo de entidade e relacionamento do sistema,
utilizada para armazenar os dados dos equipamentos entregues para manutenção.
Tabela 15 – Especificação da tabela 04 Equipamento
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDEQUIPAMENTO_04 integer Primária Identificador
TIPO_EQUIPAMENTO_05_IDTIPO_EQUIPAMENTO
varchar(20) estrangeira Identifica o tipo de equipamento
MARCA varchar(30) Registra o nome do fabricante do equipamento
MODELO varchar(30) Registra o modelo do equipamento
79
NUSERIE varchar(20) Registra o número de série
DEFEITO_EQUIPAMENTO
varchar(500)
Campo texto para registrar o defeito informado pelo cliente
GARANTIA_EQUIPAMENTO
bool Identifica se equipamento está coberto por garantia ou não
A tabela 16 é usada para especificar as características da tabela Tipo de
Equipamento, existente no modelo de entidade e relacionamento do sistema,
utilizada para armazenar os tipos de equipamentos cadastrados no sistema.
Tabela 16 – Especificação da tabela 05 Tipo de Equipamento
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDTIPO_EQUIPAMENTO_05
integer Primária Identificador
NO_TIPO_EQUIPAMENTO
varchar(20) Registra os diversos tipos de equipamentos que o estabelecimento atende
A tabela 17 é usada para especificar as características da tabela Orçamento,
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os dados dos orçamentos cadastrados no sistema.
Tabela 17 – Especificação da tabela 06 Orçamento
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDORCAMENTO_06 integer Primária Identificador
OS_03_NUMOS_03 Integer(12) estrangeira Identificador da ordem de serviço
STATUS_09_IDSTATUS integer estrangeira
Identifica o status do orçamento, em
execução, concluído, autorizado,
encerrado, cancelado.
SERVIÇO_IDSERVIÇO integer estrangeira Identifica o tipo de serviço a ser executado.
PEÇAS_07_IDPEÇAS integer estrangeira Identificador das peças a substituir no equipamento.
A tabela 18 é usada para especificar as características da tabela Peças,
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os tipos de peças cadastrados no sistema.
Tabela 18– Especificação da tabela 07 Peças
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDPEÇAS_07 integer Primária Identificador
PEÇAS varchar(80) Descrição das peças
PREÇO_PEÇAS vachar(10) Registro dos preços das peças
80
A tabela 19 é usada para especificar as características da tabela Serviços,
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os dados dos serviços cadastrados no sistema.
Tabela 19 – Especificação da tabela 08 Serviços
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
ID_SERVIÇOS_08 integer Primária Identificador
TIPO_SERVIÇO varchar(60) Registra a descrição do tipo de serviço
PREÇO varchar(10) Registra o preço dos serviços
A tabela 20 é usada para especificar as características da tabela Status,
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os dados de Status dos orçamentos cadastrados no sistema.
Tabela 20– Especificação da tabela 09 Status
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDSTATUS Integer Primaira Identificador
NO_STATUS varchar Identifica os status possíveis para um orçamento: em execução, concluído, autorizado, encerrado, cancelado.
A tabela 21 é usada para especificar as características da tabela Perfil
existente no modelo de entidade e relacionamento do sistema, utilizada para
armazenar os dados dos perfis das pessoas cadastradas no sistema.
Tabela 21 – Especificação da tabela 10 Perfil
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
ID_PERFIL_10 integer Primária Identificador
NO_PERFIL Varchar(20)
Identificador dos perfis das pessoas cadastradas no sistema: Cliente, fornecedor, funcionário-Atendente, funcionário-Técnico, funcionário-Gerente
A tabela 22 é usada para especificar as características da tabela Sexo,
existente no modelo de entidade e relacionamento do sistema, utilizada para
identificar o sexo, quando pessoa física, cadastrada no sistema.
Tabela 22 – Especificação da tabela 11 Sexo
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDSEXO_11 integer Primária Identificador
81
NO_SEXO Varchar(12) Número identificador do sexo da pessoa física: Masculino, Feminino.
A tabela 23 é usada para especificar as características da tabela UF,
existente no modelo de entidade e relacionamento do sistema, utilizada para
identificar a Unidade da Federação, cadastrados no sistema.
Tabela 23 – Especificação da tabela 12 UF
ATRIBUTOS TIPO DO DADO
TIPO DE CHAVE
DESCRIÇÃO
IDUF_12 integer Primária Identificador
NO_UF Varchar(12) Número identificador da Unidade da Federação
6.9 Árvore do Sistema
A figura 11 apresenta árvore de navegação no sistema, menu principal e os
sub-menus, e ilustra o fluxo de navegação no sistema
Figura 11 Fluxo de navegação
82
6.10 Especificações Física
A seguir são apresentados os principais layouts das interfaces do SATI.
6.10.1 Layout das Principais Telas da Aplicação
Na figura 12 apresentamos o layout da interface de login do sistema, através
dessa interface que se autentica e atribui o perfil do usuário previamente cadastrado
no sistema.
Figura 12 – Interface de Login
A figura 13 apresenta o layout principal do sistema, através dessa interface
são mostrados os módulos do sistema.
83
Figura 13 - Layout principal do sistema
A figura 14 apresenta o layout da consulta de cliente, através desta tela é
possível consultar os dados de um cliente por seu CPF/CNPJ.
Figura 14 – Tela de consulta de Cliente
A figura 15 apresenta a tela de cadastro de clientes, ao consultar
um cliente se este não for localizado é a presentada a tela de
84
cadastramento, ou esta opção pode ser solicitada através do menu
cadastro, cliente.
Figura 15 – Tela de Cadastro de Clientes
A figura 16 a tela de cadastramento de ordem de serviço/equipamento, onde
o atendente cadastra os dados de equipamento, defeito identificado pelo cliente e as
observações pertinentes.
Figura 16 - Cadastro de Equipamento
85
A figura 17 apresenta a impressão de uma ordem de serviço impressa.
Figura 17 - Ordem de serviço
A figura 18 apresenta a tela de consulta de ordens de serviços na qual o
técnico estabelece um modo de consulta uma OS específica ou pelo status.
Figura 18 - Consulta de OS
86
A figura 19 apresenta a relação de OS, segundo o critério de consulta
escolhido, que permite a escolha de uma OS aberta para elaborar um orçamento.
Figura 19 - Retorno da consulta
A figura 20 apresenta uma ordem de serviço aberta e pronta para receber os
dados de orçamento.
Figura 20 - Consulta uma OS
87
A figura 21 apresenta a tela de cadastramento de serviços e peças,
conforme o diagnostico do equipamento, ara a formação do orçamento.
Figura 21 - Elaboração de Orçamento
A figura 22 apresenta o resumo de um orçamento.
Figura 22 - Resumo de orçamento
88
6.11 Segurança Física e Lógica
O acesso ao sistema será efetuado através de login e senha, os funcionários
cadastrados terão acesso físico e lógico ao sistema e apenas aos recursos inerentes
a sua função.
6.12 Norma de Segurança Física
Recomenda-se a utilização de um ambiente segregado das demais áreas de
atividade da empresa para abrigar o servidor, ambiente este dotado de controle de
acesso, sistema de prevenção contra incêndios e roubos, o equipamento servidor de
aplicação deverá servir unicamente a este proposito, recomendamos a utilização de
mobiliário como armários e racks metálicos com tranca.
6.13 Normas de Segurança Lógica
Os funcionários serão cadastrados pelo gestor do estabelecimento através de
uma identificação única que também lhe atribuirá o perfil adequado à atividade que
este desempenhará. As funções serão segregadas, ou seja, aquele que estabelece
o contato com o cliente não pode elaborar orçamentos ou efetuar alterações no
mesmo, o sistema também será dotado de arquivos de log de acesso para
possibilitar a auditoria do sistema.
89
7. Plano de Implantação
O plano de implantação tem a finalidade de descrever o conjunto de tarefas
necessárias aos testes e instalação do produto desenvolvido de modo que ele possa
ser efetivamente transferido com sucesso ao cliente, garantindo uma implantação
bem sucedida para o novo sistema com o mínimo de impacto.
É de responsabilidade do cliente garantir que os recursos de hardware e de
software estejam devidamente instalados, implantar o produto nos ambientes de
teste e produção e realizar os testes de homologação do produto, verificando se está
atendendo todos os requisitos funcionais.
7.1 Hardware
Por tratar-se de um sistema direcionado a micro e pequenas empresas o
mesmo equipamento em residir o servidor de aplicação, também poderá ser
instalado o banco de dados, devido a baixa complexidade do sistema, este não
necessita de uma capacidade de processamento muito grande, assim sendo um
computador dotado de 4GB de memória, processador Intel I3, ou equivalente AMD
atenderá plenamente aos requisitos de hardware para o servidor.
7.2 Software
Para executar o sistema SATI, no servidor de aplicação faz-se necessária a
instalação do servidor web Apache, que é capaz de suportar aplicações PHP e
banco de dados MySQL, disponível em versões para Linux e Windows e tem
distribuição gratuita.
90
8. CONCLUSÃO
Esse trabalho apresentou o desenvolvimento de um sistema observando as
necessidades de uma loja específica a Shift Computadores, no entanto o sistema
desenvolvido pode ser adaptado às necessidades de outras oficinas similares.
Nossas pesquisas na Empresa Shift Computadores foram realizadas para
identificar os principais fatores de risco que uma empresa desse tipo poderia
enfrentar para implantação de um sistema que realmente atendesse suas
necessidades. Nas reuniões com a equipe da Shift também foram esmiuçados todos
os requisitos que o sistema teria que abranger para atender seu escopo. O segundo
passo realizado foi a definição das tarefas de cada um dos integrantes da equipe de
desenvolvimento, suas metas e quais objetivos a serem atingidos em cada etapa.
Dessa forma acreditamos que atingimos o resultado esperado entregando à
empresa um sistema eficaz, fácil de manipular e que atende a todas as
necessidades atuais dos usuários e permita sua evolução com o crescimento da
empresa, aliado a isso o SATI agrega a empresa uma ferramenta de gestão de alta
qualidade visto que possibilita aos gestores obter uma fotografia do desempenho da
sua equipe de colaboradores, identificar as atividades que demandam maior
utilização de seus recursos, e desta forma gerir seu capital e empregar tais recursos
de forma mais eficaz e econômica para a otimização dos serviços prestados aos
seus clientes.
91
9. REFERENCIAS BIBLIOGRÁFICAS
ABBEY,Michael, Oracle 8: Um guia para iniciantes e COREY,Michael J. BALMMER, Steve. Mercado Brasileiro é Promissor. G1, São Paulo, 30 abr. 2010. Disponível em: <http://g1.globo.com/tecnologia/noticia/2010/04/brasil-sera-o-3-maior-mercado-de-pcs-no-mundo-diz-presidente-da-microsoft.html>. Acessado em: 21 mar. 2011. ANSI/IEEE STD 100_1984. Atividades Heurísticas. Disponível em: http://www.arlima.com.br/2010/07/07/heuristicas-algoritmos-sdcas-pdcas-inovacao-e-metas/. Acessado em 20 mar. 2011. CARDOSO, Caique. UML na Pratica: do Problema ao Sistema. Rio de Janeiro:Editora Ciencia Moderna Ltda, 2003. COSTA, Rogerio Luis de C.. SQL guia prático. 2ª.ed. Rio de Janeiro: Brasport, 2006. DATE, C.J.. Introdução A Sistemas de Banco de Dados. 8ª.ed. São Paulo: Campus, 2004. DALL'OGLIO, Pablo. PHP Programando com Orientação a Objetos. 2ª ed. São Paulo: Novatec, 2009. DEBONI, José Eduardo Zindel. Modelagem Orientada a Objetos com a UML. São Paulo: Futura, 2003. DEITEL, H. M. Java, como programar/ H.M e P.J Deitel; trad. Carlos Arthur Lang Lisbôa - 4.ed - Porto Alegre : Bookman, 2003. DEITEL, H. M. JAVA – Como programar. 6ª.ed. São Paulo Editora Pearson Prentice Hall, 2005. ELMASRI, Ramez. Sistemas de banco de dados. Ramez Elmasri e Shamkant B. Navathe; revisor técnico Luis Ricardo de Figueiredo. São Paulo: Addison Wesley, 2005. GUEDES, Gilleanes T. A. UML Uma Abordagem Prtática. São Paulo: Novatec , 2004. GALANTE, C. A., Banco de Dados Orientado a Objeto: Uma Realidade. Disponível em: http://www.fsma.edu.br/si/edicao3/banco_de_dados_orientado_a_objetos.pdf. Acessado em: 27/05/2011 as 00h32. GUIMARÃES, C. C. Fundamentos de Banco de Dados: Modelagem, projeto e linguagem SQL. São Paulo: Unicamp, 2003.
92
KAPLAN, Robert S. A Estratégia em Ação - Balanced Scorecard/Roberts S Kaplan, David P.Norton: tradução Luiz Euclydes Trindade Frazão Filho. Rio de Janeiro: Campus, (1997). KENDALL, S. O Processo Unificado Explicado. Porto Alegre: Bookman, 2003. KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistema de Banco de Dados. 2ª.ed. rev. São Paulo: Makron Books, 1995. KRUCHTEN, Philippe. Introdução ao RUP - Rational Unified Process. Rio de Janeiro: Editora Ciencia Moderna Ltda, (2003). MELO, Ana Cristina. Desenvolvendo Aplicações Com UML 2.0 - Do conceitual à Implementação. 2º. ed. Rio de Janeiro:Brasport, 2004. MORIMOTO, Carlos E. Hardware II, - o Guia Definitivo. São Paulo: GDH Press e Sul Editores, 2010. MORAZ, Eduardo. Treinamento em PHP 5.0. São Paulo: Digerati Boosk , 2005. OLIVEIRA, Celso H. Poderoso de, Guia de consulta rápida Oracle 10G PL/SQL, São Paulo: Editora Novatec Editora Ltda. (2005).
PINHEIRO,Wellington, Java 7: Modificações na Linguagem, em Detalhes e Exemplos, Disponível em: http://www.infoq.com/br/articles/java7coin, Acessado em: 28/05/2011 as 23h45. PRESSMAN, Roger S. Engenharia de Software. 3ª.ed.São Paulo: Makron Books, 1995 RAMALHO, José Antonio Alves. SQL: A Linguagem dos Bancos de Dados. São paulo: Berkeley Brasil, 1999. SOUKUP, Ron. Desenvolvendo o Microsoft SQL Server 6.5. Rio de Janeiro: Campos, 1998. VASCONCELOS, Laercio. Consertando Micros. 2º.ed. Rio de Janeiro: Laercio Vasconcelos Computação Ltda, 2010 WELLING, Luke; THOMSON, Laura. PHP e MySQL Desenvolvimento Web. 3ª.ed. Rio de Janeiro: Elsevier, 2005.