Ensaio Entidade-Relacionamento de “Controle de Estoque”
1 Situação de Modelagem
Para os estudantes da matéria de Bancos de Dados, mostrei o vídeo de uma aplicação de gestão acadêmica1. A intenção da atividade era a de elaborar um modelo entidade-relacionamento (MER) para a interação de Login
entre um usuário e uma aplicação.
1.1 Interação de login
A interação de login é típica em aplicações de software . O usuário, atuando como um Administrador
, digita o seu login
(MASTER
, por exemplo), seguido da sua senha
. Ao clicar no botão Ok, ele abre o elenco de funcionalidades da aplicação para o seu uso:
Partindo da interpretação do que foi visto no vídeo, solicitei que fizessem um modelo ER para suportar a interação de login. Como etapa preparatória, sugeri que elaborassem um modelo do caso de uso Login
. Após alguns momentos, os estudantes demonstraram uma reação de surpresa.
É comum encontrarmos exemplos deste caso de uso em diversas referências234. Vamos interpretar a interação de login no contexto (muitas vezes não explícito) do subsistema de autenticação
:
Quais seriam os elementos de um MER nesta interpretação?
1.2 Modelo ER (i)
A maior parte dos estudantes criou um tipo de entidade Administrador
com dois atributos chamados login
e senha
. O diagrama ilustra o MER por eles elaborado:
Desta forma, um usuário atuando no papel de Administrador
poderia ser autenticado com base no seu login
e na sua senha
. Sob o ângulo de modelagem de dados, será possível confirmar a seguinte afirmação: “é verdade que existe o login
e a senha
na base de dados”. Neste momento, fiz um questionamento: qual seria o modelo ER em uma situação de Login
no contexto de um subsistema de autorização
?
2 Acesso a Funcionalidades
2.1 Modelos de Casos de Uso
Cabe lembrar que um modelo de casos de uso revela o ponto de vista dos atores em relação a um processo de negócio5. O ponto de vista é capturado no papel desempenhado pelo ator. Desta forma, um modelo de caso de uso indica quais funcionalidades o usuário está autorizado a utilizar quando atua em um determinado papel. O diagrama para o caso Login
no contexto de autorização
é:
Quais seriam os tipos de entidades envolvidos nesta situação? Um delas seria Secretaria Acadêmica
. Existiriam outros tipos? E qual seria o tipo de relacionamento entre eles?
2.2 Modelo ER (ii)
A ideia primária de um modelo de caso de uso é revelar quais funcionalidades devem ser oferecidas pelo subsistema para ajudar o ator a atingir os seus objetivos. Assim, ao atuar em um específico papel, o usuário teria acesso a um grupo de funcionalidades; em um outro de papel, o usuário teria acesso a outro grupo de funcionalidades.
Neste sentido, o caso de uso Login
se degenera em um passo a ser realizado pelo ator para atingir o seu objetivo naquele papel. Ao cumprir uma tarefa, um usuário atuando como Secretaria Acadêmica
não tem por objetivo realizar um login. Para atuar como Secretaria Acadêmica
, este usuário faz um login para ter acesso às funcionalidades da aplicação que lhe permitem atingir os seus objetivos, como cadastrar estudantes e listar os matriculados em ordem alfabética, por exemplo. Em termos de um modelo ER, teríamos o diagrama:
Ou seja, no papel de Secretaria Acadêmica
, o usuário terá uma única Autorização
para acessar as Funcionalidade
s da aplicação (eventualmente, nenhuma funcionalidade lhe será acessível). Cada Funcionalidade
sempre terá alguma Autorização
para ser útil a algum usuário que atue como Secretaria Acadêmica
. No diagrama, o tipo de entidade Autorização
foi modelado como uma entidade fraca: o seu atributo de identificação resultará da composição da senha
com login
.
2.3 Modelo ER (iii)
Ao modelarmos o tipo de uma autorização como uma entidade fraca, tomamos a decisão de definir o seu atributo identificador como sendo do tipo composto. Uma ocorrência de Autorização
será identificada por um valor composto pela sua senha
com o login
de uma Secretaria Acadêmica
. Esse modelo é:
Como seria a leitura deste diagrama? Uma ocorrência do tipo Secretaria Acadêmica
terá um login
e uma senha
de acesso a um grupo de Funcionalidade
s da aplicação. Não se trata, aqui, de uma senha de autenticação: é uma senha de autorização.
3 Combinação de Perspectivas
Em face dos diferentes modelos ER necessários para suportar os subsistemas de autenticação
e de autorização
, a tela da aplicação-exemplo original deve ser suportada — e isso é apenas uma conjectura — por uma composição revelada no DER:
Do ponto de vista operacional, é comum adotarmos uma mesma combinação de login
-senha
para um usuário que atue como Secretaria Acadêmica
. Tal decisão procura atender ao requisito não-funcional de “usabilidade” da aplicação:
Um usuário, desempenhando o papel de Secretaria Acadêmica
, fornece um par login
-senha
para se autenticar e receber autorização de acesso às diversas Funcionalidade
s da aplicação. Cada Funcionalidade
ajuda os usuários do tipo Secretaria Acadêmica
es a atingirem os seus objetivos.
4 Conclusão
Após apresentar uma típica janela de interação de Login
, os estudantes elaboraram um modelo ER enfatizando o tipo de entidade Administrador
, caracterizado pelos atributos login
e senha
. Entretanto, ao explicitar o subsistema autenticação
como contexto do Login
em um modelo de caso de uso, outra consideração pode ser feita: quais funcionalidades da aplicação estariam acessíveis para o Administrador
?
Um ângulo de modelagem diferente ajudou a lidar com esta preocupação. A interação de Login
foi contextualizada no subsistema autorização
. O modelo ER, revisado, expôs o tipo de entidade Funcionalidade
acessível para as secretarias conduzirem as suas atividades.
A combinação destes dois modelos de casos de uso resultou em modelo ER com dois tipos de entidades (Secretaria Acadêmica
e Funcionalidade
) caracterizadas pelos atributos login
, senha
e código
.
- Sistema de Gestão Educacional — Delta SGE, página
http://www.youtube.com/watch?v=Qvpox-tYeac
, acessada no dia 7/7/2013.↩ http://www.dmo.fee.unicamp.br/~henrique/cursoc++/diagrama.pdf
↩http://wiki.stoa.usp.br/Casos_de_Uso/Efetuar_Login
↩http://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso
↩- Jacobson, I.; Spence, I.; Bittner, K.; USE-CASE 2.0 — The Guide to Succeeding with Use Cases, Dec 2011,
http://30db.co/ebooks/Use-Case_2_0_Jan11.pdf
, acessado no dia 7/7/2013.↩
Tópicos recentes
Categorias
Tags
Abstração Ambientes de Aprendizagem Híbridos Presenciais Arquitetura de Von Neumann Backus Casos de uso Ciência da Computação Cálculo de Pi David Tall Desenvolvimento de Software Dissertação Doutorado Encontros Engenharia de Software Ensino FALCOM Fábula OCC-RDD Fábula PXP Ghergich IA Jogos de Tabuleiro em Aulas de Computação Mestrado Mestre Mecânico Meta-Modelo MMS Modelagem de Software Modelos ER Modelos Matemáticos Máquina Abstrata Método de Monte Carlo Narrativa Narração de Histórias OCC-RDD Padrões Adaptativos Parnas Programação de Computadores PXP Simulação Estatística Software Biomimético Taleb Tecnologias Adaptativas TIC TIDD UML WTA Ética