SATI - Sistema de Atendimento Técnico de Informática

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


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.

SATI - Sistema de Atendimento Técnico de Informática

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SATI - Sistema de Atendimento Técnico de Informática

Similar a SATI - Sistema de Atendimento Técnico de Informática (20)

Más de UNIEURO

Más de UNIEURO (11)

SATI - Sistema de Atendimento Técnico de Informática