quarta-feira, agosto 15, 2007

O Glossário do RUP e do OpenUP: Um Ser Incompreendido!

O artefato Glossário, contido na disciplina de requisitos do Rational Unified Process e do OpenUP, costuma ter pouca utilização prática dentro das empresas. Pouca gente conhece sua potencial utilidade e, neste artigo, tratarei sobre esse assunto. Provavelmente essas idéias ajudarão muitos analistas de requisitos e analistas de sistemas a melhorar a qualidade de seus requisitos.

As informações que passarei foram sumarizadas e baseadas no livro Use Case Modeling de Bittner e Spence, no livro Patterns for Effective Use Cases de Cockburn et al e na apostila do treinamento oficial "Mastering Requirements Management with Use Cases" da IBM Rational.

Quando a técnica de modelagem de casos de uso é utilizada para especificar requisitos funcionais de um sistema, muitos analistas de sistemas acham que a definição todos os atributos, tamanhos e domínios das entidades não está sob sua responsabilidade. Mas é claro que esses elementos fazem parte dos requisitos a se levantar junto com os usuários.

Por exemplo, vamos supor que se esteja definindo os requisitos de um sistema de e-commerce. Se o analista de requisitos disser em um caso de uso que o cliente pode alterar as informações de perfil de cliente, porém não incluir quais são essas informações, o que o desenvolvedor fará? Ele irá perguntar para o analista de requisitos. E o analista de requisitos fará o que? Perguntará para o usuário :-) !

Portanto esses atributos e seus respectivos tamanhos e domínios precisam estar documentados. Mas se eu inserir estas informações na especificação de caso de uso o que ocorrerá?

Problemas

Exemplo de especificação de caso de uso "complicada":
...
Passo 4 - O cliente informa ao sistema os dados de Nome, Endereço e Sexo do Perfil do Cliente.
Passo 5 - O sistema valida os dados do Perfil do Cliente. Nome deve ter 40 posições - alfanumérico; Endereço deve ter 2 linhas de 60 posições cada uma - alfanumérico; Sexo deve ter 1 posição - caractere - domínio: F para Feminino ou M para Masculino.
...

Terei dois problemas graves:

1 - Especificações de casos de uso gigantes, com dezenas de páginas.

2 - O mais grave: quando você utilizar uma entidade em vários casos de uso você gerará duplicação de informações em diferentes artefatos. Essa falha levará a sérias dificuldades na manutenção dessa documentação e ocasionará possíveis erros quando alguém esquecer de alterar um atributo em todos os casos de uso que o referenciam.

Solução

Coloque, além de uma definição simples acerca da entidade, TODOS os atributos e seus respectivos tamanhos e domínios dentro do Glossário. Dessa forma você centralizará essas informações em um único artefato. O Glossário então se tornará um elemento essencial para o desenvolvimento do sistema e atuará também como uma espécie de dicionário de dados do negócio.

Exemplo

Exemplo No Glossário:
Entidade Perfil do Cliente -> entidade que representa as informações básicas de um cadastro realizado pelo próprio usuário do site de e-commerce.
Atributos:
Nome: 40 posições - alfanumérico
Endereço: 2 linhas de 60 posições cada uma - alfanumérico
Sexo: 1 posição - caractere - domínio: F para Feminino ou M para Masculino
...

Na especificação de caso de uso a dica é usar algo para realçar uma entidade que está descrita no Glossário. Defina um padrão para seu projeto. No exemplo abaixo eu padronizei que todas as entidades descritas em uma especificação de caso de uso estarão em itálico.

Exemplo em uma especificação de caso de uso:
...
Passo 4 - O cliente informa ao sistema os dados do Perfil do Cliente.
Passo 5 - O sistema valida os dados do Perfil do Cliente.
...

Portanto, usem o glossário como uma ferramenta essencial da documentação de requisitos. Vocês notarão a melhoria no entendimento dos casos de uso e a facilidade de manutenção que essa técnica proporcionará.

Marcadores: , , ,

10 Comentários:

At 11:20 AM, Blogger Michel disse...

Parabens pelo artigo, muito bom.

Exatamente como o Alistar comenta em seu livro "Escrevendo casos de uso eficazes". Só que no livro, como ele não cita nenhum processo, como o RUP por exemplo, o Alistar utiliza um outro nome para o artefato gerado onde fica os atributos, se não me engano Documento de campos de dados (não me recordo).

Michel Amaral

 
At 1:31 PM, Anonymous Rodrigo disse...

Muito bom, estou começando um novo projeto...e vou aplicar essa técnica...

Parabéns pelos seus artigos..
Abraçoss

 
At 1:32 PM, Anonymous Rodrigo Pellegrini disse...

Muito bom, estou começando um novo projeto...e com certza vou tentar aplicar essa técnica...

Parabéns pelos seus artigos..
Abraçoss

 
At 12:29 PM, Blogger :>) disse...

Boa tarde José,
Gostaria se possível algumas dicas ou material sobre o Eclipse Process Framework e como trabalhar com ele..eu ainda n~çao consegui entender como trabalhar com o EPF. Seria interessante criar um tutorial ou alguma materia sobre como trabalhr com esta ferramente com o OpenUp. Ficaria muito grato caso tivesse alguma resposta.
Obs. Sempre acompanho seus post's em seu blog. Parabéns pelas matérias, são ótimas. Inclusive tenho aprendido bastante com elas.
Obrigado.
Fernando RM.

 
At 3:13 PM, Blogger Alexander disse...

O glossário não seria o artefato correto, para documentar o detalhamento dos atributos utilizados no casos de uso.

Na disciplina de analise e design o artefato modelo de classe poderá estar entrando neste detalhe.

 
At 3:23 PM, Blogger José Papo, MSc disse...

Olá Alexander,

Essas dicas são definidas pelos próprios responsáveis do RUP (como o Kruchten, o Bittner e o Spence). Já conversei com eles num evento da IBM Rational nos EUA e essa dica foi confirmada por eles. Talvez não tenha ficado tão claro mas, esses atributos são como um modelo conceitual de dados, num nível ainda de negócios. Portanto, são requisitos. Mas uma outra forma seria criar um artefato de dicionário de dados. Ele não existe no RUP mas poderia ser inserido.

 
At 3:52 PM, Blogger Alexander disse...

Concordo com o dicionário de dados, porém, a questão é descrever no glossário informações que são de produto e que podem descaracterizar o objetivo do artefato, independente do feedback que lhe foi passado.

Além disso, uma necessidade de negócio poderia ser por exemplo Manter Funcionario onde as informações necessárias são: nome, cargo e salario, sendo assim, não vejo o glossário com o artefato correto para descrever o detalhe dos atributos(tipo, formato e etc) conforme você orientou.

 
At 3:59 PM, Blogger José Papo, MSc disse...

Alexander,

Essa pode ser a sua opinião. Mas não é a opinião dos papas do RUP e de casos de uso e nem a minha :-) . Nada te impede de fazer do seu jeito, até porque o RUP permite a customização. Mas gosto de deixar claro para a audiência do meu blog o que lá fora é considerado boa prática por aqueles que criaram o processo e a técnica.

 
At 4:18 PM, Blogger Alexander disse...

Não é minha opnião e sim o que o RUP descreve como objetivo do glossário, que é definir os termos importantes utilizados pelo projeto.

Além disso, o Glossário é o principal artefato utilizado para capturar informações sobre o domínio de negócios do projeto.

Detalhar as informações dos requisitos(tipo, formato e etc) não são termos que devem ser definidos no glossário.

Qual seria a razão para o negócio em descrever no glossário que o nome deve ter 40 posições e ser alfanumérico?

Acho que a boa prática precisa ser revista.

Fim dos comentários sobre este assunto.

Obrigado pela atenção.

 
At 4:28 PM, Blogger José Papo, MSc disse...

Olá Alexander,

Como já comentei, essa é sua opinião e todos têm direito a uma. Porém, Ivar Jacobson (simplesmente O cara que inventou a técnica de modelagem de casos de uso e gestão de requisitos do RUP) tem outra. A dele é a que descrevi em meu blog. Fica a critério de cada organização definir a melhor forma de fazer dentro do seu contexto específico. Inclusive, isso é fundamental: Cada prática precisa ser adaptada para seu contexto específico.

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas