A modelagem conceitual é a descrição da informação que o sistema irá gerenciar, sendo um artefato do domínio do problema e não do domínio da solução. A modelagem conceitual não deve ser confundida com a arquitetura do software ou com o modelo de dados, pois apresenta o problema (o que precisa ser feito) a ser resolvido e não a solução (o como deve ser feito)
Neste artigo, estamos considerando o gap semântico como sendo o problema de comunicação e compreensão de requisitos existente entre o que o usuário solicita e o que o analista compreende. Esta distância de entendimento resulta em falhas na compreensão dos requisitos por parte do analista.
Introdução
Durante muito tempo o desafio da análise de sistemas tem sido a busca incessante da redução e/ou eliminação do gap semântico existentes na etapa de análise, decorrente da má compreensão por parte do analista dos anseios do usuário. Muitos autores definem este problema como sendo um problema crítico de compreensão de requisitos por parte do analista, outros como um desvio das metodologias de análise mal implementadas. Eu costumo dizer que o problema é de comportamento do analista de sistemas perante o uso correto das ferramentas de análise.
O assunto tem ocupado dezenas de páginas em bons livros de modelagem e de engenharia de software, mas ainda há muito a se aprender sobre o assunto, uma vez que se trata da representação do conhecimento humano no sentido de diminuir esta separação existente entre o entendimento do usuário e do analista de sistemas.
Com o surgimento do conceito de modelagem orientada a objetos, incentivada pela UML, boas práticas tais como a modelagem conceitual, diagramação do sistema e maior envolvimento dos usuários puderam sair dos livros e ir parar nas mesas dos analistas de sistemas e engenheiros de software. Desta nova fase, onde o maior foco passou a ser uma análise de requisitos de qualidade munida de ferramentas de diagramação que permitam uma visão abrangente do sistema/problema, podemos destacar a redução do gap semântico existente entre usuário e analista de sistemas como maior alvo de atuação.
No presente artigo abordarei o assunto em dois momentos. No primeiro momento apresentarei o assunto focando o seu principal objetivo que é a compreensão da natureza do problema. Em seguida veremos como a modelagem conceitual pode auxiliar o analista de sistemas a especificar o seu sistema de forma consistente.
O problema do Gap Semântico
O Gap Semântico, definido como “a distância do que o usuário solicita para o que o analista de sistemas compreende” (ver Figura 1), ilustrado no típico exemplo do “Balanço ecológico”, surge como sendo um dos maiores fatores de insucesso de projetos de software.
De fato, duas pessoas que descrevem o mesmo processo quase sempre usarão uma seqüência de passos diferentes (ver Figuras 2 e 3).
Podemos ilustrar o problema do gap semântico através do seguinte exemplo: em uma mesa de reunião estão sentados o usuário principal, aqui representado como ator principal, e o analista de sistemas. O objetivo de ambos é construir uma solução capaz de eliminar o re-trabalho manual em uma determinada área da companhia.
Sentado na cadeira principal, em sua sala, está o ator principal. A compreensão dos requisitos é algo que para o ator principal é claro e de seu domínio. O ator principal é quem domina as regras de negócio, apto e com grande experiência na área onde o sistema será implementado, este personagem conhece muito bem as regras de negócio, trabalha na companhia há muitos anos e sabe como o processo acontece, porém ignora a tecnologia da informação.
Do outro lado da mesa, está você, o analista de sistemas. O analista de sistema é o especialista, domina muito pouco as regras de negócio, tem domínio superficial do assunto, porém possui domínio da tecnologia da informação. Não conhece a regra de negócio a fundo, depende do Ator Principal para modelar o sistema a ser desenvolvido.
Durante o processo de especificação, os atores apresentados no exemplo hipotético terão de conversar e especificar o que será o sistema e quais os seus requisitos. O gap semântico nasce aqui.
O levantamento dos requisitos é difícil por que deve ser feito com apoio dos usuários que são os únicos que sabem o que precisam. Mas eles não são especialistas em desenvolvimento de sistemas, na maior parte das vezes não sabem qual parte do seu trabalho pode ser implementada e muito desconhecem como o computador pode lhes ajudar.
Outro problema é que cada usuário tem uma visão restrita do domínio e do que o sistema precisa fazer, vamos precisar unificar essas visões parciais em uma grande visão do sistema. Finalmente, os requisitos mudam: as máquinas evoluem, novos métodos de trabalho são introduzidos, leis mudam constantemente, etc.
Quando dois seres humanos com culturas, hábitos e meios ambientes diferentes se encontram, há muito mais do que simplesmente interesses pessoais os separando. Quando a etapa de levantamento de requisitos se inicia, a primeira conversa apenas estabelece o contato, não permite ainda o equilíbrio completo de compreensão e relacionamento.
O problema do gap semântico está intimamente relacionado com o entendimento e compreensão de ambas as partes. Esta linha tênue de relacionamento deve possuir como objetivo entender o que precisa ser desenvolvido. O ator principal, o usuário, sabe o que espera receber. O analista de sistemas espera entender o que o ator principal deseja receber, para definir como irá atendê-lo.
A distância destes dois atores, métrica intangível, não permite com exatidão determinar o fator de sucesso de projeto, mas, permite determinar o nível de detalhamento que será necessário para que todos os requisitos funcionais e alguns requisitos não funcionais possam ser especificados com eficiência (ver Figura 4).
Quanto menor o gap semântico, mais eficiente tende a ser a construção da solução.
Modelagem Conceitual
O modelo conceitual deve descrever o conjunto de entidades que o sistema vai gerenciar. Trata-se de um artefato do domínio do problema e não do domínio da solução (ver Nota 2). Portanto, o modelo conceitual não deve ser confundido com a arquitetura do software, pois esta, embora inicialmente derivada do modelo conceitual, pertence ao domínio da solução, e dessa forma, serve a um objetivo diferente (Wazlawick, 2004, p. 102).
Domínio do problema versus Domínio da solução
Os artefatos de domínio de problema possuem como objetivo compreender o que necessita ser realizado, de acordo com a necessidade do usuário. Na etapa subseqüente, os artefatos de domínio da solução permitem definir a partir do “o que precisa ser feito” definir “como será implementada a solução”. A principal distinção está no foco com que tratam o problema, na etapa de domínio “o que precisa ser feito”, na etapa de solução “como deve ser feito”.
Uma dificuldade dessa atividade é que ela deve resultar numa especificação dos requisitos que seja compreensível pelo analista e pelos próprios usuários. Isso significa utilizar uma linguagem clara e direta. O processo de descrição pode ser dificultoso, uma vez que a linguagem do analista de sistemas e do usuário pode ser divergente, sendo necessário um alinhamento prévio dos termos para que isso não resulte no aumento da distância de compreensão.
Quando falamos em modelagem conceitual, falamos sobre o comportamento do analista em abstrair dados durante a etapa de levantamento de requisitos, e modelá-los em um padrão que seja compreensível por todos os stakeholders (ver Nota 3).
Stakeholder
Os interessados em um projeto (stakeholders) são todas as pessoas da organização que têm algum tipo de envolvimento direto ou indireto com o sistema, como usuários, gerentes, clientes, proprietários e financiadores.
Segundo Larman, durante a etapa de análise orientada a objetos, o objetivo é encontrar e descrever os conceitos de domínio do problema. Em um exemplo de biblioteca, por exemplo, poderíamos ter como entidades conceituais identificadas Livro, Biblioteca e Usuário.
A modelagem se divide em três etapas, conforme Figura 5, muito bem definidas com objetivos distintos, sendo: conceito do domínio, visualização do conceito do domínio e, por último, a representação em uma linguagem de programação (Larman, 2004).
Conceito de domínio
Compreender o problema entendendo com exatidão o que de fato deve ser feito, sem neste momento se preocupar com a implementação, é o principal objetivo quando se está buscando compreender o conceito de domínio. Larman define está etapa como“a coisa certa a ser realizada” sem descrever como ela será realizada. É como se eu apresentasse a planta de uma casa sem apresentar as ferramentas ou os métodos de construção que serão utilizados (ex.: pré-moldado ou construção tradicional).
De acordo com Larman, a análise enfatiza uma investigação do problema e dos requisitos, em vez de uma solução. Nesta etapa em vez de nos preocuparmos com os arcabouços que serão utilizados para resolver o problema, focamos a investigação dos requisitos e a investigação dos objetos de domínio (Larman, 2004, p. 30).
Durante esta fase o analista de sistemas deve dedicar-se a compreender a natureza do problema conhecendo as regras de negócio e a abrangência do sistema. Nesta etapa, indico o método proposto pela UML através da descrição do caso de uso.
Visualização do conceito de domínio
A visualização do conceito de domínio consiste em abstrair as informações a fim de apresentar o modelo que representa a compreensão das informações, e não a sua representação física.
O processo de descoberta dos elementos do modelo conceitual pode variar conforme o método de análise utilizado. Todavia, uma forma bastante útil, quando se trabalha com ciclos iterativos, é olhar para o texto do(s) caso(s) de uso expandido(s) (ler Nota 4). A partir da leitura deste texto, deve-se tentar descobrir todos os elementos que eventualmente referenciam informação a ser guardadas, processadas ou apresentadas pelo sistema.
Caso de uso expandido
O processo de expansão dos casos de uso corresponde ao aprofundamento da análise de requisitos realizada no caso de uso principal. O maior foco nesta expansão é o entendimento do fluxo principal do sistema.
Em geral esses elementos textuais são compostos por substantivos, como “pessoa”, “empréstimo”, “conta”, etc., ou por expressões que denotam substantivos (conhecidas em lingüística como “sintagmas nominais”), como “item de locação”, “autorização de pagamento”, etc.
Além disso, no texto, algumas vezes certos verbos podem indicar conceitos, pois o verbo pode exprimir um ato que corresponde a um substantivo, como: “pagar”, que corresponde ao substantivo “pagamento” e ”devolver”, que corresponde ao substantivo “devolução”.
Via de regra, entretanto, o analista deve ter em mente os objetivos do sistema enquanto procura descobrir os elementos do modelo conceitual. Não é interessante representar no modelo conceitual uma informação irrelevante para o sistema. Assim, nem todos os substantivos e verbos deverão ser considerados no modelo. O analista tem a responsabilidade de compreender quais são as verdadeiras necessidades de informação e filtrar as irrelevâncias.
O processo de identificação dos conceitos e atributos, segundo Wazlawick, consiste em:
- Identificar no texto dos casos de uso as palavras que correspondem a conceitos sobre os quais se tem interesse em manter a informação no sistema;
- Agrupar as palavras ou expressões que são sinônimas, como, “empréstimo” e “locação”, “cliente” e “pessoa que faz locação”;
- Identificar quais dos itens considerados correspondem a conceitos complexos e quais deles são meros atributos. Os atributos são aqueles elementos que podem ser considerados alfanuméricos, usualmente: nomes, números em geral, códigos, datas, valores em moeda, valores booleanos (verdadeiro e falso), etc.
Quando se aplica essa técnica ao caso de uso identificado, são encontrados os principais elementos de informação a serem trabalhados no modelo conceitual nesta iteração do ciclo.
Os elementos encontrados no processo de visualização do conceito de domínio são descritos como objetos do mundo real. Cada objeto do mundo real (no domínio universitário, um professor particular, uma aula específica) pode ser representado por um objeto. A Figura 6 apresenta a modelagem de uma classe a partir da observação de um objeto cliente do mundo real. Cada objeto “pertence” a uma classe. A estrutura do objeto, como as operações que ele pode executar, são descritas pela classe.
Classes
A análise orientada a objetos baseia-se em conceitos que começamos a aprender no jardim-de-infância (forçado): objetos e atributos, classes e membros, o todo e suas partes. O modelo de representação de classes proposto pela UML, resume em um retângulo as informações do objeto do mundo real apresentando através de linhas e setas as ligações existentes entre as várias classes.
Uma classe é a descrição de um tipo de objeto. Todos os objetos são instâncias de uma classe, onde a classe descreve as propriedades e comportamentos daquele objeto (ver Figura 7).
Usam-se classes para classificar os objetos que identificamos no mundo real. Uma classe pode ser a descrição de um objeto em qualquer tipo de sistema – sistemas de informação, técnicos, integrados, distribuídos, softwares, etc. Num sistema de software, por exemplo, existem classes que representam entidades de software em um sistema operacional como arquivos, programas executáveis, janelas, barras de rolagem, etc.
Atributos
Um atributo de uma classe é uma variável pertencente a esta classe que é destinada a armazenar alguma informação que está intrinsecamente associada ao objeto. Por exemplo, o cliente possui como atributos Nome e Telefone, sendo Nome do tipo texto e Telefone do tipo número.
Métodos
Enquanto os atributos permitem armazenar dados associados aos objetos, ou seja, valores que descrevem a aparência ou estado de um certo objeto, os métodos (methods) são capazes de realizar operações sobre os atributos de uma classe ou capazes de especificar ações ou transformações possíveis para um objeto.
Isso significa que os métodos conferem um caráter dinâmico aos objetos, pois permitem que os objetos exibam um comportamento que, em muitos casos, pode mimetizar (imitar) o comportamento de um objeto real.
Representação em uma linguagem de programação
A modelagem conceitual através de métodos da análise orientada a objetos não obriga o programador a utilizar uma linguagem de programação orientada a objetos para representar a solução para o problema descrito.
O paradigma estruturado possui características próprias que aumentam o gap semântico como, a geração freqüente de sistemas de difícil compreensão e manutenção. Um exemplo são as modificações na estrutura de dados, além de exigirem um profundo conhecimento da estrutura da solução, exigem mudanças em todas as funções relacionadas.
A utilização de uma linguagem que suporte a programação orientada a objetos permite uma implementação mais simples e de fácil compreensão, reduzindo significativamente o gap semântico.
Outra vantagem das linguagens orientadas a objetos em relação às estruturadas é o suporte oferecido pelas ferramentas de modelagem conceitual à geração automática da representação das classes. Nesta categoria podemos citar como exemplos as ferramentas Rational Rose Data Modeler, JUDE e Umbrello.
As ferramentas citadas também permitem engenharia reversa onde, a partir de uma representação em uma linguagem orientada a objetos, pode-se gerar os diagramas UML relativos a implementação.
Na Listagem 1 vemos a implementação do modelo conceitual do Cliente ilustrado na Figura 6.
//Importação da Classe Calendar
import java.util.Calendar;
//Classe Cliente
public class Cliente {
//Declaração dos atributos de Cliente
String nome;
String corOlhos;
int altura;
Calendar dtNascimento;
boolean statusCliente = true;
int telefone;
Endereco end;
String email;
// Métodos de Cliente
public int getAltura() {
return altura;
}
public void setAltura(int altura) {
this.altura = altura;
}
public String getCorOlhos() {
return corOlhos;
}
public void setCorOlhos(String corOlhos) {
this.corOlhos = corOlhos;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public Endereco getEnd() {
return end;
}
public void setEnd(Endereco end) {
this.end = end;
}
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
public Calendar getDtNascimento() {
return dtNascimento;
}
public void setDtNascimento(Calendar dtNascimento) {
this.dtNascimento = dtNascimento;
}
public boolean isStatusCliente() {
return statusCliente;
}
public void setStatusCliente(boolean statusCliente) {
this.statusCliente = statusCliente;
}
public int getTelefone() {
return telefone;
}
public void setTelefone(int telefone) {
this.telefone = telefone;
}
}Gap semântico ao longo do projeto
O gap semântico pode surgir também durante as diferentes fases do projeto, ocorrendo inclusive entre os próprios membros de uma equipe de desenvolvimento. Pode acontecer a qualquer momento decorrente de uma nova funcionalidade a ser implementada, por exemplo, ou de uma manutenção do sistema solicitada pelo usuário.
A preocupação na especificação do sistema e na comunicação dos requisitos sempre sugere uma atenção especial para as ocorrências do gap semântico. Reduzir esta distância de entendimento e compreensão é um objetivo a ser buscado pelas equipes de desenvolvimento.
Conclusões
Uma boa modelagem de sistema depende de um bom entendimento do problema e da solução a aplicar. Obter êxito na compreensão dos requisitos e na modelagem implica diretamente em reduzir o gap semântico. Vimos que o modelo sugerido pela UML e pela metodologia de análise orientada a objetos aumenta sensivelmente a aderência entre a especificação e o produto produzido, aumentando assim a satisfação do cliente e reduzindo o Gap semântico.
