Incremento II

Requisitos do incremento II:

 - Efetuar download (João Paulo)
 - Efetuar busca (Bartira)

Arquitetura da Aplicação

A arquitetura do sistema está baseada no modelo em três camadas:

1. Apresentação
2. Negócio
3. Persistência

O grupo optou por esta modalidade pois além de ser uma boa prática de desenvolvimento, facilita a divisão de trabalho e codificação.

Diagrama de Classe - Pacote Bean

Pacote Bean:

Diagrama de Classe - Pacote Bean

Pacote Bean:

Diagrama de Classe - Pacote Model

Pacote Model:

Diagrama de Classe - Pacote Service

Pacote Service:

Diagrama de Classe - Pacote DAO

Pacote Dao:

Regras de Negócio - RN 3 Efetuar Upload

RN 3.1 - O usuário pode efetuar upload de arquivos. Ao fazê-lo, deve classificar o arquivo como público ou privado.
RN 3.2 - Ao classificar um arquivo como público, o arquivo deve estar disponível para todos os usuários cadastrados no sistema.
RN3.3 - Ao classificar um arquivo como privado, o arquivo estará disponível apenas para os usuários classificados como contatos do usuário logado.
RN 3.4 - Ao efetuar upload de um arquivo, o usuário deve informar se deseja enviar um aviso a outros usuários, informando que um novo arquivo foi publicado.
RN 3.5 - O aviso deve incluir um link direto para o arquivo postado, juntamente com uma breve descrição feita pelo usuário.
RN 3.6 - O aviso será enviado para todos os usuários que possuem como área de interesse a área do artigo, caso o arquivo seja público.
RN 3.7 - Se o arquivo for publicado como privado, somente seus contatos receberão aviso, independente de suas áreas de interesse.
RN 3.8 - Ao publicar um arquivo, o usuário deve classificá-lo por áreas de interesse. Deve existir uma área de interesse ‘outros’ para tornar o sistema mais abrangente.
RN 3.9 - Ao publicar um arquivo, o usuário deve especificar seu tipo como artigo, monografia, recorte de notícias, trecho de livros, links, vídeos, imagens e outros.

Diagrama de Sequência - UC_EfetuarUpload

Diagrama de sequência referente ao caso de uso UC001 - Efetuar Upload.

O fluxo de mensagens segue o modelo em três camadas: apresentação, negócio e persistência.

Casos de Uso do Requisito

Os casos de uso do requisito escolhido para este incremento, apesar de aparentemente simples, envolveram um grau de complexidade maior do que aparentavam, exatamente por ser este requisito "o coração" do nosso sitema.

UC 001 - Efetuar Upload

Ator Principal:

Usuário do Sistema.

Descrição:

Este caso de uso tem por objetivo permitir que os usuários cadastrem arquivos no sistema.

Pré – Condições:

O usuário deve estar cadastrado no sistema.

Pós – Condições:

O arquivo estará disponível para visualização através do sistema para os usuários autorizados.

Cenário Alternativo:

Não há.

Cenário Principal:

1. O sistema oferece ao usuário:

1.1. Selecionar um arquivo em seu disco local.

1.1.1. O usuário deve selecionar um arquivo em seu disco local.

1.2. Selecionar uma referência a um arquivo através de um link.

1.2.1. O usuário deve informar o link para o arquivo.

2. O usuário deve classificar o arquivo de acordo com as categorias disponíveis.

3. O usuário deve classificar o nível de acesso ao arquivo como público ou privado.

4. O usuário deve informar se deseja enviar para outros usuários um aviso informando sobre a publicação do arquivo.

5. O usuário deve informar se deseja submeter seu arquivo à avaliação de professores.

6. O usuário deve informar a(s) área(s) de interesse do arquivo.

6. O usuário poderá adicionar uma descrição ao arquivo.

7. Ao selecionar a opção ‘Publicar Arquivo’, o arquivo selecionado estará disponível para visualização pelos usuários autorizados.

Exceções:

EXC001 – Arquivo não informado.

O sistema não deve permitir a publicação de um arquivo se o mesmo não for informado no campo destinado para tal e será exibida uma mensagem de erro.

EXC002 – Categoria não informada.

O sistema não deve permitir a publicação de um arquivo cuja categoria não tenha sido informada e será exibida uma mensagem de erro.

EXC003 – Área de interesse não informada.

O sistema não deve permitir a publicação de um arquivo cuja(s) área(s) não tenha(m) sido informada(s) e será exibida uma mensagem de erro.

EXC004 – Formato de arquivo não permitido.

O sistema não deve permitir a publicação de arquivos com extensão .exe, .bat, .cmd e .src. Se o arquivo selecionado possuir extensão inválida o sistema exibirá uma mensagem de erro.

EXC004 – Capacidade máxima de armazenamento excedida.

O sistema não deve permitir a publicação de arquivos que exceda a capacidade máxima de armazenamento definida para cada usuário. O sistema deverá exibir uma mensagem de erro contendo a capacidade máxima permitida.

Inclusão (includes):

UC 003 – Enviar Recado.

Extensões (extends):

Não há.

Regras de Negócio: 

RN 3 – Upload de Arquivos.

Diagrama Entidade-Relacionamento

O nosso diagrama de Entidade-Relacionamento teve papel fundamental na etapa de análise, funcionando em parte como um digrama de classes na fase de negócio. Alguns atributos poderão ser incluídos posteriormente em função dos próximos incrementos.

Upload Slide 1 - Apresentação do Projeto

Arquivo .ppt do primeiro slide referente à apresentação do projeto.
Link para download aqui.

Requisitos e Planejamento do Incremento 1

REQ FUNCIONAIS:
1 - Gerenciar Autenticação no Sistema
2 - Gerenciar Contatos do Usuário
3 - Efetuar Uploads
4 - Gerenciar Comentários e Notas
5 - Permitir Indicações
6 - Realizar Pesquisa
7 - Efetuar Download
8 - Disponibilizar Fórum
9 - Hospedar Currículos
10 - Exibir perfil do twitter.
11 - Permitir Denunciar Usuário

REQ NÃO-FUNCIONAIS:
1- Estar disponível na internet e protegido;
2- Suportar inicialmente 20 requisições por segundo.
3- Cada usuário poderá hospedar até 1GB de arquivos.
4- O sistema deverá ser capaz de reproduzir arquivos em formato multiídia, tais como video e som, arquivos pdf, .doc e .ppt.
5- O sistema deve ser compatível com as versões atualizadas dos seguintes navegadores:
Internet Explorer, Mozila Firefox e Google Chrome.


Como primeiro incremento nossa equipe escolheu o requisito 3. Efetuar Upload.
Este requisito contempla a funcionalidade central do nosso sistema, de modo que poderemos ter uma noção mais precisa no início do projeto do grau de complexidade com qual estamos trabalhando.
Planejamento do Incremento:

• Definição e detalhamento dos Casos de Uso;
• Projeto Arquitetural e Estudo das Tecnologias;
• Montagem da Infra-Estrutura do Projeto (versionador de código);
• Projeto;
• Implementação / Testes;

Modelos de Processo de Software

1.       MODELO EM CASCATA

Também conhecido como ciclo de vida clássico, o modelo em cascata define estágios seqüenciais para o desenvolvimento de software. Estes estágios compreendem as atividades de análise e levantamento de requisitos, planejamento, análise e projeto de sistemas e de software, implementação e testes, implantação e manutenção. É indicado para sistemas que apresentem requisitos bem definidos e estáveis, isto porque, apesar do modelo permitir “ciclos de realimentação”, modificações durante o projeto tendem a ser onerosas e envolvem um ‘retrabalho’ significativo. Além disto, a natureza linear do modelo pode gerar, ainda, o que Pressman apud Bradac denominou “estados de bloqueio”, que ocorrem quando membros da equipe precisam esperar que outros membros concluam as suas atividades para iniciarem ou retomarem às suas.

2.       MODELO INCREMENTAL

O modelo incremental combina elementos do modelo em cascata aplicados interativamente [Pressman]. No modelo incremental o primeiro incremento, chamado de núcleo do produto, apresenta os requisitos básicos do sistema. O núcleo do produto é disponibilizado para o cliente enquanto novos incrementos são elaborados, fornecendo progressivamente novas funcionalidades, de modo a atender necessidades do cliente que ainda não haviam sido definidas ou que não foram implementadas por escassez de mão de obra ou prazos impossíveis.

Os primeiros incrementos são versões funcionais do sistema que, embora incompleto, atende às necessidades iniciais do cliente e servem como uma plataforma de avaliação pelo usuário [Pressman].

3.       MODELO EVOLUCIONÁRIO

O modelo evolucionário tem como base a idéia de criar rapidamente um sistema inicial a partir de especificações abstratas que são progressivamente refinadas pelo cliente de modo a produzir um sistema que satisfaça suas necessidades [Sommerville]. O modelo evolucionário caracteriza-se, ainda, por intercalar as fases do ciclo de vida clássico do software em detrimento da linearidade tradicional do modelo em cascata.

Segundo Sommerville, há dois tipos de modelo evolucionário: o desenvolvimento exploratório, também conhecido como modelo espiral e a prototipagem. O desenvolvimento exploratório tem por objetivo trabalhar com o cliente a fim de explorar seus requisitos. O desenvolvimento se inicia com as partes do sistema que foram compreendidas enquanto às demais são elaboradas à medida que novas necessidades forem sendo identificadas pelo cliente. Já a prototipagem consiste em compreender os requisitos do cliente e elaborar protótipos para validação dos mesmos. A prototipagem oferece ao cliente uma visão mais clara dos requisitos quando o mesmo não identifica quais são os requisitos de entrada, processamento e saída do sistema [Pressman]. Apesar de poder ser utilizada como um modelo independente, a prototipagem geralmente é utilizada como uma técnica em quaisquer dos modelos citados com o objetivo de refinar os requisitos junto ao cliente.

O modelo evolucionário permite que os usuários desenvolvam uma melhor compreensão de seus problemas, o que reflete diretamente na eficácia do sistema [Sommerville]. Além disso, permite que o cliente tenha uma melhor compreensão dos riscos de cada etapa do projeto e reajam de maneira a causar o menor impacto possível no processo de desenvolvimento.

REFERÊNCIAS BIBLIOGRÁFICAS

SOMMERVILLE, Ian. Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003.

PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo: McGraw-Hill, 2006.

Protótipo de Interface

Protótipo é a representação da idéia de um produto em concepção.
No contexto da Engenharia de Software, protótipos podem ser
entendidos como uma representação gráfica, não necessariamente funcional,
de um sistema em fase de projeto, seja construção ou re-engenharia.
Protótipos podem ser classificados em termos de fidelidade, que é o grau
de similaridade entre o protótipo e a interface do produto final, incluindo
características tais como métodos de interação, aparência visual, nível de detalhes,
conteúdo, etc. Em princípio, de acordo com a fidelidade, os protótipos são
classificados em baixa-fidelidade e alta-fidelidade, em que os de alta-fidelidade
são mais similares ao produto final do que os de baixa-fidelidade.

Recentemente, alguns autores introduziram a noção de protótipos de
média-fidelidade, com o objetivo de agregar vantagens dos protótipos
de baixa-fidelidade aos de alta-fidelidade.

Fundamentando...

Uma breve fundamentação teórica a respeito da E.S. do projeto:

• REQUISITOS DE SOFTWARE:
  Dizem respeito aos objetivos e restrições que o software deve alcançar/obedecer, visando atender o objetivo final que este se propõe.
  São tradicionalmente divididos em funcionais e não-funcionais.
  Os Requisitos Funcionais abrangem a descrição das funcionalidades desejadas do software.
  Exemplo: O software deve gerar dados estatísticos referentes ao seu uso." 
  Os Requisitos Não-Funcionais são os aspectos quantitativos e qualitativos globais destas funcionalidades. 
  Exemplo: O sistema depende de uma velocidade de rede.

Planejamento para o dia 08/10

Base Teórica Sobre:
-Ciclo de vida; - Bartira
-Gerência de requisitos - Tiago
-Protótipo de Interface - Joao Paulo

Referências

Plano de Desenvolvimento

Nome da Equipe: JPTB Desenvolvimento
Componentes: Bartira Machado, João Paulo Paschoal e Tiago de Oliveira
Tecnologias e Ferramentas: Java / Netbeans IDE / Jude UML / MySQL / JSF Framework / Hibernate Framework
Escopo: Sistema de compartilhamento e discussão de trabalhos acadêmicos e informações de interesse. Um espaço para troca de conhecimento entre os usuários como opiniões, comentários, dúvidas, etc.