ISSN 0798 1015

Vol. 40 (Nº 2) Ano 2019. Pág. 13

Um método de ensino usando a aprendizagem baseada em problema para traduzir um requisito não-funcional para aspecto

A teaching method using problem-based learning to translate a non-functional requirement into aspect

SIQUEIRA, Leandro 1; GUEIBER, Ezequiel 2; MATOS, Simone 3

Recebido: 05/08/2018 • Aprovado: 03/12/2018 • Publicado 21/01/2019

Conteúdo

1. Introdução

2. Técnicas para elicitação de requisitos não-funcionais

3. Método de ensino proposto para traduzir um RNF para um aspecto usando um BPL

4. Aplicação do método proposto

5. Conclusões

Referências bibliográficas

1. Introdução

O mercado de trabalho exige do profissional de informática um alto nível de conhecimento. A expectativa do mercado é receber um profissional que saiba aplicar seu conhecimento para solucionar problemas e trabalhar em equipe (EVENSON; HMELO, 2000), além de ser capaz de pensar de forma crítica. Observando esse cenário se percebe a necessidade de criar um método de ensino que prepare o aluno conforme as expectativas do mercado.

A Aprendizagem Baseada em Problema (Problem Based Learning - PBL) é uma das inovações significativas para educação profissional (BOUD; FELETTI, 1997; DUCH, GROH, ALLEN, 2001). PBL é uma abordagem pedagógica que possui como princípio, o uso de problemas do mundo real e estudos de caso para aumentar os níveis de integração e aquisição do conhecimento (JACINTO; DE OLIVEIRA, 2007). As atividades desenvolvidas nesse processo são orientadas de modo que os alunos desenvolvam habilidades meta-cognitivas que permitam a identificação de várias soluções para o mesmo problema (MELO-SOLARTE, BARANAUSKAS; 2008).

Gomes, Brito e Varela (2016) e Sockalingam et al. (2011) apontam os pontos relevantes em relação ao uso da abordagem baseada em problemas na formação do aluno no ensino superior, tais como: desenvolver o raciocínio, pesquisa e resolução de problemas para que consigam se adaptar as diversas mudanças do mercado profissional. Devincenzi et al. (2017) propôs algumas tecnologias persuasivas como o uso de gatilhos de alto aprendizagem que permitem ao aluno identificar temas em que possui dificuldade de entendimento durante a etapa de auto-aprendizagem.

Na PBL a responsabilidade do aluno é resolver o problema enquanto a do professor é direcionar as pesquisas de solução do problema realizando indagações com o objetivo de orientá-los a refletirem sobre suas proposições e contradições. O professor é também responsável por realizar dinâmicas que propiciem o aprendizado de todos e estimule o trabalho em equipe (COSTA et al.; 2007). Apesar dessa postura do professor, o aluno deve ser o sujeito ativo.

Uma das grandes dificuldades enfrentadas por alunos de computação dentro do desenvolvimento de software é a elicitação de requisitos de sistema. Essa elicitação permite identificar o que precisa ser construído. Trabalho em equipe e pensamento crítico são habilidades fundamentais para que a elicitação de requisitos seja realizada com sucesso.

Este trabalho utiliza a abordagem PBL para desenvolver essas habilidades em disciplina de computação para ensinar a separação de requisitos. Os requisitos de sistemas são divididos em Requisitos Funcionais (RF) e Requisitos Não-Funcionais (RNF). Requisitos Funcionais compreendem o negócio do cliente. Requisitos Não-Funcionais se relacionam com padrões de qualidade como confiabilidade, desempenho, robusteza e outros (XAVIER, 2009).

O aluno deve elicitar os Requisitos Funcionais porque são esses que representam o que o cliente deseja que o software faça. Por sua vez, a identificação dos Requisitos-Não Funcionais permite ao software realizar, de forma satisfatória, o que deve ser feito.

O modo com que a elicitação de requisitos é abordada em sala costuma dar maior ênfase aos Requisitos Funcionais e os Requisitos Não-Funcionais acabam ficando em segundo plano.

Grande parte dos métodos para elicitar requisitos tem o objetivo de identificar os Requisitos Funcionais do sistema. Porém, erros devido a não elicitação ou a elicitação incorreta dos RNFs estão entre os mais caros e difíceis de corrigir, uma vez que um sistema tenha sido implementado (BROOKS; 1987, CYSNEIROS, 2001; DAVIS; 1993).

Este artigo apresenta o método de ensino que promove o pensamento crítico e trabalho em equipe usando como base a abordagem PBL. O método proposto traduz RNFs para aspectos.  A justificativa para propor um método utilizando esse paradigma é que a Orientação a Aspectos consegue tratar adequadamente as Preocupações Transversais que os outros métodos da literatura não contemplam. Essa característica permite elevar o grau de reusabilidade do código-fonte e o nível de manutenibilidade e modularidade do software.

O método proposto contempla a disposição de carteiras e equipamentos necessários para a solução do problema proposto. Esta deve ser determinada de modo que permita aos alunos interagirem entre si e outros grupos.

A troca de informação entre os grupos e a análise crítica de suas proposições e contradições devem ser estimuladas pelo professor. Da mesma forma o professor deve coordenar a discussão de modo que os alunos criem e mantenham um foco produtivo. No dia da apresentação da solução encontrada, as carteiras podem ser organizadas em forma de semicírculo para facilitar a comunicação com todos os alunos da sala.

Este artigo está organizado da seguinte forma. A seção 2 descreve dois métodos para identificação de RNFs da literatura. A seção 3 apresenta o método proposto para traduzir RNFs para aspectos utilizando PBL. A seção 4 descreve a aplicação do método proposto. A seção 5 apresenta a conclusão sobre o método proposto e proposta de trabalho futuro.

A principal tarefa dentro do desenvolvimento de software é a elicitação de requisitos. Os Requisitos Não-Funcionais e Requisitos Funcionais são difíceis de serem elicitados porque eles são subjetivos.

A subjetividade é um problema grande dentro do desenvolvimento de software. Porém, o problema dos RNFs é potencializado porque eles têm uma natureza mais abstrata e são descritos de forma breve e vaga (CYSNEIROS, 2001; CHUNG et al., 1999).

Gastaldo e Midorikawa (2003) apresentam um processo de Engenharia de Requisitos para identificar os Requisitos Não-Funcionais de desempenho. Para inserir um requisito desse tipo que não foi tratado desde o início do projeto pode ser necessário mudar a arquitetura de software, hardware e até mesmo a concepção da solução do problema. O processo apresentado fornece os subsídios necessários para que o analista de sistema identifique os RNFs de desempenho logo nas primeiras fases do desenvolvimento de software.

Xavier (2009) propõe um método para integração dos requisitos não-funcionais aos modelos de processos de negócio, por meio de notações intuitivas para todos os usuários envolvidos no processo. Esse método fornece as ferramentas necessárias para que o analista de sistemas compreenda o negócio da empresa, o escopo do software e melhore a comunicação entre todos os envolvidos no desenvolvimento do sistema.

A grande dificuldade apresentada por esses métodos é que eles não tratam adequadamente as Preocupações Transversais do sistema e não estabelece um método que propicie a integração entre o grupo para a identificação destes requisitos, o que poderia melhorar a qualidade da solução.

Os RNFs identificados por estes métodos não são encapsulados dentro de um aspecto. Isso resultará em espalhamento e entrelaçamento de código e, consequentemente, diminuirá os níveis de reuso de código e manutenibilidade do sistema. Porém, esses métodos podem ser utilizados para gerar os RNFs que serão aplicados em matrizes adjacentes.

A atenção dada aos Requisitos Não-Funcionais é inversamente proporcional a sua importância. O método proposto tem o objetivo de ensinar uma técnica para tradução de um RNF para um aspecto que possa ser aplicada por alunos de computação ou áreas afins. Durante a aplicação do método é possível observar que a elicitação de RNFs é parte do processo para tradução de RNFs para aspectos.

A tradução de um RNF para um aspecto propicia mais vantagens em relação à apenas a elicitação de Requisitos Não-Funcionais dentro do desenvolvimento de software.

Utilizando a tradução de RNFs para aspectos é possível diminuir o entrelaçamento e espalhamento de código. Isso resultará em índice mais alto de reuso de código e níveis maiores de modularidade e manutenibilidade do sistema.

A Figura 1 ilustra um diagrama de atividades UML (Unified Modeling Language) mostrando as atividades realizadas para ensinar essa técnica proposta. A abordagem PBL foi aplicada nas etapas 'Desenvolver casos de uso e Descrição Textual' e 'Aplicar Descrição Textual em matriz adjacente'.

Figura 1
Modelo do método de ensino para elicitação de aspectos

Diagrama de Caso de Uso exibe o comportamento do sistema a partir da perspectiva do usuário (RUMBAUGH et al., 2005). O principal objetivo desse tipo de diagrama é obter os Requisitos Funcionais do sistema. Para traduzir os RNFs do sistema em aspectos o aluno utilizará a Descrição Textual (DT) de cada caso de uso. Enquanto um Diagrama de Caso de Uso exibe, de forma genérica, as funcionalidades do sistema, a Descrição Textual de um caso de uso exibe os passos que compõem essa funcionalidade.

No Desenvolvimento de Software Orientado a Aspectos um RNF é geralmente mapeado para um aspecto. Um detalhe importante em relação aos RNFs é percebido durante o levantamento de requisitos. Se o cliente exigir explicitamente que um RNF esteja presente no sistema, esse RNF torna-se um RF.

Em seu estudo Mairiza et al. (2010) apontam os cinco RNFs mais frequentemente identificados no desenvolvimento de software: Desempenho, Confiabilidade, Usabilidade, Segurança e Manutenibilidade. Apresenta também uma perspectiva de Tipos de RNF descrita por Mairiza et al. (2010).

O professor pode substituir a análise de estudo sobre RNFs por um método de elicitação de RNFs.

Essa ação ocorre em paralelo à atividade descrita na Seção 3.2. Para a realização desse passo é necessário que uma proposta de projeto para o desenvolvimento de software tenha sido apresentada aos alunos. A partir dessa proposta é possível modelar os casos de uso e criar suas descrições textuais. Essa é a primeira atividade onde a abordagem PBL será aplicada.

O problema proposto nessa etapa é desenvolver casos de uso e descrição textual. A avaliação de desempenho dos alunos tem início logo após o problema ter sido apresentado e estende-se até o momento da entrega da solução do mesmo.

A solução encontrada por cada equipe nas etapas PBL terá seu peso na avaliação do professor, mas o objetivo principal é avaliar o desempenho e a contribuição dos alunos durante a busca pela solução do problema.

A justificativa para esse tipo de avaliação baseia-se no fato de as etapas ‘Desenvolver casos de uso e Descrição Textual’ e ‘Aplicar Descrição Textual em matriz adjacente’ envolverem a compreensão do domínio do problema.

A técnica apresentada nesse artigo, tradução de um RNF para um aspecto, é a ferramenta que formaliza a informação lapidada pelo aluno, enquanto que a abordagem PBL ajuda o aluno a desenvolver habilidades cognitivas, tais como resolução de problemas, pensamento crítico e outros. Para que essa abordagem possa ser aplicada o professor precisa seguir três passos.

O primeiro passo é formular o problema que será resolvido nessa atividade. Nessa aplicação do método se propõem o desenvolvimento dos casos de uso e Descrição Textual para o problema. Antes de propor o problema para os alunos, o professor deve refletir sobre questões como “O aluno possui conhecimento suficiente para, pelo menos, ter uma orientação de como resolver o problema?” ou “O problema permitirá que os alunos desenvolvam habilidades como pensamento crítico e trabalho em equipe?”. Se as respostas para essas questões forem positivas o professor pode avançar para o segundo passo. Do contrário, o professor deve oportunizar o conhecimento sobre casos de uso e sua descrição ao aluno ou definir um novo problema.

O segundo passo é dividir a turma em equipes de três alunos. O critério de divisão é estabelecido pelo professor. Recomenda-se, fortemente, que o professor faça essa divisão porque no mercado de trabalho não serão os alunos que irão escolher seus colegas de equipe.

O terceiro e último passo a ser realizado é definir a disposição de carteiras e equipamentos necessários para a solução do problema proposto. O professor deverá observar atentamente cada aluno para que seja possível realizar uma avaliação precisa. Ao final dessa atividade o professor pode fazer questionamentos como “O aluno participou ativamente das discussões para solução do problema?” ou “Em situação de dúvida o aluno consultava outras equipes e/ou o professor?” para avaliar o aluno.

Os resultados das atividades descritas nas seções 3.2 e 3.3 permitirão que o aluno aplique as DT em matrizes adjacentes. Essas matrizes serão utilizadas da seguinte forma:

• As linhas irão conter os passos do fluxo básico da Descrição Textual de caso de uso.
• As colunas irão conter os atributos dos RNFs identificados por Mairizia et al. (2010).
• Uma intersecção é um aspecto, ou seja, representa que o atributo daquela coluna é identificado no passo daquela linha.

Os atributos de RNFs aplicados nas matrizes adjacentes são obtidos por meio da atividade 'Analisar estudo sobre Requisitos Não-Funcionais'. O professor tem a liberdade de utilizar outro método para identificar esses atributos. Caso isso aconteça, os RNFs identificados pelo método escolhido serão inseridos em cada matriz adjacente. Quando o professor optar por outro método para identificação de RNFs, ele deverá substituir a atividade ‘Analisar estudo sobre Requisitos Não Funcionais’ pela aplicação desse método.

Esta etapa é a segunda e última atividade do método proposto que aplica a abordagem PBL. Cada etapa onde essa abordagem ocorre possui avaliação própria.

A aplicação desse método na tradução de RNFs para aspectos pode ser realizada utilizando qualquer linguagem orientada a aspectos. Nesse artigo, os aspectos foram codificados utilizando AspectJ (Kiczales et al., 2001).

Essa atividade ocorre em paralelo com a atividade 'Ensinar uma linguagem de programação orientada a aspectos'. O professor apresenta alguns conceitos sobre a linguagem de programação escolhida e, para consolidar o aprendizado, propõe alguns exercícios de programação extraclasse denominados de APSs (Atividades Práticas Supervisionadas).

Essas atividades podem ocorrer na forma de: estudos dirigidos, trabalhos individuais, trabalhos em grupo, desenvolvimento de projetos, atividades em laboratório, atividades em campo e outras. As APSs foram estabelecidas na Universidade A pela Resolução nº 78 do Conselho de Ensino, Pesquisa e Pós-Graduação (COEPP) de 21 de Agosto de 2009 (Universidade A, 2011).   

A aplicação do método proposto inicia-se com a atividade 'Ensinar diagrama de caso de uso'.

Supondo que o aluno já possua o conhecimento para criar casos de uso e descrição textual essa atividade pode ser ignorada.

As atividades 'Analisar estudo sobre Requisitos Não Funcionais' e 'Desenvolver casos de uso e Descrição Textual' são realizadas em paralelo.

A atividade 'Desenvolver casos de uso e Descrição Textual' foi aplicada utilizando a abordagem PBL. O problema apresentado nessa atividade foi desenvolver casos de uso e Descrição Textual. A primeira atividade desse método de ensino, 'Ensinar diagrama de caso de uso', forneceu o conhecimento necessário para o aluno realizar essa atividade. Após a apresentação do problema a turma foi dividida aleatoriamente em equipes de três alunos. Finalmente, a disposição das carteiras e equipamentos utilizados na solução do problema foi definida.

O exemplo de aplicação desse artigo irá utilizar um diagrama de caso de uso Acessar

 o Sistema como resultado da atividade 'Desenvolver casos de uso e Descrição Textual' (DT). A Figura 2 ilustra a descrição do caso de uso.

Figura 2
DT do caso de uso Acessar no Sistema

Ao final desta atividade, o professor atribuiu para cada equipe uma nota e um respectivo peso em relação à solução encontrada.

O RNF segurança será utilizado nessa aplicação do método e mostra o resultado obtido por uma das equipes de alunos. Os atributos do RNF segurança são identificados a partir da atividade 'Analisar estudo sobre Requisitos Não-Funcionais'. A Figura 3 mostra os atributos de segurança obtidos pelos alunos ao ler o trabalho de Mairiza et al. (2010).

Figura 3
Atributos do RNF segurança

O aluno pode acrescentar seus próprios atributos de segurança ou retirar alguns desses. Essa flexibilidade lhe permite adaptar o método conforme suas necessidades.

A atividade 'Aplicar Descrição Textual em matriz adjacente' utiliza o resultado das atividades 'Analisar estudo sobre Requisitos Não-Funcionais' e 'Desenvolver caso de uso e Descrição Textual'. Essa atividade foi aplicada utilizando a abordagem PBL. Os passos a serem seguidos para a aplicação dessa abordagem são os mesmos daqueles utilizados pela atividade 'Desenvolver casos de uso e Descrição Textual'.

A identificação de um aspecto dentro da matriz adjacente inicia-se com a análise de cada passo da DT. Um aspecto será encontrado quando um atributo for identificado dentro do passo analisado. Na Figura 4 é possível observar o resultado de uma das matrizes de adjacência identificada por uma das equipes.

Figura 4
Matriz adjacente para o RNF segurança

Esta figura apresenta a matriz adjacente para o RNF do tipo segurança, onde Pn representa cada passo da DT do caso de uso e Sm representa cada atributo apresentado na Figura 3. Os aspectos identificados são: S2(Integridade), S3(Disponibilidade), S4(Controle de acesso) e S5(Autenticação).

As atividades 'Ensinar uma linguagem de programação orientada a aspectos' e 'Atividades em sala e APS' também são realizadas em paralelo. Supondo que os alunos já possuam conhecimento sobre a linguagem de programação a ser utilizada. Essas duas atividades tornam-se opcionais.

A última atividade realizada nessa aplicação do método proposto foi codificar os aspectos identificados. A Figura 5 apresenta um aspecto relacionado à segurança codificado utilizando AspectJ.

Figura 5
RNF de segurança mapeado para um aspecto codificado

O método de ensino proposto utiliza a abordagem PBL em duas de suas atividades. A abordagem PBL permitiu desenvolver habilidades necessárias ao aluno de computação, tais como pensamento crítico e trabalho em equipe.

A ausência dessas habilidades durante a realização das atividades 'Desenvolver casos de uso e Descrição Textual' e 'Aplicar Descrição Textual em matriz adjacente' pode representar consequências graves. Por exemplo, na atividade 'Desenvolver casos de uso e Descrição Textual' resultará em inconsistência entre o que o cliente deseja e o que o profissional entendeu. O aluno que desenvolver essas habilidades é capaz de identificar o que o cliente quer e o que o cliente não sabia que queria.  

Uma das principais características do paradigma da Orientação a Aspectos é tratar, adequadamente, as Preocupações Transversais. As vantagens apresentadas por essa característica tornam a tradução de RNFs para aspectos uma ferramenta valiosa para qualquer desenvolvedor de sistemas. Além disso, a abordagem PBL aplicada a disciplina para elicitação de requisitos a alunos de computação  permitiu que ao acadêmico desenvolver habilidades como pensamento crítico e trabalho em equipe. Essas habilidades são essenciais para o bom uso de ferramenta e para sua melhor alocação no mercado profissional.

A aplicação da tradução de RNFs para aspectos apresentada nesse artigo como parte de um método de ensino atingiu um nível satisfatório porque consegui mapear os aspectos identificados na etapa de Projeto para a etapa de Construção (codificação).

Estudos futuros podem ser realizados em relação a aplicação da abordagem baseada em problemas em outras disciplinas do ensino superior na computação, assim como a realização de outros experimentos na área de elicitação de requisitos.

BOUD, D.; FELETTI, G. (1997). “The Challenge of Problem Based Learning, Kogan Page Limited”. 2º ed.

BROOKS Jr., F. P. (1987). No Silver Bullet: Essences and Accidents of Software Engineering. IEEE Computer, n. 4, p. 10-19.

CHUNG, L., NIXON, B., YU, E., MYLOPOULOS, J. (1999). “Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers”. 2ª ed.

COSTA, I. C., et al. (2007). “Desenvolvimento de um curso seguindo a Aprendizagem Baseada em Problemas: um estudo de caso”, In: XIII Workshop sobre Informática na Escola, Rio de Janeiro, Rio de Janeiro, Brasil.

CYSNEIROS, L. M. (2001) “Requisitos Não Funcionais: Da Elicitação ao Modelo Conceitual”. Tese de Doutorado, PUC-RJ.

 DAVIS, A. (1993). “Software Requirements: Objects Functions and States”, Prentice Hall, 1993.

DEVINCENZI, S. et al. O uso de tecnologias persuasivas para potencializar o proceso de aprendizagem baseado em problemas. (2017). Revista Espacios. Vol. 38, n (60), p. 13.

DUCH, B. J., GROH, S. E., ALLEN, D. E. (2001). The Power of Problem-Based Learning: A Practical  “How To” for Teaching Undergraduate Courses in Any Discipline. Stylus Pub.

EVENSON, D. H.; HMELO, C. E. (2000). Problem Based Learning - A Research Perspective on Learning Interactions, Lawrence Erlbaum Associates, Inc, 1ª edição.

GASTALDO, D. L., MIDORIKAWA, E. T. (2003) “Processo de Engenharia de Requisitos Aplicado a Requisitos Não-Funcionais de Desempenho – Um Estudo de Caso”. Workshop em Engenharia de Requisitos, p. 302-316.

GOMES, R. M.; BRITO, E., VARELA, A. (2016).  Intervenção na formação no ensino superior: a aprendizagem baseada em problemas (PBL). Revista Interecções. Vol 12, n (42), p. 44-57.

JACINTO, A. S., DE OLIVEIRA, J. M. P. (2007), “Uma investigação de STI que emprega a PBL de forma individual”, In: XVIII Simpósio Brasileiro de Informática na Educação (SBIE 2007), p. 360-369.

KICZALES, G., et al. (2001) Getting started with ASPECTJ. ACM Communications, v. 44, n. 10.

MAIRIZA, D., ZOWGHI, D., NURMULIANI, N. (2010). An Investigation into the Notion of Non-Functional Requirements. (2010). Proceedings of the ACM Symposium on Applied Computing, p. 311-317.

MELO-SOLARTE, D. S., BARANAUSKAS, M. C. C. (2008), “Uma Abordagem para EaD Baseada em Resolução de Problemas”, Em: XIX Simpósio Brasileiro de Informática na Educação (SBIE 2008), paginas 716-725.

RUMBAUGH, J., JACOBSON, I., BOOCH, G. (2005). The unified modeling language reference manual. Pearson Education, Inc., 2 ed.

SOCKALINGAM, N. S. H. G. (2011). Characteristics of Problems for Problem-Based Learning : The Students ’ Perspective. Interdisciplinary Journal of Problem-Based Learning, vol 5, n (1), p. 3–16.

UNIVERSIDADE A. (2011). “Regulamento das Atividades Práticas Supervisionadas da Universidade A”. Disponível em http://www.utfpr.edu.br/toledo/estrutura-universitaria/diretorias/dirgrad/documentos-e-formularios/regulamento-das-atividades-praticas-supervisionadas-da-utfpr. Acesso em jul, 2018.

XAVIER, L. (2009) “Integração de Requisitos Não-Funcionais a Processos de Negócios: Integrando BPMN e RNF”. Dissertação de Mestrado, UFP-PE.

1. Graduado pela Universidade Tecnológica Federal do Paraná. Desenvolve sistemas na empresa KMM a aproximadamente 5 anos usando orientação a objetos. Pode ser contato através siqueiradasilvaleandro@gmail.com

2. Professor assistente na UEPG – Universidade Estadual de Ponta Grossa de Ponta Grossa, Paraná – Brasil. Departamento de Ciência da Computação. Trabalha com sistemas de banco de dados a vinte anos. Realiza atividade de pesquisa em Banco de Dados Heterogêneos, NO-SQL e Sistemas de Informação. Pode ser contatado através egueiber@gmail.com

3. Professora Titular da UTFPR - Universidade Federal de Tecnologia, Paraná - Brasil. Departamento de Ciência da Computação. Trabalha com desenvolvimento de sistemas nos últimos 20 anos. Sua atividade de pesquisa é em Engenharia de Software (Frameworks, Patterns Design, Arquitetura J2EE) e Sistemas de Informação. Ela pode ser contatada através simone@pg.cefetpr.br