S.O.G.R.A. 2 - Sistema de Organização e Gerência de...

Universidade Federal do Rio Grande do Sul - Instituto de InformáticaINF01127 - Engenharia de Software N - Prof.º Marcelo Pimenta

Carlos Eduardo Ramisch - Cartão 134657Jean Felipe Patikowski Cheiran - Cartão 124231

{ceramisch, jfpcheiran}@inf.ufrgs.br

S.O.G.R.A. 2 - Sistema de Organização e Gerência de Receitas Alimentícias 2

Introdução

Pessoas que cozinham costumam ter um livro de receitas, que contém a descrição detalhada do preparo de diversos alimentos. Receitas são buscadas no livro, e para isso precisam estar organizadas. Freqüentemente, também, elas são alteradas ou então compartilhadas entre as pessoas. Para facilitar tarefas como essas, propomos o S.O.G.R.A., um sistema de organização e de compartilhamento de receitas que tem por objetivo agilizar e tornar agradável a manutenção de um livro de receitas.

A concepção original do S.O.G.R.A. na forma de um projeto de encerramento da disciplina de classificação e pesquisa de dados. Em sua primeira versão, o programa contava com funcionalidades bastante simples e úteis para auxiliar na organização e recuperação de receitas. O objetivo de reviver o S.O.G.R.A. é, através dos conceitos e metodologias de engenharia de software aprendidos, criar um sistema mais robusto e completo que auxilie todos aqueles que se interessam por culinária a manter suas receitas sempre acessíveis, estendendo as funcionalidades da versão anterior. Para tanto, iremos desenvolver o sistema em 5 etapas, sendo as três primeiras de planejamento, análise e projeto, seguindo-se da implementação (primeiramente de um protótipo, para posteriormente completar suas funcionalidades) e, por fim, do teste do sistema.

Etapa 1 - Planejamento

Listagem de Requisitos

Funcionais:

As funcionalidades e operações que o sistema deve oferecer para seus usuários são as seguintes:

• Permitir o cadastro de usuários não cadastrados no sistema, mediante a criação de um perfil de usuário e de uma identificação única.

• Permitir que um usuário cadastrado possa editar as informações presentes no seu perfil de usuário.

• Permitir que o usuário cadastrado consulte o seu livro de receitas, podendo navegar entre as diversas receitas e visualizar informações sobre uma receita específica.

• Permitir que um usuário cadastrado adicione ao seu livro de receitas novas receitas ou receitas compartilhadas por outros usuários.

• Permitir que um usuário cadastrado exclua receitas do seu livro de receitas. • Permitir que um usuário cadastrado modifique as informações sobre as receitas presentes no seu

livro de receitas. • Permitir que um usuário cadastrado realize buscas (baseadas em critérios) sobre o seu livro de

receitas ou sobre o conjunto de receitas compartilhadas por outros usuários. Isso inclui que o usuário veja as informações sobre as receitas buscadas e visualize informações sobre uma receita específica.

• Permitir que um usuário cadastrado cancele sua participação no sistema. O perfil e o livro de receitas do usuário que cancelar sua participação são apagados.

• Permitir que um usuário cadastrado visualize o perfil de outro usuário cadastrado através das receitas compartilhadas por aquele usuário.

• Permitir que um usuário cadastrado envie um recado para outro usuário cadastrado.• Permitir que um usuário visualize os recados que recebeu. • Permitir que um usuário exclua os recados que recebeu.

Não-Funcionais:

Além das funcionalidades acima, o sistema também deve obedecer às seguintes restrições:

• A interface com o usuário deve ser amigável, simples e clara, para agradar o público-alvo do sistema. Isso significa que os elementos de interface não podem ser em número excessivo, não podem ter cores muito contrastantes ou desarmoniosas, não podem ter nomes que confundam o usuário ou estarem mal posicionados. Por ser uma restrição muito subjetiva, é importante que seja sempre levada em conta a opinião do usuário para verificar o obedecimento a esse requisito - requisito de usabilidade.

• O sistema deve funcionar em diversas plataformas (por exemplo, diversos sistemas operacionais) - requisito de implementação.

Glossário de Termos

• Receita: Uma receita é uma entidade abstrata que tem por objetivo guiar alguém no preparo de determinado alimento. Ela é composta por uma lista de ingredientes com suas respectivas quantidades, e de um modo de preparo (descrição da seqüência de passos necessários para preparar o alimento), além, é claro, de ser associada a um nome. Opcionalmente, uma receita possui informações diversas que auxiliam no preparo, como dicas, rendimento, autoria, etc.

• Ingrediente : Um ingrediente é simplesmente um alimento usado na preparação de outro alimento.

• Usuário : Os usuários do sistema, ou usuários cadastrados no sistema, incluem todas as pessoas que se interessam por culinária, seja para fins pessoais (como cozinhar para a família) ou profissionais (como em um restaurante). Entre os usuários cadastrados no S.O.G.R.A., podemos citar cozinheiros profissionais, ajudantes de cozinha, donas de casa, empregadas domésticas, vovós, etc.

• Usuário não cadastrado : São usuários que ainda não possuem cadastro no sistema, podendo apenas acessá-lo para cadastrarem-se.

• Livro de Receitas : Coleção abstrata de receitas chamada simbolicamente de "livro" para remeter ao objeto do mundo real usado para anotar as receitas de determinada pessoa ou grupo de pessoas.

• Perfil de Usuário : Conjunto de informações relevantes sobre um usuário cadastrado no sistema, como por exemplo o nome, endereço, contato eletrônico, preferências alimentares e gastronômicas, etc.

• Recado: Um recado é uma mensagem de conteúdo qualquer enviada de maneira particular de um usuário cadastrado para outro usuário cadastrado. Apenas quem recebe o recado é que pode visualizá-lo. Um recado não pode ser modificado.

Casos de Uso Preliminares

Aqui são apresentados os casos de uso preliminares que, devido a sua natureza intuitiva e grau de abstração, não receberão mais detalhes além de sua descrição textual.

Descrição Textual dos Casos de Uso Preliminares

CADASTRAR-SE

Ator: Usuário não cadastrado

Descrição: O usuário não cadastrado solicita cadastro no sistema, preenche as informações e confirma seu cadastro. O sistema valida as informações do perfil e registra o usuário.

PESQUISAR RECEITAS PÚBLICAS

Ator: Usuário não cadastrado

Descrição: O usuário não cadastrado escolhe pesquisar uma receita pública preenchendo os critérios desejados e confirma a operação. O sistema realiza uma busca e mostra os resultados ao usuário não cadastrado.

PESQUISAR

Ator: Usuário

Descrição: O usuário escolhe pesquisar uma receita (pública ou em seu livro de receitas) ou um outro usuário cadastrado preenchendo os critérios desejados e confirma a operação. O sistema realiza uma busca e mostra os resultados ao usuário.

GERENCIAR RECEITAS

Ator: Usuário

Descrição: O usuário cadastrado identifica-se no sistema, escolhe visualizar seu livro de receitas, e escolhe inserir uma nova receita, editar uma receita já existente ou excluir uma receita registrada.

GERENCIAR RECADOS

Ator: Usuário

Descrição: O usuário cadastrado identifica-se no sistema, escolhe visualizar sua caixa de entrada, e escolhe ler ou excluir um recado existente.

GERENCIAR PERFIL

Ator: Usuário

Descrição: O usuário cadastrado identifica-se no sistema, escolhe editar o próprio perfil e escolhe modificar suas informações pessoais.

CANCELAR PRÓPRIA PARTICIPAÇÃO

Ator: Usuário

Descrição: O usuário identifica-se, escolhe cancelar a própria participação no sistema e a confirma. O sistema apaga o perfil, o livro de receitas e a caixa de entrada daquele usuário, o usuário perde acesso às operações de usuário cadastrado e torna-se um usuário não cadastrado.

Modelo Conceitual Preliminar

Etapa 2 - Análise

Casos de Uso Essenciais

Observação: o caso de uso "Identificar usuário" está presente em todas as operações de um usuário cadastrado e suas indicações de inclusão foram suprimidas para fins de clareza no diagrama.

Descrição Textual dos Casos de Uso Essenciais

CASO DE USO 1 Cadastrar-se

META NO CONTEXTO

Permite que um usuário não cadastrado cadastre-se.

DESCRIÇÃO PASSO AÇÃO

0 Sistema solicita operação.

1 Usuário não cadastrado solicita cadastro no sistema.

2 Sistema solicita informações de perfil que podem/devem ser preenchidas.

3 Usuário não cadastrado preenche as informações.

4 Usuário não cadastrado confirma operação.

5 Sistema valida as informações.

6 Sistema registra o perfil.

7 Sistema notifica que a operação foi bem sucedida.

ALTERNATIVAS E EXTENSÕES

PASSO AÇÃO

1a

Usuário não cadastrado tenta acessar operações de usuários cadastrados:Sistema informa que o usuário não cadastrado deve primeiro cadastrar-se.

4aUsuário não cadastrado aborta operação:Sistema retorna ao estado inicial.

5aSistema detecta informações obrigatórias ausentes ou informações inválidas:Sistema notifica erros e retorna ao passo 2.

6a Sistema não pode registrar informações:Sistema notifica um erro e retorna ao estado inicial.

CASO DE USO 2 Ver o próprio livro de receitas

META NO CONTEXTO

Permite que um usuário visualize seu livro de receitas.



1 Usuário identifica-se.

2 Sistema valida identificação.

3 Sistema mostra as opções de operação.

4 Usuário escolhe ver o próprio livro de receitas.

5 Sistema mostra o livro de receitas daquele usuário.


PASSO AÇÃO

2aSistema detecta erro na validação ou usuário não cadastrado:Sistema notifica que houve um erro ou que o usuário não está cadastrado.

CASO DE USO 3 Inserir receita no próprio livro de receitas

META NO CONTEXTO

Permite que um usuário adicione uma nova receita ou inclua uma receita existente no seu próprio livro de receitas






4 Usuário escolhe inserir uma nova receita em seu próprio livro de receitas.

5 Sistema solicita preenchimento das informações da receita.

6 Usuário preenche as informações.

7 Usuário confirma operação.

8 Sistema valida informações da receita.

9 Sistema registra receita.

10 Sistema informa que a operação foi bem sucedida.


PASSO AÇÃO


4a

Usuário escolhe inserir uma receita de outro livro de receitas para seu próprio:Sistema gera uma referência da receita selecionada para o usuário solicitante.

7aUsuário aborta operação:Sistema retorna ao estado inicial.



CASO DE USO 4 Editar receita no próprio livro de receitas

META NO CONTEXTO

Editar uma receita de própria autoria em seu livro de receitas







5 Sistema mostra livro de receitas do usuário.

6 Usuário escolhe editar uma receita.

7 Sistema mostra dados da receita que podem ser alterados e solicita mudanças.

8 Usuário preenche as alterações.


10 Sistema valida alterações.

11Sistema exibe os dados originais e os dados alterados e solicita confirmação.


13 Sistema registra alterações.

14 Sistema notifica que a operação foi bem-sucedida.


PASSO AÇÃO


9aUsuário aborta operação:Sistema retorna ao estado inicial.


12a Usuário aborta operação:Sistema retorna ao estado inicial.


CASO DE USO 5 Excluir receita do próprio livro de receitas

META NO CONTEXTO

Excluir uma receita do próprio livro (inserida nova ou copiada de outro livro).







5 Sistema mostra livro de receitas do usuário.

6 Usuário escolhe excluir uma receita.

7 Sistema mostra os detalhes daquela receita.

8 Sistema solicita confirmação da operação.


10 Sistema apaga registro da receita.

11 Sistema informa que a operação foi bem-sucedida.


PASSO AÇÃO



10a Sistema não pode apagar as informações:Sistema notifica um erro e retorna ao estado inicial.

CASO DE USO 6 Pesquisar receitas

META NO CONTEXTO

Permitir que um usuário pesquise uma receita dentre as receitas públicas e as receitas de seu próprio livro de receitas.






4 Usuário escolhe pesquisar uma receita

5 Sistema mostra as opções de critérios de pesquisa

6 O usuário preenche os critérios que deseja

7 Usuário confirma a operação

8 Sistema realiza a pesquisa

9 Sistema exibe uma lista de resultados para o usuário


PASSO AÇÃO



Observação: foram escolhidos apenas os casos de uso mais interessantes para serem apresentados até este ponto. Os demais casos são similares e receberão maior detalhamento no decorrer do trabalho.

Modelo Conceitual

O modelo conceitual transmite as informações relevantes sobre as classes. Algumas informações foram omitidas para clareza, e outras explicadas através de notas. Apenas os métodos públicos e mais importantes foram especificados.

Diagrama de Estados

Neste caso, optou-se por especificar os estados para as classes Recado, Receita e Perfil, que estão envolvidas em diversos casos de uso e necessitam de explicação mais detalhada. As demais classes são classes componentes ou classes de controle e seus estados não são relevantes para essa etapa de análise do sistema. Fazer diagramas de estados para todas elas apenas iria confundir e atrapalhar em prol de um formalismo desnecessário.

Diagrama de estados para a classe Recado

Observações: Como a seus membros são congelados, Essa classe não sofre muitas transformações de estado depois de criada

Diagrama de estados para a classe Receita:

Diagrama de estados da classe Perfil

Observações: Para evitar poluição visual no diagrama, o caso de uso de busca de usuários não foi considerado. Adicionalmente, ela é trivial (semelhante à busca descrita no diagrama de estados de receita) e sua presença não acrescentaria informação útil ao diagrama

Etapa 3 - Projeto

Aspectos de Arquitetura e Implementação

Para implementar o sistema, decidiu-se por uma arquitetura de três camadas simples, de acordo com as principais referências de engenharia de software, que divide o sistema em três camadas: Interface, Persistência e Negócio. As classes de interface são responsáveis pela comunicação com o usuário (entrada e saída de dados). A camada de persistência comunica-se com o SGBD e realiza as operações de bancos de dados para salvar os conceitos em meio físico. A camada de negócio é a que foi modelada até o presente momento e a que contém as classes de base, responsáveis pela funcionalidade efetiva do sistema.Além da escolha da arquitetura, optou-se por desenvolver o sistema sobre uma plataforma Web, usando a linguagem PHP 5, que suporta orientação a objetos. Para a persistência, optou-se pelo SGBD MySQL, facilmente integrável com a plataforma Web de desenvolvimento. As demais decisões e modelos de projeto são apresentados de acordo com a notação UML nas seções seguintes.

Casos de Uso Reais

CASO DE USO 1: Cadastrar-se

AÇÃO DO USUÁRIO RESPOSTA DO SISTEMA

0) Sistema pronto para uso (Fig.A1).

1) Usuário não cadastrado clica na opção de cadastrar-se no sistema (Fig.A1) no item (1).

2) Sistema carrega área de cadastro com campos para preenchimento (Fig.B) e aguarda preenchimento do usuário.

3) Usuário não cadastrado preenche os campos obrigatórios (Fig.B) (1), (2), (3), (15) e (4), e pode preencher, opcionalmente, os campos (Fig.B) (5), (6), (7), (8) e (9) para complementar seu perfil.

4) Usuário não cadastrado clica no botão (Fig.B) (10) para enviar os dados para cadastro.

5) Sistema valida os dados (verificação de preenchimento de dados obrigatórios, uso de caracteres inválidos, unicidade de 'nome de usuário', disponibilidade no banco de dados, etc). Se estiverem corretos, ele armazena as informações no banco de dados e informa o usuário que a operação foi realizada com sucesso.

6) Sistema retorna ao estado de pronto para uso na tela principal (Fig.A1).

ALTERNATIVAS, EXCEÇÕES E EXTENSÕES


3.1) Caso o usuário não cadastrado deseje carregar um arquivo de imagem para seu perfil (avatar) adicionando o caminho da imagem de seu disco rígido, ele irá inserir esse caminho no campo (Fig.B) (6) e clicará no botão (Fig.B) (12).

3.2) Sistema valida o upload (verificação do caminho, extensão da imagem, conteúdo malicioso, disponibilidade de serviço no banco de dados, etc). Se estiver correto, ele armazena a imagem em um buffer de visualização e a exibe na área (Fig.B) (13).

3.2.1) Sistema valida o upload. Se algo estiver incorreto, ele aborta a operação de upload de arquivo e notifica o usuário, retornando à tela da Fig.B (mantendo os dados informados nos campos).

3.1.1) Opcionalmente, o usuário não cadastrado poderá clicar no botão (Fig.B) (11) e procurará o arquivo através do painel de interação (exemplo na Fig.C). Após carregar o nome do caminho no campo (Fig.B) (6), o usuário não cadastrado clicará no botão (Fig.B) (12).

3.2) (idem anterior)

4.1) Usuário não cadastrado cancela a operação no botão (Fig.B) (14).

4.2) Sistema informa o usuário que todos os dados serão perdidos e solicita confirmação de cancelamento de cadastro.

4.3) Usuário confirma operação. 6) (idem anterior)

5.1) Sistema valida os dados. Se algo estiver incorreto, então ele retorna à tela da Fig.B na AÇÃO 4 (mantendo os dados informados nos campos), assinala em cores diferenciadas os campos que contêm erros (se houver erros) e notifica o usuário dos erros encontrados.

Fig. A1 - Sistema pronto para uso.

Fig. A2 - Sistema pronto para uso (logado).

Fig. B

Fig. C

CASO DE USO 2: Ver livro de receitas



1) Usuário cadastrado clica na opção de login no sistema (Fig.A1) no item (2).

2) Sistema carrega tela de login (Fig.D) com campos de nome de usuário (1) e senha (2) para serem preenchimentos e aguarda preenchimento do usuário.

3) Usuário preenche os campos de nome de usuário (Fig.D) (1) e senha (2).

4) Usuário clica no botão (Fig.D) (3) para encaminhar a validação de seu login.

5) Sistema valida os dados (verificação de casamento dos dados nome de usuário e senha no banco de dados, disponibilidade no banco de dados, conteúdo malicioso, etc). Se estiverem corretos, abre uma sessão para o usuário e mostra a tela principal (Fig.A) com o sistema pronto para uso, porém como usuário logado.

6) Usuário clica no link para seu livro de receitas (Fig.A2) (3) ou (6).

7) Sistema retorna ao estado de pronto para uso na tela do livro de receitas do usuário (Fig.E).



1.1) Usuário não logado clica no link de Livro de Receitas (Fig.A) no item (3) ou (6).

2) (idem anterior)

4.1) Usuário cancela a operação no botão (Fig.B) (14) ou selecionando outro link.

7) (idem anterior)

5.1) Sistema valida os dados. Se algo estiver incorreto, então ele retorna à tela de login (Fig.D) na AÇÃO 2 e notifica o usuário do problema ocorrido (problemas de acesso à base de dados, nome de usuário não encontrado, nome de usuário e senha não casam, etc).

8) Usuário clica na opção de Logoff (Fig.E) no item (1).

9) Sistema fecha a sessão do usuário e retorna ao estado de pronto para uso na tela principal (Fig.A1).

OBS.: Os passos de login (de 2 a 5) do caso de uso 2 serão válidos para todos os demais casos de uso que necessitem que o usuário do sistema seja um usuário cadastrado.

Fig. D

Fig. E

CASO DE USO 3: Editar o próprio perfil



1) Usuário logado clica na opção de Perfil no sistema (Fig.A2) no item (8).

2) Sistema valida a sessão do usuário e, se estiver válida, carrega área de visualização de perfil (Fig.F).

3) Usuário seleciona a opção de alterar perfil (Fig.F) no item (1).

4) Sistema carrega página para alteração dos dados de perfil (Fig.G) com campos para preenchimento (contendo a informação antiga) e aguarda alterações do usuário.

5) Usuário altera os campos disponíveis (Fig.G) (1) ,(2) ,(3), (13), (4), (5), (8), (9) e (10) que desejar.

6) Usuário clica no botão (Fig.G) (11) para confirmar a operação.

7) Sistema solicita confirmação da operação.

8)Usuário confirma ação.

9) Sistema valida os dados (validade da sessão, uso de caracteres inválidos, disponibilidade no banco de dados, etc). Se estiverem corretos, ele armazena as informações no banco de dados e informa o usuário que a operação foi realizada com sucesso.

10) Sistema retorna ao estado de pronto para uso na tela de visualização do perfil do usuário (Fig.F).



2.1) Sistema detecta que a sessão do usuário expirou.

2.2) Sistema informa o usuário que a sessão expirou, carrega tela de login (Fig.D) com campos de nome de usuário (1) e senha (2) para serem preenchimentos e aguarda preenchimento do usuário.

3.1) Usuário seleciona voltar para a página principal (Fig.F) (3).

3.2) Sistema retorna ao estado de pronto para uso na tela principal (Fig.A2)

6.1) Usuário clica no botão de cancelar operação (Fig.G) (12).

6.2) Sistema informa que todas as alterações serão perdidas e pede confirmação do usuário.

6.3) Usuário confirma operação. 6.4) Sistema retorna para a tela de perfil (Fig.F).

8.1) (análogo ao item 6.1)

9.1) Sistema valida os dados. Se algo estiver incorreto, então ele retorna à tela de alterações (Fig.G) na AÇÃO 4 (mantendo os novos dados informados nos campos), assinala em cores diferenciadas os campos que contêm erros (se houver erros) e notifica o usuário dos erros encontrados.

Fig. F

Fig. G

CASO DE USO 4: Apagar recado


0) Sistema pronto para uso (Fig.A).

1) Usuário logado clica na opção de Caixa de Entrada no sistema (Fig.A2) no item (4) ou (7).

2) Sistema verifica validade da sessão do usuário e, se estiver válida, exibe a tela de caixa de entrada de mensagens (Fig.H).

3) Usuário seleciona na mensagem que desejar clicando sobre ela (Fig.H) como no item (3).

4) Sistema exibe a mensagem com o dados descritivos daquela mensagem (Fig.I).

5) Usuário clica em apagar esta mensagem (Fig.I) no item (2).

6) Sistema solicita confirmação da operação.

7) Usuário confirma operação. 8) Sistema exclui a mensagem do banco de dados e retorna para a tela de caixa de entrada (Fig.H).





3.1) Usuário seleciona voltar para a página principal (Fig.H) (7).

3.2) Sistema retorna ao estado de pronto para uso na tela principal (Fig.A2)

3.3) Usuário seleciona várias mensagens de uma vez marcando as checkboxes (Fig.H) (2) que desejar.

3.4) Usuário seleciona apagar mensagens selecionadas (Fig.H) (6).

3.5) Sistema notifica que todas as mensagens selecionadas serão permanentemente apagadas e solicita confirmação da operação.

3.6) Usuário confirma ação.3.7) Sistema exclui as mensagens selecionadas do banco de dados e retorna a tela de caixa de entrada (Fig.H).

5.1) Usuário clica em voltar para caixa de entrada (Fig.I) (3).

5.2) Sistema retorna a tela de caixa de entrada (Fig.H).

Fig. H

Fig. I

CASO DE USO 5: Ver receita (de autoria de outro usuário) no próprio Livro de Receitas

OBS.: Incluso no caso de uso 2 (Ver livro de receitas)


0) Sistema pronto para uso (Fig.E).

1) Usuário clica no nome de uma receita (Fig.E) (3) para visualizá-la.

2) Sistema verifica validade da sessão do usuário e, se estiver válida, exibe a tela com os dados da receita (Fig.J).





2.3) Usuário clica em enviar recado (Fig.J) (2) 2.4) Inicia-se o caso de uso "Enviar Recado"

2.5) Usuário clica em excluir um comentário (Fig.J) (4) que ele mesmo tenha colocado.

2.6) Sistema notifica que aquele comentário será apagado e solicita confirmação da operação.

2.7) Usuário confirma ação.2.8) Sistema excluir aquele comentário da base de dados e retorna para a tela da receita visualizada (Fig.J).

Fig. J

CASO DE USO 6: Pesquisar Usuários


0) Sistema pronto para uso (Fig.A).

1) Usuário clica na opção de Pesquisa Avançada (Fig.A1) no item (9).

2) Sistema exibe a tela de Pesquisa Avançada (Fig.K).

3) Usuário clica na opção de Pesquisa Avançada de Usuários (Fig.K) (2).

4) Sistema verifica validade da sessão do usuário e, se estiver válida, exibe a tela de Pesquisa Avançada de Usuários (Fig.L), e aguarda preenchimento dos critérios de pesquisa.

5) Usuário preenche os critérios (Fig.L) (1), (2), (3), (4) e (5), e confirma operação solicitando a pesquisa (6).

6) Sistema valida as informações (formatação do email, conteúdo malicioso, disponibilidade do banco de dados, etc) e, se tudo estiver correto, exibe uma tela de resultados (Fig.M).





5.1) Usuário cancela a operação (Fig.L) no item (7).

5.2) Sistema notifica que todos os critérios de pesquisa inseridos serão apagados e solicita confirmação da operação.

5.3) Usuário confirma ação. 5.4) Sistema retorna a tela de Pesquisa Avançada (Fig.K).

5.3.1) Usuário cancela ação.

5.3.2) Sistema permanece na tela de Pesquisa Avançada de Usuários (Fig.L) mantendo os dados dos critérios de pesquisa fornecidos e aguardando ação do usuário.

6.1) Sistema detecta algum problema na validação das informações.

6.2) Sistema retorna a tela de Pesquisa Avançada de Usuários (Fig.L), assinala em cores diferenciadas os campos que contêm erros (se houver erros) e notifica o usuário dos erros encontrados.

6.3) Usuário clica no nome de algum usuário (1) da tela de resultados (Fig.M)

6.4) Sistema inicia o caso de uso "Ver Perfil de Usuário".

Fig. K

Fig. L

Fig. M

Modelo Conceitual

Para facilitar a compreensão, os modelos foram separados de acordo com as camadas especificadas na arquitetura / pacotes. O modelo conceitual da camada de negócio é semelhante ao da etapa de análise e será repetido aqui com modificações sutis para adaptar-se a aspectos de implementação. As camadas de persistência e de interface foram projetadas levando-se em conta aspectos de implementação descritos anteriormente. A comunicação entre as classes dos pacotes pode ser observada nos diagramas de seqüência, na próxima sessão.

Modelo Conceitual da Camada de Negócio

Modelo Conceitual da Camada de Persistência

Modelo Conceitual da Camada de Interface

Diagramas de Seqüência

Para os casos de uso modelados no projeto, foram criados os diagramas de seqüência que evidenciam as responsabilidades de cada classe e a interação entre elas.

Aspectos omitidos:

• Chamada a métodos get e set triviais.

• Chamadas com parâmetros excessivamente numerosos, conhecidos ou dedutíveis (como os construtores, por exemplo).

• Chamadas a métodos auxiliares não relevantes, e a métodos de objetos primitivos da linguagem ou biblioteca.

• Retorno de funções com retorno trivial.

• Tipos de parâmetros e retornos cujo nome indica claramente de que tipo de objeto se trata, por exemplo, o objeto "meuPerfil" não terá associado um tipo, pois é óbvio que trata-se de um objeto do tipo Perfil.

• Funções e trechos de código que não podem ser descritos pela abordagem orientada a objetos

na linguagem escolhida (funções javascript, páginas html, etc.) • Condições de erro ou exceções decorrentes de problemas de funcionamento (Banco de Dados,

Rede) ou bugs, cujo tratamento é semelhante em todos os casos (chamar a função exibirErro() em GUI).

Convenções:

• Chamadas a classes são sempre estáticas, chamadas a objetos são sempre a métodos de instância

• Como, na linguagem de implementação, o tempo de vida dos objetos é igual ao do método/função em que foram declarados, e não existe uma função "main" para manter os objetos que devem ficar vivos entre uma chamada e outra, o único recurso é armazenar os objetos do usuário (Perfil, CaixaDeEntrada, LivroReceitas) na sua sessão. No entanto, não há como compartilhar os dados de uma sessão entre vários usuários. Como um usuário pode alterar o Livro de receitas de outro (modificando uma receita que aquele usuário adicionou) ou sua caixa de entrada (enviando-lhe uma mensagem), esses objetos não serão mantidos entre as chamadas (até porque isso tornaria o sistema pesado e pouco escalável, contrariando o requisito não-funcional de desempenho). O único objeto mantido sempre vivo é o perfil do usuário (privativo, ninguém pode alterá-lo a não ser o próprio usuário). Os demais métodos chamados são estáticos ou de instâncias que morrem ao fim da chamada e têm como propósito fornecer uma maneira estruturada de passar parâmetros entre classes.

Sub-diagramas:

• Conectar DB

• Get Receita

Equivalências e analogias:

• O diagrama para o caso de uso "Cancelar Própria Participação" é semelhante aos diagramas de "Excluir receita do próprio livro de receitas", "Excluir Comentário" e "Excluir Recado recebido", trocando-se apenas as referências a Perfil e suas classes relacionadas por referências às classes relacionadas a Receita, Comentário e Recado, respectivamente. Por esse motivo, os diagramas não acrescentariam informação útil e foram omitidos. Cabe aqui ressaltar que as classes gerentes de Comentario e de receita são as mesmas (GUIReceitas, CadastroGeralReceitas e DBReceitas para interface, negócio e persistência, respectivamente).

• Da mesma forma, o diagrama de "Editar receita no próprio livro de receitas" é análogo ao diagrama para "Editar o próprio perfil", trocando-se as classes e métodos respectivos a Perfil pelos de Receita.

• O diagrama do caso de uso "Comentar Receita" foi ocultado por ser parecido com o do caso de uso "Enviar recado", trocando-se apenas as classes de Recado pelas de Comentário.

• O diagrama de "Ver próprios recados" é semelhante ao de "Ver próprio livro de receitas", trocando-se o LivroDeReceitas pela CaixaDeEntrada e Receitas por Recados.

• O diagrama para "Pesquisar Usuários" difere pouco de "Pesquisar Receitas (públicas)" e foi omitido, podendo ser facilmente deduzido, se necessário. Os casos de uso reais de “Pesquisa Avançada” são equivalentes ao diagrama de seqüência de "Pesquisar Receitas (públicas)".

Modelo de Banco de Dados

Como anexo ao projeto UML padrão, foi desenvolvido um modelo baseado na técnica de modelagem Entidade-Relacionamento para o banco de dados responsável pela parte operativa da camada de persistência do sistema. Abaixo, os dois modelos gerados: o primeiro é o modelo conceitual, em que detalhes de implementação são ocultos e apenas os conceitos são explicitados; e o segundo é o modelo lógico, com as tabelas, chaves estrangeiras e tipos de campos indicados. Para tornar a apresentação mais clara, ambos os modelos usam a notação "pata de corvo", onde a linha significa "1" e a pata de corvo significa "n".

Modelo Conceitual

Modelo Lógico

S.O.G.R.A. 2 - Sistema de Organização e Gerência de...

Documents

Transcript of S.O.G.R.A. 2 - Sistema de Organização e Gerência de...