Este documento apresenta um resumo do projeto de desenvolvimento de um sistema chamado SIQA - Sistema Indicador de Qualidade de Atividade. O sistema terá como objetivo gerar gráficos que indiquem a adesão dos funcionários de uma empresa aos seus programas de qualidade de vida e assistência social. O sistema será desenvolvido utilizando técnicas de engenharia de software e banco de dados relacional para armazenar as informações sobre departamentos, funcionários e eventos da empresa.

1. FACULDADE ALVORADA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Cristiana Carolina Andrade Mendes Souza
SIQA - Sistema Indicador de Qualidade de Atividade
Brasília-DF
2010

2. v
Cristiana Carolina Andrade Mendes Souza
SIQA - Sistema Indicador de Qualidade de Atividade
Monografia apresentada a Faculdade Alvorada
para a obtenção do título de Bacharel em
Sistemas de Informação.
Orientadora: Profa. Mestra Elizabeth d‟Arrochella Teixeira
Brasília-DF
2010

3. v
À minha amada filha Tácila Taiana que dá
razão ao meu ato de respirar.

4. vi
AGRADECIMENTOS
Agradeço à minha mãe Gina, cujo exemplo de vida e perseverança faz
com que todos os meus esforços sejam apenas reflexos de seus atos. E, em
memória ao meu amado pai Brasilton, pela certeza que por amor tudo vale à pena.
À minha professora Elizabeth d‟Arrochella Teixeira por fazer entender,
através de uma única frase a importância do seguir a diante, mais uma vez obrigada.

5. vii
“Jamais desistir é a fórmula dos teimosos
para alcançar o sucesso”.
Cristiana Mendes

6. 8
RESUMO
O monitoramento das atividades desenvolvidas pela empresa em busca da
qualidade de vida dos seus funcionários é uma preocupação para os líderes das
organizações. Utilizando a tecnologia para tratar os dados coletados, das atividades
e programas sociais, são gerados indicadores de adesão, cujos índices são de
sumária importância para tomada de decisão. Estudos empíricos indicam as
organizações que possuem um bom índice de monitoramento de suas atividades,
com o uso de sistemas de informação, apresentam maiores sucesso na manutenção
e introdução de novas formas de qualidade de vida. A proposta apresentada nesse
trabalho é a criação de um sistema capaz de gerar gráficos que indiquem a adesão
dos funcionários aos programas de qualidade de vida e assistência social da
empresa.
Palavras-chave: Sistema de Informação. Monitoramento de Atividade e Indicadores.

7. 9
ABSTRACT
The monitoring activities undertaken by the company in pursuit of quality of life and
welfare of its employees is a concern to its leaders. Using technology to process the
data collected from activities and social programs are generated compliance
indicators, whose indices are of importance for summary decision. Empirical studies
indicate that organizations are a good indicator for monitoring their activities with the
use of information systems, have greater success in maintaining and introducing new
forms of quality of life. The proposal presented in this paper is to create a system
able to generate graphs showing the membership of officials to the quality programs
of life and welfare of the company.
Keywords: Information System. Monitoring and Activity Indicators.

8. 10
LISTA DE FIGURAS
Figura 1 - Organograma da Empresa ........................................................................ 20
Figura 3 – Arquitetura de Processo RUP .................................................................. 27
Figura 4 – Estrutura Estática RUP ............................................................................ 28
Figura 5: Padrão Template Method em um framework ............................................. 32
Figura 6 - Padrão Facade ......................................................................................... 33
Figura 7 – Classes do Subsistema Compilador......................................................... 34
Figura 8 – Representação da Arquitetura MVC......................................................... 37
Figura 9 - Tipos de Diagramas UML ......................................................................... 42
Figura 10 – Diagrama de Caso de Uso ..................................................................... 62
Figura 11 – Diagrama de Classes ............................................................................. 68
Figura 12 – Modelo de Entidade de Relacionamento................................................ 68
Figura 13 – Árvore do Sistema .................................................................................. 70
Figura 14 – Tela de login ........................................................................................... 70
Figura 15 – Tela Principal.......................................................................................... 71
Figura 16 – Cadastro Departamento ......................................................................... 71
Figura 17 – Cadastro Funcionário ............................................................................. 72
Figura 18 – Cadastro Evento..................................................................................... 72
Figura 19 – Alterar Departamento ............................................................................. 73
Figura 20 – Alterar Funcionário ................................................................................. 73
Figura 21 – Alterar Evento ........................................................................................ 74
Figura 22 – Excluir Departamento ............................................................................. 74
Figura 23 – Excluir Funcionário ................................................................................. 75
Figura 24 – Lista de Departamento ........................................................................... 75
Figura 25 – Lista de Funcionário Cadastrados .......................................................... 76
Figura 26 – Lista de Evento....................................................................................... 76
Figura 27 – Relatório em Gráfico .............................................................................. 77
Figura 28 – Menu de Navegação dos Sistema.......................................................... 77

9. 11
LISTA DE TABELAS
Tabela 1 - Planejamento do Projeto de Desenvolvimento ......................................... 23
Tabela 2 – Casos de Uso .......................................................................................... 61
Tabela 3 – Caso de Uso UC01 – Login ..................................................................... 63
Tabela 4 – Caso de Uso UC02 – Manter Usuário ..................................................... 64
Tabela 5 – Caso de Uso UC03 – Manter Departamento ........................................... 65
Tabela 6 – Caso de Uso UC04 – Manter Evento ...................................................... 66
Tabela 7 – Caso de Uso UC05 – Manter Relatório ................................................... 67
Tabela 8 – tab_departamento ................................................................................... 69
Tabela 9 – tab_funcionario ........................................................................................ 69
Tabela 10 – tab_departamento ................................................................................. 69
Tabela 11 – tab_relatorio .......................................................................................... 69

10. 12
LISTA DE ABREVIATURAS E SIGLAS
ADO ActiveX Data Objects
ANSI American National Standards Institute
ASP Active Server Pages
BPMN Business Process Modeling Notation
DBA Administrador de Banco de Dados
DCL Linguagem de Controle de Dados
DDL Data Deinition Lnguage
DDL Linguagem de Definição de Dados
DML Linguagem de Manipulação de Dados
HTML Hiper Text Markup Language
IPL InterBase Public License
JSP Java Server Pages
MVC Model View Controller
OO Orientação a Objetos
POO Programação Orientada a Objetos
RUP Rational Unified Process
SGBD Sistema Gerenciador de Banco de Dados
SIAQ Sistema Indicador de Qualidade de Atividade
SO Open Source
SQL Structured Query Language
UML Unified Modeling Language
WWW Word Wide Web
XP Extreme Programming

11. 13
SUMÁRIO
1.Introdução .............................................................................................................. 16
1.1. Tema ........................................................................................................... 17
1.2. Justificativa ................................................................................................. 17
1.3. Formulação do Problema ............................................................................ 17
1.4. Objetivos ..................................................................................................... 18
1.4.1. Objetivo Geral ...................................................................................... 18
1.4.2. Objetivo Específico .............................................................................. 18
1.5. Organização do Trabalho ........................................................................ 19
2. Análise Institucional ........................................................................................... 20
2.1. A Empresa e seu Negócio .......................................................................... 20
2.1.1. Organograma da Empresa .................................................................. 20
2.2. Descrição das Necessidades ...................................................................... 21
3. Cronograma ....................................................................................................... 23
4. Referencial Teórico ............................................................................................ 24
4.1. Engenharia de Software .............................................................................. 24
4.1.1. Cleanroom ........................................................................................... 24
4.1.2. Métodos Ágeis ..................................................................................... 25
4.1.2.1. Extreme Programming .......................................................................... 25
4.1.2.2. Scrum .................................................................................................... 26
4.1.3. Rational Unified Process – RUP .......................................................... 27
4.1.4. Padrões de Projeto .............................................................................. 29
4.1.4.1. Padrão Singleton ................................................................................. 30
4.1.4.2. Padrão Template Method .................................................................... 31
4.1.4.3. Padrão Facade .................................................................................... 32
4.1.5. Arquitetura de Software ....................................................................... 34
4.1.5.1. Modelo Microkernel.............................................................................. 35
4.1.5.2. Modelo Broker...................................................................................... 36
4.1.6. Modelagem de Processos ................................................................... 38
4.1.6.1. aSideML ............................................................................................... 38
4.1.6.2. Business Process Modeling Notation – BPMN .................................... 39
4.1.6.3. Unified Modeling Language – UML ...................................................... 39
(Linguagem de Modelagem Unificada) .............................................................. 39
4.1.7. A Orientação a Objetos ........................................................................ 42
4.1.7.1. Objetos ................................................................................................ 42
4.1.7.2. Classes ................................................................................................ 42
4.1.7.3. Encapsulamento .................................................................................. 43
4.1.7.4. Herança ............................................................................................... 43
4.1.7.5. Polimorfismo ........................................................................................ 43
4.1.8. Linguagem de Programação ................................................................ 44
4.1.8.1. Active Server Pages – ASP ................................................................. 44
4.1.8.2. Java Server Pages – JSP .................................................................... 45
4.1.8.3. HyperText Markup Language – HTML ................................................. 46

12. 14
4.1.8.4. Linguagem PHP ................................................................................... 47
4.1.9. Banco de Dados .................................................................................. 47
4.1.10. Sistema Gerenciador de Banco de Dados ........................................... 50
4.1.10.1. Firebird ................................................................................................ 52
4.1.10.2. Microsoft SQL Server .......................................................................... 53
4.1.10.3. PostgreSQL ......................................................................................... 53
4.1.10.4. Oracle.................................................................................................. 54
4.1.10.5. MySQL ................................................................................................ 54
4.1.10.6. Linguagem SQL.......................................................................................... 55
4.2. Escolhas para o Desenvolvimento do Projeto ................................................ 56
5. Proposta do Novo Sistema................................................................................. 58
5.1. Descrição do Sistema Proposto .................................................................. 58
5.2. Resultados Esperados ................................................................................ 58
5.3. Restrições do sistema proposto .................................................................. 59
5.4. Relação Custo Versos Benefícios: Análise de Viabilidade Econômica do
Novo Sistema ........................................................................................................ 59
5.5. Áreas Afetadas Pelo Novo Sistema ............................................................ 59
5.6. Banco de Dados.......................................................................................... 59
6. Documentação de Análise ................................................................................. 60
6.1. Visão Macro dos Atores .............................................................................. 60
6.2. Identificação dos Atores .............................................................................. 60
6.3. Listas de Casos de Uso .............................................................................. 61
6.4. Diagrama de Caso de Uso .......................................................................... 61
6.5. Descrição detalhada dos Casos de Uso ..................................................... 63
6.6. Diagramas de Classes ................................................................................ 68
6.7. Modelo de Entidade-Relacionamento ......................................................... 68
6.8. Especificação das Tabelas ......................................................................... 69
6.9. Árvore do Sistema....................................................................................... 70
6.10. Especificação Técnica ................................................................................ 70
6.10.1. Layout das Principais Telas da Aplicação ............................................... 70
6.10.2. Layout dos Principais Relatórios ................ Erro! Indicador não definido.
6.11. Navegação .................................................................................................. 77
6.12. Segurança Física e Lógica .......................................................................... 77
6.12.1 Norma de Segurança Física .................................................................... 78
6.12.2 Norma da Segurança Lógica ................................................................... 78
7. Plano de Implantação......................................................................................... 79

13. 15
8. Conclusão .......................................................................................................... 80
9. Referências Bibliográficas .................................................................................. 81

14. 16
1. Introdução
Uma informação estratégica, no cenário atual das empresas, pode gerar
várias oportunidades a uma organização e para atingir seus objetivos as empresas
promovem a integração e automação de seus processos.
Promover o monitoramento de seus processos é essencial para que as
empresas possam verificar as execuções e eficácia dos mesmos.
A informação é a principal mola propulsora existente que inclina as
organizações à busca constante de seu gerenciamento e dos comportamentos a ela
relacionados, contribuindo para uma aprendizagem organizacional firme, para obter
maior eficiência e desempenho dos seus processos.
Mensurar dados e, transformá-los em linhas e grades inteligíveis aos olhos
dos líderes de organizações é a proposta de grande parte dos sistemas
desenvolvidos tendo como foco a geração de indicadores. "... De forma a obter um
maior entendimento do relacionamento entre atividades da qualidade e o
desempenho dos negócios, pesquisadores precisam desenvolver um método mais
sofisticado de medição dos efeitos das atividades de qualidade" (MANN e KEHOE,
1994).
"... As mudanças na tecnologia, competição, ambientes (interno e externo)
estão demandando que nós mudemos o que medimos, como medimos e
como usamos a medição. Estas mudanças estão forçando-nos a
reexaminarmos paradigmas relativos à medição." (SINK, 1991).
Segundo DAVENPORT (1994), as informações entram e saem das
organizações sem que se tenha plena consciência de seu impacto, valor e custo.
Portanto, é necessário que as informações relevantes sejam identificadas,
selecionadas e disseminadas para a adaptação no meio em que elas se encontram.
O monitoramento do ambiente externo traz um aprendizado gerencial sobre a
informação contida nos eventos e tendências do ambiente externo de uma
organização, e a utilização de um sistema de informação avançado potencializa todo

15. 17
o processo de monitoramento desse ambiente externo.
O principal objetivo da gestão da informação é tornar estratégica a informação
recebida e estimulá-la a se transforma em conhecimento (CHOO, 2002).
Utilizando softwares livres, será desenvolvido um programa capaz de exibir os
indicadores de adesão de atividades do programa de qualidade de vida e serviço
social da empresa.
1.1. Tema
O Sistema Indicador de Qualidade de Atividade (SIQA) será um sistema
capaz de mensurar a adesão dos funcionários às atividades propostas pela
empresa, observando os de maior relevância para a corporação.
1.2. Justificativa
Tendo por principio o tratamento das informações de participação dos
funcionários nas atividades de assistência social e programas de qualidade de vida,
procurando dessa forma, organizar os dados obtidos após a realização dos eventos
para que esses possam ser apresentados de forma a que sejam utilizados para
estudos das atividades hoje desenvolvidas.
A metodologia hoje utilizada pela empresa para a realização dessa atividade
de tratamento dos dados é comum (planilha eletrônica e papel impresso).
1.3. Formulação do Problema
CHOO (2002), relata que a informática há muitos anos é usada para ajudar na
aquisição de dados internos, e que existem ganhos dramáticos em eficiência
processual nas aplicações utilizadas.

16. 18
Muitas ainda são as dificuldades encontradas para realizar o procedimento
operacional de monitoramento de atividades de assistência social e qualidade de
vida oferecida pela empresa. Grande número das atividades é realizado
simultaneamente das dependências dos departamentos fisicamente distantes.
Dessa forma, existe uma força tarefa para conhecer a satisfação de todos os
funcionários, acreditando-se que a participação dos colaboradores em seus
programas indica um bom desempenho do evento.
Dessa forma os esforços hoje estão em identificar quais eventos e programas
mais satisfazem os funcionários.
1.4. Objetivos
Um objetivo pode ser definido como um propósito ou alvo que se pretende
atingir. Tudo aquilo que se deseja alcançar através de uma ação clara e explicita,
pode ser chamado de objetivos (MARINHO, 2007).
1.4.1. Objetivo Geral
Desenvolver um sistema utilizando o ambiente Web, com uma interface
prática para que o usuário tenha facilidade de incluir, modificar e extrair as
informações das atividades do programa de qualidade de vida e assistência social
da empresa.
1.4.2. Objetivo Específico
Obter dados, transforma-los em informação e gerá-los em forma de
gráfico para a realização de estudo sobre os eventos sociais e atividades de
qualidade de vida que mais satisfazem os funcionários, para tomada de decisão, nos
departamentos e suas respectivas divisões.

17. 19
1.5. Organização do Trabalho
O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivos
da monografia em apresentação.
O segundo capítulo realiza a apresentação da empresa Cristini S.A. e seu
ramo de negócio.
O terceiro capítulo, apresenta o cronograma das atividades de
desenvolvimento dessa monografia, sinalizando os prazos para a finalização do
trabalho.
O quarto capítulo descreve o referencial teórico, todas as fontes de pesquisa
de ferramentas que serão utilizadas para o desenvolvimento do sistema e escrita da
monografia.
No quinto capítulo, é apresentada a proposta, a descrição, os resultados, as
restrições e as áreas afetadas pelo sistema que será desenvolvido.
No sexto capítulo é apresentada a descrição e identificação dos atores e
casos de uso do sistema. Como também, a apresentação das principais telas do
sistema e suas funcionabilidades.
O sétimo capítulo descreve as atividades desempenhadas para a implantação
sistema na empresa.
Para o oitavo capítulo esta registrada a conclusão do trabalho.
No nono e último capitulo está descrito todas as referências bibliografias que
dão sustentação e base ao desenvolvimento deste trabalho.

18. 20
2. Análise Institucional
Como tudo que é instituído, instituinte ou em vias de institucionalização, a
análise institucional é um produto social-histórico. Trata-se da concepção de história
da empresa (GOMES, 2006).
2.1. A Empresa e seu Negócio
A Cristini S.A. é uma empresa (fictícia) nacional do setor elétrico brasileiro,
tendo como área de atuação parte do território nacional e atividades em países
como Angola e Haiti, tendo como atividade principal, a geração e transmissão de
energia elétrica.
A Cristini S.A. está sempre preocupada com a qualidade de vida de seus
funcionários e colaboradores, por isso, ela possui diversos profissionais que tem em
suas atividades primárias a busca pela satisfação e bem estar de todos que torna
possível o Programa de Qualidade de Vida.
2.1.1. Organograma da Empresa
A presidência, as diretorias e os departamentos da empresa Cristini S.A.,
estão dispostos da seguinte forma:
Presidente
Diretoria Diretoria Diretoria
Financeira de Operação de Construção
DA.F DL.F DT.F DE.O DI.O DT.O D1.O D2.O DA.C DL.C DT.C
Figura 1 - Organograma da Empresa

19. 21
2.2. Descrição das Necessidades
Segundo BEZERRA (2002), a atividade de levantamento de requisitos
corresponde à etapa de compreensão do problema, aplicada ao desenvolvimento de
software. O principal objetivo do levantamento de requisitos é que usuários e
desenvolvedores tenham a mesma visão do problema a ser desenvolvido. Nessa
etapa, os desenvolvedores, juntamente com os clientes, definem as necessidades
dos futuros usuários do sistema a ser desenvolvido. Essas necessidades são
geralmente denominadas requisitos.
A empresa, hoje, precisa de um controle da aceitação e participação dos
funcionários e colaboradores em suas atividades, por isso existe a necessidade de
identificar quais atividades são carentes de mais atenção ou até mesmo a exclusão
de programas que hoje fazem parte do calendário da empresa.
Dessa forma o SIQA, deverá conter duas fases. Uma para o gerente do
departamento para acompanhamento das informações e outra interfase para que o
usuário realize a alimentação com os dados. Todos os acessos deverão ser
identificados através de usuário e senha evitando assim a publicação dos dados
para pessoas não autorizadas.
2.3. Sistema de Informação Existente na Empresa
Todo o procedimento de controle dos eventos realizados hoje pela empresa é
inserido em uma planilha do aplicativo Microsoft Excel e enviado às pessoas que
analisarão estes dados através de e-mail.
2.4. Normas de Funcionamento
Após análise, observa-se que para o pleno funcionamento do sistema, é
necessário: o usuário ter acesso à intranet da empresa; utilizar usuário e senha para
acessar o sistema; quando o acesso for gerencial, este poderá administrar os
usuários e os departamentos a que estes pertencem; quando o acesso for de

20. 22
usuário, este poderá indicar qual atividade irá alimentar os bancos dados e permitir a
consulta dos mesmos através de números, percentuais e gráficos;
2.5. Ambiente Tecnológico Existente
O ambiente tecnológico é composto por: 10 computadores AMD Sempron,
1GB, HD 160GB, Gravador de DVD - Space BR, monitor LCD 15.6", sistema
operacional Windows XP, todo o pacote Microsoft Office 2003; 5 impressoras
Lexmark T632 e, 5 scaner HP 5590.

21. 23
3. Cronograma
Desenvolver o cronograma significa determinar as datas de início e fim para
as atividades do projeto. Se as datas de início e fim não forem realísticas, é
improvável que o projeto termine como planejado.
ETAPAS MAR ABR MAI JUN JUL AGO SET OUT NOV DEZ
Definição do
Problema
Delimitação do
Tema
Pesquisa
Bibliográfica
Levantamento
Teórico
Definição da
metodologia
Planejamento
de Ações
Levantamento
de Requisitos
Análise (def.
casos de uso)
Escrever a
Monografia
Apresentação
Ref. Teórico
Acertos após
Apresentação
Entrega Final -
I Semestre
Projeto
Implementação
Implantação
Apresentação
da monografia
Acertos após
apresentação
Entrega final
Tabela 1 - Planejamento do Projeto de Desenvolvimento

22. 24
4. Referencial Teórico
O objetivo deste capítulo é apresentar todas as tecnologias, processos e
conceitos estudados, que podem ser utilizados e os que foram escolhidos para o
desenvolvimento do sistema.
4.1. Engenharia de Software
“Um processo de software é um conjunto de atividades e resultados
associados que geram um produto de software” (SOMMERVILLE, 2003). O processo
é o fundamento da engenharia de software, é o que possibilita o desenvolvimento
racional do software através da efetiva utilização da tecnologia de engenharia
(PRESSMAN, 2004).
4.1.1. Cleanroom
O método cleanroom tem demonstrado que pode melhorar tanto a
produtividade de desenvolvedores, que o utilizam, quanto à qualidade do software
que estes produzem. A engenharia de software cleanroom é um processo orientado
à equipe, que torna o desenvolvimento gerenciável e preditível, porque é feito sob o
controle estatístico da qualidade (LINGER, 1994).
O processo cleanroom é baseado no desenvolvimento e na certificação de
um fluxo incremental de informações de software, elaborado por pequenas equipes
independentes. Nesse processo, a correção é obtida pela equipe de
desenvolvimento (geralmente próxima de zero defeito), através de especificação,
projeto e verificação formais. A equipe de verificação da correção substitui o teste de
unidade e a conseqüente depuração, passando o software diretamente para a fase
de testes do sistema, sem que seja executado previamente pela equipe de
desenvolvimento (LINGER, 1994).

23. 25
4.1.2. Métodos Ágeis
Para LARMAN (2005), o método de desenvolvimento ágil aplica
desenvolvimento iterativo e evolutivo de tempo limitado, emprega planejamento,
promove entrega incremental e inclui outros valores e práticas que encorajam
agilidade - resposta rápida e flexível à modificação.
Segundo LARMAN (2005), não é possível definir exatamente métodos
ágeis, pois as práticas específicas variam muito. No entanto, iterações curtas de
tempo limitado com refinamento evolutivo de planos, requisitos e projeto é uma
prática básica que os métodos compartilham. Além disso, eles promovem práticas e
princípios que refletem uma sensibilidade ágil de simplicidade, leveza, comunicação,
equipes auto-organizadas, entre outras.
4.1.2.1. Extreme Programming
A Extreme Programming (Programação Extrema) é uma metodologia ágil para
equipes pequenas e médias que desenvolvem software baseado em requisitos
vagos e que se modificam rapidamente (BECK, 1999). Dentre as principais
diferenças da Extreme Programming (XP) em relação às outras metodologias estão:
feedback constante; abordagem incremental e a comunicação entre as pessoas é
encorajada. A Figura 2 mostra algumas das características da Extreme Programming
(XP):
Figura 2 – Características da XP

24. 26
A maioria das regras da XP causa polêmica à primeira vista e muitas não
fazem sentido se aplicadas isoladamente. É a sinergia de seu conjunto que sustenta
o sucesso de XP, encabeçando uma verdadeira revolução no desenvolvimento de
software. A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a
satisfação do cliente, além de favorecer o cumprimento das estimativas. As regras,
práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento
de software para os seus seguidores, que são conduzidos por quatro valores:
comunicação, simplicidade, feedback e coragem (BECK , 1999).
4.1.2.2. Scrum
Outra metodologia que apresenta uma comunidade grande de usuários é a
Scrum, também chamada de metodologia Ágil (SCHWABER e BEEDLE, 2002). Seu
objetivo é fornecer um processo conveniente para projeto e desenvolvimento
orientado a objeto. A Scrum apresenta uma abordagem empírica que aplica algumas
idéias da teoria de controle de processos industriais para o desenvolvimento de
softwares, reintroduzindo as idéias de flexibilidade, adaptabilidade e produtividade.
O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe
para produzir o software de forma flexível e em um ambiente em constante
mudança.
Conforme SIQUEIRA (2007), processos empíricos aceitam as falhas como
conseqüência natural da produção e tentam torná-las visíveis e passíveis de
correção, o mais cedo possível, para que a abordagem empírica se torne ideal para
o ambiente de desenvolvimento de software. Nesses ambientes, as funcionalidades
consideradas “terminadas” muitas vezes não estão suficientemente testadas e
aceitas pelo cliente, fazendo-se necessárias atividades de inspeção e de adaptação.
A idéia principal da metodologia Scrum é que o desenvolvimento de softwares
envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e
tecnologia, que podem mudar durante o processo. Isto torna o processo de
desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar
as mudanças. O resultado do processo deve ser um software que é realmente útil
para o cliente. (SCHWABER e BEEDLE, 2002).

25. 27
4.1.3. Rational Unified Process – RUP
Rational Unified Process (Processo Unificado da Rational), é um processo
proprietário de desenvolvimento de software criado pela IBM Rational Software
Corporation. O Processo Unificado da Rational (RUP) é um processo bem
estruturado para desenvolver software com alta qualidade de modo repetível e
previsível (KRUCHTEN, 2003).
Logo abaixo é representada a arquitetura global do RUP, que é
organizada em duas dimensões. O eixo horizontal evidencia o aspecto dinâmico do
processo, descrevendo como ocorre o desenvolvimento ao longo do tempo em
termos de fases, iterações e marcos. Também mostra como a ênfase varia ao longo
do tempo. Por exemplo, nas iterações iniciais, é utilizado mais tempo com
modelagem de negócio, requisitos, análise e projeto; enquanto nas iterações finais o
tempo é mais utilizado com implementação, teste e distribuição. Embora os nomes
dos fluxos de engenharia possam evocar as fases seqüenciais do modelo em
cascata, estes fluxos são revisitados ao longo do ciclo de vida, variando de
intensidade a cada iteração.
Na figura 3, o eixo vertical representa o aspecto estático do processo,
organizado em termos de disciplinas. No RUP, processo é definido como sendo uma
descrição de quem está fazendo o quê, como e quando – estes quatro elementos
estruturais, correspondem a Papel (quem), Atividade (como), Artefato (o quê) e
Fluxo (quando).
Figura 3 – Arquitetura de Processo RUP

26. 28
Na Figura 4 são apresentados todos os conceitos-chave, os elementos
estruturais estáticos, definidos no RUP.
Figura 4 – Estrutura Estática RUP
Fluxo: é a seqüência de atividades que produz um resultado de valor
observável. No RUP, o fluxo é expresso como um diagrama de atividade da UML.
Há muitas maneiras de se organizar o conjunto de atividades em fluxos num
processo de engenharia de software. No RUP, os fluxos são organizados em dois
níveis: Fluxo Central (Disciplina) e Detalhes de Fluxo (KRUCHTEN, 2003).
Atividade: é o trabalho executado para produzir um resultado significativo no
contexto do projeto; consiste, geralmente, na criação ou atualização de artefatos.
Toda atividade é atribuída a um papel específico. Mentor de Ferramenta fornece
diretrizes de como usar uma ferramenta de software específica na execução da
atividade (KRUCHTEN, 2003).
Papel: define o comportamento e as responsabilidades de um indivíduo ou
grupo de indivíduos trabalhando em equipe. O comportamento é expresso em

27. 29
termos de atividades a serem executadas. Responsabilidades são expressas em
termos de artefatos que o papel cria, modifica ou controla (KRUCHTEN, 2003).
Artefato: é um produto do projeto; pode ser um documento, um modelo, um
código-fonte, um programa-executável etc. Um artefato é de responsabilidade de um
único papel, embora possa ser usado por vários papéis. Artefatos são usados,
produzidos ou modificados em atividades. Gabarito (Template) é um „modelo‟ do
artefato a ser usado em sua criação. Os gabaritos são ligados à ferramenta que será
usada. Por exemplo, um template do Microsoft Word pode ser usado como gabarito
de um artefato que seja um documento ou relatório. Um Relatório consiste em
informações que são extraídas de um ou vários artefatos. Diretrizes são informações
sobre como desenvolver, avaliar e usar os artefatos. Uma atividade representa o
trabalho a ser feito enquanto as diretrizes expressam como fazer o trabalho. São
regras, recomendações ou métodos para auxiliar a realização de atividades.
Descrevem técnicas específicas para criar certos artefatos, transformar um artefato
em outro, ou avaliar a qualidade de um artefato (KRUCHTEN, 2003).
O RUP também pode ser utilizado no desenvolvimento e manutenção de
projetos de pequeno ou de médio porte. Para que isso seja possível, algumas
etapas ou passos podem ser eliminados a depender das características do projeto
para simplificar ou diminuir as necessidades de documentação, minimizando a
formalização (KOHRELL e WONCH ,2005). As diferentes configurações do RUP
possibilitam o suporte de equipes grandes e pequenas, além de técnicas de
desenvolvimento disciplinadas ou menos formais (KRUCHTEN, 2000).
4.1.4. Padrões de Projeto
“...cada padrão descreve um problema no nosso ambiente e o núcleo de
sua solução, de tal forma que você possa usar esta solução mais de um
milhão de vezes, sem nunca fazê-lo da mesmo maneira...” ALEXANDER
(1977)
Muito embora ALEXANDER (1997), estivesse falando acerca de padrões, em
construção e cidades, o que ele diz é verdadeiro em relação aos padrões de projeto
orientados a objeto. Nossas soluções são expressas em termos de objetos e
interfaces em vez de paredes e portas, mas no cerne de ambos os tipos de padrões

28. 30
estão às soluções para um problema num contexto (GAMMA et al, 2000).
GAMMA et al (2000), explicam que em geral, um padrão tem quatro
elementos essenciais: o nome do projeto é uma referência que podemos usar para
descrever um problema de projeto, suas soluções e conseqüências em uma ou duas
palavras. Dar nome a um padrão aumenta imediatamente o nosso vocabulário. Isso
nos permite projetar em um nível mais alto de abstração; o problema descreve
quando aplicar o padrão. Ele explica o problema e seu contexto. Pode descrever
problemas de projeto específicos, tais como representar algoritmos como objetos; e
descrever os elementos que compõem o projeto, seus relacionamentos, suas
responsabilidades e colaborações. A solução não descreve um projeto concreto ou
uma implantação em particular porque um padrão é como um gabarito que pode ser
aplicado em muitas situações diferentes. Em vez disso, o padrão fornece uma
descrição abstrata de um problema de projeto e de como um arranjo geral de
elementos (classes e objetos, no nosso caso) resolve o mesmo; as conseqüências
são os resultados e análises das vantagens e desvantagens da aplicação do padrão.
Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de
uma estrutura de projeto comum para torná-la útil para a criação de um projeto
orientado a objeto reutilizável. O padrão de projeto identifica as classes e instâncias
participantes, seus papéis, colaborações e a distribuição de responsabilidades. Cada
padrão de projeto focaliza um problema ou tópico particular de projeto orientado a
objetos. Ele descreve quando pode ser aplicado, se ele pode ser aplicado em função
de outras restrições de projeto e as conseqüências, custos e benefícios de sua
utilização (GAMMA et al, 2000).
4.1.4.1. Padrão Singleton
Garantir que uma classe tenha somente uma instância e fornece um ponto
global de acesso para a mesma. É importante para algumas classes ter uma, e
apenas uma, estância. Por exemplo, embora possam existir muitas impressoras em
um sistema, deveria haver somente um spooler de impressoras. Da mesma forma
deveria haver somente um sistema de arquivos e um gerenciador de janelas. Um

29. 31
filtro digital terá somente um conversor A/D. Um sistema de contabilidade será
dedicado a servir somente a uma companhia (GAMMA et al, 2000).
Como garantimos que uma classe tenha somente uma instância e que essa
instância seja facilmente acessível. Uma variável global torna o objeto acessível,
mas não impede você de instanciar múltiplos objetos (GAMMA et al, 2000).
Para GAMMA et al (2000), uma solução melhor seria tornar a própria classe
responsável por manter o controle de sua única instância. A classe pode garantir
que nenhuma outra instância seja criada (pela interceptação das solicitações para
criação de novos objetos), bem como pode fornecer um meio para acessar sua
única instância.
4.1.4.2. Padrão Template Method
Definir o esqueleto de um algoritmo em uma operação, postergando
(deferring) alguns passos para subclasses. Templat e Method (Modelo de Método)
permitem que subclasses redefinam certos passos de um algoritmo sem mudar a
estrutura do mesmo (GAMMA et al, 2000).
O padrão Template Method pode ser utilizado para a construção de
frameworks. Ele também poderia ser considerado um padrão estrutural porque
define uma estrutura inicial (“esqueleto”) para um determinado algoritmo ou tarefa
(GAMMA et al, 2000).
Por exemplo, um jogo de computador é uma aplicação que, basicamente,
implementa um laço de execução do tipo: 1) recupera dados de entrada do usuário
(input); 2) atualiza o estado da aplicação, baseado nos dados de entrada; 3)
desenha os resultados na tela (render) e; 4. voltar para 1 (GAMMA et al, 2000).
É possível definir um framework inicial para jogos como é mostrada na
figura 05.

30. 32
Figura 5: Padrão Template Method em um framework
A classe base Game implementa o laço de execução (a operação run) de
maneira fixa, enquanto as classes derivadas implementam as funcionalidades
específicas (getInput, update e render) (GAMMA et al, 2000).
Esse padrão está relacionado com outros padrões como o State, que
define classes para representar estados de uma aplicação. Nesse caso, cada classe
representaria uma “fase de jogo” (ou seja, cada fase seria um estado diferente),
sendo que todas elas utilizariam o Template Method para definir a funcionalidade (ou
sejam, todas elas utilizariam o framework) (GAMMA et al, 2000).
4.1.4.3. Padrão Facade
Fornece uma interface unificada para um conjunto de interfaces em um
subsistema. Facade (Fachada) define uma interface de nível mais alto que torna o
subsistema mais fácil de ser usado. Estruturar um sistema em subsistemas ajuda a
reduzir a complexidade. Um objetivo comum de todos os projetos é minimizar a
comunicação e as dependências entre subsistemas. Uma maneira de atingir este
objetivo é introduzir o objeto facade, o qual fornece uma interface única e
simplificada para os recursos e facilidades mais gerais de um sistema, conforme
exibido na figura 6 (GAMMA et al, 2000).

31. 33
Figura 6 - Padrão Facade
Considere, por exemplo, um ambiente de programação que fornece
acesso às aplicações para o seu subsistema compilador. Este subsistema contém
classes, tais como Scanner, Parser, ProgramNode, BytecodeStram e
ProgramaNodeBuilder, que implementam o compilador. Algumas aplicações
especializadas podem necessitar acessar essas classes diretamente. Mas a maioria
dos clientes de um compilador geralmente não se preocupa com detalhes tais como
análise (parsing) e geração de código; eles apenas querem compilar seu código.
Para eles, as interfaces poderosas, porém de baixo nível, do subsistema compilador
somente complicam sua tarefa (GAMMA et al, 2000).
Para fornecer uma interface de nível mais alto que pode isolar os clientes
destas classes, o subsistema compilador também inclui uma classe compiler (ver
figura 7). A classe compiler funciona como uma facade (fachada): ela fornece aos
clientes uma interface única e simples para o subsistema compilador. Ela junta as
classes que implementam a funcionalidade de um compilador, sem ocultá-las
completamente. O compilador facade torna a vida mais fácil para a maioria dos
programadores, sem, entretanto, ocultar a funcionalidade de nível mais baixo dos
poucos que a necessitam (GAMMA et al, 2000).

32. 34
Figura 7 – Classes do Subsistema Compilador
O padrão facade isola os clientes dos componentes do subsistema, desta
forma reduzindo o numero de objetos com que os clientes têm que lidar e tornando o
subsistema mais fácil de usar. Ele não impede as aplicações de utilizarem as
classes do subsistema caso necessitem fazê-lo. Assim, você pode escolher entre a
facilidade de uso e a generalidade. (GAMMA et al, 2000).
4.1.5. Arquitetura de Software
À medida que o tamanho e a complexidade dos sistemas de software
aumentam, o projeto e a especificação da estrutura global do sistema se tornam
questões mais importantes do que a escolha de algoritmos e estruturas de dados de
computação (SHAW e GARLAN, 1996).
A especificação de uma arquitetura adequada é essencial para o sucesso
de um projeto de software. Ela representa a base da solução computacional para o
problema descrito pelos requisitos do software, sendo o artefato que vai guiar as

33. 35
etapas subseqüentes do desenvolvimento, como o projeto detalhado e a
implementação. É por isso que a maior parte do tempo de um arquiteto é dedicada
ao particionamento adequado do sistema em um conjunto de componentes, módulos
ou objetos interrelacionados (GORTON, 2006).
Para MEHDI et al (2000), a arquitetura de software é colocada como uma
ferramenta para lidar com a complexidade do software e enfatizam que arquitetura
deve satisfazer os requisitos funcionais e não funcionais do sistema, incrementando
a definição de que arquitetura de software é o conjunto de componentes e seus
relacionamentos. Portanto, é possível notar que a arquitetura de software é mais do
que a descrição dos componentes que a compõem e do relacionamento entre eles.
A arquitetura é a interface entre duas partes distintas: o problema de negócio e a
solução técnica (ASTUDILLO e STUART 1998).
Para BASS et al (1998) arquitetura de software são as estruturas que
incluem componentes, suas propriedades externas e os relacionamentos entre eles,
constituindo uma abstração do sistema.
4.1.5.1. Modelo Microkernel
O padrão arquitetural Microkernel é formado pelos componentes
microkernel, internal server, external server, adpter e client. Este padrão se adequa
bem às características de um framework de aplicações. O componente microkernel
representa os frozen spots do framework, o internal server representa subsistemas
independentes, mas presentes no núcleo do framework, os external servers
representam os hot spots, os clients são os aplicativos desenvolvidos e o adapter
constitui uma interface entre clientes e seus servidores externos (BUSCHMANN et
al, 1996).
Propõe a separação de um conjunto de funcionalidades mínimas das
funcionalidades estendidas e partes específicas de clientes. O encapsulamento dos
serviços fundamentais da aplicação é realizado no componente microkernel. As

34. 36
funcionalidades estendidas e específicas devem ser distribuídas entre os
componentes restantes da arquitetura (BUSCHMANN et al, 1996).
4.1.5.2. Modelo Broker
Para aplicações distribuídas, onde uma aplicação pode acessar serviços
de outras aplicações simplesmente pelo envio de mensagens a objetos mediadores,
sem se preocupar com questões específicas relacionadas à comunicação entre
processos, como a sua localização (BUSCHMANN et al, 1996).
O uso de um broker de integração pode trazer vários benefícios: quando
um fornecedor de serviços muda o formato da mensagem que usa, um broker pode
transformar versões obsoletas e incompatíveis de mensagens para adaptar ao novo
formato de mensagens. Também fornecem uma infra-estrutura fiável de mensagens
(EMILOV, 2001)
Existem três responsabilidades envolvidas na comunicação, baseada num
mediador: encaminhamento de mensagens, que permite o controle do fluxo,
identificando a mensagem vinda de uma aplicação e com base no tipo e no
conteúdo, redirecioná-la para a aplicação alvo; transformação de mensagens, que
permite a tradução adequada da mensagem para a aplicação receptora. Os
elementos da mensagem recebida são convertidos para o formato conhecido pela
aplicação destino. É necessário um dicionário que permita ao broker identificar qual
o formato compreendido pelas aplicações envolventes e validação de mensagens,
que permite a identificação do conteúdo das mensagens, tornando possível a sua
transformação e distribuição para o recipiente adequado no formato correto.
Orquestração de processos, que permite a integração e coordenação dos processos
de negócio das aplicações envolvidas (EMILOV, 2001)
4.1.5.3. Modelo Model View Controller – MVC
(Modelo Visão Controle)
O Modelo Model View Controller (Modelo, Visão e Controle) é descrito
como um padrão arquitetural aplicável a software interativos e que organiza a

35. 37
aplicação em três tipos de componentes: os módulos model, view e controller.
(BUSCHMANN et al, 1996).
Na figura 8 é possível ver a ilustração de como a arquitetura é dividida em
três tipos de componentes, que possuem responsabilidades bem definidas, a saber:
modelo, visão e controlador. O modelo encapsula os dados e a funcionalidade do
negócio, sendo independente de representações de saída e tratamento das
interações dos usuários com a aplicação; a visão mostra as informações para os
usuários, sendo responsável pelos formatos de saída específicos e obtendo seus
dados a partir do modelo; e o controlador trata os eventos de entrada dos usuários
disparados nas interfaces, que são traduzidos para requisições de serviços ao
modelo ou à visão (BUSCHMANN et al, 1996).
Figura 8 – Representação da Arquitetura MVC
A adoção da arquitetura Model View Controller (MVC) torna a aplicação
escapável e de fácil manutenção, além de propiciar o desenvolvimento em paralelo
para cada camada, pois todas são independentes (MACORATTI, 2010).
Na arquitetura MVC o modelo representa os dados da aplicação e as
regras do negócio que governam o acesso e a modificação dos dados. O modelo
mantém o estado persistente do negócio e fornece ao controlador a capacidade de
acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo
(MACORATTI, 2010).

36. 38
4.1.6. Modelagem de Processos
Segundo RUMBAUGH (1994), um modelo é uma abstração de alguma
coisa, cujo propósito é permitir que se conheça essa coisa antes de construí-la.
Como um modelo emite os detalhes não-essenciais, sua manipulação é mais fácil do
que a da entidade original.
4.1.6.1. aSideML
A linguagem aSideML oferece semântica, notação e regras que permitem
que o projetista construa modelos cujo foco sejam os principais conceitos,
mecanismos e propriedades de sistemas orientados a aspectos, nos quais os
aspectos e crosscutting sejam explicitamente tratados como cidadãos de primeira
classe. Esses modelos ajudam a lidar com a complexidade de sistemas orientados a
aspectos, ao fornecer visões essenciais da estrutura e do comportamento que
enfatizam o papel dos elementos crosscutting e seus relacionamentos com outros
elementos. Esses modelos também servem como planos preliminares (blueprints)
que devem ser desenvolvidos na direção dos modelos de implementação de
ferramentas e linguagens de programação orientadas a aspectos (CHAVEZ, 2004)
Em aSideML, a modelagem estrutural oferece a visão estática de um
sistema na presença dos aspectos. Os principais constituintes dos modelos
estruturais são as classes, aspectos e seus relacionamentos. A visão estática
descreve as características transversais de aspectos como elementos de
modelagem discretos, organizados em interfaces transversais. O comportamento
dinâmico dessas características e descrito por modelos comportamentais (CHAVEZ,
2004)
Em CHAVEZ (2004) é apresentada aSideML, como uma linguagem de
modelagem construída para especificar e comunicar projetos orientados a aspectos.

37. 39
4.1.6.2. Business Process Modeling Notation – BPMN
A Business Process Modeling Notation (Notação de Modelo de Processo
de Negócio) está se consolidando como o mais importante padrão de notação
gráfica aberta para desenhar e modelar processos de negócios. Com ela é possível
modelar os processos de negócio capturando e documentando modelos atuais (AS-
IS) em diagramas de fácil entendimento, projetar e descrever modelos ideais (TO-
BE), estender detalhes técnicos, monitorar e mensurar o negócio com indicadores
de desempenho baseados nas atividades dos fluxos de processos automatizados. O
objetivo do desenho é ser de entendimento rápido por todos os usuários de negócio,
para que permita aos analistas criarem seus primeiros esboços dos processos e os
arquitetos de tecnologia da informação e desenvolvedores adaptem os processos a
serem gerenciados e monitorados. (BITENCOURT, 2010)
A Business Process Modeling Notation (BPMN) suporta orquestração de
serviços e a execução de tarefas humanas do workflow, ao permitir coreografia de
múltiplos processos de negócio. Além disso, possui o mapeamento para gerar as
linguagens XML para execução de processos em Business Process Modeling
Language (BPML) e Business Process Execution Language (BPEL) diminuindo
distâncias entre o desenho do processo e a sua automação (BITENCOURT, 2010).
4.1.6.3. Unified Modeling Language – UML
(Linguagem de Modelagem Unificada)
A Unified Modeling Language (Linguagem de Modelagem Unificada) é
uma linguagem padrão para especificar, visualizar, documentar e construir artefatos
de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de
desenvolvimento e através de diferentes tecnologias de implementação (FURLAN,
1998).
A Linguagem de Modelagem Unificada (UML) é uma linguagem visual
para modelar sistemas orientados a objetos. Isso quer dizer que a UML é uma
linguagem constituída de elementos gráficos (visuais) utilizados na modelagem que
permitem representar conceitos do paradigma da orientação a objetos. Através dos

38. 40
elementos gráficos definidos nesta linguagem pode-se construir diagramas que
representam diversas perspectivas do sistema (BEZERRA, 2002).
Uma empresa de software bem-sucedida é aquela que fornece software
de qualidade e capaz de atender às necessidades dos respectivos usuários. Uma
empresa que consiga desenvolver esse software de maneira previsível e em
determinado período, com utilização eficiente e eficaz de recursos, será uma
empresa com um negócio viável (BOOCH et al, 2006).
A modelagem é uma parte central de todas as atividades que levam à
implantação de um bom software, Construímos modelos para comunicar a estrutura
e o comportamento desejados do sistema. Construímos modelos para visualizar e
controlar a arquitetura do sistema. Construímos modelos para compreender melhor
o sistema que estamos elaborando, muitas vezes expondo oportunidades de
simplificação e reaproveitamento. Construímos modelos para gerenciar riscos
(BOOCH et al, 2006).
Segundo BOOCH et al (2006), a UML é uma linguagem destinada a:
visualizar; especificar; construir e documentar.
O vocabulário da UML abrange três tipos de blocos de construção, itens
são as abstrações identificadas como cidadãos de primeira classe em um modelo;
os relacionamentos reúnem esses itens; os diagramas agrupam coleções
interessantes de itens (BOOCH et al, 2006).
BOOCH et al (2006), nos explicam que existem quatro tipos de itens na
UML: estruturais são os substantivos utilizados em modelos da UML. São partes
mais estáticas do modelo, representando elementos conceituais ou físicos.
Coletivamente, os itens estruturais são chamados de classificadores;
comportamentais são as partes dinâmicas dos modelos de UML. São os verbos de
um modelo, representando comportamentos no tempo e no espaço. Ao todo,
existem dois tipos principais de itens comportamentais: interação e máquina de
estado; agrupamentos são as partes organizacionais dos modelos de UML. São os
blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo

39. 41
principal de itens de agrupamento, chamado pacotes e, anotacionais são as partes
explicativas dos modelos de UML. São comentários, incluídos para descrever,
esclarecer e fazer alguma observação sobre qualquer elemento do modelo.
Na literatura de BOOCH et al (2006), está registrado que existem quatro
tipos de relacionamento na UML: primeiro, uma dependência é um relacionamento
semântico entre dois itens, nos quais a alteração de um (o item de independente)
pode afetar a semântica de outro (o item de dependente); segundo, uma associação
é um relacionamento estrutural entre classes que descreve um conjunto de ligações,
em que as ligações são conexões entre objetos que são as instâncias das classes;
terceiro, uma generalização é um relacionamento de especialização/generalização,
no qual os objetos dos elementos especializados (os filhos) são substituíveis por
objetos do elemento generalizado (os pais) e quarto, uma realização é um
relacionamento semântico entre classificadores, em que um classificador especifica
um contrato que outro classificador garante executar.
Diagrama na UML é uma representação gráfica de um conjunto de
elementos, geralmente representados como gráficos de vértices (itens) e arcos
(relacionamentos). São desenhados para permitir a visualização de um sistema sob
diferentes perspectivas; nesse sentido, um diagrama constitui uma projeção de um
determinado sistema. Em todos os sistemas, com exceção dos mais triviais, um
diagrama representa uma visão parcial dos elementos que compõem o sistema. O
mesmo elemento pode aparecer em todos os diagramas, em apenas alguns (o caso
mais comum) ou em nenhum (um caso raro). Na teoria, um diagrama pode conter
qualquer combinação de itens e de relacionamentos. Na prática, porém, aparecerá
um pequeno número de combinações comuns, que são consistentes com as cinco
visões mais úteis na arquitetura de um sistema completo de software. Por isso, a
UML inclui 13 desses diagramas (BOOCH et al, 2006).
A UML possui treze tipos de diagramas, divididos em duas categorias:
diagramas estruturais ou estáticos e dinâmicos.

40. 42
Figura 9 - Tipos de Diagramas UML
4.1.7. A Orientação a Objetos
O termo Orientação a Objetos (OO) sugere uma associação entre
(abstrações de) coisas do mundo real e trechos de programas de computador ou
objetos (YOURDON, 1999). Na Programação Orientada a Objetos (POO), dados e
procedimentos passam a fazer parte de um elemento básico, o objeto. A POO
introduz uma abordagem na qual o desenvolvedor visualiza seu programa em
execução como uma coleção de objetos cooperantes que se comunicam por meio
de troca de mensagens (VINCENZI, 2004).
4.1.7.1. Objetos
É uma instância de uma classe criada em tempo de execução. Cada
objeto tem uma cópia dos dados definidos na classe e encapsula estado e
comportamento. Os objetos interagem entre si e são ativados por meio de troca de
mensagens. (VINCENZI, 2004).
4.1.7.2. Classes
É uma descrição de um grupo de objetos com propriedades (atributos),
comportamentos (operações), relacionamentos com outros objetos e semânticas

41. 43
comuns. Assim, uma classe é um gabarito para criar objetos, onde cada objeto é
uma cópia de alguma classe. (TERRY, 2001).
4.1.7.3. Encapsulamento
É uma técnica empregada para garantir a ocultação de informações na
qual a interface e a implementação de uma classe são separadas sintaticamente.
Somente os métodos pertencentes ao objeto podem ter acesso aos dados
encapsulados. O encapsulamento estimula a modularidade do programa e restringe
possíveis interdependências com outras classes, exceto por meio de sua interface.
(VINCENZI, 2004).
4.1.7.4. Herança
É o mecanismo de reutilização de atributos e operações, definidos em
classes gerais, por classes mais específicas, podendo ser usada para expressar
tanto generalização como associação. (FURLAN, 1998).
4.1.7.5. Polimorfismo
Qualidade ou estado de um objeto ser capaz de assumir diferentes
formas. Possibilita que ao enviar uma mesma mensagem para um conjunto de
objetos, cada objeto responda de maneira diferente em função da mensagem
recebida (VINCENZI, 2004).
Embora este conceito exista há décadas, as técnicas de orientação a
objeto permitem reutilizar mais do que simplesmente o código, podendo fazer uso de
requisitos, análise, projeto, planejamento de testes, interfaces de usuários e
arquiteturas. Assim, praticamente todos os componentes do ciclo de vida da
engenharia de software podem ser encapsulados como objetos reusáveis.
(YOURDON, 1999).

42. 44
Alguns benefícios da orientação a objetos apresentados por OLIVEIRO
(2000) são: reaproveitamento: as classes são projetadas de forma que possam ser
reutilizadas em vários sistemas; estabilidade: classes projetadas para reutilização
tornam-se estáveis, pois são testadas e aperfeiçoadas para várias situações;
projetistas pensam no comportamento dos objetos e não nos detalhes de baixo-
nível: o encapsulamento oculta os detalhes e faz com que as classes se tornem
caixas-pretas, onde somente se precisa compreender seu comportamento e como
se comunicar com elas; desenvolvimento Acelerado: os aplicativos são criados com
componentes pré-existentes que se adaptam a um projeto em particular e bibliotecas
de classes corporativas: as empresas podem desenvolver bibliotecas de classes
próprias, que refletem os padrões internos da organização e as necessidades de
suas aplicações. Estes benefícios proporcionaram o início da reutilização de
soluções no desenvolvimento de software.
4.1.8. Linguagem de Programação
Podemos imaginar o computador como uma super calculadora, capaz de
fazer cálculos muito mais rápido que nós, mas para isso devemos dizer para o
computador o que deve ser calculado e como deve ser calculado. A função das
linguagens de programação é exatamente essa, ou seja, servir de um meio de
comunicação entre computadores e humanos (ANDRADE, 2007).
4.1.8.1. Active Server Pages – ASP
O Active Server Pages (Páginas de Servidor Ativa) são páginas web
dinâmicas que interagem com a linguagem Hyper Text Markup Language (HTML) e
surgiu juntamente com o lançamento do IIS (Internet Information Server 3.0). O IIS é
o servidor web mais recomendado pela Microsoft para desenvolvimento de sites
dinâmicos com Active Server Pages (ASP). A tecnologia ASP disponibiliza um
conjunto de componentes para o desenvolvimento de páginas web que possuem
conteúdo dinâmico, interativo e de alta performance. Isto quer dizer que uma parte
da página é escrita em HTML, ou seja, estática e a outra parte é dinâmica que
significa que pode ser escrita em uma linguagem de script onde os mesmos são

43. 45
inseridos nas páginas HTML e processados pelo servidor web antes de serem
enviadas ao navegador do usuário. Assim, muitas funcionalidades e lógicas de uma
página ASP é controlada através de comandos de script. Teoricamente, o ASP pode
ser trabalhado em qualquer linguagem de criação de scripts, do VBSCRIPT ao
PHYTON. O Visual Basic Script Language é uma das muitas possibilidades de
linguagem de script que executam em um servidor e, para o IIS, ela é a linguagem
padrão (WEISSINGER, 2000).
O ASP é uma tecnologia largamente empregada na Internet, isso se deve
ao fato da sua capacidade de interagir com banco de dados através do ActiveX Data
Objects (ADO). O ADO é uma coleção de objetos utilizados para recuperação,
alteração, inclusão e exclusão de registros em bancos de dados ODBC e OLE DB,
inserido nas páginas e é executado no Servidor Web, retornando assim as
informações contidas no banco de dados em formato HTML (WEISSINGER, 2000).
4.1.8.2. Java Server Pages – JSP
O (Páginas de Servidor Java) foi desenvolvido pela Sun Microsystems e
consiste em uma tecnologia baseada em Java que simplifica o processo de
desenvolvimento de aplicações para a web. A tecnologia JSP interage fortemente
com Java, HTML, banco de dados e Hypertext Transfer Protocol (HTTP) (FIELDS,
2000).
O Java Server Pages (JSP) pode ser visto como um tipo de linguagem de
criação de scripts no servidor. O seu código de programação é tipicamente Java,
onde ainda aceita um conjunto de tags personalizadas que interagem com objetos
Java no servidor, sem a necessidade de que o código java apareça na página, com
isto permite uma separação da camada de apresentação e da lógica de negócio do
site. Sendo uma tecnologia baseada em java, ela se aproveita de todas as
vantagens que a linguagem java fornece em relação a desenvolvimento e
acionamento (FIELDS, 2000).

44. 46
4.1.8.3. HyperText Markup Language – HTML
O HyperText Markup Language (Linguagem de Marcação Hiper Texto) é
uma linguagem simples composta de marcações de formatação e diagramação de
hipertexto/hipermídia (informações em texto, imagens, sons e ações ligadas umas
às outras de uma forma complexa e não seqüencial através de chaves
relacionadas). (CASTRO, 2005).
A linguagem do HyperText Markup Language (HTML) é a linguagem da
Word Wide Web (WWW), justamente por essa capacidade de formatação e
diagramação de hipertexto/hipermídia. Atualmente existem muitas outras linguagens
utilizadas concorrentemente com a HTML (Java, ActiveX, etc...) mas a base da
WWW ainda é, de longe, o HTML, que é interpretada por todos os navegadores
(browers) disponíveis (Netscape, Internet Explorer, Mosaic, etc...).(CASTRO, 2005).
Para CASTRO (2005), HTML ou linguagem de marcação é uma linguagem
universal e se destina à elaboração de páginas de hiper-texto, como o próprio nome
indica. Ela é uma linguagem simples composta de marcações de formatação e
diagramação de hipertexto/hipermídia (informações em texto, imagens, sons e ações
ligadas umas às outras de uma forma complexa e não seqüencial através de chaves
relacionadas). Conceitua-se hiper-texto por certos itens de um documento que
contém uma ligação à outra zona do mesmo documento ou, como é mais vulgar, a
outros documentos.
A principal aplicação do HTML é a criação de páginas na web que não se
trata de uma linguagem de programação. Antes uma espécie de linguagem de
formatação, o HTML é um ficheiro de texto que é formatado através de uma série de
comandos, os tags (CASTRO, 2005).
Embora existam várias dezenas desses tags, apenas uma pequena parte
deles é utilizada normalmente e ainda existem algumas regras básicas que são
necessárias para compreender antes de se começar com a criação de páginas
(CASTRO, 2005).

45. 47
4.1.8.4. Linguagem PHP
A tecnologia PHP surgiu em 1994 como um projeto pessoal de Rasmus
Lerdorf com o intuito de controlar 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 inerente 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. Além das mudanças referentes à sintaxe e aos
novos recursos de programação, o PHP trouxe também um otimizador chamado
Zend, que permite a execução mais 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 (BRAVALHERI, 2008).
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 para o cliente (BRAVALHERI, 2008).
Uma das 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 (BRAVALHERI, 2008).
4.1.9. Banco de Dados
Banco de Dados é um sistema de armazenamento de Dados baseado em
computador, cujo objetivo é registrar e manter informações consideradas
significativas à Organização. O trabalho do Administrador de Banco de Dados (DBA)

46. 48
contribui para a operação efetiva de todos os Sistemas que rodam utilizando-se de
Banco de Dados (LIMA, 2001).
4.1.9.1. Modelo de Banco de Dados Hierárquicos
GALANTE (2007) nos explica que o banco de dados hierárquico foi o primeiro
modelo a ser conhecido como modelo de dados. Sua estrutura é do tipo árvore e
sua formação se dá através de registros e links, onde cada registro é uma coleção
de dados e o link é uma associação entre dois registros. Os registros que precedem
outros são chamados de registro pai os demais são chamados de registros filhos.
Cada registro tem suas ligações, o registro pai pode ter vários filhos (1:N), o registro
filho só pode ter um pai. Caso um determinado registro filho tenha a necessidade de
ter dois pais é necessário replicar o registro filho. A replicação possui duas grandes
desvantagens: pode causar inconsistência de dados quando houver atualização, e o
desperdício de espaço é inevitável. Para acessar registros em um modelo
hierárquico deve-se obedecer aos padrões desse modelo. A navegação deve
começar no topo da árvore e da esquerda para direita. Esse modelo foi muito
importante no sistema de banco de dados IMS (Information Management System – é
o sistema de banco de dados mais antigo) da IBM. É importante ressaltar que esse
modelo era superior a outros modelos da época o que o tornou bem utilizado.
Apesar desse, ser o melhor da época ele tem algumas desvantagens como:
complexidade dos diagramas de estrutura de árvores, limitações das ligações entre
registros - ex.: um filho só pode ter um pai, a navegação é feita através de ponteiros,
complexidade na hora das consultas, ausência de facilidades de consultas
declarativas, só trabalha com dados primitivos.
4.1.9.2. Modelo de Banco de Dados em Rede
O modelo em rede surgiu para suprir algumas deficiências do modelo
hierárquico. O conceito de hierarquia foi abolido nesse novo modelo, o que permitiu
que um registro estivesse envolvido em várias associações, ou seja, esse modelo
aceitar relacionamentos (N:M), um filho pode ter mais de um pai, ele só trabalha com
dados primitivos. Uma outra característica que difere esse modelo do hierárquico é
que ele utiliza grafos ao invés de árvores. A Data Base Task Group da CODASYL
estabeleceu uma norma para esse modelo, uma linguagem própria para definição e

47. 49
manipulação de dados. As ferramentas geradoras de relatório da CODASYL
padronizaram dois aspectos importantes dos sistemas gerenciadores de dados:
concorrência e segurança. Com isso, o mecanismo de segurança já permitiu que
uma determinada área de banco de dados fosse bloqueada para evitar acessos
simultâneos, quando necessário. No modelo em rede qualquer nó pode ser
acessado sem precisar passar pelo nó raiz. O sistema mais conhecido dessa
implementação é o IDMS da Computer Associates. O diagrama para essa estrutura
é formado por registros e links (GALANTE, 2007).
4.1.9.3. Modelo de Banco de Dados Relacional
Segundo GALANTE (2007) o modelo relacional surgiu com o propósito de
aumentar a independência dos dados nos sistemas gerenciadores de banco de
dados; disponibilizar um conjunto de funções apoiadas em álgebra relacional para
armazenar e recuperar dados; permitir processamento ad hoc. A representação do
banco de dados desse modelo é feito através de coleções de tabelas. Então quando
parte para essa visão, é possível ter tabelas de valores, onde cada tabela tem um
nome, e dentro de cada tabela temos as tuplas que são as linhas da tabela, e em
cada tabela temos um domínio que é valor atômico, ou seja, são valores indivisíveis
no que diz respeito ao modelo relacional. Cada domínio possui um formato de
dados. O modelo relacional também tem algumas restrições: restrições inerentes ao
modelo de dados (em uma relação não pode ter tuplas repetidas), restrições
baseadas em esquema – são especificações em DDL (data definition language), que
são restrições de domínio, de chave, restrições em null, restrições de integridade de
entidade e restrições de integridade referencial, e restrições baseadas em aplicação.
4.1.9.4. Modelo de Banco de Dados Relacional Orientado a
Objeto
O modelo relacional orientado a objeto é a junção do modelo relacional
com o modelo OO. Segue o padrão SQL 1999 e estendem a SQL para incorporar o
suporte para o modelo de dados relacional-objeto, gerencia transações,
processamento e otimização de consultas. Como por exemplo, ele passou a ter
construtores de tipos para especificar objetos complexos, passou a ter tuplas e

48. 50
array. Os construtores set, list, bag ainda não foram adicionados ao modelo. Nesse
Modelo passou a ter identidade de objeto (reference type), encapsulamento de
operações e foram adicionados mecanismo de herança e polimorfismo. Mesmo com
todas essas características a implementação fisicamente continua sendo feita
através de tabelas, ou seja, como um modelo relacional. A semântica da aplicação é
modelada e representada através de objetos, enquanto sua implementação física é
feita na forma relacional. As principais extensões ao modelo relacional que
caracterizam os modelos relacionais objeto são: definição de novos sistemas de
tipos de dados, mais ricos, incluindo tipos de dados complexos; incorporação de
novas funcionalidades ao Sistema Gerenciador de Banco de Dados (SGBD) para
manipular estes novos tipos complexos de dados, suporte a herança, possibilidade
de manipulação de objetos diretamente por parte do usuário, extensões feitas na
linguagem SQL, para possibilitar manipular e consultar objetos. (GALANTE, 2007).
4.1.9.5. Modelo de Banco de Dados Orientado a Objeto
Um banco de dados orientado a objeto é um banco em que cada
informação é armazenada na forma de objetos, e só pode ser manipuladas através
de métodos definidos pela classe que esteja o objeto. O conceito de banco de dados
OO possui o mesmo conceito da linguagem orientada a objeto, havendo uma
pequena diferença: a persistência de dados. Existem pelo menos dois fatores que
levam a adoção desse modelo, a primeira é que banco de dados relacional se torna
difícil de trabalhar com dados complexos. A segunda é que aplicações são
construídas em linguagens orientadas a objetos (java, C++, C#) e o código precisa
ser traduzido para uma linguagem que o modelo de banco de dados relacional
entenda, o que torna essa tarefa muito tediosa. Essa tarefa também é conhecida
como “perda por resistência” (ELMASRI, 2005).
4.1.10. Sistema Gerenciador de Banco de Dados
Um SGBD é muito importante para as aplicações nos dias de hoje. Bancos
de dados são conjuntos de dados estruturados que organizam informação. Para

49. 51
manipular as informações que estão contidas nesse banco de dados, é utilizado um
SGBD, que é responsável pelo gerenciamento dos dados (ELMASRI, 2005).
Para GALANTE (2007) as principais características de um SGBD são:
controle de redundância: pode-se construir regras para que o gerenciamento seja
mais eficaz evitando assim a redundância dos dados e economiza-se espaço em
disco. Por exemplo, um aluno só pode ser cadastrado uma única vez em cada curso;
cada disciplina só pode ser cadastrada uma vez em um único curso; ou ainda, cada
aluno só pode se inscrever uma vez em cada matéria; restrição a acesso não
autorizado: Em um banco de dados com vários usuários, cada um tem acesso no
que lhe é permitido. Com um SGBD é possível restringir os acessos de cada usuário
ou grupo de usuários, permitido assim acessos autorizados para cada usuário;
garantia de armazenamento persistente: com um SGBD é possível armazenar dados
de uma forma organizada. Em muitos SGBD’s é necessário fazer a conversão de
tipo, porque muitos deles não conhecem o formato dos tipos da linguagem OO,
então é necessário fazer a conversão. Uma das vantagens de um banco de dados
orientado a objetos é que ele reconhece esse formato não precisando fazer
conversão de tipos; garantia de armazenamento de estruturas para o
processamento eficiente de consultas: uma outra característica de um SGBD é que
além de armazenar dados ele deve prover mecanismo que facilitem a busca, a
inserção ou atualização da base de dados; compartilhamento de dados: SGBD’s
multiusuários devem fornecer controle de concorrência para assegurar que
atualizações simultâneas resultem em modificações corretas. Um outro mecanismo
que permite a noção de compartilhamento de dados em um SGBD multiusuários é a
facilidade de definir visões de usuário, que é usada para especificar a porção da
base de dados que é de interesse para um grupo particular de usuários;
fornecimento de múltiplas interfaces: devido aos vários tipos de usuários, com
variados níveis de conhecimento técnico, um SGBD deve fornecer uma variedade de
interfaces para atendê-los. Os tipos de interfaces incluem linguagens de consulta
para usuários ocasionais, interfaces de linguagem de programação para
programadores de aplicações, formulários e interfaces dirigidas por menus para
usuários comuns; representação de relacionamento complexo entre dados: uma
base de dados pode possuir uma variedade de dados que estão inter-relacionados

50. 52
de muitas maneiras. Um SGBD deve ter a capacidade de representar uma variedade
de relacionamentos complexos entre dados, bem como recuperar e modificar dados
relacionados de maneira fácil e eficiente; backup e restauração: Garantir backup e
restauração de dados é tarefa essencial para qualquer SGBD. Mesmo que as falhas
sejam ocasionadas por falhas de software ou hardware ele deve garantir a
integridade dos dados e restrições de integridade: Num SGBD é possível impor
restrições, por exemplo, em uma tabela ALUNO que contém atributos: Nome, CPF,
Endereço, Tel, o atributo Nome possa ter no máximo 50 caracteres, e que CPF pode
ter 11 caracteres e que Tel pode receber 11 inteiros, ou ainda, a tabela Turma deve
ser preenchida com dados da tabela professor e da tabela Aluno etc.
4.1.10.1. Firebird
O Firebird é baseado no código fonte do InterBase 6.0 que foi liberado
como Open Source (SO) pela Borland em Agosto de 2000. A história do Interbase
remonta aos idos de 1984, portanto, são cerca de 20 anos de experiência com base
de dados relacional no produto. O Firebird permite bases de dados realmente
enormes. Bases de Dados podem se estender a múltiplos arquivos, o tamanho de
cada arquivo depende do SO. O limite teórico é atualmente 64TB para um único
arquivo da base de dados, então o limite prático é normalmente o sistema de
arquivos / operacional ou o espaço disponível no HD. O Firebird suporta um grande
número de métodos de conectividade, incluindo: Pacotes de componentes nativos
para C/C++ e Delphi, ODBC, JDBC (JayBird), Driver PHP, driver OLEDB,
dbExpress, net data provider e finalmente através de chamadas diretas à API
usando a biblioteca fbclient.dll/.so. O Firebird é licenciado sob a IPL (InterBase
Public License), a qual tem os mesmo termos da Mozilla Public License 1.1. O
Firebird é completamente gratuito para usar e distribuir a seus clientes. Você não
precisa entregar o código fonte do seu sistema, independente do seu modelo de
licenciamento. Se você modificar o núcleo do Firebird, entretanto, você deve liberar
o acesso público ao código fonte de suas modificações (BERETA e REIS, 2003).

51. 53
4.1.10.2. Microsoft SQL Server
O Microsoft SQL Server é um SGBD relacional produzido pela Microsoft, ele
faz uso da linguagem Transaction-SQL (T-SQL) que implementa sobre o SQL ANSI
algumas melhorias e funcionalidades novas. Inicialmente o SQL Server foi criado a
partir de um modelo do banco de dados da Sybase adquirido pela Microsoft em
1988, após lançar diversas versões o SQL Server atingiu o reconhecimento de
mercado e grande utilização a partir da versão 7, quando o sistema incorporou
diversas funcionalidades e ferramentas até então não existentes em outros bancos
de dados. Com o SQL Server 2000 a Microsoft conquistou parte do mercado de
banco de dados, principalmente a mudanças de arquitetura, segurança, facilidade no
uso e ferramentas, o que tornou o SQL Server um dos mais poderosos bancos de
dados disponíveis (COLLA, 2005).
4.1.10.3. PostgreSQL
Em 1994, foi adicionado um interpretador SQL ao Postgres por Andrew Yu
e Jolly Chen, e em 1995, no departamento de Ciências da Computação da
Universidade da Califórnia, em Berkeley, sendo lançado o Postgre95, voltado para
Web, completamente escrito em ANSI C (ANSI – American National Standards
Institute). Em 1996, o Postgre95 foi substituído pelo PostgreSQL, atualizado com as
novas versões da linguagem SQL, tornando-se um dos melhores bancos de dados
para sistema operacional GNU Linux, por ser robusto em aplicações simples e
complexas, com suporte a várias linguagens e por permitir herança de tabelas
(NEVES, 2002).
O PostgreSQL é um gerenciador de banco de dados relacional que
evoluiu muito nos últimos anos, incorporando características de banco de dados
tradicionais como, por exemplo, o Oracle. Tornou-se muito atraente a sua utilização
por ser poderoso, versátil, seguro e também por ser um banco de dados gratuito
(NEVES, 2002).

52. 54
4.1.10.4. Oracle
O Oracle é um sistema gerenciador de banco de dados relacional com
funções completas baseadas no ANSI SQL, segundo OLIVEIRA (2005).
O SGBD da Oracle foi desenvolvido primeiramente para um projeto da
NASA em 1977 e sua primeira aplicação comercial foi em 1979. É um sistema
portável para várias arquiteturas de hardware, desde mini e micro a computadores
de grande porte. Tem portabilidade para Unix, MS-DOS, Macintosh, Windows, entre
outros OLIVEIRA (2005).
“O SGBDD da Oracle fornece capacidades de interligação dos bancos de
dados distribuídos como se estes fossem um só. Essas capacidades
incluem pesquisas, inclusões, exclusões, atualizações e transações
distribuídas, retenção, replicação e particionamento de tabelas locais
múltiplos”. (CERÍCOLA, 1995).
Conforme a documentação oracle, o Oracle possui uma arquitetura
distribuída com execução bifásica automática, que possibilita uma transparência ao
usuário, mesmo tendo várias aplicações residindo em vários computadores de uma
rede de comunicação.
4.1.10.5. MySQL
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 seqüencial 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,
(WELLING e THOMSON, 2004).
O Mysql utiliza o modelo de dados relacional, suportando banco de
dados que consistem em um conjunto de dados e relacionamentos entre si,
(WELLING e THOMSON, 2004).

53. 55
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 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 (SILVA, 2006)
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,
(WELLING e THOMSON, 2004).
Os índices são tabelas de pesquisas especiais mantidas pelo MySQL
que possibilitam encontrar dados sem ter que procurar linha por linha de uma tabela
(SILVA, 2006)
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 (SILVA, 2006)
4.1.10.6. Linguagem SQL
A linguagem de consulta estruturada (Structured Query Language - SQL)
está entre as linguagens para banco de dados mais utilizadas em todo o mundo. Ela
foi desenvolvida pela IBM nos projetos System-R e Sequel-XRM por volta de 1974 a
1977 e imediatamente foi introduzido em outros SGBDs (RAMAKRISHNAN e
GEHRKE, 2000). A SQL tornou-se padrão em 1986 quando a American National
Standards Institute (ANSI) endossou o SQL como uma linguagem padrão para os
bancos de dados relacionais (LUCHTENBERG, 2002).

54. 56
Para OLIVEIRA (2005) a SQL trouxe para os bancos de dados relacionais
uma série de benefícios principalmente por incorporar recursos de programação
específicos para as necessidades de banco de dados, como: Inclusão, exclusão e
alteração de dados do banco. A linguagem SQL é dividida em três tipos, são eles:
Linguagem de Definição de Dados (DDL): comandos que fazem alterações nos
objetos e na estrutura da base de dados; Linguagem de Manipulação de Dados
(DML): Comandos que recuperam ou manipulam os dados do banco de dados e,
Linguagem de Controle de Dados (DCL): serve para gerenciar o acesso dos
usuários a determinadas tabelas, e manter a integridade destas.
Na DML podemos encontrar comandos como Update, Delete, Insert e
Select, comandos necessários para atualizar, excluir, inserir e selecionar dados de
um ou mais objetos de um banco de dados, já na DDL encontramos comandos
como Create Table, Alter Procedure, Add Column, Drop Table, comandos usados
para criar objetos, alterar objetos e/ou excluir os mesmos. Para a DCL alguns dos
principais comandos são os COMMITs, ROLLBACKs, GRANTs e REVOKEs
(OLIVEIRA, 2005).
4.2. Escolhas para o Desenvolvimento do Projeto
A engenharia de software Cleanroom é um processo que tem por traço
principal ser orientado à equipe. A XP é uma metodologia que tem como base
feedback constantes e por se tratar de um projeto pequeno porte e tendo como
desenvolvedor e analista um acadêmico tornou-se dispensável. A proposta deste
trabalho é desenvolver um sistema utilizando praticidade, uma vez que, este deve
ser desenvolvido individualmente, a Scrum, não apresenta tal característica, pois
envolve muitas variáveis técnicas e do ambiente, tornando o processo de
desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar
as mudanças. O RUP foi escolhido como base para a especificação do processo
neste trabalho, pelos fatores de ser uma arquitetura que entende a UML para
especificação de processos e por ser interativo.

55. 57
O padrão Singleton não foi escolhido para ser o padrão de projeto desse
trabalho, por ser um padrão de criação, que tem por objetivo especificar o processo
de criação de objetos, podem abstrair os detalhes de criação para que a
implementação seja independente dos tipos de objetos envolvidos. O Template
Method não está listado como padrão de projeto para este trabalho por seu um
padrão comportamental que tem por característica interações de objetos entre si, ou
seja, controlam determinados tipos de ações no sistema e distribuem
responsabilidades. O Facade é o padrão de projeto escolhido para este trabalho por
usar as conexões ou relacionamentos entre objetos, tendo por característica
principal a produção de interface simples para o cliente e uma mais complexa e
dinâmica para o gerente.
O modelo Microkernel não fará parte desse trabalho por aplicar-se a
sistemas que devem se adaptar às mudanças de requisitos. A plataforma de
aplicação depende da capacidade de executar aplicações escritas para um padrão
existente. Para tanto, a plataforma deve ser capaz de emular as outras plataformas
para as quais a aplicação está sendo desenvolvida. O modelo Broker é utilizado em
sistemas cuja estrutura é distribuída com desacoplamento de componentes que
interagem através de invocação remota de serviços, (BUSCHMANN et al., 1996).
Por esse motivo não é o modelo escolhido para este trabalho. Este padrão MVC foi
escolhido como modelo de arquitetura para este trabalho pela característica bem
marcante de sistemas de interface de usuário dos aplicativos a serem
desenvolvidos.
A linguagem de modelagem aSideML não fará parte deste trabalho por ser
uma modelagem orientada a aspectos e tem por características oferecer uma visão
estática de um sistema. A UML foi escolhida como linguagem de modelagens de
processos por ser uma linguagem que abrange todas as outras linguagens. Por ser
uma linguagem orientada a objeto.
A linguagem de programação PHP e o banco de dados MySQL estão
sendo requisitados para compor esse projeto, por serem software livres e
principalmente por possuir características de sinergia com as outras escolhas.

56. 58
5. Proposta do Novo Sistema
Uma solução computacional para automatizar a visão de quantidade dos
atendimentos e adesão aos programas de qualidade de vida dos funcionários e
colaboradores da empresa. Fornecer recursos necessários para mensurar o
quantitativo de atendimento no departamento de assistência social e adesão aos
programas de qualidade de vida, cujos dados deverão ilustrar através de relatório
numérico e gráfico a realidade dos funcionários e colaboradores participantes dos
benefícios oferecidos pela empresa. As informações extraídos possibilitam uma
análise das atividades e programas desenvolvidos pela empresa para um melhor
direcionamento de recursos.
5.1. Descrição do Sistema Proposto
Criar um sistema de controle de adesão aos programas da empresa,
utilizando a intranet, tendo como principal idéia mensurar o quantitativo de
funcionários que recebem os convites para os programas, eventos e atendimento de
assistência social e, o número de participantes em cada evento, para que dessa
forma possam ser identificados quais atividades são de maior aceitação pelos
funcionários. O sistema deverá receber os dados, transformá-los em linguagem
inteligível para a gerência a qual fará um estudo sobre os programas e eventos
proposto pela empresa.
5.2. Resultados Esperados
O sistema utilizará a intranet da empresa, estará disponível todos os
terminais, facilitando o acesso. É esperado que o sistema consiga armazenar os
dados e ser uma opção valiosa para o estudo dos recursos direcionados para os
eventos e atendimento de assistência social. Mesmo sendo o sistema disponível na
intranet, este estará disponível apenas para os colaboradores que fazem estrutura
que desenvolve os programas de qualidade de vida da empresa. O controle dos
convites enviados, a documentação dos registros de participação são pontos
primários do estudo que deseja a empresa e esse sistema está apto para fazê-lo.