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êmica¹. 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ências²³⁴. 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ócio⁵. 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 Funcionalidades 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 Funcionalidades 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 Funcionalidades da aplicação. Cada Funcionalidade ajuda os usuários do tipo Secretaria Acadêmicaes 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 .