Projeto Entregar
-
Upload
bruninhali -
Category
Documents
-
view
4.955 -
download
10
Transcript of 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
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
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,
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
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).
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 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,
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
25
26
DIAGRAMA DE ATIVIDADE DO NEGÓCIO
28
DIAGRAMA DE CLASSE
29
30
DIAGRAMA DE CASO DE USO DE SOFTWARE
Usuário Visitante
31
CADASTRADO USUÁRIO
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
DIEGO REIS CARDOSO
JOÃO PAULO OLIVEIRA SANTOS
JULIANE SANTIAGO SILVA
LARISSA MYLENA MORAES
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
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.
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.
52
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.
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
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.