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

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

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

nosso sistema vem aproveitar esse crescente mercado para popularizar o contexto presente nas canções. Além do grande potencial comercial que um site colaborativo acarreta.5 JUSTIFICATIVA O desenvolvimento de sistemas web está cada vez mais em evidência no mercado atual. 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. . 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. A ausência de um sistema nesse estilo na web. Escolhemos desenvolver um sistema onde usuários possam partilhar seus conhecimentos sobre música. e entendendo a sua importância na área acadêmica e cultural. Baseando na popularização da web colaborativa e das redes sociais. motivou a criação desse sistema. expressão de idéias e entretenimento.

 Aplicar os conhecimentos em análise OO e diagramas UML para o desenvolvimento da modelagem de um sistema web.  Implementar o sistema web modelado.6 OBJETIVOS OBJETIVO GERAL O objetivo principal desse projeto é a modelagem de um sistema web. OBJETIVOS ESPECÍFICOS  Entender como funciona a modelagem de um sistema web. suas características de desenvolvimento e implantar um sistema em que forneça aos usuários com afinidade e conhecimento por música. aplicando os conhecimentos acadêmicos adquiridos. utilizando a análise orientada a objetos e os diagramas UML. . vamos entender como funciona os sistemas web. meios para divulgar esse conhecimento a outros usuários e interagirem com eles. Como objetivo final.  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

Para a produção desses artefatos dispomos na UML 2. assim sendo.10 chamadas Física e Jurídica. data de nascimento. um metamodelo que otimiza métodos da OO. além de seguir um padrão único para o desenvolvimento. desde que seja bem documentada.Alex Ferreira). resultado que pode ser conseguido se aplicarmos corretamente seus métodos e ferramentas (diagramas). A modelagem de sistemas pode ser feita de várias maneiras. portanto são de grande compreensão por parte dos analistas e desenvolvedores. Segue abaixo um esquema que ilustra o quadro de evolução da UML desde o seu surgimento. ambas herdarão da classe Pessoa seus atributos e além destes a classe Física possuirá CPF.0 de 13 diagramas. enquanto a classe Jurídica possuirá CNPJ. em prol da boa prática de Engenharia de Software.3. data da criação. 2.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. . usam para tal os diagramas da UML. que nos oferece subsídios para a construção de aplicações consistentes e confiáveis. maioria quase absoluta dos projetistas que hoje desenvolvem sistemas. haja vista que no âmbito da UML esses documentos têm caráter gráfico e. e os reúne em uma única ³receita´ padrão. (Artigo Análise de Ferramentas de Modelagem UML Gratuitas . inscrição estadual entre outros. os documentos produzidos através das ferramentas e metodologias da Linguagem de Modelagem Unificada são denominados artefatos de software. 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. Diagramas são ferramentas gráficas usadas para que possamos visualizar o sistema sob várias perspectivas.

ou seja. classes e relacionamentos constituem os elementos sintáticos básicos do diagrama de classes (SILVA. como elas se comportam e desenvolvem suas tarefas em um ambiente integrado com as demais classes.2 DIAGRAMA DE CLASSES Após identificadas as classes do sistema. após serem preenchidos os seus atributos. é o diagrama mais importante da UML. O diagrama de classes é fundamental em uma especificação OO. representamos todas elas em um modelo onde são expostas as classes e seus relacionamentos. obviamente depende da elaboração do próprio diagrama de classes. 2007).3. Semelhante ao diagrama de .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. 2.11 Figura XX ± Evolução da UML 2.3.

em que o primeiro contém o nome do objeto e o segundo os atributos com seus respectivos valores. Figura XX ± Diagrama de Objetos 2. Segundo Page-Jones (2001) o diagrama de pacotes possui a finalidade de organizar os elementos em módulos. conforme exemplifica a figura XX. Tem como proposta apresentar a modelagem estrutural do sistema em divisões lógicas e suas interações em alto nível. estes que por sua vez representam coleção de classes. Segundo Furlan (1998) o diagrama mostra os objetos e como se relacionam entre si em um dado espaço de tempo. um retângulo com duas divisões. mostrando suas .3.12 classes.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. Com o objetivo de descrever um conjunto de objetos e seus relacionamentos em um dado espaço de tempo. porém representa instâncias e ligações entre as instâncias. sendo que sua representação é similar à de uma classe.

essas colaborações são descritas pela visão de cooperação de um conjunto de elementos (instâncias). Também pode ser aplicado em bibliotecas adquiridas ou aplicação com características relativas. Figura XX ± Exemplo de Diagrama de Pacotes. Evidencia demonstrar colaborações.13 dependências.3. que interagem entre si para executar uma função específica. Exemplo: . 2.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. figura XX.

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

tarefas. tomemos como exemplo um sistema bancário seriam os servidores. . quais são os atores que participam dessa tarefa. Para descrever esse cenário dispomos de uma representação gráfica da UML chamada Diagrama de Caso de Uso. dado um elaborado sistema de software.Comunicação dos próprios atores com o sistema. este demonstra a relação entre atores e as funcionalidades do software. máquinas envolvidas. e assim modelarmos um bom projeto. o diagrama de implantação expressa o aparelho de hardware e toda a tecnologia física relacionada com a instalação do sistema. Este pode ser uma máquina. seria como se um pessoa o observasse sob uma perspectiva de fora. o ator solicita um serviço que é o caso de uso. Fornece uma visão estática e externa do funcionamento do sistema. e qual é o relacionamento desse ator com essa tarefa. seja topologia e protocolos de rede. como se estivesse assistindo seu funcionamento sem participar dele. 2. y Caso de Uso ± é a própria interação entre o usuário e o sistema. dispositivos e até outros sistemas.agente que interage com o sistema. mais que apenas pessoas ou indivíduos e sim na verdade o papel que por essa entidade é executada no processo. relacionamentos. painéis de comunicação com os clientes e demais. uma pessoa. O diagrama de caso de uso apresenta os seguintes componentes básicos: y Ator .3. ou seja. Nessa atividade de identificação é essencial que conheçamos quais são as tarefas a serem realizadas pelo software. essa interação se dá a partir da troca de mensagens entre os atores e o sistema. generalizações e associações entre os elementos do sistema. os terminais onde se imprimem as senhas.7 DIAGRAMA DE IMPLANTAÇÃO Determina os requisitos físicos necessários a execução do sistema computacional. apenas identificando atores. os caixas eletrônicos.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.15 2. e o executa. este que é um serviço disponibilizado pelo sistema.3. y Interação .

ou seja. quando uma função em um determinado local. é penoso e complicado de entender o fluxo de controle em um programa orientado a objetos.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. demonstrando sua existência por vez da execução de uma dada seqüência. ou seja. y Ativação ± determina o tempo que estará executando uma ação. elevação explícita de eventos e mais. determinado qual a ordem desempenhadas pelas mensagens que são emitidas pelos objetos. . quem é o ator que executa esse método e como esse microprocesso se desenrola dentro desse macro processo. y Autodelegação ± de caráter recursivo. Mostra a troca de mensagens entre os objetos do sistema. 2. estas por sua vez podem ser casos de uso. y Mensagem ± determina como os objetos se comunicam.16 y Sistema ± é o conjunto de elementos unidos que trabalham harmonicamente com o intuito de produzir um objetivo único e comum entre todos. dependendo do contexto do processo analisado.chama a si própria para se executar. envio de sinal entre linhas ativas. são várias as formas. ou subtarefas. uma vez que o modelo terá diversas operações elementares que confundem a seqüência geral do comportamento. Segundo Furlan (1998). 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. definindo precisamente a ordem em que são emitidas as mensagens e o momento em que são expedidas.3. dentre elas: chamada de procedimento. Ainda de acordo com Furlan (1998) este diagrama possui os seguintes componentes básicos: y Linha da vida ± evidencia um objeto desenhado com uma linha pontilhada. Identifica quem é o objeto que emite uma mensagem.

. Acompanha os estados por quais passa um objeto.17 2.3. e como podem se comportar ao receber estímulos de outros autômatos. 2. exceto que nesse o foco é em como os objetos de um processo estão vinculados entre si. registra as mudanças sofridas por um objeto em um contexto de um determinado processo. com objetos semelhantes. Como é exemplificado na Figura XX. uma vez que no diagrama de seqüência existe uma preocupação no sentido de se averiguar a temporalidade das tarefas.11 DIAGRAMA DE COMUNICAÇÃO Complemento do diagrama de seqüência esse diagrama.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. Como exemplo. 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. apresentamos a Figura XX abaixo: Figura XX ± Exemplo de Diagrama de Máquina de Estados. e quais são as mensagens por eles trocadas.

A exemplo de um fluxograma. 2. ou seja. que não aceite o prosseguimento. mesmo que sejam traçados caminhos paralelos estes estarão previstos no diagrama de atividades.18 Figura XX ± Exemplo de Diagrama de Comunicação.3. 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. finalizando assim a tarefa. . ou seja. o caminho percorrido ao se executar uma operação. imediatamente se começa outra no contexto da atividade expressada pelo diagrama. já a atividade pode ser particionada em várias ações. O termo ação oferece uma idéia de atomicidade.12 DIAGRAMA DE ATIVIDADES Esse modelo de diagramas ilustra como as informações trafegam dentro de um objeto. indivisibilidade uma coisa que não pode ser mais fragmentada. O prosseguimento das execuções dá-se da seguinte maneira: ao se terminar uma ação.

e consiste em monitorar as restrições temporais do sistema. ilustra a interação do sistema como um todo. do funcionamento global do sistema. e até seu papel.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. 2. que ilustra o fluxo de controle geral do sistema. consultas e emissão de relatórios. uma atividade de cadastro. como por exemplo. Modela a interação e a evolução de estados. mas mesmo assim um projeto de aplicação web segue processos um pouco diferentes. 2. usado freqüentemente para expressar como um dado objeto se comporta durante certo tempo em resposta a eventos externos. como cadastros. que mostra o fluxo de um subsistema. existem ferramentas que auxiliam de uma maneira mais adequada o desenvolvimento desse tipo de aplicação.3. entre todos os subsistemas ou funcionalidades. . de forma geral.3. Pode reger-se pelos princípios da OO e ter seu processo de modelagem elaborado e apoiado por ferramentas da UML. condição. assim sendo se faz necessário que apresentemos os fundamentos da tecnologia web. de forma similar ao modelo expresso pelo diagrama de atividades. além de suas regras de negócio obedecerem a outras legislações e particularidades. monitorado através desse diagrama durante um determinado espaço de tempo.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. De acordo com Melo (2004) o Diagrama de Visão Geral é uma variação do diagrama de atividades. E o diagrama de interação geral. ou de uma dada funcionalidade em questão.19 2.14 DIAGRAMA DE TEMPORIZAÇÃO Objetos instanciados a partir de classes do sistema poderão ter suas mudanças de estado. Contudo.

porém não existe uma metodologia que seja específica para o desenvolvimento de aplicações web. Metodologias empregadas com sucesso ontem podem não oferecer resultados satisfatórios hoje. e com a engenharia de software não é diferente. todo o ciclo de desenvolvimento deve ser organizado e bem definido para que tudo sejam produzido e entregue no prazo. é preciso ter a visão do negócio como um todo. Com a engenharia de sites também é assim. Desenvolver softwares hoje em dia é mais que apenas programar os componentes de código. padrões e conceitos. em sua abordagem global é semelhante a uma aplicação desktop.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. usamos modelos de processo pré-definidos sem contudo desprezar novas tecnologias. .

 Cadastro de Música: Função responsável pela inclusão de uma nova música. sendo que a consulta poderá ser realizada utilizando os seguintes filtros: músicas. gêneros e versões de histórias das músicas. história.  Consulta: Função responsável pela consulta nos cadastros. músicas. As principais funções do sistema serão:  Cadastro Usuário: Função responsável pela inclusão de um novo usuário. histórias das músicas e bandas/artista.  Alteração de Música: Função responsável pela alteração dos dados das músicas cadastradas.  Exclusão de Usuário: Função responsável pela exclusão de usuário cadastro. escolhemos desenvolver um Sistema web que visa o cadastro e armazenamento dos internautas (usuários).  Exclusão de História: Função responsável pela exclusão de histórias de músicas cadastradas com algum erro.21 ESTUDO DE CASO Modelagem do Negócio Com o objetivo principal de criar um site colaborativo de música.  Alteração da História: Função responsável pela alteração dos dados das histórias das músicas cadastradas. autores.  Cadastro de História: Função responsável pela inclusão de uma nova história.  Alteração Usuário: Função responsável pela alteração dos dados dos usuários cadastrados. .  Avaliação: Função responsável pela avaliação do conteúdo será utilizado o sistema de estrelas.  Cadastro de Artista: Função responsável pela inclusão de um novo artista.  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.  Visualização: Função responsável pela visualização de algum resultado da consulta. artista. música.  Alteração de Artista: Função responsável pela alteração dos dados dos artistas cadastrados.

eles terão acesso a todos os cadastros com permissão para a realização de todas as funções do sistema. pois ele não apresenta requisitos tão claros e definidos. terão a restrição de realizá-las apenas nos conteúdos que o próprio usuário cadastrou.  Usuários: Eles terão acesso a todas as funções do sistema. Terão função de moderação. O processo de desenvolvimento do sistema será baseado no ciclo de vida evolutivo. Alteração e Exclusão.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. e estará sempre passando por validação e evolução. caso queira realizar as demais funções será solicitada a realização de cadastro. . mas nas funções de Cadastro.  Visitantes: Terão acesso apenas às funções de busca e visualização. O sistema apresenta três tipos básicos de usuários:  Administradores: Responsáveis pela administração do sistema.

Buscar musica cantor/banda pelo Usuário cadastrado. Autenticar usuários Usuário Cadastrado administrador cadastrados e administradores para terem acesso ao sistema e entrarem em sua página pessoal. administrador e visitante Consultar cantor/banda . administrador Incluir música no site Usuário Cadastrado administrador e Efetuar login Efetuar logout Cadastrar Música Cadastrar cantor/banda Cadastrar música gênero e e e e e Incluir cantor/banda que ainda Usuário cadastrado não estejam no site administrador Usuário cadastrado administrador Usuário cadastrado administrador da Incluir gêneros de músicas Cadastrar história da Incluir história da música música Cadastrar comentário Incluir comentário sobre as Usuário cadastrado histórias das músicas (mini-forum) Consultar música Busca no banco de dados das s Usuário cadastrado. músicas cadastradas aquelas administrador e visitante que apresentam o mesmo nome que o pesquisado pelo usuário e apresenta uma lista de resultados. Finalizar a sessão dos usuários Usuário Cadastrado autenticados.23 LISTA DE REQUISITOS Nome Cadastrar usuário Descrição Ator Cadastrar usuários que Visitante desejam contribuir com o site.

Exemplo tema: 2ª Guerra. na lista de resultados administrador e visitante será escolhido o resultado que corresponde ao interesse do usuário para ser efetuada a visualização da música. Visualizar história da Após. Visualizar música Após. realizada a consulta da Usuário cadastrado.24 Consultar música gênero da Buscar música pelo gênero Usuário cadastrado. na lista de administrador e visitante resultados será escolhido o resultado que corresponde ao interesse do usuário para ser efetuada a visualização da história da música Editar postagem Modificar postagem cadastrada Usuário pelo usuário cadastrado(responsável postagem) pela Excluir postagem Excluir a postagem cadastrada Usuário pelo usuário cadastrado(responsável pela postagem) e administrador Indicar site através de e-mail Avaliar conteúdo do site Usuário cadastrado e visitante Usuário cadastrado Indicar site Avaliação do site . Fé. administrador e visitante cadastrado. Separação. cadastrado. Consultar história da Busca no banco de dados das Usuário aquelas que administrador e visitante música pela temática da historias apresentam o mesmo tema que história o digitado pelo usuário e apresenta uma lista de resultados. música. realizada a consulta da Usuário música história da música.

25 DIAGRAMA DE CASO DE USO DE NEGÓCIO .

26 .

27 DIAGRAMA DE ATIVIDADE DO NEGÓCIO .

28 DIAGRAMA DE CLASSE .

29 DIAGRAMA DE CASO DE USO DE SOFTWARE Usuário Visitante .

30 CADASTRADO USUÁRIO .

O Sistema analisa os dados dos campos preenchidos 5. Usuário acessa o site como visitante 2. o sistema exibe mensagem de erro e retorna ao passo 3 Ações do Sistema . O Sistema grava os dados do usuário 7.1 O Sistema verifica o login inserido pelo usuário 6. Usuário solicita novo cadastro 3. O Sistema loga o usuário no site Fluxo Alternativo Ações do Ator Ações do Sistema 5. O Usuário solicitados preenche os campos 5. Sistema pede para que o usuário preencha os campos solicitados 4.a Se os campos obrigatórios não estiverem sido preenchidos.31 DESCRIÇÃO DE CASOS DE USO Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Cadastrar Visitante Usuário visitante Esse Caso de Uso descreve as etapas percorridas por um usuário visitante para se cadastrar no sistema Fluxo Principal Ações do Ator 1.

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 .32 5.

O usuário solicitados preenche os campos 5. 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. O usuário solicita o cadastro de um novo cantor/banda Ações do Sistema 2. 4.33 Nome do Caso de Uso Caso de Uso Geral Ator Principal Ator Secundário Resumo Cadastrar Cantor/banda Usuário Cadastrado Usuário Visitante Esse Caso de Uso descreve as etapas percorridas pelo usuário cadastrado para cadastrar um cantor/banda O usuário estar logado no sistema Pré-condições Fluxo Principal Ações do Ator 1. 5. O Sistema analisa os dados dos campos preenchidos. O Sistema pede para que o usuário preencha os campos solicitados.1 O Sistema verifica se o nome do cantor/banda já está cadastrado 6. O Sistema verifica se o usuário está logado 3.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 .

O sistema grava os dados do novo gênero 7. O sistema pede para que o usuário preencha os campos solicitados 4.1 O sistema verifica se o gênero já está cadastrado 6. o sistema exibe a . O sistema verifica se o usuário está logado 3. O sistema analisa os dados 5.35 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Cadastrar gênero da música Usuário Cadastrado Esse Caso de Uso descreve as etapas percorridas por um usuário para cadastrar um novo gênero de música O Usuário deve estar cadastrado no sistema Pré-condições Fluxo Principal Ações do Ator 1. O sistema finaliza o cadastro Fluxo Alternativo Ações do Ator Ações do Sistema 2. O usuário preenche os dados solicitados 5.a Se algum dos campos obrigatórios não tiver sido preenchido. O Usuário solicita o cadastro de um novo gênero de música Ações do Sistema 2.a Se o usuário não estiver logado o sistema solicita ao usuário que se logue 5.

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 .

gênero) que caracterizarão a música para verificar se aquela música já está cadastrada 5. O sistema verifica se o usuário está logado 3. O usuário solicitados preenche os campos 5. O sistema pede para que o usuário preenche os campos solicitados 4. O sistema finaliza o cadastro Fluxo Alternativo Ações do Ator Ações do Sistema . O sistema analisa os dados 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. artista.37 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Cadastrar música Usuário cadastrado Esse caso de uso descreve as etapas percorridas pelo usuário para realizar o cadastro de músicas O usuário precisa estar logado Pré-condições Fluxo Principal Ações do Ator 1.1 O sistema verifica se o conjunto de dados(nome.O usuário solicita o cadastro de uma nova música Ações do Sistema 2.

a Se o usuário não esteja logado o sistema solicita ao usuário que se logue 5.1b Se a música dada pelo usuário já pertença a algum cadastro. o sistema exibe a mensagem e retorna ao passo 3 5.38 2.a Se algum dos campos obrigatórios não tenha sido preenchido. o sistema exibe uma mensagem e vai para o passo 7 .1a Se o gênero ou artista da música ainda não esteja cadastrado o sistema solicita o cadastro 5.

O sistema verifica se o usuário está logado 3. O sistema envia mensagem aos mediadores para que possam revisar o comentário 7.a Se o usuário não estiver logado o sistema solicita ao usuário que se logue Ações do Sistema . O sistema finaliza o cadastro Fluxo Alternativo Ações do Ator Ações do Sistema 2. O usuário digita o comentário resposta 5. Usuário solicita o cadastro de um novo comentário resposta 2. O sistema grava o comentário reposta 6. O sistema pede para que o usuário digite o comentário resposta 4.39 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Cadastrar comentário Usuário cadastrado Esse caso de uso descreve as etapas percorridas pelo usuário cadastrado para cadastrar comentário resposta Fluxo Principal Ações do Ator 1.

a Se o usuário que solicita a edição não for o que cadastrou a postagem. O sistema grava a edição 7. o sistema segue para o passo 7. O sistema abre edição para o usuário 4. Usuário edita postagem 5. Ações do Sistema .Usuário solicita que o sistema grave a edição 6. O usuário solicita a edição da postagem 2.40 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Editar postagem Usuário cadastro 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 1. O sistema finaliza a edição Fluxo Alternativo Ações do Ator Ações do Sistema 2. O sistema verifica se o usuário que solicitou a edição é o mesmo que fez a postagem 3.

o sistema segue para o passo 4 Ações do Sistema . Sistema exclui a postagem 4.a Se o usuário que solicita a edição não for que cadastrou a postagem. O usuário ou administrador solicita exclusão da postagem 2.41 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Excluir postagem Usuário cadastrado e moderador Esse caso de uso descreve as etapas percorridas pelo usuário para excluir uma postagem Usuário deve estar logado Usuário deve ser o mesmo que realizou a postagem Pré-condições Fluxo Principal Ações do Ator 1.Sistema finaliza o caso de uso Fluxo alternativo Ações do Ator Ações do Sistema 2. Sistema verifica se o usuário que solicita a exclusão é o mesmo que fez a postagem ou um administrador 3.

O sistema solicita que o usuário preencha os campos da consulta 3. O sistema realiza consulta 5. O usuário solicita consulta 2.42 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Realizar a consulta no site Usuário Esse caso de uso descreve as etapas que o usuário vai percorrer para realizar consulta no site Fluxo Principal Ações do Ator 1. O usuário solicitados preenche os campos 4. O sistema apresenta resultados da consulta na tela Ações do Sistema .

O usuário solicita a visualização de um dos resultados da consulta apresentados na tela 2.43 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Visualizar consulta no site Usuário Esse caso de uso descreve as etapas que o usuário vai percorrer para realizar consulta no site Fluxo Principal Ações do Ator 1. Sistema apresenta visualização para o usuário Ações do Sistema .

a1 O sistema redireciona o usuário para seção de cadastro 2.a O usuário avisa ao sistema que não possui login 2. Se o usuário não estiver autenticado. O sistema finaliza login Fluxo Alternativo Ações do Ator 2. O sistema solicita que o usuário preencha os campos de usuário e senha 3.44 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Pré-condições Fluxo Principal Ações de Ator 1. O sistema autentica usuário 4. O usuário solicita login no sistema Realizar login Usuário cadastrado Esse caso de uso descreve as etapas percorridas pelo usuário para efetuar login O usuário deve estar cadastrado Ações do Sistema 1.a2 O sistema retorna ao passo 2 do fluxo principal 3a.1 O sistema solicita o login no sistema 2. retorna ao passo 2 Ações do Sistema .

O sistema realiza logout do usuário .45 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Realizar logout Usuário logado Esse caso de uso descreve as etapas percorridas pelo usuário quando realizar logout O usuário deve estar logado Pré-condições Fluxo Principal Ações do Ator 1. O usuário solicita ao sistema logaut Ações do Sistema 2.

46 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Avaliação do site Usuário cadastrado Esse caso de uso descreve as etapas percorridas pelo usuário para efetuar avaliação do site O usuário deve estar cadastrado Pré-condições Fluxo Principal Ações do Ator 1. O usuário preenche a avaliação 4. O sistema abre campo de avaliação e solicita preenchimento 3. O sistema finaliza a avaliação do site . O sistema grava os dados 5. O usuário solicita avaliação do site Ações do Sistema 2.

O sistema finaliza caso de uso Ações do Sistema . O sistema envia e-mail com mensagem de indicação 5.47 Nome do Caso de Uso Caso de Uso Geral Ator Principal Resumo Indicar site Usuário Esse caso de uso descreve as etapas percorridas por um usuário que deseja indicar o site Fluxo Principal Ações do Ator 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.

mmoraes@hotmail.com .santiago08@hotmail.com DIEGO REIS CARDOSO Reiscardoso.com JOÃO PAULO OLIVEIRA SANTOS Oliveirajp77@gmail.com JULIANE SANTIAGO SILVA Ju. Documento Visão Bruna Vaz Vieira Bruninhaerosmith@gmail.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.diego@gmail.com LARISSA MYLENA MORAES Larissa.

Além do tempo gasto. 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.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. 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. letras e diversas informações a cerca das musicas. sendo que o mesmo poderá cadastrar história. OBJETIVO Buscamos desenvolver um sistema web onde o usuário possa partilhar os seus conhecimentos a respeito das musicas. SISTEMAS SIMILARES Não existem sistemas similares na web . bandas. . pode em alguns casos não é encontrado o que se procura.

A divulgação da mensagem que a banda quer passar através da música. Uma divulgação incompleta da história do trabalho realizado pelo compositor Uma solução satisfatória Um sistema web capaz de: seria Cadastrar as canções. em diversas páginas. Disponibilizar aos pesquisadores as informações a respeito da banda. contexto histórico. Cadastrar a histórias das canções. compositor. gênero. Fornecer informações rápidas a respeito das músicas. para conseguir obter as informações necessárias. Armazenamento e recuperação rápida de informações.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. Manter os dados dos usuários sempre atualizados. O impacto é Dificuldade de obter informações por parte de pesquisadores. 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. .

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. Também a postagem de informações da historia e a armazenagem destes 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. Difere Oferece mecanismos que auxiliam na pesquisa e na postagem de histórias de musicas e que permitem armazenar estes dados. Oportunidad e melhoria As buscas terão condições de ser infinitamente mais veloz. . Produto proposto Deverá facilitar a busca por informações a respeito das canções. Manter cadastro de canções e temas de forma organizada e de fácil acesso. 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.51 PRODUTO História musica da Sistema web voltado para cadastro e consulta de história de músicas. uma vez que de todo o processo de procura será de fácil entendimento.

compositores e comentários. músicas. Eles estão classificados nas categorias abaixo. como julgar adequado. 2 Cadastrar Papel bandas. moderando postagens e administrar todo o . de fato. letra. 2 Consultar as postagens. Categoria Atores Humanos Usuários logados 2 Cadastrar-se 2 Fornecer conteúdo ao site. gênero. interagem com o sistema web e que fornecem as informações a serem postadas. histórias. Administrador 2 Visualiza todo o conteúdo do site e pode moderá-lo sistema. Usuários Os usuários são as pessoas que.52 Clientes e usuários Clientes Descrever os clientes Nome Administrador Representa Administrador sistema Papel do Organizar enviadas as pelos informações usuários e avaliar cada uma delas para que possam ser postadas no site.

53 Ambiente do usuário Computador. N2: Oferecer conteúdo ao site C2: Cadastrar os conteúdos a cerca das musicas postadas para oferecer informações a pesquisadores. C4: Oferecer aos visitantes um ambiente onde estes possam promover pesquisas a respeito das músicas. acesso a Internet Perfis de usuários Usuários com computadores que tenham acesso a internet. seja este referente às músicas. N3: Cadastrar banda. C3: Propiciar uma forma desses usuários do site interagirem entre si trocando experiências e opiniões a respeito do conteúdo. suas histórias . bandas. historias. C3: registrar no site informações importantes sobre as musicas para que facilite assim as pesquisas de visitantes. letra. músicas. comentários e compositores. gênero. Necessidades dos usuários N1: Oferecer dados para o cadastro de usuários. autores e histórias. Servidor. 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. C1: Manter os dados pessoais atualizados.

DataNascimento Data Login Senha Texto Texto Classe: Cantor/Banda Atributo codigo Nome Tipo Inteiro Texto 50 500 Tamanho Descrição Código único de identificação da banda Nome do cantor/banda Grava a historia da banda HistoriaDaBanda Texto Classe: Musica Atributo codigo Nome Tipo Inteiro Texto 50 Tamanho Descrição Código único de identificação da música Nome da música Cantor banda que interpreta a musica Interprete CantorBanda .54 GLOSSÁRIO DE ATRIBUTOS Classe: Usuário Atributo codigo Nome Sobrenome Tipo Inteiro Texto Texto 50 50 Tamanho Descrição Código único de identificação do usuário Nome do usuário Sobrenome do usuário Grava a data de nascimento do usuário. Guarda a senha que o usuário vai ter para acessar o site. Com formato de mascara de: dd/mm/aaa 20 30 Guarda o login único que o usuário vai acessar o site.

55 Classe: Gênero Atributo codigo Nome Descriçao Tipo Inteiro Texto Texto 50 300 Tamanho Descrição Código único de identificação do gênero Nome do gênero Descrição do gênero Classe: Historia Atributo Tipo codigo Titulo Historia Inteiro Texto Texto 50 1000 Tamanho Descrição Código único de identificação da história Titulo da historia História da música Classe: Postagem Atributo Tipo codigo Data Historia Titulo Usuário Inteiro Data Historia Texto Usuário 50 Tamanho Descrição Código único de identificação da postagem Data da postagem no formato: dd/mm/aaaa Historia da musica Titulo da postagem Usuário que cadastrou a postagem. .

Efetue login. Mensagem .56 GLOSSÁRIO DE MENSAGENS Nº 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 Cadastre-se! Usuário cadastrado com sucesso! Usuário excluído com sucesso! Usuário e/ou senha incorretos. Cantor/Banda cadastrado com sucesso! Cantor/Banda excluído com sucesso! Música cadastrada com sucesso! Música excluída com sucesso! História cadastrada com sucesso! História excluída com sucesso! Comentário cadastrado com sucesso! Comentário excluído com sucesso! Gênero cadastrado com sucesso! Gênero excluído com sucesso! O item pesquisado não foi encontrado.

Não poderá existir duas bandas/artistas com mesmo nome. Somente o usuário que efetuou a postagem pode excluí-la. gênero. Não poderá existir dois logins de usuários idênticos. . Não poderá existir dois gêneros com mesmo nome.57 REGRAS DE NEGÓCIO Numero RN01 RN02 RN03 RN04 RN05 Regra Somente usuários logados podem realizar os cadastros de música. cantor/banda. história no site.

58 MODELO ENTIDADE ± RELACIONAMENTO (MER) .

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

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

BEZERRA. Desenvolvimento de Sistema Web utilizando arquitetura em Três Camadas e Applets. Carneiro de Freitas Programação Orientada ao Objeto: uma http://www.live.Linguagem de Modelagem Unificada Diagrama de Caso de Uso.unicamp. Acessado em 15 de Junho de 2010. Kanji Hara Neto.com/blog/cns!397FD8C3C55E019F!151. 2007. Roger S.br/artigos/UML1. 2ª Reimpressão SOMMERVILLE. Lucas G Nadalete. 2007. Eduardo Princípios de Análise e Projeto de Sistemas com UML/ Eduardo Bezerra Rio de Janeiro: Elsevier. Antonio A.spaces. http://www.php. 8ª edição / Ian Sommerville São Paulo: Pearson Addison ± Wesley. São Paulo: Pearson Education do Brasil. abordagem didática UML . Ian Engenharia de Software. Marcelo Nogueira. 1995. Fabio A. Pressman . Gennari. Acessado em 05 de Junho de 2010. Análise Orientada a Objetos Evolução ou Revolução Resumo http://teobaldobh.entry.delphibr. Engenharia de Software/Roger S.ccuec.com.html Acessado em 17 de Junho de 2010.61 BIBLIOGRAFIA PRESSMAN. .br/revista/infotec/artigos/leite_rahal.

62 UML Unified Modeling Language.html Acessado em 30 de Maio de 2010 Junior.com.scriptfacil.br/materia/694/UML/uml-unified-modeling-language. . João Carlos da Silva http://www.

8ª edição / Ian Sommerville São Paulo: Pearson Addison ± Wesley. . 1995. 2007. Apud (COX 85). São Paulo: Pearson Education do Brasil. 2007. Ian Engenharia de Software. Engenharia de Software/Roger S.63 REFERÊNCIAS BIBLIOGRÁFICAS PRESSMAN. Pressman . Roger S. BEZERRA. Eduardo Princípios de Análise e Projeto de Sistemas com UML/ Eduardo Bezerra Rio de Janeiro: Elsevier. 2ª Reimpressão Sommerville.

Sign up to vote on this title
UsefulNot useful