3. Os Problemas-Alvo
3.4 Questões de Investigação e Objetivo da Tese
Esta seção descreve (na subseção 3.4.1) um problema observado quando vários modeladores constroem, independentemente, MDs para um mesmo sistema: esses MDs ficam muito diferentes entre si. Isso inspirou o estabelecimento de algumas questões a serem investigadas (subseção 3.4.2), a partir das quais foi definido o objetivo principal desta tese (subseção 3.4.3).
3.4.1 O Problema da Inconsistência entre MDs
Em uma série de trabalhos, SVETINOVIC (2005) e SVETINOVIC et al. (2005, 2006) apresentaram e discutiram um problema observado ao longo de 5 (cinco) anos lecionando um curso sobre técnicas orientadas a objetos para o desenvolvimento de software. Nesse período, os autores revisaram pessoalmente 135 especificações de requisitos (em média 120 páginas cada), de um total de 195 elaboradas com a participação de 740 estudantes de Engenharia de Software, Ciência da Computação, Engenharia Elétrica e Engenharia de Computação. Na seqüência das três disciplinas do curso, os estudantes desenvolvem um sistema de telefonia que inclui um subsistema de informações para o gerenciamento de contas. Eles utilizam UCs para capturar requisitos no nível de domínio, e a Análise Orientada a Objetos (AOO) (COAD, YOURDON, 1990) como uma ponte para o projeto OO do sistema.
Fazendo a revisão das especificações produzidas pelos estudantes, e interagindo com eles, os autores observaram muitas dificuldades surgidas ao longo do processo de especificação. A dificuldade observada mais freqüentemente (em quase todas as especificações) se localiza na análise de domínio OO, mais especificamente, na:
1. Identificação de conceitos do domínio do sistema, e na 2. Atribuição da funcionalidade do sistema a esses conceitos.
Em particular, foi observada a falta de conceitos e responsabilidades, e equívocos na atribuição de responsabilidades aos conceitos.
Além de ocorrer mais freqüentemente, os autores afirmam que essa dificuldade tende a ficar sem solução. Também foram observadas dificuldades para trabalhar apenas com UCs no nível do sistema, e para encontrar níveis apropriados de abstração.
Como resultado, os modelos de domínio produzidos por diferentes grupos, para um mesmo sistema, resultam drasticamente diferentes (provavelmente por terem os grupos considerados conjuntos muito distintos de conceitos), e com um grande número de conceitos em níveis diferentes de abstração. Os autores consideram essa uma forma particular de inconsistência dos modelos de domínio.
O estudo levado a cabo pelos autores (SVETINOVIC et al., 2005) traz evidências de que essa dificuldade se manifesta tanto em sistemas grandes como em sistemas pequenos. Além disso, segundo os autores, a dificuldade não está nos estudantes, nem na sua incapacidade de compreender a orientação a objetos, mas nas
limitações das técnicas correntes de análise orientada a objetos, pelo menos em sua aplicação à engenharia de requisitos.
Os autores concluem que simplesmente não há garantias de consistência entre os MDs produzidos por diferentes analistas para um mesmo sistema, e que não é possível prever que diferenças existirão, ou mesmo entender porque essas diferenças acontecem. A ampla variação entre os modelos de domínio produzidos por diferentes analistas para o mesmo sistema levanta um questionamento sobre o benefício de se aplicar AOO. Eles consideram ainda que é preciso confrontar essa questão e descobrir meios de reduzir ou controlar essa variação, e que, apesar de difícil, é essencial estabelecer relações significativas entre os artefatos envolvidos (UCs e o MD).
Motivado por esses resultados, Svetinovic desenvolveu uma tese de doutorado cujo objetivo foi encontrar uma solução para esse problema (SVETINOVIC, 2005) (SVETINOVIC, 2006). Como veremos na próxima seção, também faz parte da presente tese investigar uma solução distinta para o mesmo problema.
3.4.2 Questões de Investigação
A seção 3.2.1 defendeu que trabalhar com os dois modelos na fase de requisitos é uma necessidade, pois ambos capturam informações complementares, úteis para as fases subseqüentes do desenvolvimento do sistema. Mas, como os modelos modelam um mesmo objeto (o sistema), e não são completamente ortogonais, surge a questão da consistência entre eles.
A análise das propostas que tentam promover a consistência entre os dois modelos (vide seção 3.3), nos permite concluir que:
1. Quando se tenta derivar automaticamente o MD a partir do MUC, o resultado é um modelo muito incompleto. Todas as propostas que visam certa automatização desse processo de transformação utilizam alguma forma de análise lingüística (por exemplo, (KÄRKKÄINEN et al., 2008)), sabidamente incapaz de levar a resultados conclusivos. Ou seja, a maior parte da obtenção do MD fica a depender da interpretação do modelador.
2. Quando se tenta verificar a consistência entre os dois modelos obtidos em separado, novamente, a parte passível de automatização é mínima. Em outras palavras, os rastros formalmente identificáveis entre os dois modelos são
poucos. Isso fica evidente no trabalho de GLINZ (2000) (descrito na seção 3.3.2).
Apesar dessas dificuldades, poder-se-ia argumentar que a não automatização da obtenção do MD, ou da verificação da consistência entre ele e o MUC, não é um problema real; ou seja, que por serem esses modelos muito diferentes12, essa obtenção e verificação precisam mesmo ser feitas manualmente pelo modelador, com base no seu conhecimento do sistema pretendido e do domínio onde ele se insere. Mas se é assim, o MD (como qualquer modelo de requisitos) precisa ser validado pelos stakeholders. E essa validação leva a outros questionamentos.
A validação do MD por pessoas não acostumadas a essa técnica de modelagem é problemática. O stakeholder típico não se sente a vontade para ler e interpretar um MD (LAUESEN, 2002). Ele parece se ressentir do alto nível de abstração e da linguagem formal, utilizados nesse modelo. A saída, a nosso ver apenas parcial, é parafrasear o MD em linguagem natural, e com isso conseguir (pontualmente) que os stakeholders exprimam sua avaliação sobre os aspectos modelados. Entretanto, persiste outra preocupação, ainda maior, sobre a possibilidade de uma validação efetiva do MD pelos stakeholders.
O modelador não é a fonte mais confiável para escolher as abstrações de domínio relevantes para o sistema. Em geral, ele não detém ou domina o conhecimento necessário para elicitar com segurança essas abstrações. Daí a necessidade de validação pelos stakeholders. Mas, uma coisa é extrair dos stakeholders as abstrações que eles utilizam ou julgam mais relevantes, e outra coisa é apresentar a eles um modelo pronto, contendo as abstrações identificadas pelo modelador, e pedir que eles as validem. Mesmo contando com o esforço e boa vontade deles, ao serem apresentados a um MD pré-existente (elaborado pelo modelador), é possível que eles sejam induzidos a “aceitar” as abstrações lá representadas, e abram mão facilmente (talvez até inconscientemente) das suas próprias abstrações, utilizadas no dia-a-dia do negócio. Isso é ainda mais preocupante se considerarmos os resultados obtidos por SVETINOVIC et al. (2005), que mostram uma grande variação entre os MDs obtidos por diferentes modeladores, para um mesmo sistema. Qual dos MDs deveria ser validado? Conseqüentemente, há um sério risco de que tal validação não seja efetiva.
12 Enquanto o MUC é funcional, o MD é orientado a objetos, e empregam níveis de formalização
Em vista do exposto, vemos indícios de que, em geral:
a) O modelo de UCs é pobre como fonte de informações úteis à determinação de um MD;
b) Os modeladores não têm o conhecimento necessário para tomar uma decisão segura sobre as abstrações a serem escolhidas;
c) O espaço de abstrações de um domínio é muito amplo e, portanto, sem uma orientação para limitar a busca nesse espaço, diferentes modeladores tendem a chegar a conjuntos mais ou menos disjuntos de abstrações, ao tentarem obter um MD.
Das análises e discussões anteriores, podemos identificar várias questões cuja investigação é relevante para aperfeiçoar o papel complementar do MUC e do MD na modelagem de requisitos:
Q1. Como aumentar a cobertura de elementos do MD, deriváveis automaticamente a partir do MUC?
Q2. Como reduzir, no MD obtido a partir do MUC, a dependência da interpretação do modelador?
Q3. Como minimizar os riscos apontados para uma validação efetiva do MD?
Q4. Como aumentar o grau de formalização da verificação de consistência entre os modelos?
Q5. Como eliminar (ou reduzir) o indeterminismo apontado por SVETINOVIC et al. (2005), no processo de obtenção do MD a partir dos UCs?
3.4.3 Objetivo da Tese
O objetivo deste trabalho de tese é obter respostas para os questionamentos listados no final da seção anterior, e propor uma solução correspondente que:
O1. Inclua mais rastros formais entre elementos dos dois modelos, contribuindo assim para um maior automatismo e cobertura de elementos, na derivação do MD a partir do MUC, ou na verificação de consistência entre os dois modelos; O2. Elimine ou reduza a inconsistência entre MDs obtidos por diferentes
modeladores, a partir dos UCs de um mesmo sistema.
Acreditamos que o alcance do segundo objetivo acima decorra, em parte, de se alcançar o primeiro. O próximo capítulo identifica e analisa as possíveis causas para os problemas aqui caracterizados, e propõe um enfoque para resolvê-los.