Projeto Entregar

86
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

Transcript of Projeto Entregar

Page 1: Projeto Entregar

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

Page 2: Projeto Entregar

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

Page 3: Projeto Entregar

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

Page 4: Projeto Entregar

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,

Page 5: Projeto Entregar

4

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

Page 6: Projeto Entregar

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.

Page 7: Projeto Entregar

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;

Page 8: Projeto Entregar

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

Page 9: Projeto Entregar

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

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,

Page 10: Projeto Entregar

9

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.

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

Page 11: Projeto Entregar

10

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).

Page 12: Projeto Entregar

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

Page 13: Projeto Entregar

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

Page 14: Projeto Entregar

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:

Page 15: Projeto Entregar

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.

Page 16: Projeto Entregar

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.

Page 17: Projeto Entregar

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.

Page 18: Projeto Entregar

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.

Page 19: Projeto Entregar

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.

Page 20: Projeto Entregar

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,

Page 21: Projeto Entregar

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.

Page 22: Projeto Entregar

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;

Page 23: Projeto Entregar

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.

Page 24: Projeto Entregar

23

LISTA DE REQUISITOS

Nome Descrição Ator

Cadastrar usuário Cadastrar usuários que desejam contribuir com o site.

Visitante

Efetuar login Autenticar usuários cadastrados e administradores para terem acesso ao sistema e entrarem em sua página pessoal.

Usuário Cadastrado e administrador

Efetuar logout Finalizar a sessão dos usuários autenticados.

Usuário Cadastrado e administrador

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

Cadastrar cantor/banda Incluir cantor/banda que ainda não estejam no site

Usuário cadastrado e administrador

Cadastrar gênero da música

Incluir gêneros de músicas Usuário cadastrado e administrador

Cadastrar história da música

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

Cadastrar comentário (mini-forum)

Incluir comentário sobre as histórias das músicas

Usuário cadastrado

Consultar música Busca no banco de dados das s músicas cadastradas aquelas que apresentam o mesmo nome que o pesquisado pelo usuário e apresenta uma lista de resultados.

Usuário cadastrado, administrador e visitante

Consultar cantor/banda Buscar musica pelo cantor/banda

Usuário cadastrado, administrador e visitante

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

Page 25: Projeto Entregar

24

música administrador e visitante

Consultar história da música pela temática da história

Busca no banco de dados das historias aquelas que apresentam o mesmo tema que o digitado pelo usuário e apresenta uma lista de resultados.

Exemplo tema: 2ª Guerra, Separação, Fé.

Usuário cadastrado, administrador e visitante

Visualizar música Após, realizada a consulta da música, na lista de resultados será escolhido o resultado que corresponde ao interesse do usuário para ser efetuada a visualização da música.

Usuário cadastrado, administrador e visitante

Visualizar história da música

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

Usuário cadastrado, administrador e visitante

Editar postagem Modificar postagem cadastrada pelo usuário

Usuário cadastrado(responsável pela postagem)

Excluir postagem Excluir a postagem cadastrada pelo usuário

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

Page 26: Projeto Entregar

25

Page 27: Projeto Entregar

26

DIAGRAMA DE ATIVIDADE DO NEGÓCIO

Page 28: Projeto Entregar

28

DIAGRAMA DE CLASSE

Page 29: Projeto Entregar

29

Page 30: Projeto Entregar

30

DIAGRAMA DE CASO DE USO DE SOFTWARE

Usuário Visitante

Page 31: Projeto Entregar

31

CADASTRADO USUÁRIO

Page 32: Projeto Entregar

31

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

Page 33: Projeto Entregar

32

5.1a Se o login inserido pelo usuário já pertencer a algum usuário cadastrado o sistema exibe uma mensagem e retorna ao passo 3

Page 34: Projeto Entregar

33

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

Page 35: Projeto Entregar

34

Login

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

Page 36: Projeto Entregar

35

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

Page 37: Projeto Entregar

36

mensagem e retorna ao passo 3

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

Page 38: Projeto Entregar

37

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

Page 39: Projeto Entregar

38

2.a Se o usuário não esteja logado o 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

Page 40: Projeto Entregar

39

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

Page 41: Projeto Entregar

40

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

Page 42: Projeto Entregar

41

Caso de Uso Geral

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

Page 43: Projeto Entregar

42

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

Page 44: Projeto Entregar

43

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

Page 45: Projeto Entregar

44

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

Page 46: Projeto Entregar

45

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

Page 47: Projeto Entregar

46

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

Page 48: Projeto Entregar

47

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

Page 49: Projeto Entregar

48

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

[email protected]

DIEGO REIS CARDOSO

[email protected]

JOÃO PAULO OLIVEIRA SANTOS

[email protected]

JULIANE SANTIAGO SILVA

[email protected]

LARISSA MYLENA MORAES

[email protected]

Page 50: Projeto Entregar

49

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

Page 51: Projeto Entregar

50

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

seria

Um sistema web capaz de:

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.

Page 52: Projeto Entregar

51

PRODUTO

História da

musica

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

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

proposto

Deverá facilitar a busca por informações a respeito das canções. Também a

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

e de

melhoria

As buscas terão condições de ser infinitamente mais veloz, uma vez que

todo o processo de procura será de fácil entendimento.

Page 53: Projeto Entregar

52

Page 54: Projeto Entregar

53

Clientes e usuários

Clientes

Descrever os clientes

Nome Representa Papel

Administrador Administrador do

sistema

Organizar as informações

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 1:N Cadastrar-se

2:N Fornecer conteúdo ao site.

3:N Cadastrar bandas, histórias, músicas,

gênero, letra, compositores e comentários.

4:N Consultar as postagens.

Administrador 5:N Visualiza todo o conteúdo do site e pode

moderá-lo como julgar adequado,

moderando postagens e administrar todo o

sistema.

Page 55: Projeto Entregar

54

Ambiente do usuário

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

Page 56: Projeto Entregar

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

Page 57: Projeto Entregar

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.

Page 58: Projeto Entregar

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.

Page 59: Projeto Entregar

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.

Page 60: Projeto Entregar

59

MODELO ENTIDADE – RELACIONAMENTO (MER)

Page 61: Projeto Entregar

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

Page 62: Projeto Entregar

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.

Page 63: Projeto Entregar

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.

Page 64: Projeto Entregar

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

Page 65: Projeto Entregar

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.

Page 66: Projeto Entregar