0

UNIVERSIDADE ESTADUAL DE GOIÁS

UNIDADE RIO DAS PEDRAS

CURSO DE SISTEMAS DE INFORMAÇÃO

ESTUDO DE CASO DE ANÁLISE ORIENTADA A OBJETOS PARA SISTEMA WEB

VOLTADOS PARA CADASTRO E CONSULTA DE HISTÓRIA DE MÚSICAS.

BRUNA VAZ VIEIRA

DIEGO REIS CARDOSO
JOÃO PAULO DE OLIVEIRA SANTOS
JULIANE SANTIAGO
LARISSA MILENA MORAES

ORIENTADOR: PROFª. LILIANE BAUDUÍNO

ITABERAÍ / 2010
 1

SUMÁRIO

TEMA...............................................................................................................3
LISTA DE ABREVIATURAS.........................................................................3
APRESENTAÇÃO DO TEMA........................................................................3
JUSTIFICATIVA.............................................................................................5
OBJETIVOS.....................................................................................................6
OBJETIVO GERAL.........................................................................................6
OBJETIVOS ESPECÍFICOS...........................................................................6
FUNDAMENTAÇÃO TEÓRICA....................................................................7
2.1 CONSIDERAÇÕES INICIAIS..................................................................7
2.2.1 BREVES CONSIDERAÇÕES SOBRE ORIENTAÇÃO A OBJETOS. 7
2.2.2 CLASSE..................................................................................................8
2.2.3 OBJETO..................................................................................................8
2.2.4 ENCAPSULAMENTO............................................................................8
2.2.5 POLIMORFISMO...................................................................................9
2.2.6 HERANÇA..............................................................................................9
2.3.1 PADRONIZAÇÃO DA MODELAGEM DE SISTEMAS USANDO A UML
..........................................................................................................................10
2.3.2 DIAGRAMA DE CLASSES...................................................................11
2.3.3 DIAGRAMA DE OBJETOS...................................................................11
2.3.4 DIAGRAMA DE PACOTES..................................................................12
2.3.5 DIAGRAMA DE ESTRUTURA COMPOSTA......................................13
2.3.6 DIAGRAMA DE COMPONENTES......................................................14
2.3.7 DIAGRAMA DE IMPLANTAÇÃO.......................................................15
2.3.8 DIAGRAMA DE CASOS DE USO........................................................15
2.3.9 DIAGRAMA DE SEQÜÊNCIA.............................................................16
2.3.10 DIAGRAMA DE MÁQUINA DE ESTADOS.....................................17
2.3.11 DIAGRAMA DE COMUNICAÇÃO....................................................17
2.3.12 DIAGRAMA DE ATIVIDADES..........................................................18
2.3.13 DIAGRAMA DE VISÃO GERAL DE INTERAÇÃO.........................19
 2

2.3.14 DIAGRAMA DE TEMPORIZAÇÃO...................................................19

2.4 DESENVOLVENDO SISTEMAS PARA WEB........................................19
ESTUDO DE CASO.........................................................................................21
LISTA DE REQUISITOS................................................................................23
DIAGRAMA DE CASO DE USO DE NEGÓCIO..........................................25
DIAGRAMA DE ATIVIDADE DO NEGÓCIO.............................................27
DIAGRAMA DE CLASSE..............................................................................28
DIAGRAMA DE CASO DE USO DE SOFTWARE......................................29
DESCRIÇÃO DE CASOS DE USO................................................................31
DOCUMENTO VISÃO....................................................................................48
GLOSSÁRIO DE ATRIBUTOS......................................................................54
GLOSSÁRIO DE MENSAGENS....................................................................56
REGRAS DE NEGÓCIO.................................................................................57
MODELO ENTIDADE – RELACIONAMENTO (MER)..............................58
CONCLUSÃO..................................................................................................59
BIBLIOGRAFIA..............................................................................................61
REFERÊNCIAS BIBLIOGRÁFICAS.............................................................63
 3

TEMA
Estudo de caso de análise orientada a objetos para sistema web voltados
para cadastro e consulta de história de músicas.

LISTA DE ABREVIATURAS

OO – Orientação a Objeto
UML – Linguagem de Modelagem Unificada
HTML – Linguagem de Marcação de Hipertexto
PHP - Hypertext Preprocessor
ASP - Active Server Pages

APRESENTAÇÃO DO TEMA

Na atualidade é cada vez mais crescente a popularização da internet e a sua utilização

para os mais diversos fins, sejam eles acadêmicos, culturais, comerciais ou mesmo para lazer e
entretenimento.
Junto com essa popularização veio à evolução do desenvolvimento web, antes
baseado apenas em páginas estáticas, basicamente desenvolvidas em HTML, que evoluíram e
agora se tornaram dinâmicas utilizando as mais diversas linguagens como PHP, ASP, Ruby, Java,
além de passarem a ter conexão com banco de dados.
Com todos esses recursos as páginas de internet deixaram de ser apenas páginas e
passaram a ser verdadeiros sistemas, com grande tamanho e complexidade. Com essa evolução,
os sistemas web passaram a necessitar do mesmo planejamento aplicado aos sistemas desktop,
com análise, projeto, programação, padrões a serem seguidos, etc.
Motivados por toda essa evolução, faremos nesse projeto, a modelagem de um
sistema web. Utilizaremos todo paradigma da análise orientada a objetos e os diagramas UML
que são necessários para esse processo, com o intuito acadêmico de aplicar os conhecimentos
adquiridos nas disciplinas de análise/programação, além de apresentar como é feita a modelagem
de um sistema web.
Para essa modelagem desenvolveremos um sistema, ainda inexistente no mercado,
 4

em que os usuários possam cadastrar e comentar músicas e suas histórias de composição.

 5

JUSTIFICATIVA

O desenvolvimento de sistemas web está cada vez mais em evidência no mercado

atual, baseado nessa crescente de mercado e para adquirir a experiência de como funciona a
modelagem de um sistema web, modelaremos uma aplicação utilizando os conhecimentos
adquiridos em análise orientada a objetos e UML.
Escolhemos desenvolver um sistema onde usuários possam partilhar seus
conhecimentos sobre música. A ausência de um sistema nesse estilo na web, e entendendo a sua
importância na área acadêmica e cultural, motivou a criação desse sistema.
Baseando na popularização da web colaborativa e das redes sociais, nosso sistema
vem aproveitar esse crescente mercado para popularizar o contexto presente nas canções, de
forma que torne mais fácil o aproveitamento dessas músicas, para ilustrar trabalhos em todas as
disciplinas nas suas mais variadas formas como: divulgação de cultura, expressão de idéias e
entretenimento. Além do grande potencial comercial que um site colaborativo acarreta.
 6

OBJETIVOS

OBJETIVO GERAL

O objetivo principal desse projeto é a modelagem de um sistema web, utilizando a

análise orientada a objetos e os diagramas UML, aplicando os conhecimentos acadêmicos
adquiridos.
Como objetivo final, vamos entender como funciona os sistemas web, suas
características de desenvolvimento e implantar um sistema em que forneça aos usuários com
afinidade e conhecimento por música, meios para divulgar esse conhecimento a outros usuários e
interagirem com eles.

OBJETIVOS ESPECÍFICOS

 Entender como funciona a modelagem de um sistema web;

 Aplicar os conhecimentos em análise OO e diagramas UML para o desenvolvimento da
modelagem de um sistema web;
 Implementar o sistema web modelado;
 Deixar essa modelagem como modelo para que sirva de exemplo para outros que queiram
desenvolver sistemas web;
 7

FUNDAMENTAÇÃO TEÓRICA

2.1 CONSIDERAÇÕES INICIAIS

Apresentamos neste tópico os conhecimentos nos quais fundamentamos nosso

trabalho, são eles, fundamentalmente, o conceito de Orientação a Objetos (OO) usando a
Linguagem de Modelagem Unificada (UML), focando a sua aplicação em um sistema web,
adaptando conceitos e paradigmas da OO com as peculiaridades de aplicações para internet.
Para melhor entendimento se faz necessária, uma breve abordagem e um estudo
superficial dos termos usados, bem como a metodologia por nós aplicada e suas ferramentas,
contudo, focamos nossas explanações nos conceitos fundamentais das tecnologias utilizadas, sem
os quais não seria possível o bom entendimento do negócio e conseqüentemente, do estudo de
caso em questão.
Serão demonstradas hipóteses de soluções para os problemas do nosso estudo de
caso, problemas estes que foram identificados aplicando-se de métodos e ferramentas da UML, e
fundamentando-se efetivamente nos paradigmas da OO.

2.2.1 BREVES CONSIDERAÇÕES SOBRE ORIENTAÇÃO A OBJETOS

Segundo Sommerville, Análise Orientada a Objetos concentra-se no desenvolvimento

de um modelo orientado a objetos do domínio da aplicação. Os objetos nesse modelo refletem as
entidades e as operações associadas ao problema a ser resolvido, assim o Projeto Orientado a
Objetos se concentra no próprio sistema de software para se implementar os requisitos
identificados. A idéia da modelagem de um projeto orientado a objetos veio revolucionar o
mundo de software porque usando essa abordagem é possível se aproveitar um componente de
software desenvolvido anteriormente, este é o conceito principal de um objeto, ser um
componente reusável, pois este é encapsulado independente de estado e operações. O conceito de
orientação a objetos se resume ao fato de um objeto real ser refletido no sistema tendo as mesmas
características que ele tem em sua existência real, sendo elas as suas características próprias
(atributos), e seu comportamento (métodos).
Os conceitos apresentados nos tópicos a seguir têm como fundamento básico os
mencionados no livro – Princípios de Sistemas de Informação Usando UML – de Eduardo
 8

Bezerra, contudo não se restringem às explanações únicas desta obra, somam definições e
entendimentos também os adquiridos em Engenharia de Software – Roger S. Pressman (1995) e
Engenharia de Software – Sommerville (2007).

2.2.2 CLASSE

Nas palavras de Pressman (1995), todos os objetos são membros de uma classe mais
ampla e herdam sua estrutura de dados e suas operações, que foram definidas para esta classe, de
outra perspectiva, mas ainda de acordo com Pressman (1995) uma classe seria um conjunto de
objetos com as mesmas características, sendo que um objeto individual é, por conseguinte, uma
instância de uma classe mais ampla. Para ilustrar imaginemos um martelo, ele é um membro ou
instância de uma classe maior de objetos, à qual denominamos ferramenta. Todas as ferramentas
possuem custo, dimensões, peso, cor, numeração entre outros inúmeros atributos. Quer estejamos
falando de um martelo, de um alicate ou de qualquer outro objeto da classe ferramenta, todos
herdam da classe ferramenta os seus atributos, logo, ao instanciarmos um novo objeto da classe
ferramenta, este possuirá os mesmos atributos: cor, peso, custo e etc.

2.2.3 OBJETO

Pressman (1995) disse que um objeto é um componente do mundo real que é

mapeado para domínio do software. Ao se representar graficamente um objeto na concepção de
software, o mesmo é composto por uma estrutura de dados e processos particulares, que são as
suas operações, que são responsáveis pelas mudanças que transformam essas estruturas de dados,
e estas operações são invocadas através de mensagens – que são solicitações enviadas para que
um objeto execute uma de suas operações.

2.2.4 ENCAPSULAMENTO
 9

Os objetos criados ao se instanciar uma classe são responsáveis por executar funções
específicas a ele atribuídas, essas operações são os métodos. Segundo os princípios do encapsulamento,
quando um objeto requisita operações de outro objeto este que requisita o serviço não tem acesso aos
trâmites internos envolvidos na execução da operação, apenas recebe o resultado, o objeto encapsulado
restringe aos “olhos” do objeto requisitante o seu comportamento interno, restringe sua estrutura. O objeto
que fornece um serviço deve preocupar-se com como o serviço deve ser fornecido ao usuário, ou seja, os
detalhes de implementação. Eis o resumo de encapsulação fornecido por COX85:

[Um objeto] fornece uma encapsulação, por meio da qual uma estrutura de dados e um
grupo de procedimentos para acessá-la podem ser postos em serviço, de tal forma que os
usuários desse recurso possam acessá-la através de um conjunto de interfaces
cuidadosamente documentadas, controladas e padronizadas. Essas estruturas de dados
encapsuladas, denominadas objetos, resultam em dados ativos que podem ser solicitados
a fazer coisas ao se enviar mensagens a eles. (PRESSMAN, 1995, p. 531).

2.2.5 POLIMORFISMO

Os objetos ao receberem alguma mensagem de outro objeto, ou seja, receber deste

uma requisição deve executar suas operações competentes. Polimorfismo é a propriedade que é
dada aos objetos de cada elemento responder de forma diferente mesmo que tenha recebido uma
mensagem idêntica a recebida pelas demais, seria como se o mesmo tipo de entrada produzisse
diferentes efeitos, executados, é claro, em elementos diferentes.

2.2.6 HERANÇA

Uma gama de classes semelhantes pode ser organizada hierarquicamente de forma

que cada classe herda de todas as outras acima de si, comportamentos e características, além de
poder conter comportamentos e atribuições particulares que sejam peculiares às outras das quais
foi generalizada. Esse conceito torna efetiva a idéia de reusabilidade promovida pelo universo da
OO.
 10

Dessa forma consideremos uma classe chamada Pessoa, esta possui os seguintes
atributos: nome, telefone, endereço, e outros. Da classe Pessoa instanciaremos duas novas classes
chamadas Física e Jurídica, ambas herdarão da classe Pessoa seus atributos e além destes a classe
Física possuirá CPF, data de nascimento, enquanto a classe Jurídica possuirá CNPJ, data da
criação, inscrição estadual entre outros.

2.3.1 PADRONIZAÇÃO DA MODELAGEM DE SISTEMAS USANDO A

UML

O objetivo da UML (Unified Modeling Language) é tornar ossível a boa prática do

desenvolvimento de software, um metamodelo que otimiza métodos da OO, e os reúne em uma
única “receita” padrão, que nos oferece subsídios para a construção de aplicações consistentes e
confiáveis, resultado que pode ser conseguido se aplicarmos corretamente seus métodos e
ferramentas (diagramas), em prol da boa prática de Engenharia de Software.
A modelagem de sistemas pode ser feita de várias maneiras, desde que seja bem
documentada, assim sendo, maioria quase absoluta dos projetistas que hoje desenvolvem
sistemas, usam para tal os diagramas da UML, haja vista que no âmbito da UML esses
documentos têm caráter gráfico e, portanto são de grande compreensão por parte dos analistas e
desenvolvedores, além de seguir um padrão único para o desenvolvimento, os documentos
produzidos através das ferramentas e metodologias da Linguagem de Modelagem Unificada são
denominados artefatos de software. Para a produção desses artefatos dispomos na UML 2.0 de 13
diagramas. Diagramas são ferramentas gráficas usadas para que possamos visualizar o sistema
sob várias perspectivas. As definições dos diagramas UML a seguir fundamentam-se nos
conceitos apresentados por Eduardo Bezerra em seu livro Princípios de Sistemas de Informação
Usando UML e do Artigo A história de UML e seus diagramas de Thânia Clair de Souza Vargas.
Segue abaixo um esquema que ilustra o quadro de evolução da UML desde o seu
surgimento. (Artigo Análise de Ferramentas de Modelagem UML Gratuitas - Alex Ferreira).
 11

Figura XX – Evolução da UML

2.3.2 DIAGRAMA DE CLASSES

Após identificadas as classes do sistema, representamos todas elas em um modelo

onde são expostas as classes e seus relacionamentos, como elas se comportam e desenvolvem
suas tarefas em um ambiente integrado com as demais classes, é o diagrama mais importante da
UML. O diagrama de classes é fundamental em uma especificação OO, classes e relacionamentos
constituem os elementos sintáticos básicos do diagrama de classes (SILVA, 2007).

2.3.3 DIAGRAMA DE OBJETOS

Este diagrama fornece uma ilustração de objetos instanciados a partir da visão das
classes após serem munidas de valores, ou seja, após serem preenchidos os seus atributos,
obviamente depende da elaboração do próprio diagrama de classes. Semelhante ao diagrama de
 12

classes, porém representa instâncias e ligações entre as instâncias. Com o objetivo de descrever
um conjunto de objetos e seus relacionamentos em um dado espaço de tempo.
Segundo Furlan (1998) o diagrama mostra os objetos e como se relacionam entre si
em um dado espaço de tempo, sendo que sua representação é similar à de uma classe, um
retângulo com duas divisões, em que o primeiro contém o nome do objeto e o segundo os
atributos com seus respectivos valores, conforme exemplifica a figura XX.

Figura XX – Diagrama de Objetos

2.3.4 DIAGRAMA DE PACOTES

É uma visão do sistema como um todo, sob tal perspectiva que se possa observar
todos os subsistemas que o compõem. Tem como proposta apresentar a modelagem estrutural do
sistema em divisões lógicas e suas interações em alto nível.
Segundo Page-Jones (2001) o diagrama de pacotes possui a finalidade de organizar os
elementos em módulos, estes que por sua vez representam coleção de classes, mostrando suas
 13

dependências, figura XX. Também pode ser aplicado em bibliotecas adquiridas ou aplicação com
características relativas.

Figura XX – Exemplo de Diagrama de Pacotes.

2.3.5 DIAGRAMA DE ESTRUTURA COMPOSTA

Mostra a estrutura interna dos elementos da modelagem estrutural, de forma que se

obtenha uma visão detalhada de sua estrutura. Evidencia demonstrar colaborações, essas
colaborações são descritas pela visão de cooperação de um conjunto de elementos (instâncias),
que interagem entre si para executar uma função específica. Exemplo:
 14

Figura XX – Exemplo de Diagrama de Estrutura Composta.

2.3.6 DIAGRAMA DE COMPONENTES

Quando estamos próximos da implementação, este diagrama nos fornece uma visão
modelada entre os módulos do próprio código fonte, bibliotecas e formulários, arquivos de banco
de dados e demais arquivos de sistema. Determina como cada um desses elementos estará
disposto na organização do sistema e como interagem entre si. Mostra os artefatos de que os
componentes são feitos, são eles: os arquivos de código fonte, tabelas de bancos de dados,
bibliotecas, contudo, as associações entre os componentes são possíveis graças às suas interfaces.
 15

2.3.7 DIAGRAMA DE IMPLANTAÇÃO

Determina os requisitos físicos necessários a execução do sistema computacional,

dado um elaborado sistema de software, o diagrama de implantação expressa o aparelho de
hardware e toda a tecnologia física relacionada com a instalação do sistema, seja topologia e
protocolos de rede, máquinas envolvidas, tomemos como exemplo um sistema bancário seriam os
servidores, os caixas eletrônicos, os terminais onde se imprimem as senhas, painéis de
comunicação com os clientes e demais.

2.3.8 DIAGRAMA DE CASOS DE USO

Ao analisarmos um problema e desenvolvermos um estudo de caso sobre um

determinado negócio precisamos detectar e identificar as necessidades do negócio e registrá-las
de forma que possamos descrever essas funcionalidades que constatamos no processo, e assim
modelarmos um bom projeto. Nessa atividade de identificação é essencial que conheçamos quais
são as tarefas a serem realizadas pelo software, quais são os atores que participam dessa tarefa, e
qual é o relacionamento desse ator com essa tarefa. Para descrever esse cenário dispomos de uma
representação gráfica da UML chamada Diagrama de Caso de Uso, este demonstra a relação
entre atores e as funcionalidades do software. Fornece uma visão estática e externa do
funcionamento do sistema, seria como se um pessoa o observasse sob uma perspectiva de fora,
como se estivesse assistindo seu funcionamento sem participar dele, apenas identificando atores,
relacionamentos, tarefas, generalizações e associações entre os elementos do sistema.
O diagrama de caso de uso apresenta os seguintes componentes básicos:
 Ator - agente que interage com o sistema, ou seja, mais que apenas pessoas ou
indivíduos e sim na verdade o papel que por essa entidade é executada no processo. Este pode ser
uma máquina, uma pessoa, dispositivos e até outros sistemas;
 Caso de Uso – é a própria interação entre o usuário e o sistema, o ator solicita um
serviço que é o caso de uso, e o executa, este que é um serviço disponibilizado pelo sistema.
 Interação - Comunicação dos próprios atores com o sistema, essa interação se dá a
partir da troca de mensagens entre os atores e o sistema.
 16

 Sistema – é o conjunto de elementos unidos que trabalham harmonicamente com o

intuito de produzir um objetivo único e comum entre todos.

2.3.9 DIAGRAMA DE SEQÜÊNCIA

No âmbito de um dado processo, o diagrama de seqüência registra a ordem pela qual

são executas determinadas tarefas, estas por sua vez podem ser casos de uso, ou subtarefas,
dependendo do contexto do processo analisado, determinado qual a ordem desempenhadas pelas
mensagens que são emitidas pelos objetos, ou seja, requisições enviadas de um objeto a outro a
fim de solicitar deste os serviços (métodos) que este disponibiliza para a execução do processo.
Identifica quem é o objeto que emite uma mensagem, quem é o ator que executa esse método e
como esse microprocesso se desenrola dentro desse macro processo. Mostra a troca de
mensagens entre os objetos do sistema, definindo precisamente a ordem em que são emitidas as
mensagens e o momento em que são expedidas.
Segundo Furlan (1998), é penoso e complicado de entender o fluxo de controle em
um programa orientado a objetos, uma vez que o modelo terá diversas operações elementares que
confundem a seqüência geral do comportamento. Ainda de acordo com Furlan (1998) este
diagrama possui os seguintes componentes básicos:
 Linha da vida – evidencia um objeto desenhado com uma linha pontilhada,
demonstrando sua existência por vez da execução de uma dada seqüência;
 Mensagem – determina como os objetos se comunicam, são várias as formas,
dentre elas: chamada de procedimento, envio de sinal entre linhas ativas, elevação explícita de
eventos e mais;
 Ativação – determina o tempo que estará executando uma ação;
 Autodelegação – de caráter recursivo, ou seja, quando uma função em um
determinado local,chama a si própria para se executar.
 17

2.3.10 DIAGRAMA DE MÁQUINA DE ESTADOS

Os diagramas de máquina de estados, ou diagrama de estados como era chamado em

versões anteriores da UML, registra as mudanças sofridas por um objeto em um contexto de um
determinado processo. Acompanha os estados por quais passa um objeto, podendo também
expressar como se comportam casos de uso ou até mesmo subsistemas do sistema geral. Ilustra
como os objetos podem ser representados na forma de máquinas de estados ou autômatos, e como
podem se comportar ao receber estímulos de outros autômatos. Como exemplo, apresentamos a
Figura XX abaixo:

Figura XX – Exemplo de Diagrama de Máquina de Estados.

2.3.11 DIAGRAMA DE COMUNICAÇÃO

Complemento do diagrama de seqüência esse diagrama, com objetos semelhantes,

exceto que nesse o foco é em como os objetos de um processo estão vinculados entre si, e quais
são as mensagens por eles trocadas, uma vez que no diagrama de seqüência existe uma
preocupação no sentido de se averiguar a temporalidade das tarefas. Como é exemplificado na
Figura XX.
 18

Figura XX – Exemplo de Diagrama de Comunicação.

2.3.12 DIAGRAMA DE ATIVIDADES

Esse modelo de diagramas ilustra como as informações trafegam dentro de um objeto,

ou seja, o caminho percorrido ao se executar uma operação, mesmo que sejam traçados caminhos
paralelos estes estarão previstos no diagrama de atividades. A exemplo de um fluxograma, esse
diagrama mostra como está a situação ao se iniciar tal tarefa e passa por todas as micro-atividades
dentro de cada operação visitando todos os fluxos de possíveis caminhos alternativos até chegar a
um ponto decisivo, que não aceite o prosseguimento, finalizando assim a tarefa. O
prosseguimento das execuções dá-se da seguinte maneira: ao se terminar uma ação,
imediatamente se começa outra no contexto da atividade expressada pelo diagrama. O termo ação
oferece uma idéia de atomicidade, ou seja, indivisibilidade uma coisa que não pode ser mais
fragmentada, já a atividade pode ser particionada em várias ações.
 19

2.3.13 DIAGRAMA DE VISÃO GERAL DE INTERAÇÃO

Este diagrama permite capturar de uma perspectiva estática os fluxos de interação

entre os componentes do sistema, de forma geral, do funcionamento global do sistema, de forma
similar ao modelo expresso pelo diagrama de atividades, que mostra o fluxo de um subsistema,
ou de uma dada funcionalidade em questão, como por exemplo, uma atividade de cadastro. E o
diagrama de interação geral, ilustra a interação do sistema como um todo, entre todos os
subsistemas ou funcionalidades, como cadastros, consultas e emissão de relatórios.
De acordo com Melo (2004) o Diagrama de Visão Geral é uma variação do diagrama
de atividades, que ilustra o fluxo de controle geral do sistema.

2.3.14 DIAGRAMA DE TEMPORIZAÇÃO

Objetos instanciados a partir de classes do sistema poderão ter suas mudanças de

estado, condição, e até seu papel, monitorado através desse diagrama durante um determinado
espaço de tempo, usado freqüentemente para expressar como um dado objeto se comporta
durante certo tempo em resposta a eventos externos. Modela a interação e a evolução de estados,
e consiste em monitorar as restrições temporais do sistema.

2.4 DESENVOLVENDO SISTEMAS PARA WEB

Um projeto a ser desenvolvido para um ambiente web precisa assim como um projeto
normal de software ser planejado e passar por um processo de engenharia. Pode reger-se pelos
princípios da OO e ter seu processo de modelagem elaborado e apoiado por ferramentas da UML,
mas mesmo assim um projeto de aplicação web segue processos um pouco diferentes, além de
suas regras de negócio obedecerem a outras legislações e particularidades. Contudo, existem
ferramentas que auxiliam de uma maneira mais adequada o desenvolvimento desse tipo de
aplicação, assim sendo se faz necessário que apresentemos os fundamentos da tecnologia web,
 20

bem como demonstrar ao cliente que esse tipo de negócio tem detalhes um tanto quanto
particulares tanto na parte do desenvolvimento e da tecnologia aplicada quanto na manutenção do
próprio negócio.
Tudo nas nossas vidas muda os lugares, as pessoas, os costumes e demais coisas.
Metodologias empregadas com sucesso ontem podem não oferecer resultados satisfatórios hoje, e
com a engenharia de software não é diferente, usamos modelos de processo pré-definidos sem
contudo desprezar novas tecnologias, padrões e conceitos.
Desenvolver softwares hoje em dia é mais que apenas programar os componentes de
código, é preciso ter a visão do negócio como um todo, todo o ciclo de desenvolvimento deve ser
organizado e bem definido para que tudo sejam produzido e entregue no prazo.
Com a engenharia de sites também é assim, em sua abordagem global é semelhante a
uma aplicação desktop, porém não existe uma metodologia que seja específica para o
desenvolvimento de aplicações web.
 21

ESTUDO DE CASO
Modelagem do Negócio

Com o objetivo principal de criar um site colaborativo de música, escolhemos desenvolver

um Sistema web que visa o cadastro e armazenamento dos internautas (usuários), músicas,
histórias das músicas e bandas/artista. As principais funções do sistema serão:
 Cadastro Usuário: Função responsável pela inclusão de um novo usuário, música,
história, artista;
 Cadastro de Música: Função responsável pela inclusão de uma nova música;
 Cadastro de História: Função responsável pela inclusão de uma nova história;
 Cadastro de Artista: Função responsável pela inclusão de um novo artista;
 Alteração Usuário: Função responsável pela alteração dos dados dos usuários
cadastrados;
 Alteração de Música: Função responsável pela alteração dos dados das músicas
cadastradas;
 Alteração de Artista: Função responsável pela alteração dos dados dos artistas
cadastrados;
 Alteração da História: Função responsável pela alteração dos dados das histórias das
músicas cadastradas;
 Exclusão de Usuário: Função responsável pela exclusão de usuário cadastro;
 Exclusão de História: Função responsável pela exclusão de histórias de músicas
cadastradas com algum erro;
 Consulta: Função responsável pela consulta nos cadastros, sendo que a consulta poderá
ser realizada utilizando os seguintes filtros: músicas, autores, gêneros e versões de
histórias das músicas;
 Visualização: Função responsável pela visualização de algum resultado da consulta;
 Indicação: Com esta função o usuário poderá fazer da indicação música/historia que esta
visualizando através de email para algum de seus contatos;
 Avaliação: Função responsável pela avaliação do conteúdo será utilizado o sistema de
estrelas;
 22

 Resposta/comentário: Com esta função os usuários poderão comentar as postagens de

outros usuários ou ainda caso não concordem com a versão da postagem anterior postar
uma nova;

O sistema apresenta três tipos básicos de usuários:

 Administradores: Responsáveis pela administração do sistema, eles terão acesso a todos
os cadastros com permissão para a realização de todas as funções do sistema. Terão
função de moderação.
 Usuários: Eles terão acesso a todas as funções do sistema, mas nas funções de Cadastro,
Alteração e Exclusão, terão a restrição de realizá-las apenas nos conteúdos que o próprio
usuário cadastrou.
 Visitantes: Terão acesso apenas às funções de busca e visualização, caso queira realizar
as demais funções será solicitada a realização de cadastro.

O processo de desenvolvimento do sistema será baseado no ciclo de vida evolutivo, pois ele
não apresenta requisitos tão claros e definidos, e estará sempre passando por validação e
evolução.
 23

LISTA DE REQUISITOS

Nome Descrição Ator

Cadastrar usuário Cadastrar usuários que Visitante

desejam contribuir com o site.

Efetuar login Autenticar usuários Usuário Cadastrado e

cadastrados e administradores administrador
para terem acesso ao sistema e
entrarem em sua página
pessoal.

Efetuar logout Finalizar a sessão dos usuários Usuário Cadastrado e

autenticados. administrador

Cadastrar Música Incluir música no site Usuário Cadastrado e

administrador

Cadastrar cantor/banda Incluir cantor/banda que ainda Usuário cadastrado e

não estejam no site administrador

Cadastrar gênero da Incluir gêneros de músicas Usuário cadastrado e

música administrador

Cadastrar história da Incluir história da música Usuário cadastrado e

música administrador

Cadastrar comentário Incluir comentário sobre as Usuário cadastrado

(mini-forum) histórias das músicas

Consultar música Busca no banco de dados das s Usuário cadastrado,

músicas cadastradas aquelas administrador e visitante
que apresentam o mesmo
nome que o pesquisado pelo
usuário e apresenta uma lista
de resultados.

Consultar cantor/banda Buscar musica pelo Usuário cadastrado,

cantor/banda administrador e visitante

Consultar gênero da Buscar música pelo gênero Usuário cadastrado,

música administrador e visitante
 24

Consultar história da Busca no banco de dados das Usuário cadastrado,

música pela temática da historias aquelas que administrador e visitante
história apresentam o mesmo tema que
o digitado pelo usuário e
apresenta uma lista de
resultados.

Exemplo tema: 2ª Guerra,

Separação, Fé.

Visualizar música Após, realizada a consulta da Usuário cadastrado,

música, na lista de resultados administrador e visitante
será escolhido o resultado que
corresponde ao interesse do
usuário para ser efetuada a
visualização da música.

Visualizar história da Após, realizada a consulta da Usuário cadastrado,

música história da música, na lista de administrador e visitante
resultados será escolhido o
resultado que corresponde ao
interesse do usuário para ser
efetuada a visualização da
história da música

Editar postagem Modificar postagem cadastrada Usuário

pelo usuário cadastrado(responsável pela
postagem)

Excluir postagem Excluir a postagem cadastrada Usuário

pelo usuário cadastrado(responsável pela
postagem) e administrador

Indicar site Indicar site através de e-mail Usuário cadastrado e visitante

Avaliação do site Avaliar conteúdo do site Usuário cadastrado

DIAGRAMA DE CASO DE USO DE NEGÓCIO

25
 26

DIAGRAMA DE ATIVIDADE DO NEGÓCIO

 27

DIAGRAMA DE CLASSE
28
 29

DIAGRAMA DE CASO DE USO DE SOFTWARE

Usuário Visitante
30
 31

CADASTRADO USUÁRIO
 32

DESCRIÇÃO DE CASOS DE USO

Nome do Caso de Uso Cadastrar Visitante

Caso de Uso Geral

Ator Principal Usuário visitante

Resumo Esse Caso de Uso descreve as etapas

percorridas por um usuário visitante para
se cadastrar no sistema

Fluxo Principal

Ações do Ator Ações do Sistema

1. Usuário acessa o site como visitante

2. Usuário solicita novo cadastro

3. Sistema pede para que o usuário

preencha os campos solicitados

4. O Usuário preenche os campos

solicitados

5. O Sistema analisa os dados dos campos

preenchidos

5.1 O Sistema verifica o login inserido

pelo usuário

6. O Sistema grava os dados do usuário

7. O Sistema loga o usuário no site

Fluxo Alternativo

Ações do Ator Ações do Sistema

5.a Se os campos obrigatórios não

estiverem sido preenchidos, o sistema
exibe mensagem de erro e retorna ao
passo 3

5.1a Se o login inserido pelo usuário já

pertencer a algum usuário cadastrado o
 33

sistema exibe uma mensagem e retorna ao

passo 3
 34

Nome do Caso de Uso Cadastrar Cantor/banda

Caso de Uso Geral

Ator Principal Usuário Cadastrado

Ator Secundário Usuário Visitante

Resumo Esse Caso de Uso descreve as etapas

percorridas pelo usuário cadastrado para
cadastrar um cantor/banda

Pré-condições O usuário estar logado no sistema

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita o cadastro de um

novo cantor/banda

2. O Sistema verifica se o usuário está

logado

3. O Sistema pede para que o usuário

preencha os campos solicitados.

4. O usuário preenche os campos

solicitados

5. O Sistema analisa os dados dos campos

preenchidos.

5.1 O Sistema verifica se o nome do

cantor/banda já está cadastrado

6. O Sistema grava o novo cantor/banda

cadastrado

7. O Sistema finaliza o cadastro

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário não estiver logado o

sistema chama o Caso de Uso Efetuar
Login
 35

5.a Se algum dos campos obrigatórios não

estejam preenchidos o sistema exibe a
mensagem e retorna ao passo 3

5.1a Se o nome do cantor/banda inserido

pelo usuário já pertencer a algum cadastro
o sistema exibe uma mensagem e vai para
o passo 7
 36

Nome do Caso de Uso Cadastrar gênero da música

Caso de Uso Geral

Ator Principal Usuário Cadastrado

Resumo Esse Caso de Uso descreve as etapas

percorridas por um usuário para cadastrar
um novo gênero de música

Pré-condições O Usuário deve estar cadastrado no

sistema

Fluxo Principal

Ações do Ator Ações do Sistema

1. O Usuário solicita o cadastro de um

novo gênero de música

2. O sistema verifica se o usuário está

logado

3. O sistema pede para que o usuário

preencha os campos solicitados

4. O usuário preenche os dados solicitados

5. O sistema analisa os dados

5.1 O sistema verifica se o gênero já está

cadastrado

6. O sistema grava os dados do novo

gênero

7. O sistema finaliza o cadastro

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário não estiver logado o

sistema solicita ao usuário que se logue

5.a Se algum dos campos obrigatórios não

tiver sido preenchido, o sistema exibe a
mensagem e retorna ao passo 3
 37

5.1a Se o nome do gênero dado pelo

usuário já pertença a algum cadastro o
sistema exibe uma mensagem e direciona
para o passo 7
 38

Nome do Caso de Uso Cadastrar música

Caso de Uso Geral

Ator Principal Usuário cadastrado

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário para realizar o
cadastro de músicas

Pré-condições O usuário precisa estar logado

Fluxo Principal

Ações do Ator Ações do Sistema

1.O usuário solicita o cadastro de uma

nova música

2. O sistema verifica se o usuário está

logado

3. O sistema pede para que o usuário

preenche os campos solicitados

4. O usuário preenche os campos

solicitados

5. O sistema analisa os dados

5.1 O sistema verifica se o conjunto de

dados(nome, artista, gênero) que
caracterizarão a música para verificar se
aquela música já está cadastrada

5.2 O sistema abre caixa de texto para

inserir a história da música

6. O sistema grava os dados da nova

música

7. O sistema finaliza o cadastro

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário não esteja logado o

 39

sistema solicita ao usuário que se logue

5.a Se algum dos campos obrigatórios não

tenha sido preenchido, o sistema exibe a
mensagem e retorna ao passo 3

5.1a Se o gênero ou artista da música

ainda não esteja cadastrado o sistema
solicita o cadastro

5.1b Se a música dada pelo usuário já

pertença a algum cadastro, o sistema exibe
uma mensagem e vai para o passo 7
 40

Nome do Caso de Uso Cadastrar comentário

Caso de Uso Geral

Ator Principal Usuário cadastrado

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário cadastrado para
cadastrar comentário resposta

Fluxo Principal

Ações do Ator Ações do Sistema

1. Usuário solicita o cadastro de um novo

comentário resposta

2. O sistema verifica se o usuário está

logado

3. O sistema pede para que o usuário

digite o comentário resposta

4. O usuário digita o comentário resposta

5. O sistema grava o comentário reposta

6. O sistema envia mensagem aos

mediadores para que possam revisar o
comentário

7. O sistema finaliza o cadastro

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário não estiver logado o

sistema solicita ao usuário que se logue
 41

Nome do Caso de Uso Editar postagem

Caso de Uso Geral

Ator Principal Usuário cadastro

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário que deseja editar
postagem

Fluxo Principal

Pré-condições O usuário deve estar logado

O usuário que deseja editar deve ser o

mesmo que postou

Ações do Ator Ações do Sistema

1. O usuário solicita a edição da postagem

2. O sistema verifica se o usuário que

solicitou a edição é o mesmo que fez a
postagem

3. O sistema abre edição para o usuário

4. Usuário edita postagem

5.Usuário solicita que o sistema grave a

edição

6. O sistema grava a edição

7. O sistema finaliza a edição

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário que solicita a edição não

for o que cadastrou a postagem, o sistema
segue para o passo 7.

Nome do Caso de Uso Excluir postagem

Caso de Uso Geral

 42

Ator Principal Usuário cadastrado e moderador

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário para excluir uma
postagem

Pré-condições Usuário deve estar logado

Usuário deve ser o mesmo que realizou a

postagem

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário ou administrador solicita

exclusão da postagem

2. Sistema verifica se o usuário que

solicita a exclusão é o mesmo que fez a
postagem ou um administrador

3. Sistema exclui a postagem

4.Sistema finaliza o caso de uso

Fluxo alternativo

Ações do Ator Ações do Sistema

2.a Se o usuário que solicita a edição não

for que cadastrou a postagem, o sistema
segue para o passo 4
 43

Nome do Caso de Uso Realizar a consulta no site

Caso de Uso Geral

Ator Principal Usuário

Resumo Esse caso de uso descreve as etapas que o

usuário vai percorrer para realizar
consulta no site

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita consulta

2. O sistema solicita que o usuário

preencha os campos da consulta

3. O usuário preenche os campos

solicitados

4. O sistema realiza consulta

5. O sistema apresenta resultados da

consulta na tela
 44

Nome do Caso de Uso Visualizar consulta no site

Caso de Uso Geral

Ator Principal Usuário

Resumo Esse caso de uso descreve as etapas que o

usuário vai percorrer para realizar
consulta no site

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita a visualização de um

dos resultados da consulta apresentados na
tela

2. Sistema apresenta visualização para o

usuário
 45

Nome do Caso de Uso Realizar login

Caso de Uso Geral

Ator Principal Usuário cadastrado

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário para efetuar login

Pré-condições O usuário deve estar cadastrado

Fluxo Principal

Ações de Ator Ações do Sistema

1. O usuário solicita login no sistema 1.1 O sistema solicita o login no sistema

2. O sistema solicita que o usuário

preencha os campos de usuário e senha

3. O sistema autentica usuário

4. O sistema finaliza login

Fluxo Alternativo

Ações do Ator Ações do Sistema

2.a O usuário avisa ao sistema que não

possui login

2.a1 O sistema redireciona o usuário para

seção de cadastro

2.a2 O sistema retorna ao passo 2 do fluxo

principal

3a. Se o usuário não estiver autenticado,

retorna ao passo 2
 46

Nome do Caso de Uso Realizar logout

Caso de Uso Geral

Ator Principal Usuário logado

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário quando realizar
logout

Pré-condições O usuário deve estar logado

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita ao sistema logaut

2. O sistema realiza logout do usuário

 47

Nome do Caso de Uso Avaliação do site

Caso de Uso Geral

Ator Principal Usuário cadastrado

Resumo Esse caso de uso descreve as etapas

percorridas pelo usuário para efetuar
avaliação do site

Pré-condições O usuário deve estar cadastrado

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita avaliação do site

2. O sistema abre campo de avaliação e

solicita preenchimento

3. O usuário preenche a avaliação

4. O sistema grava os dados

5. O sistema finaliza a avaliação do site

 48

Nome do Caso de Uso Indicar site

Caso de Uso Geral

Ator Principal Usuário

Resumo Esse caso de uso descreve as etapas

percorridas por um usuário que deseja
indicar o site

Fluxo Principal

Ações do Ator Ações do Sistema

1. O usuário solicita indicação do site

2. O sistema abre campo de indicação

3. O usuário preenche o e-mail da pessoa

para a qual ele vai indicar o site

4. O sistema envia e-mail com mensagem

de indicação

5. O sistema finaliza caso de uso

 49

DOCUMENTO VISÃO

ESTUDO DE CASO DE ANÁLISE ORIENTADA A OBJETOS PARA SISTEMA WEB

VOLTADOS PARA CADASTRO E CONSULTA DE HISTÓRIA DE MÚSICAS.

Documento Visão

Bruna Vaz Vieira

Bruninhaerosmith@gmail.com

DIEGO REIS CARDOSO

Reiscardoso.diego@gmail.com

JOÃO PAULO OLIVEIRA SANTOS

Oliveirajp77@gmail.com

JULIANE SANTIAGO SILVA

Ju.santiago08@hotmail.com

LARISSA MYLENA MORAES

Larissa.mmoraes@hotmail.com
 50

INTRODUÇÃO

A ausência de um sistema web capaz de conter informações completas de musicas faz

com que os interessados percam tempo em diversas buscas para conseguir reunir todas as
informações que forem necessárias para sua pesquisa, . Além do tempo gasto, pode em alguns
casos não é encontrado o que se procura.
A fim de facilitar esse tipo de pesquisa na internet o presente projeto visa desenvolver
um sistema web que atenda as necessidades dos interessados e que os usuários possam interagir
com o sistema de forma efetiva cadastrando informações de musicas bandas histórias para
facilitar a pesquisa de visitantes.

OBJETIVO

Buscamos desenvolver um sistema web onde o usuário possa partilhar os seus

conhecimentos a respeito das musicas, sendo que o mesmo poderá cadastrar história, bandas,
letras e diversas informações a cerca das musicas. Na ausência de um sistema web com essas
características e entendendo a sua importância na área acadêmica e cultural o presente projeto
tem como objetivo reunir diversas informações a respeito de musicas para oferecer aos usuários e
visitantes informações completas e também a possibilidade de acrescentar informações a respeito
das mesmas.

SISTEMAS SIMILARES

Não existem sistemas similares na web

 51

PROBLEMA

O problema é A não existência de um sistema que possibilite o

armazenamento de dados que constem todas as
informações desde o tema ao contexto histórico de
músicas o que faz com que pesquisadores percam tempo
realizando varias pesquisas, em diversas páginas, para
conseguir obter as informações necessárias.
Afeta A realização de pesquisas completas a respeito de músicas e
todo o seu contexto.

A agilidade na obtenção de informações de bandas e da

história das músicas. 

A divulgação da mensagem que a banda quer passar através da

música.

O impacto é Dificuldade de obter informações por parte de

pesquisadores.

Uma divulgação incompleta da história do trabalho realizado

pelo compositor

Uma solução satisfatória Um sistema web capaz de:

seria
Cadastrar as canções. Cadastrar a histórias das canções.
Fornecer informações rápidas a respeito das músicas.

Disponibilizar aos pesquisadores as informações a respeito da

banda, gênero, contexto histórico, compositor.

Armazenamento e recuperação rápida de informações.

Manter os dados dos usuários sempre atualizados.

 52

PRODUTO

História da Sistema web voltado para cadastro e consulta de história de músicas.

musica

Que Auxilie bandas e compositores a divulgarem os seus trabalhos e auxiliem

pesquisadores a encontrarem em um só sistema toda a história da música e aos
usuários postarem suas observações.

Difere Oferece mecanismos que auxiliam na pesquisa e na postagem de histórias de

musicas e que permitem armazenar estes dados. Mantém a segurança das
informações dos usuários cadastrados e obtendo-as de forma rápida e eficiente
sempre que necessário.

Oferece aos pesquisadores a possibilidade de encontrar em um só sistema web

todas as informações das músicas também de forma rápida e eficiente.

Produto Deverá facilitar a busca por informações a respeito das canções. Também a
proposto postagem de informações da historia e a armazenagem destes dados.

Manter cadastro de canções e temas de forma organizada e de fácil acesso.

Oportunidad As buscas terão condições de ser infinitamente mais veloz, uma vez que
e de todo o processo de procura será de fácil entendimento.
melhoria
 53

Clientes e usuários

Clientes

Descrever os clientes

Nome Representa Papel

Administrador Administrador do Organizar as informações
sistema enviadas pelos usuários e
avaliar cada uma delas para
que possam ser postadas no
site.

Usuários

Os usuários são as pessoas que, de fato, interagem com o sistema web e que fornecem as
informações a serem postadas. Eles estão classificados nas categorias abaixo.

Categoria Papel
Atores Humanos
Usuários logados N1: Cadastrar-se
N2: Fornecer conteúdo ao site.
N3: Cadastrar bandas, histórias, músicas,
gênero, letra, compositores e comentários.
N4: Consultar as postagens.
Administrador N5: Visualiza todo o conteúdo do site e pode
moderá-lo como julgar adequado,
moderando postagens e administrar todo o
sistema.

Ambiente do usuário
 54

Computador, Servidor, acesso a Internet

Perfis de usuários

Usuários com computadores que tenham acesso a internet.

Necessidades dos usuários

N1: Oferecer dados para o cadastro de usuários.

C1: Manter os dados pessoais atualizados.
N2: Oferecer conteúdo ao site
C2: Cadastrar os conteúdos a cerca das musicas postadas para oferecer informações
a pesquisadores.
N3: Cadastrar banda, gênero, músicas, historias, letra, comentários e compositores.
C3: registrar no site informações importantes sobre as musicas para que facilite
assim as pesquisas de visitantes.

Características da História da musica

C1: Oferecer aos interessados a possibilidade de cadastrar-se

C2: Oferecer ao usuário logado a possibilidade de inserir conteúdos no site, seja este
referente às músicas, autores e histórias.
C3: Propiciar uma forma desses usuários do site interagirem entre si trocando
experiências e opiniões a respeito do conteúdo.
C4: Oferecer aos visitantes um ambiente onde estes possam promover pesquisas a
respeito das músicas, bandas, suas histórias
 55

GLOSSÁRIO DE ATRIBUTOS

Classe: Usuário

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação do usuário

Nome Texto 50 Nome do usuário

Sobrenome Texto 50 Sobrenome do usuário

DataNascimento Data Grava a data de nascimento do usuário. Com formato de

mascara de: dd/mm/aaa

Login Texto 20 Guarda o login único que o usuário vai acessar o site.

Senha Texto 30 Guarda a senha que o usuário vai ter para acessar o site.

Classe: Cantor/Banda

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação da banda

Nome Texto 50 Nome do cantor/banda

HistoriaDaBanda Texto 500 Grava a historia da banda

Classe: Musica

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação da música

Nome Texto 50 Nome da música

Interprete CantorBanda Cantor banda que interpreta a musica

 56

Classe: Gênero

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação do gênero

Nome Texto 50 Nome do gênero

Descriçao Texto 300 Descrição do gênero

Classe: Historia

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação da história

Titulo Texto 50 Titulo da historia

Historia Texto 1000 História da música

Classe: Postagem

Atributo Tipo Tamanho Descrição

codigo Inteiro Código único de identificação da postagem

Data Data Data da postagem no formato: dd/mm/aaaa

Historia Historia Historia da musica

Titulo Texto 50 Titulo da postagem

Usuário Usuário Usuário que cadastrou a postagem.

 57

GLOSSÁRIO DE MENSAGENS

Nº Mensagem

01 Cadastre-se!

02 Usuário cadastrado com sucesso!

03 Usuário excluído com sucesso!

04 Usuário e/ou senha incorretos.

05 Cantor/Banda cadastrado com sucesso!

06 Cantor/Banda excluído com sucesso!

07 Música cadastrada com sucesso!

08 Música excluída com sucesso!

09 História cadastrada com sucesso!

10 História excluída com sucesso!

11 Comentário cadastrado com sucesso!

12 Comentário excluído com sucesso!

13 Gênero cadastrado com sucesso!

14 Gênero excluído com sucesso!

15 O item pesquisado não foi encontrado.

16 Efetue login.
 58

REGRAS DE NEGÓCIO

Numero Regra

RN01 Somente usuários logados podem realizar os cadastros de música,

cantor/banda, gênero, história no site.

RN02 Somente o usuário que efetuou a postagem pode excluí-la.

RN03 Não poderá existir dois logins de usuários idênticos.

RN04 Não poderá existir duas bandas/artistas com mesmo nome.

RN05 Não poderá existir dois gêneros com mesmo nome.

 59

MODELO ENTIDADE – RELACIONAMENTO (MER)

 60

CONCLUSÃO

Explanaremos aqui nesta conclusão a importância do conhecimento adquirido desde o

momento em que escolhemos o ramo de negócio em que queríamos trabalhar, abrangendo o
contexto específico ou nicho do negócio focado, até todo o desenvolvimento do mesmo, a busca
pelo conhecimento necessário para desenvolver este projeto, bem como as experiências que
obtivemos com sua aplicação prática.
É chegado o momento de colocar em prática as teorias com as quais somos
bombardeados durante a graduação, selecionar e produzir conhecimento não é tarefa fácil, mas
ainda assim necessário.
O conceito de orientação a objetos é recente, mas largamente utilizado e difundido,
tendo assim uma vasta gama de material para pesquisa, pessoas com conhecimento para
compartilhá-lo em uma troca de experiências, por isso foi fundamental que tivéssemos a
orientação necessária pela nossa professora de Projeto de Graduação, que nos mostrou o caminho
para buscar informações, como solucionar os problemas encontrados e como crescer com as
dificuldades vencidas. Finalmente pudemos compreender como aplicar as técnicas da OO de
forma eficaz, utilizando para tanto ferramentas específicas como a UML.
A UML, é uma linguagem criada para oferecer subsídios para que possamos aplicar
as técnicas da OO de forma efetiva, através dos seus diagramas podemos modelar o entendimento
do negócio de forma inteligível para os projetistas e até para o usuário. Diagramas mais comuns e
que são eficazes na maioria dos casos como o diagrama de caso de uso, diagrama de classe, e até
mesmo diagrama de seqüência puderam ser bem estudados no nosso projeto, e finalmente
colocando em prática tal conhecimento foi possível entendermos como aplicar as regras da OO
através da UML, dificuldades foram encontradas mas, contudo com muito esforço e trabalho
foram superadas.
No tocante à tecnologia web foi maravilhoso trabalharmos com esta nova concepção,
para nós que estamos iniciando no área de desenvolvimento de software a engenharia de projetos
web oferece um ambiente um pouco mais complexo, o que exige ainda mais de nós atenção e
comprometimento. Foi extremamente proveitoso trabalharmos com tecnologias novas, buscarmos
novos recursos, entendermos como funciona a aplicação “por baixo das páginas” de HTML
 61

(Hypertext Markup Language) e isso nos deu uma nova visão do funcionamento da web, assim
como nos proveu meios de trabalharmos posteriormente com estas tecnologias ora conhecidas.
Ao analisarmos os efeitos deste trabalho em nossas vidas, pudemos constatar que o
crescimento não é mensurável, além do conhecimento acadêmico e profissional que adquirimos o
peso do mesmo em nossa vida pessoal, e o esforço de que dispomos para concluí-lo faz de nós
hoje pessoas mais maduras além de profissionais mais experientes, e com certeza ao concluirmos
nossa graduação sairemos prontos para enfrentar o mercado de trabalho que anseia por bons
profissionais de tecnologia.
 62

BIBLIOGRAFIA

PRESSMAN, Roger S. Engenharia de Software/Roger S. Pressman ; São Paulo: Pearson

Education do Brasil, 1995.

BEZERRA, Eduardo Princípios de Análise e Projeto de Sistemas com UML/ Eduardo Bezerra -
Rio de Janeiro: Elsevier, 2007, 2ª Reimpressão

SOMMERVILLE, Ian Engenharia de Software, 8ª edição / Ian Sommerville São Paulo: Pearson
Addison – Wesley, 2007.

Análise Orientada a Objetos - Evolução ou Revolução Resumo -

http://teobaldobh.spaces.live.com/blog/cns!397FD8C3C55E019F!151.entry, Acessado em 15 de
Junho de 2010.

Desenvolvimento de Sistema Web utilizando arquitetura em Três Camadas e Applets, Kanji Hara
Neto, Lucas G Nadalete, Fabio A. Gennari, Antonio A. Carneiro de Freitas

Programação Orientada ao Objeto: uma abordagem didática

http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html

Acessado em 17 de Junho de 2010.

UML - Linguagem de Modelagem Unificada Diagrama de Caso de Uso, Marcelo Nogueira,

http://www.delphibr.com.br/artigos/UML1.php.

Acessado em 05 de Junho de 2010.

 63

UML - Unified Modeling Language, João Carlos da Silva Junior,

http://www.scriptfacil.com.br/materia/694/UML/uml-unified-modeling-language.html

Acessado em 30 de Maio de 2010

 64

REFERÊNCIAS BIBLIOGRÁFICAS

PRESSMAN, Roger S. Engenharia de Software/Roger S. Pressman ; São Paulo: Pearson

Education do Brasil, 1995. Apud (COX 85).

BEZERRA, Eduardo Princípios de Análise e Projeto de Sistemas com UML/ Eduardo Bezerra -
Rio de Janeiro: Elsevier, 2007, 2ª Reimpressão

Sommerville, Ian

Engenharia de Software, 8ª edição / Ian Sommerville

São Paulo: Pearson Addison – Wesley, 2007.