• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
[Engenharia de Software] Marquivos.com
 

[Engenharia de Software] Marquivos.com

on

  • 1,285 views

Documento final do trabalho da cadeira Engenharia de Software, do semestre 2010/A, da UNIVATES. O documento descreve todo o processo de desenvolvimento de um software a partir da metodologia RUP.

Documento final do trabalho da cadeira Engenharia de Software, do semestre 2010/A, da UNIVATES. O documento descreve todo o processo de desenvolvimento de um software a partir da metodologia RUP.

http://blog.brunozambiazi.com

Statistics

Views

Total Views
1,285
Views on SlideShare
1,285
Embed Views
0

Actions

Likes
1
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    [Engenharia de Software] Marquivos.com [Engenharia de Software] Marquivos.com Document Transcript

    • Trabalho de Engenharia de Software Centro Universitário UNIVATES Marquivos.com Sistema Web para Gerência e Compartilhamento de Arquivos Bruno Dadalt Zambiazi, Luís Felipe Gerhardt, Renan Ednei Decker Lajeado, 02 de julho de 2010.
    • Sumário Sumário............................................................................................................................. 2 Introdução......................................................................................................................... 3 Proposta de trabalho ......................................................................................................... 4 Atores ........................................................................................................................... 4 Descrição ...................................................................................................................... 4 Motivação ..................................................................................................................... 5 Metodologia escolhida.................................................................................................. 5 Equipe do projeto ......................................................................................................... 5 Metodologia de trabalho................................................................................................... 6 Ciclo de vida................................................................................................................. 6 Etapas, disciplinas, resultados e responsabilidades ...................................................... 7 Inicial ........................................................................................................................ 7 Elaboração ................................................................................................................ 9 Construção 1 ........................................................................................................... 11 Construção 2 ........................................................................................................... 12 Transição ................................................................................................................ 14 Requisitos ....................................................................................................................... 15 Funcionais................................................................................................................... 15 Relativo aos administradores ................................................................................. 16 Relativo aos mantenedores..................................................................................... 18 Relativo à rede social.............................................................................................. 18 Relativo aos usuários ............................................................................................. 19 Não Funcionais ........................................................................................................... 22 Usabilidade ............................................................................................................. 22 Performance............................................................................................................ 22 Segurança................................................................................................................ 22 Ferramenta de apoio ....................................................................................................... 22 Aplicação e recursos................................................................................................... 22 Modelos ...................................................................................................................... 23 Conclusões...................................................................................................................... 25 2
    • Introdução O presente trabalho visa apresentar todo o processo envolvido no desenvolvimento de um software sob a perspectiva da área de conhecimento denominada como Engenharia de Software. Tendo como ponto de início a escolha de um software a ser construído e o porquê do seu desenvolvimento, foi feita a seleção de uma metodologia de trabalho que guiará o restante do processo, fazendo toda a equipe do projeto basear-se nas fases, etapas e atividades adaptadas conforme a metodologia. Esta ainda é explicada detalhadamente, de forma textual, gráfica e com modelos, a fim de mostrar a sua importância não somente dentro dos processos envolvendo este sistema, como, também, dentro da própria Engenharia de Software. Após, é feito o levantamento dos requisitos necessários para a codificação do software. Os requisitos são divididos em dois tipos, Funcionais e Não Funcionais, e apresentam casos de uso nos quais devem ser aplicados – o primeiro tipo refere-se a implementações de regras de negócios, enquanto o segundo, a funcionalidades e aplicações gerais. Além disso, há a apresentação de uma ferramenta escolhida que servirá como apoio ao desenvolvimento em determinadas etapas do projeto. Através de uma análise detalhada sobre funcionalidades e recursos, esta é apresentada com exemplos voltados à utilização no projeto proposto. Por fim, a conclusão discorre a respeito da importância do desenvolvimento da ferramenta e demais observações. Todo o trabalho é baseado no desenvolvimento de um software pela empresa fictícia SolWeb. 3
    • Proposta de trabalho A empresa SolWeb, após um longo período de análise de mercado, constatou a oportunidade para o desenvolvimento do projeto Marquivos.com – Sistema Web para Gerência e Compartilhamento de Arquivos. Atores Durante o projeto, serão utilizadas as seguintes nomenclaturas para descrever as pessoas envolvidas nas etapas do projeto: → Administradores: são as pessoas responsáveis pela manutenção do sistema como um todo, com permissão para gerenciamento de absolutamente todo o conteúdo (inclusive para exclusões sem aviso prévio); → Mantenedores: são os usuários cadastrados no site e que, por isso, possuem permissão para envio e gerenciamento de arquivos; → Usuários: são os usuários sem cadastro e que, dessa forma, possuem a permissão padrão para realizar tarefas básicas relativas aos arquivos liberados pelos mantenedores. Neste documento, todas as referências a um ator estarão enfatizadas. Descrição O sistema visa proporcionar uma estrutura para gerenciamento total e livre de diversos tipos de arquivos. Tal gerência é permitida apenas aos mantenedores, cadastrados de forma gratuita, restando aos usuários apenas a visualização dos conteúdos previamente liberados e permitidos pelos mantenedores. Haverá também uma espécie de rede social, na qual os mantenedores podem adicionar uns aos outros como amigos, tendo a possibilidade de trocar mensagens entre si. Os mantenedores terão, basicamente, as seguintes funcionalidades: → Salvar arquivos das seguintes extensões: AVI, BMP, DOC, GIF, JPEG, PNG, MPG, MP3, PDF, PPT, TXT, WMV, XLS, XML e variações (DOCX, KML, XSL, etc); → Dar permissão de acesso aos arquivos enviados por ele. A permissão significa configurar quem terá acesso aos seus arquivos, da seguinte forma: o Públicos: todos os usuários e mantenedores têm acesso; o Privados-Amigos: apenas os mantenedores na sua lista de amigos podem acessar seus arquivos; o Privados: apenas ele tem acesso ao conteúdo. 4
    • → Possibilitar aos amigos o envio de comentários a respeito dos arquivos com permissão Privado-Amigos (arquivos públicos automaticamente possibilitam comentários). O sistema deverá ser bastante interativo, proporcionando enquetes e comentários para qualquer tipo de arquivo com permissão Pública. Também haverá controle de número de visualizações de arquivos, informações que serão colocadas em destaque nas páginas iniciais do sistema, dividindo-as por categorias de arquivos. Também haverá um blog contendo as novidades do sistema e área de notícias sobre assuntos gerais (inclusive com a inclusão de vídeos, o que será feita pelos administradores). Motivação As ideias para o desenvolvimento do sistema proposto são o resultado da junção de diversas das funcionalidades citadas que são encontradas em sites diferentes. Atualmente, o crescente ingresso de usuários em redes sociais e sistemas que lhes possibilitam interação, faz com que seja necessária a criação de um sistema que englobe tudo em um ponto único de acesso. Como “inspirações”, o sistema proposto utiliza as ferramentas Google Docs1, Orkut2 e Youtube3. Metodologia escolhida Optou-se por utilizar a metodologia RUP – Rational Unified Process. A escolha deve-se ao fato da empresa SolWeb considerar este como um projeto que necessita de processos bem definidos, documentados e gerenciados, além da preferência pela orientação a objetos. Equipe do projeto A equipe considerada necessária para o desenvolvimento do sistema Marquivos.com é composta pelos seguintes integrantes: → Gerente de Projetos; → 2 Analistas de Sistemas; → Analista de Infra-Estrutura; → Analista de Testes/Testador; → DBA; → 2 Programadores; 1 Ferramenta on-line desenvolvida pelo Google que serve como um gerenciador e compartilhador de arquivos. Permite a criação e edição de arquivos de texto, planilhas e apresentações. 2 Rede social on-line adquirida e mantida pelo Google. Tem o objetivo de ajudar os membros a conhecer pessoas e manter relacionamentos. 3 Ferramenta on-line, adquirida e mantida pelo Google, que permite o envio e compartilhamento de vídeos com outros usuários. 5
    • → Designer; → Documentador. Metodologia de trabalho Como já citado, optou-se por trabalhar de acordo com a metodologia de desenvolvimento Rational Unified Process, conhecida pela sigla RUP. Caracterizado por utilizar uma abordagem totalmente orientada a objetos, o RUP pode ser visto como uma espécie de guia para a aplicação de UML4, visto que utiliza-se amplamente deste para ilustrar seus processos. No caso do sistema Marquivos.com, a SolWeb não seguiu à risca as fases características do modelo RUP. Ao contrário, preferiu adaptar algumas etapas de forma a tornar o desenvolvimento ideal e mais produtivo, pois a metodologia assim permite fazer. A escolha pelo RUP deu-se, também, devido ao fato dessa metodologia basear- se no desenvolvimento de componentes. Assim, o processo de criação de novos módulos torna-se mais simples, menos maçante e mais fácil de ser incorporado ao projeto como um todo. Ciclo de vida O ciclo de vida padrão do RUP prevê quatro fases – Concepção, Elaboração, Construção e Transição – que podem ser subdivididas a livre escolha. Dessa forma, o gráfico abaixo demonstra as cinco fases – foi posta uma fase de construção além do ciclo natural – e as nove disciplinas definidas para o desenvolvimento do Marquivos.com, juntamente com a porcentagem de tempo despendido por cada disciplina em cada uma das fases: 4 A Unified Modeling Language (UML) é uma linguagem de modelagem que auxilia na visualização e comunicação dos objetos de um sistema através de diagramas padronizados. 6
    • Etapas, disciplinas, resultados e responsabilidades Inicial → Modelagem de Negócios Avaliar status do negócio. Identificar e refinar os seus processos. Projetar as realizações do processo do Negócio. Refinar papéis e responsabilidades tanto dos envolvidos no projeto. Explorar a automatização do processo. Resultado esperado: Avaliação da viabilidade do projeto. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Requisitos Analisar o problema. Compreender as necessidades dos envolvidos. Definir como será o sistema. Gerenciar o escopo do sistema. Refinar a definição do sistema. Gerenciar requisitos variáveis. 7
    • Resultado esperado: Definição do escopo inicial do projeto. Participantes: Analista de sistema, Analista da infra-estrutura, Programador 1 e 2, Designer, DBA, Documentador e Gerente do projeto. → Análise e Design Realizar síntese arquitetural. Resultado esperado: Esboço da arquitetura do projeto. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Implementação Preparar o ambiente de suporte para que este consiga disponibilizar as ferramentas e métodos adequados para suprir as futuras necessidades do software nessa área. Desenvolver um pequeno protótipo a partir de ideias iniciais do sistema, que deve simular pouca iteração para focar mais na parte de funcionalidades, componentes e localização de informações. Resultado esperado: protótipo do sistema. Participantes: analista da infra-estrutura, programador 1, designer, gerente do projeto. → Teste Teste de diversas bibliotecas que poderão auxiliar no desenvolvimento de futuras etapas. Realizar testes com ferramentas para upload de arquivos – apenas dos tipos que serão permitidos - e redimensionamento de imagens e buscar soluções prontas para troca de informações através de vídeo- conferência em ambiente Web. Resultado esperado: documento com as informações a respeito dos testes e pesquisas. Participantes: programador 2, analista da infra-estrutura, documentador. → Implantação Não há implantação nesta fase do projeto. Resultado esperado: - Participantes: - → Gerência e Configuração de Mudança Estabelecer políticas de software; verificar e estabelecer funções. Resultado esperado: documentar propostas, funções, normas e políticas do software. 8
    • Participantes: analista de sistemas, documentador, gerente de projetos. → Gerenciamento do Projeto Compilar plano do projeto; organizar o projeto; definir processos de controle e monitoramento; planejar fases e alterações. Resultado esperado: estar com a documentação necessária para o início do projeto. Participantes: analista de sistemas, documentador, analista de infra- estrutura, gerente de projetos. → Ambiente Estudar o ambiente de desenvolvimento necessário que dará suporte à criação do software. Resultado esperado: documento contendo os resultados do estudo acerca do ambiente. Participantes: analista de sistemas, analista de infra-estrutura, documentador, gerente de projetos. Elaboração → Modelagem de Negócios Não há modelagem de negócio nesta fase do projeto. Resultado esperado: - Participantes: - → Requisitos Analisar o problema. Compreender as necessidades dos envolvidos. Definir o sistema. Gerenciar o escopo do sistema. Refinar a definição do sistema. Gerenciar requisitos variáveis. Resultado esperado: Reavaliação o escopo do projeto e gerência do mesmo. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Análise e Design Definir uma sugestão de arquitetura. Analisar comportamento dos futuros usuários. Projetar componentes. Projetar o banco de dados. Refinar a arquitetura. Resultado esperado: Definição da arquitetura base para o projeto. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. 9
    • → Implementação Início da montagem do ambiente de desenvolvimento do projeto. Inclusão e configuração de bibliotecas de templates, scripts, persistência de dados, injeção de dependência e inversão de controle, que serão usadas no projeto. Integração com o servidor de aplicações e adequação ao sistema das ferramentas pesquisadas durante a disciplina Teste na fase Iniciação. Criação do banco de dados a partir de estruturas básicas que devem estar presentes. Resultado esperado: em torno de 40% do sistema concluído. Participantes: DBA, designer, programadores, documentador. → Teste Testes sobre a estrutura do banco de dados. Criação das classes e dos casos de testes a serem utilizados na ferramenta escolhida para tais fins. Testes sobre a disciplina Implementação. Resultado esperado: modelo acerca dos testes a serem realizados e documento sobre os que foram realizados. Participantes: analista dos testes, analista do sistema, documentador. → Implantação Fim da instalação das ferramentas de suporte. Início da implantação do banco de dados no ambiente de produção. Resultado esperado: - Participantes: analista da infra-estrutura, DBA. → Gerência e Configuração de Mudança Realizar auditoria de configuração. Resultado esperado: documento do processo. Participantes: analista de sistemas, analista de infra-estrutura, documentador, gerente de projetos. → Gerenciamento do Projeto Desenvolver plano de riscos, plano de métricas, planos de aceitação do produto e de garantia da qualidade do trabalho. Resultado esperado: diagramas dos planos e documento sobre aceitação do produto. Participantes: analista de sistemas, documentador, analista de infra- estrutura, gerente de projetos, DBA, analista de testes. 10
    • → Ambiente Guias de modelagem, uso e ferramentas. Resultado esperado: documentação completa a respeito do sistema. Participantes: analista de sistemas, documentador, gerente de projetos. Construção 1 → Modelagem de Negócios Não há modelagem de negócio nesta fase do projeto. Resultado esperado: - Participantes: - → Requisitos Gerenciar requisitos variáveis. Resultado esperado: Alteração de requisitos definidos, caso seja necessário. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Análise e Design Projetar componentes. Projetar o banco de dados. Refinar a arquitetura. Resultado esperado: Projeto de componentes e Banco de Dados. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Implementação Fim da criação da estrutura do banco de dados. Início “real” do desenvolvimento do sistema. Foco inicial no desenvolvimento do template de forma a ser reaproveitado tanto por telas de cadastro quanto por telas de listagem. Desenvolvimento dos scripts client-side padrões, folhas de estilo e pequenos componentes específicos que poderão ser utilizados em mais de uma tela. Deve ser dada importância à criação do cadastro de mantenedores e upload de arquivos. Posteriormente, deve haver o desenvolvimento do blog, da área de notícias e das enquetes. Iniciar o desenvolvimento da rede social (nessa fase, os mantenedores precisam simplesmente ter a opção de adicionar uns aos outros). Resultado esperado: documento com as bibliotecas utilizadas e script de criação da parte básica do banco de dados. Participantes: gerente do projeto, programadores, DBA, documentador. 11
    • → Teste Teste do ambiente de suporte preparado na disciplina Implementação da fase Iniciação. Resultado esperado: documento sobre os testes. Participantes: analista da infra-estrutura. → Implantação Começo da instalação e configuração avançada das ferramentas de suporte preparadas durante a disciplina Implementação da fase Iniciação. Resultado esperado: - Participantes: analista de infra-estrutura. → Gerência e Configuração de Mudança Alterações necessárias nas configurações do ambiente. Resultado esperado: documentação do processo. Participantes: analista de sistemas, analista de infra-estrutura, documentador, gerente de projetos. → Gerenciamento do Projeto Desenvolvimento do plano de alterações. Resultado esperado: documento com o plano. Participantes: analista de sistemas, documentador, gerente de projeto. → Ambiente Guias de design, programação e interface, e avaliação da padronização de desenvolvimento estar sendo seguida. Resultado esperado: guias e documentos. Participantes: documentador. Construção 2 → Modelagem de Negócios Não há modelagem de negócio nesta fase do projeto. Resultado esperado: - Participantes: - → Requisitos Gerenciar requisitos variáveis. Resultado esperado: Alteração de requisitos definidos, caso seja necessário. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. 12
    • → Análise e Design Refinar a arquitetura. Resultado esperado: Alterações na arquitetura, caso seja necessário. Participantes: Analista de sistema, Analista da infra-estrutura, DBA, Documentador e Gerente do projeto. → Implementação Focar no desenvolvimento do sistema de administração de todo o site, ao qual poucas pessoas terão acesso. Terminar o desenvolvimento da rede social, permitindo que os mantenedores enviem mensagens uns aos outros. Implementação da possibilidade de adição de comentários a arquivos com determinada permissão. Criação do controle de visualizações de arquivos e da visualização desses dados na tela inicial do site, separados por tipos de arquivos. Implementação do sistema de busca de arquivos e do envio dos links a emails de amigos. Resultado esperado: sistema concluído. Participantes: designer, programadores, analista do sistema, documentador. → Teste Foco nos testes em toda a baseline disponibilizada pelas disciplinas de Implementação. Testes de usabilidade e acessibilidade. Resultado esperado: documento com os resultados dos testes e melhorias. Participantes: analista dos testes, gerente do projeto, documentador. → Implantação Configuração final do servidor de aplicação e fim da implantação do banco de dados finalizado no ambiente de produção. Resultado esperado: - Participantes: gerente do projeto, DBA. → Gerência e Configuração de Mudança Criar unidade de implantação e elencar o status das configurações. Resultado esperado: documentos. Participantes: analista de sistemas, analista de infra-estrutura, documentador, gerente de projetos. → Gerenciamento do Projeto 13
    • Listar os problemas encontrados durante a primeira construção e possíveis risco da segunda Resultado esperado: documento com os riscos e problemas Participantes: analista de testes, documentador, analista de sistemas. → Ambiente Guias de design, programação e interface, e avaliação da padronização de desenvolvimento estar sendo seguida. Resultado esperado: guias e documentos. Participantes: documentador. Transição → Modelagem de Negócios Não há modelagem de negócio nesta fase do projeto. Resultado esperado: - Participantes: - → Requisitos Gerenciar requisitos variáveis. Resultado esperado: Alteração de requisitos definidos, caso seja necessário. Participantes: Analista de sistema, Analista da infra-estrutura, Designer, DBA, Documentador e Gerente do projeto. → Análise e Design Refinar a arquitetura. Resultado esperado: Alterações na arquitetura, caso seja necessário. Participantes: Analista de sistema, Analista da infra-estrutura, DBA, Documentador e Gerente do projeto. → Implementação Desenvolvimento das melhorias apontadas nos testes de usabilidade e feedback dos usuários. Resultado esperado: finalização do sistema. Participantes: designer, programadores. → Teste Testes finais focados no sistema de administração. Resultado esperado: documento com os resultados dos testes. Participantes: analista dos testes, analista do sistema, gerente do projeto, documentador. 14
    • → Implantação Instalação do modelo final do projeto em ambiente de produção. População das tabelas do banco de dados que necessitam de uma quantidade aceitável de informações para que o sistema comece a funcionar. Instalação final de softwares e periféricos no servidor. Resultado esperado: sistema funcionando. Participantes: gerente do projeto, DBA, analista da infra-estrutura. → Gerência e Configuração de Mudança Finalizar processos de configuração. Resultado esperado: finalização dos processos. Participantes: analista de sistemas, analista de infra-estrutura, documentador, gerente de projetos. → Gerenciamento do Projeto Monitorar o status do software e verificar se o mesmo encontra-se em condições de ser colocado em produção. Resultado esperado: documento com os resultados. Participantes: analista de testes, documentador, gerente de projeto. → Ambiente Avaliação sobre a qualidade de software e finalização da documentação das guias para os usuários. Resultado esperado: guias e documentos. Participantes: documentador, gerente de projeto. Requisitos Funcionais Nesta seção, são descritos os casos de uso dos requisitos funcionais a serem implementados no sistema, sendo explanados apenas os processos que, por ventura, poderiam gerar alguma dúvida na sua implementação. Os casos de uso foram classificados em quatro categorias e cada uma possui uma explicação mais detalhada. Além disso, há 3 indicadores da prioridade do caso de uso para o funcionamento do sistema: necessário (sem o qual o sistema ainda opera), importante (sem o qual o 15
    • sistema não opera de forma eficiente) e essencial (sem o qual o sistema não pode operar). O desenvolvimento de telas de listagem do sistema administrativo não é descrito em virtude de todas as telas deverem ser iguais: uma tabela de resultados paginada a cada 25 linhas de registros, tendo cada uma destas duas colunas fixas (as duas últimas) com links para a edição e exclusão do registro da linha atual. Outra peculiaridade é em relação ao campo “Status”, contido em praticamente todos os casos, que representa o estado do registro para o sistema, ou seja, se o mesmo está ativo ou inativo. Relativo aos administradores Contém os casos de uso referentes à utilização por parte dos administradores do sistema, ou seja, as pessoas que dão a manutenção para que o sistema possa funcionar corretamente. Todos os casos de uso dessa categoria partem do princípio de que o administrador já está logado no sistema. Diagrama dos casos de uso: 1. [UCADM01] Cadastro de administradores Descrição do caso de uso: administrador cadastra um usuário para ser, também, um administrador. Campos: código, nome, email, senha, status. Prioridade: necessário. 16
    • Entradas / Pré-condições: nenhuma. Saídas / Pós-condições: novo administrador. 2. [UCADM02] Cadastro de categorias de arquivos Descrição do caso de uso: administrador cadastra uma categoria de arquivos que será relacionada a várias extensões. Campos: código, nome, status. Prioridade: essencial. Entradas / Pré-condições: nenhuma. Saídas / Pós-condições: nova categoria de arquivos. 3. [UCADM03] Cadastro de extensões de arquivos Descrição do caso de uso: administrador cadastra uma extensão permitida para upload de arquivos. Campos: código, extensão, mime-type, status. Prioridade: essencial. Entradas / Pré-condições: é necesário haver alguma categoria de arquivos já criada (UCADM02). Saídas / Pós-condições: nova extensão permitida para o upload de arquivos. 4. [UCADM04] Cadastro de enquetes Descrição do caso de uso: administrador cadastra uma enquete para ser votada por qualquer tipo de usuário. Campos: código, pergunta, opções (máximo 5), data inicial, data final, status. Prioridade: necessário. Entradas / Pré-condições: nenhuma. Saídas / Pós-condições: nova enquete com o máximo de 5 opções de resposta. 5. [UCADM05] Cadastro de notícias Descrição do caso de uso: administrador cadastra notícias para que sejam mostradas na área adequada a qualquer tipo de usuário. Campos: código, título, descrição curta, notícia completa, links (apontamentos para arquivos de dentro do sistema), data, autor, status. Prioridade: necessário. Entradas / Pré-condições: nenhuma. Saídas / Pós-condições: nova categoria com um conjunto de extensões associadas. 17
    • Relativo aos mantenedores Contém os casos de uso referentes à utilização por parte dos mantenedores do site, ou seja, os usuários que se cadastraram de forma gratuita para que pudessem enviar arquivos. Todos os casos de uso dessa categoria partem do princípio de que o mantenedor já está logado no site. 1. [UCMAN01] Envio de arquivos Descrição do caso de uso: mantenedor envia um arquivo para o servidor, cadastrando algumas informações adicionais. No momento do upload, é feita a validação da extensão e do mime-type do arquivo para ver se estes dados são permitidos (baseado nas extensões criadas de acordo com UCADM03). O mantenedor também pode cadastrar tags associadas ao conteúdo do arquivo. No momento do envio, deve ser informada uma permissão ao mesmo de acordo com a seguinte especificação: • Pública: todo o tipo de usuário tem acesso ao arquivo; • Privada-Amigos: apenas os mantenedores na lista de amigos do remetente podem visualizar o arquivo; • Privada: apenas o remetente tem acesso ao arquivo. Campos: código, título do arquivo, descrição, arquivo, extensão (valor pego automaticamente no momento do upload), data, permissão, permissão para download, status, tags. Prioridade: essencial. Entradas / Pré-condições: UCADM03 e UCUSU01 concluídos. Saídas / Pós-condições: novo arquivo. Relativo à rede social Contém os casos de uso referentes à rede social do sistema, local no qual os usuários cadastrados (mantenedores) podem adicionar uns aos outros e trocar mensagens. 1. [UCRES01] Adição de amigos Descrição do caso de uso: ao visualizar perfil de outro mantenedor, o mantenedor logado clica no botão de “Adicionar como amigo” e pode preencher um campo com texto livre para que o convite seja enviado. Campos: texto de convite. Prioridade: essencial. Entradas / Pré-condições: UCUSU01 concluído. O mantenedor só pode ser adicionado se tiver permitido isso no momento do seu cadastro. 18
    • Saídas / Pós-condições: o mantenedor adicionado somente estará presente na rede social de quem o adicionou, no momento em que aceitar a adição. Quando fizer o login no sistema, o mantenedor deve poder visualizar todas as suas mensagens e também quem o adicionou. 2. [UCRES02] Envio de mensagens Descrição do caso de uso: ao visualizar perfil de outro mantenedor, o mantenedor logado clica sobre o link “Enviar mensagem”. O mantenedor logado digita a mensagem e a envia. Campos: mensagem. Prioridade: importante. Entradas / Pré-condições: UCRES01 concluído. Saídas / Pós-condições: mantenedor que recebeu a mensagem recebe um email informando sobre isso. Quando logar no sistema, ele visualiza a mensagem e pode respondê-la diretamente através dessa página. Relativo aos usuários Contém os casos de uso referentes à utilização por parte dos usuários comuns, ou seja, qualquer pessoa que tenha acessado o site. Digrama dos casos de uso: 1. [UCUSU01] Cadastro no sistema 19
    • Descrição do caso de uso: usuário acessa a página de cadastro no sistema, preenche seus dados, recebe um email de confirmação e clica no respectivo link para validação do cadastro. O campo “rede social” é um booleano que indica se o usuário quer utilizar o sistema de rede social e permitir que os mantenedores tenham acesso ao seu perfil. Campos: código, nome, email, senha, data de nascimento, sexo, cidade, estado, pais, texto geral, rede social, status. Prioridade: essencial. Entradas / Pré-condições: nenhuma. Saídas / Pós-condições: após a confirmação do cadastro no link enviado ao email cadastrado (deve haver uma chave que perca a validade após 3 dias), um novo mantenedor está cadastrado e pode começar a enviar arquivos. 2. [UCUSU02] Visualização de um arquivo Descrição do caso de uso: usuário visualiza determinado arquivo sempre no próprio navegador. Na tela de visualização, além do arquivo, devem ser vistas as seguintes informações: • Link para que usuários possam fazer o download do arquivo, caso o mesmo seja permitido pelo mantenedor que o enviou; • Local para visualização dos comentários, caso haja algum; • Local para postagem de comentários, caso seja permitido (UCUSU03); • Tags associadas ao arquivo com links para uma busca sobre o conteúdo relacionado; • Informações sobre o autor do arquivo e possibilidade do usuário adicioná-lo à lista de amigos caso ele (o usuário que está visualizando o arquivo) esteja logado no sistema; • Informações referentes à categoria à qual o arquivo pertence e ao número de visualizações/download do mesmo; • Local para envio do link do arquivo para algum email (UCUSU04); • Local para que o usuário possa dar uma nota de 1 a 5 (através de estrelas) ao arquivo. Campos: nenhum. Prioridade: essencial. Entradas / Pré-condições: UCUSU01 concluído. Deve haver o cuidado em relação à permissão dada ao arquivo se o mesmo não possui a permissão Pública. Se a permissão for Privada-Amigos, o mesmo só pode ser visualizado por mantenedores que estejam na rede social do mantenedor do arquivo; já se a permissão for Privada, apenas o próprio mantenedor do arquivo pode visualizá-lo. Saídas / Pós-condições: nenhuma. 20
    • 3. [UCUSU03] Envio de comentários sobre um arquivo Descrição do caso de uso: se o mantenedor que enviou o arquivo tiver permitido que sejam colocados comentários nele, o usuário cadastra um comentário sobre o arquivo. Campos: título, comentário. Prioridade: necessário. Entradas / Pré-condições: UCUSU02 concluído. É necessário que o mantenedor do arquivo tenha dado permissão para o recebimento de comentários por qualquer tipo de usuário. Saídas / Pós-condições: novo comentário sobre o arquivo. 4. [UCUSU04] Envio do link do arquivo a algum email Descrição do caso de uso: usuário envia o link do arquivo por email. Se o usuário for um mantenedor e estiver logado, os campos “nome” e “email” do remetente devem ser preenchidos automaticamente. Campos: nome e email do remetente, nome e email do destinatário, mensagem. Prioridade: necessário. Entradas / Pré-condições: UCUSU02 concluído. O arquivo não pode ter a permissão Privada, pois esta não permite que usuários e mantenedores o acesssem, exceto pelo próprio mantenedor. Saídas / Pós-condições: envio do email ao endereço especificado. O email deve conter as informações preenchidas pelo usuário e, abaixo, um pequeno texto explicando do que se trata o sistema (para fins de publicidade). 5. [UCUSU05] Busca por arquivos Descrição do caso de uso: na caixa de texto para pesquisa, presente em todas as telas do site, o usuário pode realizar uma pesquisa pelos arquivos. Deve haver uma caixa de seleção ao lado do campo de texto, com o rótulo “Buscar por:”, no qual o usuário pode selecionar as opções “Tags”, “Extensão”, “Descrição”, “Autor”, “Título”, “Todas”. Campos: texto para pesquisa, opção de pesquisa. Prioridade: importante. Entradas / Pré-condições: UCUSU02 concluído. Saídas / Pós-condições: a busca deve sempre considerar o conteúdo do campo de texto e da caixa de seleção. Com uma das opções “Tags”, “Extensão” e “Autor” selecionada, a busca deve considerar o valor exato dos campos; com uma das opções “Descrição” ou “Título” selecionada, a pesquisa deve pesquisar utilizando o operador like. Para a opção “Todas”, é necessário fazer uma pesquisa através de união. 21
    • Não Funcionais Nesta seção, são descritos os casos de uso dos requisitos não funcionais que o sistema deve conter. Ao contrário dos requisitos funcionais, que referem-se a “o que o sistema faz”, os requisitos não funcionais dizem respeito a “como o sistema é”. Usabilidade O sistema deve ser fácil e prático de ser utilizado, proporcionando uma boa experiência aos usuários, que precisam se sentir satisfeitos enquanto estiverem navegando pelo mesmo. Qualquer usuário, independentemente do nível de conhecimento que possuir, deve conseguir utilizar o Marquivos.com de forma satisfatória, através de todos os recursos que o mesmo oferecer. Performance É necessário que o sistema seja suficientemente rápido para atender às necessidades dos recursos oferecidos. Seguir as recomendações de programação, realizar tunnings constantes no banco de dados e no servidor, são algumas das práticas para obter um desempenho adequado. Segurança Item essencial e que precisa possuir cuidados especiais. Dados de clientes e configurações privadas não podem ser acessados por terceiros de forma alguma. É necessário que haja verificações dos mais diversos tipos e de forma constante. Ferramenta de apoio Para que o desenvolvimento do Marquivos.com obtenha maior produtividade, optou-se por trabalhar com a ferramenta Dia, um software de diagramação open source que serve para a criação de qualquer tipo de diagramas. O Dia será usado na etapa inicial do projeto, mais precisamente na discplina “Análise e Design”, na qual definimos o esboço da arquitetura do projeto. A escolha deste deu-se devido ao fato de ser muito leve, simples e objetivo, atendendo às necessidades verificadas. Aplicação e recursos O Dia é uma ferramenta muito simples, intuitiva e poderosa, desenvolvida em GTK+ para a criação de diagramas. Lançado sob licença GPL, disponibiliza uma gama enorme de tipos de diagramas que podem ser criados, desde fluxogramas de DFD, redes 22
    • Cisco, UML, modelos Entidade-Relacionamento, até a construção de diagramas para engenharia química. Na figura 1, visualizamos a janela principal da ferramenta. No primeiro bloco, encontramos as ferramentas de ações como selecionar, mover, zoom, imagem, linha, círculo e outros. Já no segundo bloco são apresentadas algumas opções relacionadas aos diagramas. Na figura 2, é exibida a ferramenta de camadas, que permite aos utilizadores trabalhar com diversos níveis dentro do mesmo diagrama. Figura 2 Figura 1 O Dia ainda permite a exportação dos diagramas para formatos diversos, tais quais: EPS, SVG, XFIG, WMF, PNG, entre outros. Modelos Abaixo, encontra-se um diagrama para exemplificar a arquitetura do sistema e seus processos (figura 3), representando o ciclo de vida do mesmo, e um diagrama de contexto (figura 4), ambos criados com o Dia: 23
    • Figura 3 Figura 4 24
    • Conclusões A empresa SolWeb considera importante o desenvolvimento do sistema Marquivos.com por este representar a união de diversos serviços muito utilizados hoje em dia e que representam boa parte do tempo de acesso dos internautas brasileiros. A unificação que proporcioná o Marquivos.com torna-se essencial para os usuários de hoje, que têm clara preferência por sites interativos. No entanto, o sistema não pode parar por aí. Melhorias serão implementadas à medida em que se tornarem perceptíveis e necessárias. Por enquanto, as primeiras melhorias dizem respeito à tradução do sistema para, pelo menos, inglês e espanhol, além da implantação de um sistema de vídeo-conferência e do envio de recados pelo celular. Dessa forma, a SolWeb acredita que o projeto possui todos os requisitos para se tornar um novo portal-referência na internet. 25