Diagramas de classe

O diagrama de classe “fornece uma visão geral do sistema de destino através da descrição dos objetos e classes dentro do sistema e as relações entre eles. Ele fornece uma ampla variedade de usos; de modelar a estrutura de dados de domínio específico para o projeto detalhado do sistema de destino”. (VISUAL ..., C, 2016).

Nesta seção são apresentados os digramas de classe de entidade e de controladores elaborados para a implementação do sistema. Esses estão separados por pacote e possuem uma breve descrição.

4.3.3.1. Diagramas de entidade

Os diagramas de entidades têm o objetivo de apresentar as entidades que compõe o sistema e seus relacionamentos. Os relacionamentos são representados por meio de agregação (losango branco) e composição (losango preto), os quais possuem um significado não apenas de relacionamento comum, mas também como as entidades são persistidas.

 Agregação: no contexto de persistência adotado nesse trabalho, essa relação representa que uma entidade possui uma referência da chave primária da tabela da outra entidade, ou seja, possui uma chave estrangeira. Essa chave estrangeira é identificada pelo nome da tabela de destina mais a palavra “id” (exemplo: userId), e por um campo transitório identificado no diagrama pelo prefixo “~”, o qual é utilizado para realização de joins.

 Composição: no contexto de persistência adotado nesse trabalho, essa relação identifica que a entidade relacionada está contida nessa entidade, sendo armazenada no banco de dados MongoDB como um subdocumento ou um vetor de subdocumentos. Por não ser uma chave estrangeira seu

campo sempre possuirá seu tipo sendo a classe da entidade relacionada ou um vetor dessa.

A Figura 22 apresenta o diagrama de classes para o pacote “Usuários”. Nesse diagrama apontamos uma breve descrição das entidades:

 User (usuário): Essa entidade representa os dados básicos de um usuário do sistema, como nome de usuário, e-mails, etc. O campo de senha fica armazenado na propriedade services e este é codificado usando o padrão de codificação do framework Meteor (bcrypt11_).

 UserProfile (perfil do usuário): Essa classe representa as informações de perfil do usuário, contendo: nome, sobrenome e o nível de permissão do usuário.

 UserEmail (e-mail de usuário): Classe represando um e-mail do usuário. Um usuário pode conter diversos e-mails conforme especificado na classe usuário. Um e-mail possui uma flag que indica se esse já foi verificado (por meio de e-mail de verificação), sendo esse especificado na propriedade verified.

Figura 22 - Diagrama de classe de entidades do pacote usuários.

11 _{Mais informações em: https://en.wikipedia.org/wiki/Bcrypt. Repositório GitHub:}

Já a Figura 23 apresenta o diagrama de classes para o pacote “Empresas”. Nesse diagrama é descrito como foi implementado a entidade Empresa (Company) e seus relacionamentos.

Cada empresa (Company) possui seus campos básicos, como CNPJ (Cadastro Nacional de Pessoas Jurídicas), endereço, etc. e está associada a uma categoria. Essa categorização das empresas tem o objetivo de configurar melhor a aplicação a fim de exibir e buscar preferencialmente os questionários e questões que mais se adequam a categoria da empresa. Além disso a empresa possui um vetor de usuários, que representa os usuários que possuem acesso à empresa.

Outro aspecto das empresas é que elas devem possuir uma assinatura de um plano para poderem utilizar o sistema. Os planos garantem mais ou menos funcionalidades conforme de acordo com o seu nível (ver regra de negócio RN13). As funcionalidades disponíveis são armazenadas em um enumerador (PlanFeatureEnum), e cada plano é composto de seus detalhes (descrição e preço) e um conjunto de funcionalidades que são armazenadas em uma coleção própria pois vários planos podem possuir uma mesma funcionalidade.

No diagrama de classes do pacote “Questões”, veja Figura 24, são apresentadas as entidades necessárias para representar as questões utilizadas nos questionários.

Cada questão é representada pela classe Question, sendo essa composta de alternativas (classe QuestionAlternative), sendo de um tipo (conforme enumerador QuestionTypeEnum) pode ser classificada em várias categorias (interface IQuestionCategory), conforme RN9. As questões podem ser do tipo: texto, múltipla escolha, várias alternativas (checkbox) ou de avaliação por estrelas (RN3). Conforme o tipo da questão, essa poderá possuir diversas alternativas, múltipla escolha ou várias alternativas, sendo limitadas a no mínimo 2 alternativas e no máximo 7, conforme RN3, com o objetivo de evitar que o cliente que realiza a avaliação se canse ou se confunda ao responder o questionário. Se a questão for do tipo texto (campo livre para respostas discursivas), a questão não possuirá alternativas.

Figura 23 - Diagrama de classes para entidades do pacote empresa. Observe que a classe Company faz uso da entidade User presente no pacote usuários.

Como citado anteriormente, as questões podem ser categorizadas tendo como principal motivo a melhora nas buscas de questões quando é efetuado a construção dos questionários. A categorização de questões não é obrigatória, mas a utilização dela melhora a experiência do usuário durante a elaboração de questionários.

As questões poderão ser públicas (pré cadastradas) ou privadas (cadastradas pela empresa), segundo RF1, RF2 e RN8, sendo identificadas pela ausência ou não da propriedade companyId na questão persistida, respectivamente. As questões públicas, podem ser utilizadas por todas as empresas em seus questionários, porém sua edição é bloqueada sendo necessário efetuar um clone para seu banco de questões da empresa.

Após uma questão ser criada, se esta já estiver associada a um questionário, não é possível alterar o tipo da questão, bem como adicionar ou remover alternativas, sendo permitido apenas a edição das descrições. Veja regra de negócio RN16.

Figura 24 - Diagrama de classes para entidades do pacote questões.

No diagrama de classes do pacote “Questionários”, ver Figura 25, são apresentadas as entidades necessárias para poder elaborar questionários dinâmicos e como ocorrem suas relações.

Na entidade questionário conforme pede a regra de negócio RN10, os questionários são categorizados (atributo categoryId). O objetivo da categorização é de facilitar a busca e melhorar a usabilidade do sistema, pois com questionários categorizados as empresas podem efetuar a separação mais facilmente de questionários específicos para avaliar um determinado ponto de seu negócio (ex.: infraestrutura).

Outra funcionalidade é que questionários pré cadastrados podem ser direcionados a empresas de um ramo específico. Isso é realizado por meio do atributo targetCompanyCategoryId, identificando assim a categoria de empresa que esse questionário de aplica. O atributo companyId, é uma chave estrangeira e seu objetivo é identificar qual empresa esse questionário pertence, caso seja nulo esse questionário é público e pode ser utilizado por todas as empresas cadastradas no sistema.

Como um requisito especificado pela regra de negócio RN5, que diz respeito aos questionários serem dinâmicos, optou-se pela utilização de uma lista ligada múltipla. Uma lista ligada múltipla é uma lista ligada na qual cada nodo possui dois ou mais links de ligação apontando nodos em sua sequência, desse modo permitido que uma única lista possa ter diferentes maneiras de iterar sobre ela. (WIKIPEDIA, L. 2016). Essa lista ligada múltipla é representada pela entidade NextQuestionMap, a qual representa um link para a próxima questão. A primeira questão do questionário (nodo inicial) fica armazenado na entidade Questionnaire pelo atributo firstQuestionId. Por fim, as respostas dos questionários são representadas pela entidade QuestionnaireAnswer, as quais ficarão armazenadas na coleção QuestionnaireAnswers. Na entidade QuestionnaireQnswer, a propriedade userId tem a função de armazenar qual foi o usuário que aplicou esse questionário, para posterior uso em relatórios.

O diagrama de classes de entidades do pacote “metas”, na Figura 26, apresenta as entidades necessárias para criar uma meta. Uma meta no sistema, indica quantas respostas se deseja obter para um determinado questionário em um determinado período de tempo. Para isso o campo startDate e endDate definem a data de início e fim da meta, respectivamente. O campo numberOfAnswers determina o número de respostas que se deseja obter para o questionário. Por fim o campo userId identifica qual foi o usuário que criou a meta.

Figura 26 - Diagrama de classes para entidades para o pacote “Metas”

4.3.3.2. Diagramas de classes de controle

Os diagramas de classes de controle têm o objetivo de apresentar a estrutura de classes controladoras (componentes), serviços, métodos em servido e como a

comunicação entre eles ocorre. Os diagramas representam a estrutura implementada, que segue a arquitetura de sistema proposta conforme a seção 4.3.1, na Figura 16.

Por serem diagramas mais extensos e repetitivos (todos seguem o mesmo padrão), apenas serão apresentados os diagramas de classe de controle para os pacotes usuário (Figura 27) e questões (Figura 28). Os demais pacotes possuem estrutura de classes semelhantes ao apresentados aqui.