Modelagem de Dados e Funcional Portal XPRecife

Effektiv Solutions

Modelagem de Dados e Funcional Portal XPRecife

Versão <1.0>

Portal XPRecife Versão: 1.0 Especificação dos Requisitos Data Versão: 30/ 05 / 05 Especificacao Requisitos.doc

��

Nome E-mail

Allan Rodrigo dos Santos Araújo [email protected]

José Carlos de Moura Júnior [email protected]

Livar Correia de Oliveira Cavalcanti Cunha [email protected]

Rafael Oliveira Nóbrega [email protected]

Renan Távora Weber [email protected]

Portal XPRecife Versão: 1.0 Modelagem de Dados e Funcional Data Versão: 30 / 05 / 05 Documento_Modelagem.doc

Effektiv / XPRECIFE

3

Histórico das Revisões

Data Versão Descrição Autor

15/05/2005 <1.0> Especificação dos Requisitos TODOS


Effektiv / XPRECIFE

4

Sumário


Effektiv / XPRECIFE

5

��

��

Os objetivos desse documento são revisar todas as informações levantadas no documento de requisitos previamente entregue. Possui protótipos de tela feitos para validar requisitos, além de uma nova modelagem do minimundo, da camada de persistência da aplicação. Este também é capaz de avançar nos diagramas de casos de uso, de classes e de seqüência, formando assim, um valoroso material para guiar os trabalhos da equipe de desenvolvimento durante o projeto.

��

O escopo das informações presentes nesse documento é delimitado pelos requisitos levantados e revisados previamente. O nome do produto é Portal XPRecife e tem como principais componentes:

- Interface WEB (o portal propriamente dito) - Interface Administrador (sistema de gerenciamento do conteúdo do portal)

��

O Portal do XPRecife tem como objetivo ser um centro de comunicação para os membros do grupo e para qualquer outra pessoa interessada em metodologia de desenvolvimento de software, especialmente metodologias ágeis e eXtreme Programming (XP).

�� ! �

Este documento tem como público, essencialmente, a equipe de desenvolvimento. Sendo a parte de protótipos de tela, a única que pode despertar interesse nas pessoas representantes do cliente.


Effektiv / XPRECIFE

6

� ��

Uma técnica bastante utilizada na engenharia de requisitos (elicitação, descrição, análise, validação) é prototipagem rápida de interface de usuário, onde os clientes podem ratificar a solução definida, ou não. Para tanto, utilizou-se ferramentas RAD para que a atividade fosse eficiente. Apenas foram prototipadas algumas telas-chave, dado que as demais possuíam grande semelhança e poderiam ser compreendidas por analogias com as que foram criadas. Este trabalho foi de fundamental importância para as atividades subseqüentes: revisão dos fluxos de caso de uso, modelagem de dados e funcional.

Segue abaixo algumas das telas que foram prototipadas:

(Protótipo da tela principal da Interface Web)


Effektiv / XPRECIFE

7

(Protótipo de tela para Cadastrar Usuário na Interface Web)


Effektiv / XPRECIFE

8

(Protótipo de tela para Submeter uma Notícia na Interface Web)


Effektiv / XPRECIFE

9

(Protótipo de tela da página principal da Interface Administrador)


Effektiv / XPRECIFE

10

(Protótipo de tela da página para aprovar submissões na Interface Administrador)

� ��

Esta seção possui uma descrição detalhada da modelagem de dados que será utilizada no desenvolvimento do projeto. Segue com uma descrição do minimundo, do diagrama E-R, e das tabelas modeladas utilizando ferramenta CASE.


Effektiv / XPRECIFE

11

�� "��#��

O Portal do XPRECIFE tem como objetivo ser um centro de comunicação para os membros do grupo e para qualquer outra pessoa interessada em metodologia de desenvolvimento de software, especialmente metodologias ágeis e eXtreme Programming (XP).

As entidades do sistema são: • Usuário

o Cada usuário possuirá um código, um nome, um endereço, um telefone e um nível de acesso, além de um e-mail (login dele) e uma senha.

• Colunista o No caso de colunista, além das informações comuns a todos os usuários, ele

também possui uma foto. • Administrador

o O administrador possui todas as informações dos colunistas, diferenciando apenas por um nível de acesso diferente.

As entidades que representam as publicações do site são:

• Informação o Possuirá um código, um título, um texto, o autor, um indicador se a

informação foi aprovada (aprovado) e uma data. • Link

o Possuirá todos os dados de informação mais uma url (endereço). • Artigo

o Possuirá todos os dados de informação mais uma url (endereço)z. • Atividade

o Possuirá todos os dados de informação, e além deles possuirá também duas datas início e fim.

• Notícia o Possuirá todos os dados de informação, e alem deles possuirá também uma

foto (opcional) e uma classificação e uma lista de comentários. • Comentário Notícia

o Possuirá todos os dados de informação. • Revisão Livro

o Possuirá todos os dados de notícia. • Comentário Revisão Livro

o Possuirá todos os dados de informação. • Coluna

o Possuirá todos os dados de informação. • Notícia Newsletter

o Possui um código, um conjunto de notícias, um nome e uma data e o status (enviado ou não) e o autor.

• Lista Newsletter o Possui uma lista de e-mail.

Deve-se ressaltar que os códigos de todas as entidades são únicos. Um usuários possui um

único endereço. Um usuário pode submeter de 0 a N notícias, links, eventos, revisões de livro, comentários e artigos e cada “publicação” desta está relacionada a apenas 1 usuário. Um colunista e um administrador podem submeter várias colunas e uma coluna pode ser enviada por apenas um colunista. Uma notícia pode ter vários comentários, e um comentário pode estar relacionado a


Effektiv / XPRECIFE

12

apenas 1 notícia. Uma revisão de livro pode ter vários comentários, mas um comentário pode estar associado somente a uma revisão de livro.

�� $%�

O banco de dados a ser implementado no projeto é essencialmente relacional. Portanto, não permite que nosso modelo seja orientado a objetos. No entanto, por convenção, neste diagrama logo a seguir, utilizaremos notações do modelo E-R estendido para ajudar a diminuir o tamanho do diagrama e, ao mesmo tempo, comunicar com a mesma riqueza de detalhes.


Effektiv / XPRECIFE

13

Note que no diagrama acima, todos os relacionamentos do tipo “ISA” representa que, por exemplo, um administrador e um colunista têm todos os atributos de usuário, assim como todas as entidades de publicações possuem todos os atributos de informação.

�� $%��!&��'�� (��)�

A escolha do SGBD realizada por nosso cliente, satisfazendo assim aos requisitos não-

funcionais, impede quem implementemos uma modelagem de dados orientada a objetos, embora todo o restante da aplicação seja orientado a objetos. Por isso, deve haver um mapeamento indireto entre a representação das entidades e relacionamentos mostrada na secção anterior, e a solução final adotada logo abaixo, que é puramente relacional e normalizada. Vejamos:

Evitamos ter uma tabela grande concentrando a parte de “Informações” e de “Usuários” com o tamanho máximo de atributos que uma das outras entidades tinham e apenas uma coluna para dizer o tipo daquela linha. Por quê? Para não ter várias linhas com atributos com conteúdo vazio, economizando assim, espaço de armazenamento. Como visto acima, temos algumas tabelas semelhantes quanto aos atributos e, esta decisão foi tomada levando em conta a facilidade que proporcionará à implementação da aplicação.

Outra importante decisão tomada foi ter tabelas de destaque associadas aos principais tipos de

publicações. Dado que o conteúdo do site deve ser dinâmico, temos de ter as informações que devem ser carregadas na página definidas em tempo de execução.


Effektiv / XPRECIFE

14

� ��

�� "��*��+��

A visão que o diagrama de Casos de Uso de UML promove uma completa visualização da impressão que os usuários têm de um sistema. O principal foco é a interação entre os atores (agentes externos ao sistema) e os serviços que o determinado sistema provê, onde cada serviço é conhecido por “Caso de Uso”.

4.1.1 Subsistema Portal – Interface Web

(Diagrama Geral – iWeb)

(Pacote Gestão Dados Usuário – iWeb)


Effektiv / XPRECIFE

15

(Pacote Submissão – iWeb)

(Pacote Gestão Coluna – iWeb)

4.1.2 Subsistema Gerenciamento – Interface iAdmin


Effektiv / XPRECIFE

16

(Diagrama Geral – iAdmin)

(Pacote Gestão Newsletter – iAdmin)

(Pacote Gestão Usuário – iAdmin)


Effektiv / XPRECIFE

17

(Pacote Gestão Conteúdo – iAdmin)

(Pacote Gestão Submissão – iAdmin)

�� "��*��

Os diagramas de classes de UML são um dos principais elementos das visões estáticas de um sistema. Fornece uma ampla visibilidade sobre a estrutura de “classes” sobre as quais o sistema está montado. Abaixo seguem alguns dos principais modelos independentes de plataforma que obtivemos:


Effektiv / XPRECIFE

18

(Diagrama Geral – Visão Ampla)

(Diagrama dos Cadastros)


Effektiv / XPRECIFE

19

(Diagrama dos Repositórios)

(Diagrama das Classes Básicas)

É preciso entender que este primeiro modelo ainda é bastante abstrato e independente de tecnologia, nos próximos passos de projeto, o modelo acima será refinado em modelos mais concretos e próximos daquilo que será implementado.

�


Effektiv / XPRECIFE

20

�� "��*��&�,-.��

Os diagramas de seqüência de um sistema preocupam-se com a ordem temporal com que são trocadas as mensagens entre os objetos que compõe o sistema. Geralmente, são baseados nos casos de uso. Também optaremos por essa alternativa.

4.3.1 Principais Seqüências da iWeb

(Caso de Uso Cadastrar E-mail Newsletter)

(Caso de Uso Efetuar Login)


Effektiv / XPRECIFE

21

(Caso de Uso de Submissão de Informação)

Esta seqüência acima contempla a submissão de todos os tipos de informação. De acordo com cada tipo, é que será definido onde e como será inserida a informação na base de dados.

(Caso de Uso Alterar Usuário)

O caso de uso “Remover-se como Usuário” tem troca de mensagens similar ao “Alterar Usuário”, portanto, omitimos seu diagrama.

4.3.2 Principais Seqüências da iAdmin


Effektiv / XPRECIFE

22

(Caso de Uso Efetuar Login)

(Caso de Uso Alterar Usuário) O caso de uso acima é usado para alterar o status do usuário. Para remover um usuário, o fluxo das mensagens é semelhante, portanto, omitido no diagrama.

(Caso de Uso para Modificar a parte de uma das áreas de Destaque do site)


Effektiv / XPRECIFE

23

(Caso de Uso Procurar Informação)

O parâmetro não foi definido porque pode haver diversos tipos de busca: por título, por data, por classificação, etc. Por isso, demais detalhes serão definidos com a revisão do modelo acima, para gerar o modelo específico de plataforma.

InterfaceWeb Fachada CadastroNewsletter RepositorioNerwsletter

remover(email: String)remover(email: String)

remover(email: String)

Retorno Implícito: O e-mail removido ou uma exceção

(Caso de Uso Remover um E-mail da Lista de Newsletter)

InterfaceWeb EnviadorNewsletter

enviarNewsletter(n: Newsletter)

(Caso de Uso Enviar Newsletter)


Effektiv / XPRECIFE

24

InterfaceWeb Fachada CadastroNewsletter RepositorioNewsletter

Cadastrar(n: NewsLetter)Cadastrar(n: NewsLetter)

Cadastrar(n: NewsLetter)

Retorno Implícito: O newsletter inserido na base de dados, ou exceção.

(Caso de Uso Cadastrar Newsletter)

Documents

Modelagem de Dados e Funcional Portal XPRecife