Rodrigo César Lima Pádua
Sistema de Gerenciamento de Conteúdo
Utilizando PHP 5 com Programação Orientada a Objetos
Palmas
2003
Rodrigo César Lima Pádua
Sistema de Gerenciamento de Conteúdo
Utilizando PHP 5 com Programação Orientada a Objetos
“Relatório apresentado como requisito
parcial da disciplina Prática de
Sistemas de Informação II (TCC) do
curso de Sistemas de Informação,
orientado pelo Prof. M.Sc. Eduardo
Kessler Piveta”.
Palmas
2003
RODRIGO CÉSAR LIMA PÁDUA
Sistema de Gerenciamento de Conteúdo
Utilizando PHP 5 com Programação Orientada a Objetos
“Relatório
apresentado
como
requisito parcial da disciplina Prática
de Sistemas de Informação II
(Estágio) do curso de Sistemas de
Informação, orientado pelo Prof.
M.Sc. Eduardo Kessler Piveta”.
Aprovado em novembro de 2003
BANCA EXAMINADORA
Prof. MSc. Eduardo Kessler Piveta
Centro Universitário Luterano de Palmas
Profª. Esp. Cristina Dornellas Filipakis
Centro Universitário Luterano de Palmas
Profª. Jackson Gomes Dias
Centro Universitário Luterano de Palmas
Palmas
2003
A Dedico este trabalho aos meus pais, Ruiter
e Maria Ronilce Pádua, e ao meu irmão,
Emiliano Pádua, que tanto me apóiam e
incentivam em meus objetivos de vida.
AGRADECIMENTOS
Agradeço a todos os professores do CEULP/ULBRA do curso de Sistemas de
Informação, que de uma forma direta contribuíram em noventa por cento do meu
conhecimento específico. Agradeço também aos meus familiares e amigos próximos, que
me proporcionaram estrutura física e psicológica para o desenvolvimento desse trabalho.
E em especial agradeço a Deus, que teve e tem total influência em minha vida.
Não posso esquecer do professor Eduardo Piveta, que tem uma tranqüilidade e
despreocupação fora do comum, incentivando-me a viver a vida de uma forma mais
agradável.
RESUMO
A atualização de sites de Internet é uma tarefa trabalhosa e desgastante. Esse trabalho
visa modelar e desenvolver uma aplicação comercial que tem a função de gerenciar o
conteúdo de sites de Internet de forma fácil e rápida. Além de gerenciar o conteúdo, o
sistema disponibiliza por meio de classes, funcionalidades que permitem a usuários com
baixos níveis de conhecimento em programação, desenvolver um site dinâmico.
O sistema foi desenvolvido com linguagem de programação PHP (Hipertext
Preprocessor) e técnicas de Programação Orientada a Objetos.
A tarefa de desenvolvimento foi antecedida pela modelagem, onde foi utilizada a
Linguagem de Modelagem Unificada – UML.
ABSTRACT
The update of Internet sites is a laborious and tiring task. The purpose in this work
is to shape and to develop a commercial application that manages the content of Internet
sites in an easy and fast way. Besides managing the content, the system has functionalities
separated in classes, that allows the users with low levels of knowledge in programming, to
develop a dynamic site.
The system was developed with programming language PHP (Hipertext
Preprocessor) and Object-Oriented programming technique. The development task was
preceded by the modeling, that was made using the Unified Modeling Language - UML.
SUMÁRIO
LISTA DE TABELAS ............................................................................................. 20
1.
INTRODUÇÃO............................................................................................. 11
2.
REVISÃO DE LITERATURA ..................................................................... 12
2.1
Modelagem de sistemas ......................................................................... 12
2.2
Orientação a Objetos.............................................................................. 13
2.2.1
Classes ............................................................................................ 13
2.2.2
Objetos............................................................................................ 13
2.2.3
Atributos ......................................................................................... 14
2.2.4
Métodos .......................................................................................... 14
2.2.5
Herança ........................................................................................... 14
2.3
UML – (Unified Modeling Language) .................................................. 15
2.3.1
Diagrama de Casos de Uso............................................................. 15
2.3.2
Diagrama de Classes....................................................................... 16
2.3.3
Diagrama de Seqüência .................................................................. 18
2.3.4
Extensões para WEB ...................................................................... 19
2.4
PHP (Hipertext Preprocesor) ................................................................. 20
2.4.1
Melhorias OO na versão 5 .............................................................. 20
2.4.1.1
Membros Privados e Protegidos ............................................................ 20
2.4.1.2
Métodos Privados e Protegidos.............................................................. 22
2.4.1.3
Classes e Métodos Abstratos ................................................................. 22
2.4.1.4
Interface ................................................................................................. 23
2.4.1.5
Clonagem de Objeto .............................................................................. 24
2.4.1.6
Construtor .............................................................................................. 25
2.4.1.7
Destrutor................................................................................................. 25
2.4.1.8
Retorno de Objetos ................................................................................ 26
2.4.1.9
Acesso a Propriedades ........................................................................... 27
3.
4.
2.4.2
Biblioteca GD ................................................................................. 28
2.4.3
Biblioteca JpGraph ......................................................................... 29
Materiais e Métodos ...................................................................................... 30
3.1
Estrutura Física e Lógica........................................................................ 30
3.2
Métodos Aplicados ................................................................................ 30
Resultados e Discussões................................................................................ 31
4.1
Modelagem............................................................................................. 31
4.1.1
Levantamento de Requisitos........................................................... 31
4.1.2
Casos de Uso .................................................................................. 34
4.1.2.1
Cenários ................................................................................................. 34
4.1.2.2
Diagramas .............................................................................................. 37
4.1.3
Diagramas de Classes ..................................................................... 39
4.1.4
Diagramas de Seqüência de Projeto ............................................... 40
4.1.5
Banco de Dados .............................................................................. 46
4.1.5.1
Diagrama do modelo E-R ...................................................................... 47
4.2
Implementação ....................................................................................... 51
4.2.1
4.2.1.1
Banco de Dados .............................................................................. 51
Classes para manipulação de banco de dados........................................ 52
4.2.2
Aplicação ........................................................................................ 53
4.2.2.1
Estrutura dos arquivos............................................................................ 53
4.2.2.2
Criando as classes .................................................................................. 54
4.2.2.3
Classes em páginas de apresentação ...................................................... 55
4.2.2.4
Classes em páginas de ações (servidor) ................................................. 56
4.2.2.5
Tratamento de erros e avisos.................................................................. 57
4.2.2.6
Controle de acesso ................................................................................. 58
4.2.3
Problemas encontrados ................................................................... 59
5.
CONSIDERAÇÕES FINAIS ........................................................................ 60
6.
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................... 61
7.
Apêndice........................................................................................................ 62
7.1
Cenários ................................................................................................. 62
7.2
Diagramas de Casos de Uso................................................................... 94
7.3
Diagramas de Classes........................................................................... 101
LISTA DE FIGURAS
Figura 1: Exemplo de diagrama de casos de uso................................................... 16
Figura 2: Exemplo de diagrama de classes [Quatrani, 2000]................................ 17
Figura 3: Exemplo de diagrama de seqüência....................................................... 18
Figura 4: Ícones de estereótipos adicionais da UML, utilizados em conjunto com
aplicações WEB. ............................................................................................... 19
Figura 5: Uso de variável privada e protegida no PHP 5. ..................................... 21
Figura 6: Uso de método privado e protegido no PHP 5....................................... 22
Figura 7: Uso de classe e método abstrato no PHP 5. ........................................... 23
Figura 8: Interface em PHP 5. ............................................................................... 23
Figura 9: Clonagem de objetos no PHP 5. ............................................................ 24
Figura 10:
Construtor de classe no PHP 5. .......................................................... 25
Figura 11:
Destrutor de classe no PHP 5. ............................................................ 26
Figura 12:
Objeto como retorno de uma função. ................................................. 27
Figura 13:
Acesso a propriedades no PHP 5........................................................ 28
Figura 14:
Gráfico gerado com a biblioteca JpGraph.......................................... 29
Figura 15:
Diagrama de casos de Uso. Visão geral. ............................................ 37
Figura 16:
Diagrama de casos de uso. Pacote Usuário. ....................................... 38
Figura 17:
Visão geral do diagrama de classes.................................................... 39
Figura 18:
Diagrama de classes. Pacote Globais. ................................................ 40
Figura 19:
Diagrama de seqüência. Login. .......................................................... 41
Figura 20:
Diagrama de seqüência. Escolher Site................................................ 42
Figura 21:
Diagrama de seqüência. Cadastrar Enquete. ...................................... 42
Figura 22:
Diagrama de seqüência. Alterar Agenda............................................ 43
Figura 23:
Diagrama de seqüência. Diagrama 1. Cadastrar Informação............. 44
Figura 24:
Diagrama de seqüência. Diagrama 2. Cadastrar Informação............. 45
Figura 25:
Visão geral do modelo do banco de dados......................................... 47
Figura 26:
Visão parcial do modelo do banco de dados...................................... 48
Figura 27:
Visão parcial do modelo do banco de dados...................................... 48
Figura 28:
Visão parcial do modelo do banco de dados...................................... 49
Figura 29:
Visão parcial do modelo do banco de dados...................................... 50
Figura 30:
Criação de tabelas em base de dados utilizando o MySql Control
Center 51
Figura 31:
Conexão com banco de dados e consulta feitas pelas classes “Bd” e
“Consulta” ......................................................................................................... 52
Figura 32:
Estrutura dos arquivos da aplicação ................................................... 54
Figura 33:
Criação de classes em PHP ................................................................ 55
Figura 34:
Utilizando classes em páginas de apresentação. ................................ 55
Figura 35:
Apresentação de resultado obtido através de uma classe................... 56
Figura 36:
Chama a métodos através de páginas ações ....................................... 57
Figura 37:
Tratamento de erros nos métodos das classes .................................... 57
Figura 38:
Redirecionamento de páginas de avisos e erros................................. 58
Figura 39:
Controle de acesso através da classe “ControleAcesso”.................... 58
Figura 40:
Diagrama de casos de Uso. Visão geral. ............................................ 94
Figura 41:
Diagrama de casos de uso. Pacote Usuário. ....................................... 95
Figura 42:
Diagrama de casos de uso. Pacote Login. .......................................... 96
Figura 43:
Diagrama de casos de uso. Pacote Agenda. ....................................... 96
Figura 44:
Diagrama de casos de uso. Pacote Promoção. ................................... 97
Figura 45:
Diagrama de casos de uso. Pacote Promoção. ................................... 97
Figura 46:
Diagrama de casos de uso. Pacote Informação. ................................. 98
Figura 47:
Diagrama de casos de uso. Pacote Galeria de Fotos. ......................... 99
Figura 48:
Diagrama de casos de uso. Pacote Publicidade................................ 100
Figura 49:
Visão geral do diagrama de classes.................................................. 101
Figura 50:
Diagrama de classes. Pacote Globais. .............................................. 102
Figura 51:
Diagrama de classes. Pacote Controle.............................................. 103
Figura 52:
Diagrama de classes. Visão geral do pacote Categorizadas............. 103
Figura 53:
Diagrama de classes. Pacote Categorizadas – Galeria de Fotos. ..... 104
Figura 54:
Diagrama de classes. Pacote Categorizadas – Informação. ............. 105
Figura 55:
Diagrama de classes. Pacote Categorizadas – Outras. ..................... 106
Figura 56:
Diagrama de classes. Pacote Diversas.............................................. 107
LISTA DE TABELAS
Tabela 1: Fases e símbolos de um diagrama de seqüência. ................................... 18
Tabela 2: Requisitos funcionais do sistema. .......................................................... 34
Tabela 3: Requisitos não funcionais do sistema. ................................................... 34
11
1.
INTRODUÇÃO
A cada dia surgem novas ferramentas e tecnologias para o desenvolvimento de
páginas WEB, dando agilidade à sua construção e novas funcionalidades a sua utilização.
Estas ferramentas são compostas por rotinas padrões prontas, com as quais o
desenvolvedor consegue obter um bom trabalho com esforço reduzido. Contudo, estas
ferramentas deixam a desejar em uma das principais necessidades de uma boa página, que
é o gerenciamento de conteúdo.
O objetivo deste trabalho é desenvolver um sistema comercial que facilite o
gerenciamento de conteúdo de páginas WEB, onde será utilizado para o desenvolvimento
do mesmo a tecnologia PHP (Hipertext Preprocesor) versão 5, que ainda se encontra em
fase de testes. Essa nova versão da linguagem de programação PHP nos permite utilizar o
paradigma de Programação Orientada a Objetos, tornando a construção, bem como futuras
alterações, mais fáceis de serem executadas.
O sistema visa permitir que diferentes tipos de usuários manipulem as informações
de um ou mais sites. Dentre essas informações temos: agenda, galeria de fotos, informação
(genérica), enquete, promoção, publicidade e mural de recados, sendo possível moderar o
conteúdo do mural de recados e dos comentários feitos à imagens da galeria de fotos. O
sistema permite também a visualização de acessos (contador de acessos), que pode ser
analisado de forma textual, onde é apresentado o número de acessos a diferentes seções de
um site, ou de forma gráfica, onde é mostrada a quantidade geral de acesso fazendo uma
comparação entre os dias do mês.
Este relatório está organizado da seguinte forma: no capitulo 2 é feita uma revisão de
literatura. No capítulo 3 serão apresentados os materiais e métodos utilizados. Na
12
seqüência o capitulo 4 mostrará como foi desenvolvido e os resultados obtidos. E por fim,
no capitulo 5 serão apresentadas as considerações finais.
2.
REVISÃO DE LITERATURA
2.1
Modelagem de sistemas
A modelagem de um sistema é feita para que se obtenha um melhor entendimento do
sistema que deve ser desenvolvido, sendo necessária também para documentar
necessidades que seriam impossíveis de serem guardadas por uma pessoa, [Melo, 2003].
Segundo [Booch, 2000], a modelagem nos ajuda a:
Documentar as decisões tomadas pela equipe;
Especificar a estrutura e o comportamento do sistema;
Visualizar o sistema como desejamos que este realmente venha a ser;
Fornecer um modelo que guiará na construção do sistema.
Para se obter um bom desenvolvimento de um sistema é necessário seguir um
modelo que possibilite obter tanto uma visão geral, quanto uma visão mais detalhada de
cada módulo do sistema. Este modelo pode ser comparado a um projeto de engenharia de
um edifício, no qual todos os detalhes, desde a tubulação à eletrificação, são especificados
previamente e são executados à medida que cada etapa vai sendo concluída.
Sistemas construídos sem uma modelagem são mais propícios a erros, pois não
apresentam previamente os requisitos e nem os pontos sujeitos a falhas.
13
2.2
Orientação a Objetos
O paradigma de orientação a objetos vem se mostrando bastante útil em diversos
tipos de domínios, desde os mais simples aos mais complexos. Este paradigma considera o
objeto - que representa conceiros do mundo real -, como sendo a unidade principal de um
sistema. [Booch, 2000].
O desenvolvimento orientado a objetos é amplamente utilizado por sua capacidade
de prover maior rapidez de desenvolvimento, capacidade de reutilização, facilidade de
manutenção e redução dos custos.
Na modelagem orientada a objetos, um sistema é modelado segundo conceitos do
paradigma de orientação a objetos, ou seja, todas as partes do sistema são representadas
como objetos. Como exemplo, num sistema de informações imobiliárias, uma casa é
representada como um objeto.
Um objeto é representado por:
Atributos, os quais definem o estado do objeto;
Operações, as quais definem o comportamento do objeto.
2.2.1
Classes
Classes representam as propriedades de um conjunto de objetos, segundo [Booch,
2000]. Os atributos, métodos e relacionamentos de uma classe são compartilhados por
todos os objetos da mesma classe. Como exemplo, a classe “ventilador” possui a
funcionalidade de ventilar, assim todas as instâncias (objetos concretos) dessa classe
poderão também ventilar.
2.2.2
Objetos
Segundo [Martin, 1997], objeto é algo concreto do mundo real, como uma cadeira,
um carro, etc. Estes objetos possuem identidade única que os distingue dos demais. No
14
caso do ventilador, por exemplo, ele possui funcionalidades (métodos), como ventilar e
atributos como tamanho, cor e voltagem.
2.2.3
Atributos
Descrevem uma característica particular de uma classe. Um atributo representa
alguma propriedade da classe. Esses atributos possuem valores, os quais descrevem o
estado do objeto, sua característica. Nem todas as classes possuem atributos.
2.2.4
Métodos
São as funcionalidades que uma classe possui. São as operações exercidas sobre os
atributos, ou seja, acessa e manipula os valores dos atributos, podendo alterar o estado de
um objeto.
2.2.5
Herança
É quando uma classe herda todas as características e funcionalidades de outra. A
classe que compartilha seus atributos e funcionalidades é chamada de superclasse e a que
herda é chamada de subclasse, que além das características herdadas, possui suas
particularidades.
15
2.3
UML – (Unified Modeling Language)
Segundo [Quatrani, 2000], na década de 1990 foram introduzidas no mercado várias
metodologias de modelagem. Cada método possuía sua própria notação, trazendo uma
confusão ao mercado, visto que um símbolo poderia ter diferentes significados. Diante
desse problema veio a UML, uma linguagem padrão que representa a unificação de três
métodos e as melhores idéias de outros métodos.
UML é uma linguagem gráfica e textual de modelagem de sistemas orientados a
objetos, que tem como objetivo permitir a visualização, especificação, construção e
documentação dos sistemas de computação. Segundo [Booch, 2000], a UML é
independente, pois possui seu próprio vocabulário e regras, tornando-a bastante utilizada.
Serão apresentados nos próximos tópicos, alguns dos principais diagramas da
linguagem UML, que são: diagrama de casos de uso, diagrama de classes e diagrama de
seqüência.
2.3.1
Diagrama de Casos de Uso
O papel do diagrama de casos de uso é mostrar a partir de um conjunto de
funcionalidades do sistema em desenvolvimento, seus atores e relacionamentos, a interação
entre esses componentes [Booch, 2000]. Esse diagrama fornece uma visão geral do
funcionamento do sistema, mostrando suas funcionalidades e quais atores têm acesso a
determinadas funções. Um diagrama de caso de uso pode ser melhor visualizado na
figura 1.
16
Figura 1: Exemplo de diagrama de casos de uso.
No diagrama apresentado na figura 1, é permitido ao ator estudante apenas se
registrar em um curso, já o ator professor tem acesso a duas funcionalidades do sistema,
que são: registrar um curso e selecionar cursos em qual ele lecionará.
2.3.2
Diagrama de Classes
O diagrama de classes serve para mostrar graficamente uma visão estática de
algumas ou de todas as classes do modelo. O modelo apresenta um diagrama de classes
principal que contém uma visão dos pacotes do sistema. Esses pacotes por sua vez, contêm
suas classes, e podem ainda conter outros pacotes, assim sucessivamente, [Quatrani, 2000].
Esse diagrama é composto por um conjunto de classes, interfaces, as colaborações e
os relacionamentos que existem entre as classes, [Booch, 2000], e é apresentado por um
conjunto de símbolos, que podem representar desde herança a apenas uma descrição
textual [Quatrani, 2000].
Segundo [Quatrani, 2000], uma boa classe é aquela que representa e engloba
características de apenas uma abstração, por exemplo: uma classe “Aluno”, deve conter
17
apenas dados referentes ao aluno, caso haja informações sobre o histórico escolar, deve-se
criar outra classe, “AlunoHistorico”. Os símbolos e os relacionamentos são apresentados
na figura 2.
Figura 2: Exemplo de diagrama de classes [Quatrani, 2000]
Na figura 2 é apresentado um diagrama de classes onde pode ser observado que a
classe “Aluno” e a classe “Funcionário”, herdam as funcionalidade e propriedades da
classe abstrata “Pessoa”.
Existe um relacionamento entre a classe “Aluno“ e a classe “AlunoHistorico”. Este
relacionamento é modelado como agregação, pois existe uma relação estreita entre as
classes, sendo a classe “AlunoHistorico” totalmente subordinada a classe “Aluno”. Já o
relacionamento entre a classe “Funcionario” e a classe “Disciplinas” é tratado como uma
associação. Isso significa que os objetos de uma classe estão conectados aos objetos da
outra classe, mas uma não é totalmente dependente da outra.
18
2.3.3
Diagrama de Seqüência
Segundo [Booch, 2000], um diagrama de seqüência apresenta mensagens enviadas e
recebidas pelos objetos que interagem com o sistema, facilitando a visualização das tarefas
que estão sendo feitas entre os objetos.
Esse tipo de diagrama é bastante valorizado nas fases iniciais da análise, pois são
ordenados com base no tempo, tornando fácil o entendimento por parte de um cliente, por
exemplo [Quatrani, 2000]. Um diagrama de seqüência é apresentado na figura 3.
Figura 3: Exemplo de diagrama de seqüência.
O diagrama de seqüência apresentado na figura 3 ilustra a solicitação de um objeto
da classe “Disciplinas” pelo ator “Professor”. As fases e os símbolos são melhores
explicadas na tabela 1.
Etapa
1
2
3
4
Processo
O ator “Professor” envia dados de acesso a classe “controleAcesso”.
A classe “controleAcesso” envia os dados para a classe “Pessoa”.
A classe “Pessoa” retorna os dados para a classe “controleAcesso” que
registra as informações do usuário.
O ator “Professor” requisita um objeto à classe “Disciplinas”.
Tabela 1: Fases e símbolos de um diagrama de seqüência.
19
2.3.4
Extensões para WEB
Segundo [Conallen, 1998], a utilização da linguagem UML para especificação de
sistemas construídos em arquitetura WEB exigem a utilização de estereótipos adicionais,
que são: Server Pages, Client Pages e Form. A figura 4 apresenta os ícones desses
estereótipos adicionais.
Figura 4: Ícones de estereótipos adicionais da UML, utilizados em conjunto com
aplicações WEB.
20
2.4
PHP (Hipertext Preprocesor)
Trata-se de uma linguagem de programação estruturada e orientada a objetos, criada
para trabalhar em conjunto com HTML ou XML em padrão WEB, permitindo a
dinamização do conteúdo com consultas a bando de dados. Esta tecnologia trabalha no
lado servidor, pois todo o seu código é interpretado no servidor, sendo enviado para o
cliente apenas o resultado, [Fuller, 2002].
O seu funcionamento é dado a partir de extensões de servidores WEB, que fazem a
tradução do código utilizando o servidor WEB apenas para apresentar o resultado. É uma
linguagem multiplataforma e funciona nos principais sistemas operacionais.
2.4.1
Melhorias OO na versão 5
Versões anteriores do PHP dispunham de uma orientação a objetos primitiva, com
poucos recursos, citada pelo próprio Zeev Suraski, um dos criadores da linguagem, como
um resultado de “one restless night”.
Na versão 5 a orientação a objetos foi totalmente reescrita, obtendo uma melhor
performance e novas funcionalidades. A seguir são descritas, segundo [Zend, 2003],
algumas das novas funcionalidades de orientação a objetos:
2.4.1.1 Membros Privados e Protegidos
As variáveis protegidas podem ser acessadas pela classe que estende a classe onde as
variáveis foram declaradas. Já as variáveis privadas só podem ser acessadas pela classe que
as declarou, [Zend, 2003]. Os níveis de acessos podem ser melhor visualizados na figura 5.
21
<?
class MyClass {
private $Hello = "Hello, World!\n";
protected $Bar = "Hello, Foo!\n";
protected $Foo = "Hello, Bar!\n";
}
function printHello() {
print "MyClass::printHello() " . $this->Hello;
print "MyClass::printHello() " . $this->Bar;
print "MyClass::printHello() " . $this->Foo;
}
class MyClass2 extends MyClass {
protected $Foo;
}
function printHello() {
//Imprime
MyClass::printHello();
//Não imprime
print "MyClass2::printHello() " . $this->Hello;
//Não imprime (não foi declarada)
print "MyClass2::printHello() " . $this->Bar;
//Imprime
print "MyClass2::printHello() " . $this->Foo;
}
$obj = new MyClass();
print $obj->Hello; // Não imprime nada
print $obj->Bar;
// Não imprime nada
print $obj->Foo;
// Não imprime nada
$obj->printHello();
// Imprime
$obj = new MyClass2();
print $obj->Hello;
print $obj->Bar;
print $obj->Foo;
$obj->printHello();
?>
// Não imprime nada
// Não imprime nada
// Não imprime nada
//Imprime
Figura 5: Uso de variável privada e protegida no PHP 5.
A figura 5 apresenta um trecho de código que contém a classe “MyClass” e seus
atributos: “Hello” privado; “Bar” e “Foo”, protegidos. A classe “MyClass2”, que estende
as características da classe “MyClass”, tenta ter acesso as variáveis da superclasse mas só
consegue acesso a variável “Foo”, pois a variável “Hello” é privada e pode ser acessada
apenas pela superclasse, pois a variável “Bar” não foi declarada na subclasse.
22
2.4.1.2 Métodos Privados e Protegidos
Os métodos protegidos podem ser acessados pela classe que estende a classe onde os
métodos foram declarados. Já os métodos privados só podem ser acessados pela classe que
os declarou [Zend, 2003]. Os níveis de acessos podem ser melhor visualizados na figura 6.
<?
class Foo {
private function aPrivateMethod() {
echo "Foo::aPrivateMethod() chamado.\n";
}
}
protected function aProtectedMethod() {
echo "Foo::aProtectedMethod() chamado.\n";
$this->aPrivateMethod();
}
class Bar extends Foo {
public function aPublicMethod() {
echo "Bar::aPublicMethod() chamado.\n";
$this->aProtectedMethod();
}
}
$o = new Bar;
$o->aPublicMethod();
?>
Figura 6: Uso de método privado e protegido no PHP 5.
Na figura 6 a classe “Bar”, que é extensão da classe “Foo”, tem acesso a apenas o
método protegido “aProtectMethod”, pois o método privado “aPrivateMethod” pode ser
acessado apenas pela classe onde ele foi declarado, no caso, a superclasse “Foo”.
2.4.1.3 Classes e Métodos Abstratos
As classes declaradas como abstratas podem ser estendidas por outras classes, ou
seja, uma classe estende uma classe abstrata quando deseja herdar todas as suas
características e funcionalidades, [Zend, 2003].
Os métodos abstratos não implementam nenhum código, são apenas declarados na
superclasse. A implementação é feita na subclasse.
23
<?
abstract class AbstractClass {
abstract public function test();
}
class ImplementedClass extends AbstractClass {
public function test() {
echo "ImplementedClass::test() called.\n";
}
}
$o = new ImplementedClass;
$o->test();
?>
Figura 7: Uso de classe e método abstrato no PHP 5.
Na figura 7 é criada uma classe abstrata chamada “AbstractClass” e um método
abstrato pertencente a essa classe chamado “test”. A classe “ImplementedClass” estende a
classe abstrata e implementa um código para o método abstrato herdado. A instanciação é
feita sob a subclasse, pois uma classe abstrata não pode ser instanciada e um método
abstrato não pode ser chamado.
2.4.1.4 Interface
As Interfaces permitem que o desenvolvedor necessite conhecer apenas um conjunto
reduzido de conceitos e métodos, podendo desacoplar funcionalidades da abstração de uma
classe, [Zend, 2003].
<?
interface Throwable {
public function getMessage();
}
class Exception implements Throwable {
public function getMessage() {
// ...
}
?>
Figura 8: Interface em PHP 5.
24
A figura 8 apresenta o código de uma Interface, “Throwable”, onde apenas é
declarado o nome do método, mas não ó seu código. É apresentado também a classe que
implementa o método que é declarado na interface.
2.4.1.5 Clonagem de Objeto
A clonagem de objetos no PHP 4 copiava todas as propriedades completamente
iguais, pois não era possível identificar que o construtor da classe deveria funcionar ao se
duplicar um objeto, [Zend, 2003].
<?
class MyCloneable {
static $id = 0;
function MyCloneable() {
$this->id = self::$id++;
}
}
function __clone() {
$this->name = $that->name;
$this->address = "New York";
$this->id = self::$id++;
}
$obj = new MyCloneable();
$obj->name = "Hello";
$obj->address = "Tel-Aviv";
print $obj->id . "\n";
$obj = $obj->__clone();
print $obj->id . "\n";
print $obj->name . "\n";
print $obj->address . "\n";
?>
Figura 9: Clonagem de objetos no PHP 5.
Na nova versão do PHP, quando é solicitada a duplicação de um objeto, é verificado
se o método “__clone()” está definido ou não. Caso não esteja o objeto é copiado com
todas as propriedades idênticas. Mas se o método “__clone()” está definido, ao se duplicar
o objeto as propriedades são alteradas, conforme escrito no método. A clonagem de objetos
no PHP 5 pode ser melhor visualizada na figura 9.
25
2.4.1.6 Construtor
No PHP 4 o construtor da classe era o método que tinha o nome exatamente igual ao
da classe. Com essa forma de trabalhar os construtores de classes, ao se herdar uma classe
abstrata, era preciso redefinir o construtor na subclasse, tornando o desenvolvimento
incomodo.
Foi introduzido no PHP 5 a maneira padrão de construtor de classe, que utiliza o
método “__constructor()”. A utilização desse novo recurso pode ser melhor visualizado
na figura 10.
<?
class BaseClass {
function __construct() {
print "In BaseClass constructor\n";
}
}
class SubClass extends BaseClass {
function __construct() {
parent::__construct();
print "In SubClass constructor\n";
}
}
$obj = new BaseClass();
$obj = new SubClass();
?>
Figura 10:
Construtor de classe no PHP 5.
Na figura 10 são apresentadas duas classes, sendo uma superclasse e a outra
subclasse, onde ambas possuem construtores, pois o construtor de uma classe não é
herdado, mas sim definido individualmente.
2.4.1.7 Destrutor
O recurso de definir destrutores para objetos pode ser muito útil. O destrutor é
chamado quando o ciclo de vida de um objeto acaba e todo o trabalho de limpeza de
memória pode ser definido no mesmo, [Zend, 2003].
26
<?
class MyDestructableClass {
function __construct() {
print "In constructor\n";
$this->name = "MyDestructableClass";
}
}
function __destruct() {
print "Destroying " . $this->name . "\n";
}
$obj = new MyDestructableClass();
?>
Figura 11:
Destrutor de classe no PHP 5.
Na figura 11 é apresentado uma classe que possui o método construtor
“__construct()” e o método destrutor “__destruct()”. O método construtor é o primeiro
comportamento da classe e é chamado assim que a classe é instanciada, e neste caso tem
como função, escrever uma mensagem na tela e atribuir um valor a variável “name”. O
método destrutor é o último método a ser chamado antes que o objeto seja removido da
memória, e neste caso tem com função, escrever na tela o valor da variável “name” que foi
definido no construtor da classe.
2.4.1.8 Retorno de Objetos
É possível efetuar um objeto como retorno de um método, dessa forma é possível
manipular o resultado de uma chamada a um método, pois em versões anteriores era
possível efetuar apenas o retorno de conteúdo em forma de texto ou matriz, [Zend, 2003].
27
<?
class Circle {
function draw() {
print "Circle\n";
}
}
class Square {
function draw() {
print "Square\n";
}
}
function ShapeFactoryMethod($shape) {
switch ($shape) {
case "Circle":
return new Circle();
case "Square":
return new Square();
}
}
ShapeFactoryMethod("Circle")->draw();
ShapeFactoryMethod("Square")->draw();
?>
Figura 12:
Objeto como retorno de uma função.
A figura 12 apresenta duas classes e uma função, que tem como parâmetro a
identificação da chamada de uma das classes. A função identifica qual classe foi chamada
e retorna a instância da mesma. No PHP 4 essa operação não era possível, o retorno
deveria ser um tipo de dado, string, array, inteiro, mas não um objeto.
2.4.1.9 Acesso a Propriedades
A chamada a métodos do objeto pode ser feita através do método “__call()”, e o
acesso a propriedades do objeto através dos métodos “_set()” e “__get()”.
28
<?php
class Setter {
public $n;
public $x = array("a" => 1, "b" => 2, "c" => 3);
function __get($nm) {
print "Getting [$nm]\n";
}
if (isset($this->x[$nm])) {
$r = $this->x[$nm];
print "Returning: $r\n";
return $r;
} else {
print "Nothing!\n";
}
function __set($nm, $val) {
print "Setting [$nm] to $val\n";
}
}
if (isset($this->x[$nm])) {
$this->x[$nm] = $val;
print "OK!\n";
} else {
print "Not OK!\n";
}
$foo = new Setter();
$foo->n = 1;
$foo->a = 100;
$foo->a++;
$foo->z++;
var_dump($foo);
?>
Figura 13:
Acesso a propriedades no PHP 5.
A figura 13 apresenta os métodos de acesso a propriedades. Para o método “__get()”
é passado apenas o nome da propriedade para que ele retorne o valor. Para o método
“__set()” é passado o nome da propriedade e o novo valor que deverá ser atribuído.
2.4.2
Biblioteca GD
Com essa biblioteca é possível criar imagens do tipo JPG e PNG. A criação pode ser
feita incluindo linhas, círculos, quadrados e letras em fontes True Type, ou simplesmente
manipular uma imagem já criada, onde é necessário redimensionar automaticamente uma
imagem de 640 x 480 para 400 x 300 pixels, por exemplo.
29
2.4.3
Biblioteca JpGraph
Trata-se de um conjunto de classes para PHP que trabalha em conjunto com a
biblioteca GD. Com essa biblioteca é possível construir, com pouco código de
programação, gráficos estatísticos. Um exemplo de gráfico pode ser visualizado na figura
14.
Figura 14:
Gráfico gerado com a biblioteca JpGraph.
30
3.
Materiais e Métodos
3.1
Estrutura Física e Lógica
Para o desenvolvimento deste trabalho foram utilizados dois microcomputadores
padrão IBM. Um com processador Pentium® III 500 Mhz, com sistema operacional Red
Hat® Linux 9, sendo utilizado como software, o banco de dados MySql® 4.1 e o servidor
WEB Apache® com a extensão PHP 5 beta 2. O outro microcomputador com processador
AMD® Atlhon 1300 Mhz, com sistema operacional Microsoft® Windows 2000
Professional, foi utilizado com ferramentas para o desenvolvimento do trabalho, onde
pode-se citar o Rational® Rose 2003 – utilizada para desenvolver modelagem de sistemas
utilizando a linguagem UML –, e o Macromedia® Dreamweaver 2004 – utilizado para
criação de páginas WEB, envolvendo design e programação -, como sendo as principais
ferramentas.
3.2
Métodos Aplicados
Foram feitos levantamentos de desenvolvimento orientado a objetos aplicado ao
padrão WEB, segurança, incluindo controle de acesso, além de pesquisas sobre
programação orientada a objetos utilizando PHP 5.
Para os requisitos do sistema foi feita uma pesquisa onde foram levantadas variadas
informações de diversos estilos de sites da Internet, considerando a forma de apresentação
e o conteúdo das informações.
31
4.
Resultados e Discussões
4.1
Modelagem
4.1.1
Levantamento de Requisitos
A maior dificuldade em se modelar um sistema não é a construção dos diagramas e
códigos ou o projeto da base de dados. Na realidade está no gerenciamento dos requisitos,
pois é necessário entender o que o usuário quer e demonstrar que realmente se entendeu
suas necessidades.
Descrever esses requisitos em uma linguagem natural sem um padrão pode levar a
ambigüidades, tornando ainda mais difícil o gerenciamento dos requisitos. Para que não
ocorram essas ambigüidades, ou pelo menos para minimizá-las, utilizou-se os casos de
uso, que é nada mais que um padrão de especificações em linguagem natural.
Os requisitos desse sistema foram identificados a fim de proporcionar uma fácil
utilização de um sistema de gerenciamento de conteúdo. A primeira etapa foi levantar as
necessidades mais comuns presentes em páginas na Internet, onde se obteve um número
elevado de requisitos.
Após fazer um levantamento detalhado de requisitos, foi preciso encontrar uma
forma de generalizá-los, diminuindo o número de ambigüidades de operações e dados, por
exemplo: um site possui seções que falam sobre música, cinema e humor, na qual ambas
possuem informações e dados distintos, tornando inviável a definição de requisitos para
cada uma dessas seções. Para isso definiu-se o uso do requisito de “cadastro de
informação”, onde os dados podem ser inseridos de forma genérica, sendo filtrados
posteriormente através de categorias.
32
Os requisitos definidos para esse sistema atendem de forma ampla as necessidades
genéricas de qualquer site de Internet, mas não implementa funções específicas de um
determinado domínio.
Na tabela 2 são apresentados os requisitos funcionais para o sistema de
gerenciamento de conteúdo proposto neste trabalho.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
O sistema deve permitir o usuário efetuar o login.
O sistema deve permitir o usuário efetuar o logout.
O sistema deve permitir o usuário alterar a senha.
O sistema deve permitir o usuário efetuar o cadastro de site.
O sistema deve permitir o usuário efetuar a edição de site.
O sistema deve permitir o usuário efetuar o cadastro de usuário.
O sistema deve permitir o usuário efetuar a edição de usuário.
O sistema deve permitir o usuário efetuar a exclusão de usuário.
O sistema deve permitir o usuário definir a usuários cadastrados permissões de
acesso a recursos e categorias de informação de um site.
O sistema deve permitir o usuário com acesso a mais de um site, ao efetuar login
escolher o site que irá ser gerenciado.
O sistema deve permitir o usuário efetuar o cadastro de agenda.
O sistema deve permitir o usuário efetuar a edição de agenda.
O sistema deve permitir o usuário efetuar a exclusão de agenda.
O sistema deve permitir o usuário efetuar o cadastro de compromisso em agenda.
O sistema deve permitir o usuário efetuar a edição de compromisso em agenda.
O sistema deve permitir o usuário efetuar a exclusão de compromisso em agenda.
O sistema deve permitir o usuário efetuar o cadastro de categoria e subcategoria para
galeria de fotos.
O sistema deve permitir o usuário efetuar a edição de categoria e subcategoria para
galeria de fotos.
O sistema deve permitir o usuário efetuar a exclusão de categoria e subcategoria para
galeria de fotos.
O sistema deve permitir o usuário efetuar o cadastro de galeria de fotos.
O sistema deve permitir o usuário efetuar a edição de galeria de fotos.
O sistema deve permitir o usuário efetuar a exclusão de galeria de fotos.
O sistema deve permitir o usuário efetuar o cadastro de imagem em galeria de fotos.
O sistema deve permitir o usuário efetuar a edição de imagens em galeria de fotos.
O sistema deve permitir o usuário efetuar a exclusão de imagens em galeria de fotos.
O sistema deve permitir o usuário efetuar o redimensionamento de imagem em
galeria de fotos.
O sistema deve permitir o usuário escolher o tamanho do thumbnail que será criado a
partir da imagem de galeria de fotos.
O sistema deve permitir o visitante efetuar o cadastro de um comentário em uma
imagem.
O sistema deve permitir o visitante enviar uma imagem para um e-mail.
O sistema deve permitir o usuário efetuar o cadastro de categoria e subcategoria para
informação.
33
31. O sistema deve permitir o usuário efetuar a edição de categoria e subcategoria para
informação.
32. O sistema deve permitir o usuário efetuar exclusão de categoria e subcategoria para
informação.
33. O sistema deve permitir o usuário efetuar o cadastro de informação.
34. O sistema deve permitir o usuário efetuar o cadastro de arquivo em informação.
35. O sistema deve permitir o usuário efetuar a edição de arquivos em informação.
36. O sistema deve permitir o usuário efetuar a exclusão de arquivos em informação.
37. O sistema deve permitir o usuário efetuar o cadastro de enquete.
38. O sistema deve permitir o usuário efetuar a edição de enquete.
39. O sistema deve permitir o usuário efetuar a exclusão de enquete.
40. O sistema deve permitir o usuário efetuar o cadastro de alternativa em enquete.
41. O sistema deve permitir o usuário efetuar a edição de alternativa em enquete.
42. O sistema deve permitir o usuário efetuar a exclusão de alternativa em enquete.
43. O sistema deve permitir o usuário ativar uma enquete.
44. O sistema deve permitir o usuário desativar uma enquete.
45. O sistema deve permitir o usuário efetuar o cadastro de galeria de promoção.
46. O sistema deve permitir o usuário efetuar a edição de galeria de promoção.
47. O sistema deve permitir o usuário efetuar a exclusão de galeria de promoção.
48. O sistema deve permitir o usuário efetuar o cadastro de prêmio em galeria de
promoção.
49. O sistema deve permitir o usuário efetuar a edição de prêmio em galeria de
promoção.
50. O sistema deve permitir o usuário efetuar a exclusão de prêmio em galeria de
promoção.
51. O sistema deve permitir o usuário efetuar o sorteio aleatório de um prêmio.
52. O sistema deve permitir o usuário efetuar a troca de um concorrente sorteado.
53. O sistema deve permitir o usuário efetuar o cadastro de categoria e subcategoria para
publicidade.
54. O sistema deve permitir o usuário efetuar a edição de categoria e subcategoria para
publicidade.
55. O sistema deve permitir o usuário efetuar a exclusão de categoria e subcategoria para
publicidade.
56. O sistema deve permitir o usuário efetuar o cadastro de publicidade.
57. O sistema deve permitir o usuário efetuar a edição de publicidade.
58. O sistema deve permitir o usuário efetuar a exclusão de publicidade.
59. O sistema deve permitir o usuário efetuar a moderação de mensagens do mural de
recados.
60. O sistema deve permitir o usuário efetuar a moderação de comentários de imagens da
galeria de fotos.
61. O sistema deve permitir o usuário visualizar os acessos diários por seções do site.
62. O sistema deve permitir o usuário visualizar um comparativo entre os dias, dos
acessos ao site.
63. O sistema deve permitir o visitante efetuar o cadastro de mensagem em mural de
recados.
64. O sistema deve permitir o visitante efetuar o cadastro.
65. O sistema deve permitir o visitante efetuar a edição de seus dados.
66. O sistema deve permitir o visitante efetuar login.
34
67. O sistema deve permitir ao visitante efetuar logout.
Tabela 2: Requisitos funcionais do sistema.
Na tabela 3 são apresentados os requisitos não-funcionais do sistema:
1.
2.
3.
4.
5.
6.
O sistema deve efetuar o registro de acessos ao site.
O sistema deve verificar as permissões de acesso aos recursos do sistema.
O sistema deve encriptar com função hash (md5) a senha do usuário.
O sistema deve verificar a integridade referencial dos dados.
O sistema deve efetuar validações de dados no lado do servidor.
O sistema deve manipular o tamanho de imagens.
Tabela 3: Requisitos não funcionais do sistema.
4.1.2
Casos de Uso
Os casos de uso descrevem seqüências de ações de funcionalidades, com o objetivo
de demonstrar o comportamento de um sistema, através de interações com atores. A seguir
são apresentados alguns cenários principais – que descrevem o comportamento perfeito de
um caso de uso -, e os cenários alternativos – que descrevem as seqüências alternativas de
um caso de uso. Abaixo serão apresentados alguns cenários, a fim de apenas mostrar como
são especificados. Em “Apêndice”, é apresentada a lista completa de cenários.
Posteriormente são apresentados os diagramas, que fornecem uma melhor visão entre os
casos de uso e os atores.
4.1.2.1 Cenários
Caso de Uso: Efetuar Login
Objetivo: Permite o usuário entrar no sistema.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O usuário informa os dados ao sistema:
1.1. Nome de usuário;
1.2. senha.
2. O sistema encripta a senha e a valida. Extend Encriptar Senha.
3. O sistema registra o usuário no sistema.
35
Cenários Alternativos
Alternativa: Usuário ou senha inválida
2.ª Caso negativo na validação dos dados do usuário, o mesmo é informado e
deve tentar efetuar o login novamente.
Alternativa: Permissão de Acesso
3.ª Se o usuário for “administrador geral” ou possui acesso a mais de um site,
o mesmo deve selecionar o site a gerenciar. Include Selecionar Site.
Caso de Uso: Efetuar Logout
Objetivo: Permite o usuário sair do sistema com segurança.
Ator: Administrador, operador avançado, operador.
Cenário Principal
4. O usuário registrado no sistema solicita o encerramento de sua sessão.
5. O sistema limpa a sessão do usuário.
Caso de Uso: Selecionar Site (caso de uso de extensão)
Objetivo: Permite o usuário com acesso a mais de um site, escolher o site que
irá ser gerenciado.
Ator: Administrador, operador avançado, operador.
Cenário Principal
6. O sistema mostra todos os sites que o usuário possui acesso.
7. O usuário seleciona o site a ser gerenciado.
8. O sistema atualiza as sessões com informações do site em gerenciamento.
Caso de Uso: Alterar Senha
Objetivo: Permite ao usuário, já registrado no sistema, a trocar sua senha como
medida de segurança.
Ator: Administrador, operador avançado, operador.
Cenário Principal
9. O usuário informa os dados ao sistema:
9.1. Senha atual;
36
9.2. nova senha;
9.3. confirmação da nova senha.
10. O sistema encripta a senha atual e a valida. Extend Encriptar Senha.
11. O sistema compara a nova senha com a confirmação de nova senha.
12. O sistema encripta a nova senha e atualiza o banco de dados. Extend
Encriptar Senha.
Cenários Alternativos
Alternativa: Senha Atual Inválida
3.ª Se a senha atual digitada pelo usuário não for igual à cadastrada no sistema,
informar ao mesmo e solicitar nova digitação.
Alternativa: Confirmação de Nova Senha Inválida
4.ª Se a nova senha não for igual a confirmação de nova senha, informar ao
mesmo e solicitar nova digitação.
Caso de Uso: Cadastrar/Alterar Site
Objetivo: Permite o usuário cadastrar/alterar um novo site que será gerenciado
pela ferramenta.
Ator: Administrador.
Cenário Principal
13. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
14. O usuário informa os dados ao sistema:
14.1. Nome;
14.2. localização física (diretório. Ex: ../nome_site);
14.3. arquivo imagem do cabeçalho;
14.4. padrões para imagens da galeria de fotos:
14.4.1. tamanho largura;
14.4.2. tamanho altura;
14.4.3. tamanho thumbnail.
37
4.1.2.2
Diagramas
A representação de todos os casos de uso em apenas um diagrama tornaria difícil o
entendimento. Para isso utilizam-se pacotes, que são correspondentes a um agrupamento
de casos de uso, tornando possível a divisão dos diagramas.
Para o sistema proposto neste trabalho, os casos de uso foram divididos em 10
pacotes, que podem ser melhor visualizados na figura 15.
A seguir serão apresentados alguns diagramas, a fim de mostrar como são
especificados. A lista completa de diagramas pode ser visualizada em “Apêndice”.
Figura 15:
Diagrama de casos de Uso. Visão geral.
38
A figura 15, que apresenta uma visão geral dos casos de uso do sistema, define o
caso de uso “Verificar Acesso” como sendo de “inclusão” para quase todos os outros
pacotes, não sendo relacionado ao pacote “Usuário”, pois esse pacote possui um caso de
uso que não se relaciona ao caso de uso “Verificar Acesso”. Outros dois pacotes “Imagem”
e “Segurança” também não relacionam com o caso de uso “Verificar Acesso”, pois são
formados por casos de uso de extensão e de inclusão. Já o pacote “Informação” se
relaciona com mais um caso de uso de inclusão, “Verificar Acesso em Informação”.
Pode-se verificar também na figura 15, o relacionamento de generalização entre os
atores, no qual o ator “operador” é tido como o mais genérico.
Pacote: Usuário
Figura 16: Diagrama de casos de uso. Pacote Usuário.
O diagrama apresentado na figura 16, representa as funcionalidade relacionadas ao
gerenciamento de usuários do sistema, que inclui cadastramento, definição de permissões e
regras de segurança, no caso, encriptação de senha.
39
4.1.3
Diagramas de Classes
Devido ao número de classes do sistema, foi necessário dividi-las em pacotes, pois a
apresentação em um único diagrama se tornaria difícil. A seguir serão apresentados alguns
diagramas de classes, a fim de apenas mostrar como são especificados. A lista completa
contendo todos os diagramas de classes pode ser visualizada em “Apêndice C”. Na figura
24 é apresentada uma visão geral do diagrama de classes.
Figura 17: Visão geral do diagrama de classes.
As classes do sistema foram dividas em quatro pacotes mais as classes de extensão
para a arquitetura WEB, sendo que o pacote “Categorizadas” possui outros três pacotes.
40
Pacote: Globais
Este pacote é composto por classes que possuem comportamento global no sistema,
ou seja, se relacionam com várias outras classes do sistema.
A classe “Configuração” é do tipo “Utility”, que é um agrupador de variáveis e
procedimentos globais representados na forma de uma classe. No sistema proposto, a
classe “Configuração” é responsável pelos atributos que representam as variáveis de sessão
do sistema.
Figura 18: Diagrama de classes. Pacote Globais.
4.1.4
Diagramas de Seqüência de Projeto
São apresentados cinco diagramas de seqüência, sendo que os outros diagramas são
similares, sofrendo alterações apenas nos parâmetros dos métodos e nas chamadas as
classes. Os diagramas representam as interações de: cadastro de dados utilizando e não
utilizando o conceito de categorização; alteração de dados e exclusão; interações de
controle de acesso como login e escolha de site a gerenciar.
41
O uso dos estereótipos de extensão para arquitetura WEB se faz necessário nos
diagramas de seqüência, pois com eles pode-se definir as páginas responsáveis pela
apresentação do conteúdo, as páginas com formulários de cadastro e as páginas
responsáveis pelo recebimento dos dados, enviados pelo POST ou pela QueryString, e pela
chamada aos métodos.
Login
Figura 19: Diagrama de seqüência. Login.
A figura 32 e a figura 33, ilustrão a interação “Login” e “Selecionar site” que fazem
uso da classe do tipo “Utility”, “Configuração”, responsável por guardar os dados
referentes ao usuário em variáveis de sessão.
42
Selecionar Site
Figura 20: Diagrama de seqüência. Escolher Site.
Cadastrar Enquete (não utiliza categorização)
Figura 21: Diagrama de seqüência. Cadastrar Enquete.
43
Alterar Agenda
Figura 22: Diagrama de seqüência. Alterar Agenda.
44
Cadastrar Informação (utiliza categorização)
O diagrama da interação “Cadastrar Informação” foi divido em dois, pois o número
de mensagens impossibilitou a apresentação em um único diagrama. A figura 36 e a figura
37 ilustram a interação completa.
Figura 23: Diagrama de seqüência. Diagrama 1. Cadastrar Informação.
45
Figura 24: Diagrama de seqüência. Diagrama 2. Cadastrar Informação.
46
4.1.5
Banco de Dados
Após efetuar a modelagem do sistema utilizando a UML, foi definido o modelo do
banco de dados. Apesar do sistema ser orientado a objetos, o banco de dados utiliza
conceitos de entidades e relacionamentos (E-R), pois mostra ter uma melhor aceitação
comercial.
O diagrama do modelo do banco de dados foi dividido, pois o número de entidades
impossibilitou a apresentação em um único diagrama, mas uma visão geral, sem os
atributos, do modelo do banco de dados pode ser visualizada na figura 38. Os diagramas
possuem nos relacionamentos as siglas, D:C – Delete Cascade -, D:NOA – Delete No
Action. Essas siglas representam a integridade dos dados, informando se haverá ou não
exclusão dos registros da tabela “filho” relacionados com o registro excluído da tabela
“pai”.
O modelo do banco de dados definido para o sistema utiliza os tipos numéricos
integer e boolean, os tipos de texto, char, varchar e text, e os tipos de data, date, hour,
timestamp. O sistema desenvolvido considera os campos do tipo date e timestamp,
responsáveis pelo armazenamento de datas, como sendo no formato americano, “ano-mêsdia” (aaaa-mm-dd), podendo haver problemas com a utilização de base de dados
configuradas para uma determinada região, Brasil por exemplo, que utiliza o formato “diamês-ano” (dd-mm-aaaa). A solução para esse problema é criar uma função que verifique o
formato enviado com o formato aceito pelo banco de dados, e faça as modificações na
data, se necessário.
47
4.1.5.1 Diagrama do modelo E-R
Figura 25: Visão geral do modelo do banco de dados
48
Figura 26: Visão parcial do modelo do banco de dados
Figura 27: Visão parcial do modelo do banco de dados
49
Figura 28: Visão parcial do modelo do banco de dados
50
Figura 29: Visão parcial do modelo do banco de dados
51
4.2
Implementação
4.2.1
Banco de Dados
O gerenciador de banco de dados relacional utilizado no sistema foi o MySql 4.0, que
utiliza padrões ANSI SQL. Apesar de se ter utilizado este gerenciador, a aplicação
desenvolvida não se restringe a ele, pois as classes “BD” e “Consulta” emulam o mesmo
conceito utilizado pela Microsoft com o ODBC e pela Sun com o JDBC (aplicado a
linguagem JAVA), com isso, qualquer gerenciador de banco de dados relacional que utiliza
padrão ANSI SQL (ex.: Oracle, PostgreSql, MS SQL Server) poderá ser utilizado com a
aplicação sem que haja alterações no código.
Para criação e manipulação da estrutura das tabelas, foi utilizado o software livre
MySql Control Center, desenvolvido pelo próprio grupo MySql. Este software manipula de
forma satisfatória a base de dados, deixando a desejar apenas na definição da integridade
referencial das tabelas. A criação de tabelas utilizando o MySql Control Center, pode ser
visualizada na figura 43.
Figura 30: Criação de tabelas em base de dados utilizando o MySql Control Center
52
4.2.1.1 Classes para manipulação de banco de dados
As classes “Bd” e “Consulta” foram construídas especialmente para manipulação de
banco de dados. A classe “Bd” tem a função de conectar a aplicação a uma base de dados e
executar consultas sem retorno. Já a classe “Consulta” tem a função de efetuar consultas
sob a conexão feita pela classe “Bd”, podendo não só retornar resultados, como também
percorrer os registros encontrados na consulta.
Figura 31: Conexão com banco de dados e consulta feitas pelas classes “Bd” e “Consulta”
A figura 44 ilustra uma conexão feita pela classe “Bd” e uma consulta feita pela
classe “Consulta”, onde na linha 2 e 3 são criadas instâncias das classes, na linha 5 é aberta
a conexão com o banco de dados e na linha 7 é feita a consulta utilizando a variável
“Conexao” da classe “Bd”, que tem como função guardar dados da conexão para posterior
utilização na classe “Consulta“.
Foi necessária a criação de duas classes para manipulação de banco de dados, pois
uma aplicação nem sempre se restringe a apenas um banco de dados ou uma classe nem
sempre executa apenas uma consulta. Caso tivesse sido criada apenas uma classe, seria
necessária a instanciação da mesma para cada consulta feita em uma classe.
53
4.2.2
Aplicação
A aplicação foi desenvolvida utilizando a linguagem PHP, que trabalha em conjunto
com a linguagem HTML, permitindo a construção de páginas WEB dinâmicas. A
utilização de tais tecnologias demandou a instalação do Apache com o módulo PHP, que
se trata de um servidor WEB, e da instalação do banco de dados MySql 4.0, ambos
configurados sob o sistema operacional Red Hat.
Para o desenvolvimento dos códigos foi utilizado o software Macromedia
Dreamweaver MX, que proporciona rapidez no desenvolvimento de aplicações WEB,
facilitando a semântica de códigos escritos para a linguagem PHP e HTML.
4.2.2.1 Estrutura dos arquivos
A aplicação foi dividida em seis pastas:
Arquivos:
armazena
os
arquivos
relacionado
aos
dados,
enviados
posteriormente por algum usuário da aplicação. Ex.: arquivos de informação,
galeria de fotos, enquete, etc. Esta pasta é subdividida em 7 pastas: agenda,
enquete, galeriafoto, informação, promoção, publicidade e site.
Classes: armazena as classes do sistema, definidas a partir da modelagem.
Gráficos: armazena as páginas responsáveis pela construção dos gráficos
estatíticos.
Imagens: armazena as imagens utilizadas nas páginas do sistema.
Includes: armazena arquivos globais, como: conexão com o banco, funções
JavaScript, inicialização de variáveis de sessão, etc.
Os arquivos de apresentação e de ações, são armazenados na pasta raiz. A estrutura
pode ser melhor visualizada na figura 45.
54
Figura 32: Estrutura dos arquivos da aplicação
4.2.2.2 Criando as classes
A criação de classes em PHP é similar a outras linguagens. A figura 46 ilustra
parcialmente a criação da classe “Agenda”, onde na linha 1 é feita a inclusão de outra
classe que será utilizada na nova classe. A função “require_once()” deve ser utilizada no
lugar da função “include()”, que é mais comum em aplicações PHP. Ambas possuem a
mesma função, que é a de incluir o corpo de um determinado arquivo em outro. A
diferença ente as funções, é que a “require_once()” inclui um determinado arquivo apenas
uma
vez.
Por
exemplo,
uma
página
incluindo
o
arquivo
“bd.php”
(“include(classes/bd.php)”) e o arquivo “agenda.php” que também faz a inclusão do
arquivo “bd.php” utilizando a função “include()”. Isso ocasionaria na declaração repetida
de métodos da classe “Bd”, o que não é permitido.
Na linha 4, apresentada na figura 46, é feita a declaração do nome da classe e em
seguida, da linha 6 a 10, são criadas as variáveis. A linha 13 apresenta o construtor da
classe, que neste caso tem como função instanciar classe “Bd”, dessa forma os métodos da
classe “Agenda” poderão acessar o objeto “Bd” através da assinatura “$this Bd ...”. A
partir da linha 19 são criados os métodos da classe, que podem ter o valor das variáveis
passados por parâmetro ou por referência.
55
Figura 33: Criação de classes em PHP
4.2.2.3 Classes em páginas de apresentação
As páginas de apresentação utilizam as classes apenas para mostrar o resultado
obtido a partir de uma chamada a um método. Esse resultado é retornado em forma de
matriz ou string. A figura 47 ilustra a chamada ao método “Seleciona” da classe “Agenda”
passando como parâmetro a identificação do site em edição, que está guardada em uma
variável de sessão (variável global). A classe “Agenda” retornará à variável “$ar_agenda”
uma matriz contendo os registros e os valores dos campos.
Figura 34: Utilizando classes em páginas de apresentação.
56
Após efetuar a chamada ao método, caso o retorno seja uma matriz, deve-se utilizar
uma estrutura de repetição para apresentar o conteúdo da variável. A figura 48 ilustra a
apresentação do conteúdo da variável “$ar_agenda”, definida na figura 47, onde é criada
uma estrutura de repetição usando for( ). A matriz retornada possui dois índices, sendo o
primeiro a linha do registro e o segundo o nome do campo na tabela do banco de dados.
Figura 35: Apresentação de resultado obtido através de uma classe
4.2.2.4 Classes em páginas de ações (servidor)
As páginas de ações não apresentam nenhum conteúdo no navegador, a sua função é
receber o conteúdo enviado pelo POST ou pela QueryString e efetuar a chamada a um
método de uma determinada classe.
Para o sistema foi definida uma página de ações para cada classe, onde foram
divididas as ações por meio do uso da função swtich( ), que substitui o uso de if( )
economizando recursos computacionais e melhorando a organização dos códigos.
A figura 49 ilustra parcialmente uma página de ação, onde os valores são passados
por referência às classes.
57
Figura 36: Chama a métodos através de páginas ações
4.2.2.5 Tratamento de erros e avisos
O tratamento de erros é feito pelos métodos das classes. Ao se verificar um erro, o
método retorna uma string contendo a descrição do erro, do contrario retorna null, dessa
forma as páginas de ações verificam a ocorrência de erros nas chamadas aos métodos. Na
figura 50, linha 51, é verificado se o campo obrigatório “idSubcategoria” está vazio, caso
esteja o flag “erro” recebe a descrição do erro.
Figura 37: Tratamento de erros nos métodos das classes
58
Ao receber uma string como retorno a chamada a um método, as páginas de ações
redirecionam a navegação a uma página de apresentação de erros. Na figura 51, linha 163,
é verificado o conteúdo da variável “erro”, definida na página de ações. Caso esta variável
esteja vazia, a navegação é redirecionada para uma página de avisos (linha 166), onde será
apresentada uma mensagem de feedback ao usuário, caso contrário, a navegação será
redirecionada a uma página de apresentação de erros (linha 175).
Figura 38: Redirecionamento de páginas de avisos e erros
4.2.2.6 Controle de acesso
O sistema permite definir níveis de acesso a usuários. Ao efetuar login no sistema, os
dados referentes a esse usuário são carregados em variáveis de sessão (variáveis globais),
que permanecem ativas até o fechamento do navegador.
Ao entrar em uma página ou na execução de um método, é feita uma verificação,
através do método “VerificaAcesso()” da classe “ControleAcesso”, se o usuário possui
acesso ao recurso. A figura 52 ilustra essa verificação.
Figura 39: Controle de acesso através da classe “ControleAcesso”.
59
4.2.3
Problemas encontrados
Não ocorreram problemas durante o desenvolvimento do sistema, mas algumas
preocupações elevaram o trabalho, como por exemplo, a implementação de SQL’s para
banco de dados com e sem integridade referencial. O método utilizado para o controle de
erros mostrou ser eficaz para pequenos sistemas, pois as classes retornam apenas as
mensagens de erros. Isso causaria transtorno em grandes sistemas, pois o retorno de
mensagens aplica-se apenas a erros, tornando a mensagem de “sucesso” única a cada
método.
O uso de uma versão ainda em faze de teste do PHP demandou a instalação de uma
máquina com sistema operacional Linux, pois a versão disponível para o sistema
operacional Windows não havia sido compilada para trabalhar em conjunto com banco de
dados MySql.
60
5.
CONSIDERAÇÕES FINAIS
A proposta deste trabalho foi modelar e desenvolver uma ferramenta comercial de
gerenciamento de conteúdo de sites para Internet. A ferramenta foi desenvolvida para
suprir as necessidades genéricas de um site, não atendendo a necessidades específicas. As
necessidades genéricas foram levantadas a partir de uma vasta pesquisa feita na Internet.
O sistema foi desenvolvido utilizando tecnologia PHP e técnicas de Programação
Orientada a Objetos. No trabalho foram apresentadas todas as etapas de construção da
ferramenta, desde a modelagem utilizando UML ao desenvolvimento dos códigos.
O sistema de gerenciamento de conteúdo proposto no trabalho automatiza todas as
tarefas de atualização e manutenção de sites de Internet de maneira fácil e explicativa,
além de disponibilizar funções para a dinamização de sites que serão desenvolvidos por
pessoas que possuem um mínimo de conhecimento de programação.
Algumas necessidades de sites de Internet não se encontram nesse sistema, pois a
implementação tornaria o desenvolvimento no período disponibilizado, impossível. Mas
tais necessidades podem ser posteriormente adicionadas ao sistema através da criação de
novas classes.
A utilização de Programação Orientada a Objetos tornou o desenvolvimento mais
fácil e rápido, uma vez que todas as funcionalidades ficam em arquivos separados, não
causando o efeito “espaguete”, que é comumente encontrado em sistemas WEB. Um outro
benefício encontrado foi poder utilizar e aplicar a UML na construção do sistema, fazendo
com que funcionalidades fossem documentadas antes do desenvolvimento, levando a
economia de tempo com correções e a criação de classes bem definidas.
61
6.
REFERÊNCIAS BIBLIOGRÁFICAS
[Booch, 2000]
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML,
Guia do usuário. Rio de Janeiro: Campus, 2000
[Martin, 1997]
MARTIN, James. Princípios de Análise e Projeto Baseado em
Objetos. Rio de Janeiro: Campus, 1997.
[Furlan, 1998 ]
FURLAN, José Davi. Modelagem de Objetos Através da UML –
Análise e Desenho Orientado a Objetos. São Paulo: Makron Books,
1998.
[Conallen, 1998]
CONALLEN, Jim. Modeling Web Application Design with UML.
E.U.A.: Rational Web Site, jun. 1998. Disponível em:
http://www.rational.com/products/whitepapers/100462.jsp.
acesso em: 5/11/2003.
[Quatrani, 2001]
QUATRANI, Terry. Modelagem Visual com Rational Rose 2000 e
UML. Rio de Janeiro: Ciência Moderna, 2001.
[Fuller, 2002]
FULLER, James L.; SOLIN, Daniel; STEPHENS, Jon. Professional
PHP Web Services. Idianapolis: Wrox Press, 2002.
[Melo, 2003]
MELO, Ana Cristina. Desenvolvendo Aplicações com UML. 3. ed.
Rio de Janeiro: Basport, 2003.
[Zend, 2003]
CHANGES IN PHP 5 / ZEND ENGINE 2. E.U.A.: Comunidade
PHP.net. 2003. Disponível em: http://www.php.net/zend-engine2.php. acesso em: 2 outubro 2003.
62
7.
Apêndice
7.1
Cenários
Caso de Uso: Efetuar Login
Objetivo: Permite o usuário entrar no sistema.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O usuário informa os dados ao sistema:
1.1. Nome de usuário;
1.2. senha.
2. O sistema encripta a senha e a valida. Extend Encriptar Senha.
3. O sistema registra o usuário no sistema.
Cenários Alternativos
Alternativa: Usuário ou senha inválida
2.ª Caso negativo na validação dos dados do usuário, o mesmo é informado e
deve tentar efetuar o login novamente.
Alternativa: Permissão de Acesso
3.ª Se o usuário for “administrador geral” ou possui acesso a mais de um site,
o mesmo deve selecionar o site a gerenciar. Include Selecionar Site.
63
Caso de Uso: Efetuar Logout
Objetivo: Permite o usuário sair do sistema com segurança.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O usuário registrado no sistema solicita o encerramento de sua sessão.
2. O sistema limpa a sessão do usuário.
Caso de Uso: Selecionar Site (caso de uso de extensão)
Objetivo: Permite o usuário com acesso a mais de um site, escolher o site que
irá ser gerenciado.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema mostra todos os sites que o usuário possui acesso.
2. O usuário seleciona o site a ser gerenciado.
3. O sistema atualiza as sessões com informações do site em gerenciamento.
Caso de Uso: Alterar Senha
Objetivo: Permite ao usuário, já registrado no sistema, a trocar sua senha como
medida de segurança.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O usuário informa os dados ao sistema:
1.1. Senha atual;
1.2. nova senha;
1.3. confirmação da nova senha.
2. O sistema encripta a senha atual e a valida. Extend Encriptar Senha.
3. O sistema compara a nova senha com a confirmação de nova senha.
4. O sistema encripta a nova senha e atualiza o banco de dados. Extend
Encriptar Senha.
Cenários Alternativos
Alternativa: Senha Atual Inválida
3.ª Se a senha atual digitada pelo usuário não for igual à cadastrada no sistema,
informar ao mesmo e solicitar nova digitação.
64
Alternativa: Confirmação de Nova Senha Inválida
4.ª Se a nova senha não for igual a confirmação de nova senha, informar ao
mesmo e solicitar nova digitação.
Caso de Uso: Cadastrar/Alterar Site
Objetivo: Permite o usuário cadastrar/alterar um novo site que será gerenciado
pela ferramenta.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Nome;
2.2. localização física (diretório. Ex: ../nome_site);
2.3. arquivo imagem do cabeçalho;
2.4. padrões para imagens da galeria de fotos:
2.4.1.
tamanho largura;
2.4.2.
tamanho altura;
2.4.3.
tamanho thumbnail.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Usuário
Objetivo: Permite efetuar o cadastro/alteração de outros usuários no sistema.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Nome completo;
65
2.2. nome de usuário;
2.3. e-mail;
2.4. senha;
2.5. confirmação de senha;
2.6. se é administrador geral do sistema.
3. O sistema processa os dados, fazendo a encriptação da senha. Extend
Encriptar Senha.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Confirmação de Senha Inválida
4.ª Se a nova senha não for igual a confirmação de nova senha, informar ao
mesmo e solicitar nova digitação.
Caso de Uso: Excluir Usuário
Objetivo: Permite efetuar a exclusão de usuários do sistema.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona o usuário a ser excluído.
3. O sistema exclui os dados do usuário.
4. O sistema exclui as permissões a recursos do sistema atribuídas ao usuário.
5. O sistema exclui as permissões a categorias de informação atribuídas ao
usuário.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Excluir o usuário ativo
66
3.ª Caso o usuário esteja tentando excluir ele mesmo, o sistema informa ao
mesmo e encerra o caso de uso.
Caso de Uso: Definir Permissões
Objetivo: Permite definir níveis de acesso ao sistema para um determinado
usuário.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona o usuário a se definir as permissões.
3. O usuário define as permissões de acesso a recursos do sistema.
4. O usuário define as permissões de acesso a categorias de informação.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Permissões a categorias de informação
5.ª Se não foi definido acesso ao recurso “informação” e foi definido acesso as
categorias de informação, o sistema informa ao usuário e retorna ao caso de
uso.
Caso de Uso: Cadastrar/Alterar Agenda
Objetivo: Permite efetuar o cadastro/alteração de uma agenda.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Nome;
2.2. descrição.
3. O sistema processa.
67
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Agenda
Objetivo: Permite a exclusão de uma agenda.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a agenda que deseja excluir.
3. O sistema verifica a integridade dos dados
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Compromisso existente
4ª Caso exista compromisso cadastrado para a agenda, encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Compromisso
Objetivo: Permite efetuar o cadastro de compromisso para uma determinada
agenda.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a agenda em que será cadastrado o compromisso.
3. O usuário informa os dados do compromisso:
3.1. Titulo;
3.2. cidade;
68
3.3. local;
3.4. contato;
3.5. contato telefone;
3.6. data/hora início;
3.7. data/hora fim;
3.8. se possui freqüência [diária | semanal | mensal | anual];
3.9. se possui freqüência, repetir até quando [data];
3.10. descrição;
3.11. arquivo imagem.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Compromisso
Objetivo: Permite a exclusão de um determinado compromisso de uma
agenda.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a agenda que contém o compromisso a ser excluído.
3. O usuário seleciona o compromisso a ser excluído.
4. O sistema processa.
5. Se possui arquivo imagem, o exclui fisicamente.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
69
Caso de Uso: Cadastrar/Alterar Categoria de Galeria de Fotos
Objetivo: Permite efetuar o cadastro/alteração de categorias para a galeria de
fotos.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Nome;
2.2. decrição.
3. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Categoria de Galeria de Fotos
Objetivo: Permite efetuar a exclusão de categorias de galeria de fotos.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria a ser excluída.
3. O sistema verifica a integridade dos dados.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Subcategoria existente
4ª Caso exista subcategoria cadastrada para a categoria, encerra o caso de uso.
70
Caso de Uso: Cadastrar/Alterar Subcategoria de Galeria de Fotos
Objetivo: Permite efetuar o cadastro/alteração de subcategorias para categorias
de galeria de fotos.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria em que será cadastrada a subcategoria.
3. O usuário informa os dados da subcategoria:
3.1. Nome;
3.2. descrição.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Subcategoria de Galeria de Fotos
Objetivo: Permite efetuar a exclusão de subcategoria de galeria de fotos.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria que possui a subcategoria a ser excluída.
3. O usuário seleciona a subcategoria a ser excluída.
4. O sistema verifica a integridade dos dados.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
71
Alternativa: Galeria de fotos existente
4ª Caso exista galeria de fotos cadastrada para a subcategoria, encerra o caso
de uso.
Caso de Uso: Cadastrar/Alterar Galeria de Fotos
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria em que será cadastrada a galeria de
fotos.
3. O usuário informa os dados ao sistema:
3.1. Título;
3.2. data;
3.3. crédito;
3.4. descrição;
3.5. arquivo imagem.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Galeria de Fotos
Objetivo: Permite efetuar a exclusão de galerias de fotos.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria que contém a galeria a ser excluída.
3. O usuário seleciona a galeria a ser excluída.
4. O sistema verifica a integridade dos dados.
72
5. O sistema processa.
6. Se possui arquivo imagem, o exclui fisicamente.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Imagem existente
4ª Caso exista imagem cadastrada para a galeria de fotos, encerra o caso de
uso.
Caso de Uso: Cadastrar/Alterar Imagem
Objetivo: Permite efetuar o cadastro/alteração de imagens em galeria de fotos.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a galeria de fotos em que será cadastrada a imagem.
3. O usuário localiza o arquivo da imagem.
4. O usuário informa os dados da imagem:
4.1. Redimensionamento da imagem (caso não queira manter o padrão
estabelecido no cadastro do site). Extend Redimensionar Imagem;
4.2. Tamanho do thumbnail (caso não queira manter o padrão estabelecido
no cadastro do site). Extend Redimensionar Imagem.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Formato de arquivo inválido
6.ª Se a imagem escolhida não possui um formato de arquivo de imagem
válido, encerra o caso de uso.
73
Caso de Uso: Excluir Imagem
Objetivo: Permite efetuar a exclusão de imagens cadastradas em um galeria de
fotos.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a galeria que contém a imagem a ser excluída.
3. O usuário seleciona a imagem a ser excluída.
4. O sistema processa.
5. Os arquivos da imagem (imagem e thumbnail) são excluídos fisicamente.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Moderar Comentários de Imagem
Objetivo: Permite efetuar a exclusão de comentários deixados por visitantes
em imagens de galerias de fotos.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário visualiza os comentários.
3. O usuário seleciona o comentário a ser excluído.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
74
Caso de Uso: Cadastrar/Alterar Categoria de Informação
Objetivo: Permite efetuar o cadastro/alteração de categorias para informação.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados da categoria:
2.1. Nome;
2.2. descrição.
3. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Categoria de Informação
Objetivo: Permite efetuar a exclusão de categorias de informação.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria a ser excluída.
3. O sistema verifica a integridade dos dados.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Subcategoria existente
4ª Caso exista subcategoria cadastrada para a categoria, encerra o caso de uso.
75
Caso de Uso: Cadastrar/Alterar Subcategoria de Informação
Objetivo: Permite efetuar o cadastro/alteração de subcategorias para categorias
de informação.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria em que será cadastrada a subcategoria.
3. O usuário informa os dados ao sistema:
3.1. Nome;
3.2. descrição.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Subcategoria de Informação
Objetivo: Permite efetuar a exclusão de subcategorias de categorias de
informação.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria que possui a subcategoria a ser excluída.
3. O usuário seleciona a subcategoria a ser excluída.
4. O sistema verifica a integridade dos dados.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
76
Alternativa: Informação existente
4ª Caso exista informação cadastrada para a subcategoria, encerra o caso de
uso.
Caso de Uso: Cadastrar/Alterar Informação
Objetivo: Efetuar o cadastro/alteração de informações.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria em que será cadastrada a informação.
3. O usuário informa os dados ao sistema:
3.1. Título;
3.2. autor;
3.3. data;
3.4. hora;
3.5. sinopse;
3.6. texto;
3.7. arquivo imagem.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Informação
Objetivo: Efetuar a exclusão de informações.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria que contém a informação a ser excluída.
77
3. O usuário seleciona a informação a ser excluída.
4. O sistema exclui os arquivos cadastrados para a informação.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Arquivo em Informação
Objetivo: Efetuar o cadastro/alteração de arquivos em informações.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a informação em que será cadastrado o arquivo.
3. O usuário informa o tipo de arquivo.
4. Se o arquivo for do tipo imagem, o usuário escolhe uma das opções:
4.1. Criar uma 2ª imagem e manter as propriedades da original; ou
4.2. redimensionar a imagem original; ou
4.3. não alterar a imagem original.
4.4. Caso o usuário opte pela opção 4.1 ou pela opção 4.2, é necessário
que o mesmo informe as dimensões da imagem.
5. O usuário localiza o arquivo.
6. O usuário informa ao sistema os dados referentes ao arquivo:
6.1. Crédito;
6.2. comemtário.
7. O sistema processa.
78
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Formato de arquivo inválido
8.ª Se o arquivo não for do tipo escolhido pelo usuário ou se não for
reconhecido pelo sistema, encerra caso de uso.
Caso de Uso: Excluir Arquivo de Informação
Objetivo: Efetuar a exclusão de arquivos cadastrados em informação.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a informação que contém o arquivo a ser excluído.
3. O usuário seleciona o arquivo a ser excluído.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Enquete
Objetivo: Efetuar o cadastro/alteração de enquetes.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema.
2.1. Pergunta.
3. O sistema processa.
79
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Enquete
Objetivo: Efetuar a exclusão de enquetes.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a enquete a ser excluída.
3. O sistema exclui as alternativas cadastradas para a enquete.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Alternativa
Objetivo: Efetuar o cadastro/alteração de alternativas em enquete.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a enquete em que será cadastrada a alternativa.
3. O usuário informa os dados ao sistema:
3.1. Alternativa;
3.2. votos (padrão é 0);
3.3. arquivo imagem.
4. O sistema processa.
80
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Alternativa
Objetivo: Efetuar a exclusão de alternativas em enquete.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a enquete que contém a alternativa a ser excluída.
3. O usuário seleciona a alternativa a ser excluída.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Ativar Enquete
Objetivo: Efetuar a ativação de enquetes inativas.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a enquete a ser ativada.
3. O sistema desativa as demais enquetes.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
81
Caso de Uso: Desativar Enquete
Objetivo: Efetuar a desativação de enquetes.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a enquete a ser desativada.
3. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cadastrar/Alterar Galeria de Promoção
Objetivo: Efetuar o cadastro/alteração de galerias de promoções.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Título;
2.2. descrição.
3. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
82
Caso de Uso: Excluir Galeria de Promoção
Objetivo: Efetuar a exclusão de Promoções.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a galeria a ser excluída.
3. O sistema verifica a integridade dos dados.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Prêmios Cadastrados
4.ª Caso haja prêmio cadastrado para a galeria, encerra caso de uso.
Caso de Uso: Cadastrar/Alterar Prêmio
Objetivo: Efetuar o cadastro/alteração de prêmios em galerias de promoções.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a galeria a ser cadastrado o prêmio.
3. O usuário informa os dados ao sistema:
3.1. Prêmio;
3.2. data do sorteio;
3.3. hora do sorteio;
3.4. se o sorteio é automático ou não;
3.5. arquivo imagem;
4. O sistema processa.
83
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Prêmio
Objetivo: Efetuar a exclusão de prêmios em galerias de promoções.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a galeria que contém o prêmio a ser excluído.
3. O usuário seleciona o prêmio a ser excluído.
4. O sistema exclui todos os concorrentes para o prêmio.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Sortear Prêmio
Objetivo: Efetuar o sorteio de prêmios em galerias de promoções.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona o prêmio a ser sorteado.
3. O usuário informa quantos concorrentes devem ser sorteados.
4. O sistema processa selecionando de forma aleatória os concorrentes.
84
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Trocar Participante Sorteado
Objetivo: Efetuar trocar um concorrente sorteado em uma premiação.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona o prêmio que terá o participante sorteado trocado.
3. O usuário seleciona trocar participante.
4. O sistema processa selecionando outro participante de forma aleatória.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Cancelar Sorteio de Prêmio
Objetivo: Efetuar o cancelamento de um sorteio.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona o prêmio que terá o sorteio cancelado.
3. O usuário cancela o sorteio.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
85
Caso de Uso: Cadastrar/Alterar Categoria de Publicidade
Objetivo: Efetuar o cadastro/alteração de categorias de publicidade
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa os dados ao sistema:
2.1. Título;
2.2. descrição.
3. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Categoria de Publicidade
Objetivo: Efetuar a exclusão de categorias de publicidade.
Ator: Administrador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria a ser excluída.
3. O sistema verifica a integridade dos dados.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Subcategoria existente
4ª Caso exista subcategoria cadastrada para a categoria, encerra o caso de uso.
86
Caso de Uso: Cadastrar/Alterar Subcategoria de Publicidade
Objetivo: Efetuar o cadastro/alteração de subcategorias de publicidade.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria em que será cadastrada a subcategoria.
3. O usuário informa os dados ao sistema:
3.1. Título;
3.2. descrição.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Excluir Subcategoria de Publicidade
Objetivo: Efetuar a exclusão de subcategorias de publicidade.
Ator: Administrador, operador avançado.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a categoria que possui a subcategoria a ser excluída.
3. O usuário seleciona a subcategoria a ser excluída.
4. O sistema verifica a integridade dos dados.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
87
Alternativa: Informação existente
4ª Caso exista publicidade cadastrada para a subcategoria, encerra o caso de
uso.
Caso de Uso: Cadastrar/Alterar Publicidade
Objetivo: Efetuar o cadastro/alteração de publicidade.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria em que será cadastrada a publicidade.
3. O usuário informa os dados ao sistema:
3.1. Título;
3.2. data do início da veiculação;
3.3. data do término da veiculação;
3.4. dias da semana em que a publicidade será veiculada;
3.5. URL da publicidade, se possuir;
3.6. arquivo da publicidade.
4. O usuário seleciona o arquivo da publicidade.
5. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Alternativa: Formato de arquivo inválido
6.ª Se o formato do arquivo não é reconhecido pelo sistema, encerra o caso de
uso.
88
Caso de Uso: Excluir Publicidade
Objetivo: Efetuar a exclusão de publicidades.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário seleciona a subcategoria que contém a publicidade a ser excluída.
3. O usuário seleciona a publicidade a ser excluída.
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Moderar Mensagens do Mural de Recados
Objetivo: Efetuar a exclusão de mensagens com conteúdo impróprio postadas
no mural de recados.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário visualiza as mensagens do mural de recados.
3. O usuário exclui a mensagem
4. O sistema processa.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
89
Caso de Uso: Visualizar Números de Acesso por Seção
Objetivo: Visualizar um relatório com o número de acessos de cada seção do
site.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa a data ao sistema.
3. O usuário visualiza os acessos diários por seção do site.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso.
Caso de Uso: Visualizar Estatísticas de Acessos Diários
Objetivo: Visualizar o número de acessos e um comparativo entre os dias.
Ator: Administrador, operador avançado, operador.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso. Include Verificar
Acesso.
2. O usuário informa ao sistema o intervalo de datas.
3. O sistema gera um gráfico comparando o total de acessos/dia.
Cenários Alternativos
Alternativa: Acesso Negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso. Include Erro.
90
Caso de Uso: Cadastrar de Visitante
Objetivo: Permite um visitante efetuar o cadastro no sistema.
Ator: Visitante
Cenário Principal
1. O visitante informa os dados ao sistema.
1.1. Nome;
1.2. sobrenome;
1.3. e-mail;
1.4. data de nascimento;
1.5. residente em qual cidade;
1.6. estado da cidade em que reside;
1.7. telefone;
1.8. senha e confirmação de senha.
2. O sistema processa e envia um e-mail para validação de e-mail do visitante.
Extend Enviar E-mail de Validação de E-mail.
Caso de Uso: Editar Dados de Visitante
Objetivo: Permite o visitante efetuar a alteração de seus dados cadastrais.
Ator: Visitante
Cenário Principal
1. O visitante efetua login no sistema. Include Login de Visitante.
2. O visitante informa os dados ao sistema:
2.1. Nome;
2.2. sobrenome;
2.3. e-mail;
2.4. data de nascimento;
2.5. residente em qual cidade;
2.6. estado da cidade em que reside;
2.7. telefone;
2.8. senha e confirmação de senha.
3. O sistema processa.
91
Cenários Alternativos
Alternativa: Visitante não registrado
4.ª Caso o usuário não tenha efetuado o login, o sistema considera o
preenchimento dos dados como um cadastro de um novo usuário.
Alternativa: E-mail trocado
4.ª Caso o visitante tenha alterado o e-mail, é enviado um e-mail para
validação do novo e-mail. Extend E-mail de Validação de E-mail.
Caso de Uso: Login de Visitante
Objetivo: Permite um visitante cadastro no sistema efetuar o login.
Ator: Visitante
Cenário Principal
1. O visitante informa ao sistema seu e-mail e sua senha.
2. O sistema valida os dados.
Cenários Alternativos
Alternativa: Acesso negado
3.ª Se o sistema não validou os dados informados pelo visitante, informa ao
visitante e o visitante deve tentar novamente.
Caso de Uso: Logout de Visitante
Objetivo: Permite um visitante sair do sistema.
Ator: Visitante
Cenário Principal
1. O visitante seleciona encerrar a sessão no sistema.
2. O sistema processa.
92
Caso de Uso: E-mail para Validação de E-mail (caso de uso de extensão)
Objetivo: Enviar e-mail para validação de e-mail de um visitante cadastrado.
Ator: Sistema.
Cenário Principal
1. O sistema envia um e-mail para o visitante contendo um link com
informações do visitante.
2. O visitante recebe o e-mail e ativa o link.
3. O sistema registra o visitante como ativo.
Caso de Uso: Verificar Acesso
Ator: Sistema.
Cenário Principal
1. O sistema verifica se o usuário possui acesso ao recurso do sistema.
Cenários Alternativos
Alternativa: Acesso negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso em andamento.
Caso de Uso: Verificar Acesso a Informação
Ator: Sistema.
Cenário Principal
2. O sistema verifica se o usuário possui acesso a uma determinada categoria
de informação.
Cenários Alternativos
Alternativa: Acesso negado
2.ª Se o usuário não possui acesso ao recurso, o sistema informa ao mesmo e
encerra o caso de uso em andamento.
93
Caso de Uso: Redimensionar Imagem
Ator: Sistema.
Cenário Principal
1. Os dados são passados para sistema:
1.1. Nome o arquivo temporário;
1.2. localização do novo arquivo;
1.3. dimensões da imagem.
2. O sistema processa.
Cenários Alternativos
Alternativa: Acesso negado
3.ª Se o arquivo temporário não foi encontrado, encerra o caso de uso.
Caso de Uso: Encriptar Senha (caso de uso de extensão)
Objetivo: Efetuar a encriptação de uma mensagem usando função hash (md5).
Ator: Sistema.
Cenário Principal
1. O sistema recebe a mensagem original.
2. O sistema aplica a função hash (md5) sob a mensagem original e retorna o
resultado.
94
7.2
Diagramas de Casos de Uso
Figura 40:
Diagrama de casos de Uso. Visão geral.
A figura 15, que apresenta uma visão geral dos casos de uso do sistema, define o
caso de uso “Verificar Acesso” como sendo de “inclusão” para quase todos os outros
pacotes, não sendo relacionado ao pacote “Usuário”, pois esse pacote possui um caso de
95
uso que não se relaciona ao caso de uso “Verificar Acesso”. Outros dois pacotes “Imagem”
e “Segurança” também não relacionam com o caso de uso “Verificar Acesso”, pois são
formados por casos de uso de extensão e de inclusão. Já o pacote “Informação” se
relaciona com mais um caso de uso de inclusão, “Verificar Acesso em Informação”.
Pode-se verificar também na figura 15, o relacionamento de generalização entre os
atores, no qual o ator “operador” é tido como o mais genérico.
Pacote: Usuário
Figura 41: Diagrama de casos de uso. Pacote Usuário.
O diagrama apresentado na figura 16, representa as funcionalidade relacionadas ao
gerenciamento de usuários do sistema, que inclui cadastramento, definição de permissões e
regras de segurança, no caso, encriptação de senha.
96
Pacote: Login
Figura 42: Diagrama de casos de uso. Pacote Login.
O diagrama apresentado na figura 17, além de definir os atores que trocaram
mensagens com os casos de uso “Login” e “Logout”, define também que um usuário ao
efetuar login, tem sua senha encriptada, e posteriormente deve escolher o site que irá ser
gerenciado.
Pacote: Agenda
Figura 43: Diagrama de casos de uso. Pacote Agenda.
97
Pacote: Enquete
Figura 44: Diagrama de casos de uso. Pacote Promoção.
Pacote: Promoção
Figura 45: Diagrama de casos de uso. Pacote Promoção.
98
Pacote: Informação
Figura 46: Diagrama de casos de uso. Pacote Informação.
O caso de uso “Cadastrar/Alterar Arquivo em Informação”, visualizado no diagrama
apresentado na figura 21, tem o caso de uso “Redimensionar Imagem” como complemento
funcional, podendo ser chamado de caso de uso de extensão. Este caso de uso tem como
objetivo redimensionar o tamanho de imagens adicionadas como arquivos de uma
determinada informação, com isso elimina-se a necessidade de efetuar o tratamento de
imagens utilizando softwares específicos.
99
Pacote: Galeria de Fotos
Figura 47: Diagrama de casos de uso. Pacote Galeria de Fotos.
100
Pacote: Publicidade
Figura 48: Diagrama de casos de uso. Pacote Publicidade.
101
7.3
Diagramas de Classes
Figura 49: Visão geral do diagrama de classes.
As classes do sistema foram dividas em quatro pacotes mais as classes de extensão
para a arquitetura WEB, sendo que o pacote “Categorizadas” possui outros três pacotes.
102
Pacote: Globais
Este pacote é composto por classes que possuem comportamento global no sistema,
ou seja, se relacionam com várias outras classes do sistema.
A classe “Configuração” é do tipo “Utility”, que é um agrupador de variáveis e
procedimentos globais representados na forma de uma classe. No sistema proposto, a
classe “Configuração” é responsável pelos atributos que representam as variáveis de sessão
do sistema.
Figura 50: Diagrama de classes. Pacote Globais.
103
Pacote: Controle
Figura 51: Diagrama de classes. Pacote Controle.
Pacote: Categorizadas
Foi necessário criar sub-pacotes para o pacote “Categorizadas”, pois o número de
classes tornou a apresentação em um único diagrama impossível. Uma visão geral desse
pacote é apresentada na figura 27.
Figura 52: Diagrama de classes. Visão geral do pacote Categorizadas.
104
Pacote: Categorizadas - Galeria de Gotos
Figura 53: Diagrama de classes. Pacote Categorizadas – Galeria de Fotos.
105
Pacote: Categorizadas – Informação
Figura 54: Diagrama de classes. Pacote Categorizadas – Informação.
106
Pacote: Categorizadas – Outras
Figura 55: Diagrama de classes. Pacote Categorizadas – Outras.
107
O Pacote “Outras”, apresentado na figura 30, é composto por classes que se
relacionam apenas a classe “Categoria”, diferente das classes dos pacotes “Informação” e
“Galeria de Fotos”, que possuem uma relação com as classes “Categoria” e
“Subcategoria”.
Pacote: Diversas
Figura 56: Diagrama de classes. Pacote Diversas.