[Engenharia de Software] Marquivos.com

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.

→ 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
Não há modelagem de negócio nesta fase do projeto.
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.

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.

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.
Participantes: analista da infra-estrutura, DBA.

Realizar auditoria de configuração.
Resultado esperado: documento do processo.

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
Participantes: -

→ Requisitos
Resultado esperado: Alteração de requisitos definidos, caso seja necessário.

Projetar componentes. Projetar o banco de dados. Refinar a arquitetura.
Resultado esperado: Projeto de componentes e Banco de Dados.

→ 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.
Participantes: analista de infra-estrutura.

Alterações necessárias nas configurações do ambiente.
Resultado esperado: documentação do processo.

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
Participantes: -

→ Requisitos

12

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.
Participantes: gerente do projeto, DBA.

Criar unidade de implantação e elencar o status das configurações.
Resultado esperado: documentos.


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.
Participantes: documentador.

Transição
Participantes: -

→ Requisitos

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.

Finalizar processos de configuração.
Resultado esperado: finalização dos processos.

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

[Engenharia de Software] Marquivos.com

Mais conteúdo relacionado

Destaque

Semelhante a [Engenharia de Software] Marquivos.com

Mais de Bruno Dadalt Zambiazi

[Engenharia de Software] Marquivos.com