Diretrizes: Regras de Negócios

Regras de Negócios
As regras de negócios são declarações de políticas ou condições que devem ser cumpridas.

Tópicos

• Explicação
• Níveis de formalismo
• Categorias de regras de negócios
• Como as regras de negócios são refletidas nos modelos

Explicação

As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos.

Níveis de Formalismo

As regras de negócios devem ser expressas rigorosa e formalmente para que sejam uma base para automação. Uma alternativa pode ser o uso da Linguagem de Restrição de Objetos (OCL) conforme especificado na Linguagem Unificada de Modelagem. [RUM98]

Exemplo:

É possível expressar um limite para o tamanho da equipe; por exemplo, menos de dez membros em uma equipe. Com a OCL, é possível definir essa regra de negócio com uma invariante:

context Team inv:

    self.numberOfMembers <= 10

Lembre-se que esse tipo de linguagem formal pode ser difícil de interpretar para muitos dos envolvidos; portanto, é preferível um estilo de linguagem mais natural. É possível definir um conjunto de expressões reservadas que são usadas para definir as regras. Essas expressões poderiam ser as mesmas das definidas em [ODL98]:

• IF
• ONLY IF
• WHEN
• THEN
• ELSE
• IT MUST ALWAYS HOLD THAT
• IS CORRECTLY COMPLETED

Exemplo:

Nessa linguagem menos formal, o exemplo acima poderia ser:

IT MUST ALWAYS HOLD THAT o número dos membros da equipe é menor ou igual a 10.

Categorias de Regras de Negócios

As regras podem ser classificadas de várias formas, embora seja comum separá-las em regras de restrição e de derivação. [ODL98] As categorias podem ser subdivididas posteriormente conforme descrito abaixo:

• Regras de restrição especificam políticas e condições que restringem o comportamento e a estrutura de objetos. 

• Regras de estímulo e resposta restringem o comportamento especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado. 
• Regras de restrição de operação especificam as condições que devem ser verdadeiras antes e após uma operação para garantir que a operação seja executada corretamente. 
• Regras de restrição de estrutura especificam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados. 

• Regras de derivação especificam políticas ou condições para deduzir ou calcular fatos de outros fatos. 

• Regras de dedução especificam que se determinados fatos são verdadeiros, uma conclusão pode ser deduzida. 
• Regras de cálculo derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução. 

Essa classificação de regras de negócios é prática para explicar quais são as regras de negócios, como localizá-las e como trabalhar com elas. Contudo, elas não são um grupo fixo ao qual é necessário fazer referência sempre. Portanto, nosso template de artefato de regras de negócios não mostra essa classificação; é proválvel que no seu projeto haja outros grupos (de domínio, de usuário ou de produto) que merecem ser exibidos.

Como as Regras de Negócios são Refletidas nos Modelos

Uma regra de negócio afeta a aparência do modelo. Ela também pode afetar as atividades de seqüência no diagrama de atividades, além de afetar as associações entre as entidades de negócios. Não é fácil converter algumas regras diretamente para a aparência de um diagrama; elas devem estar presentes em descrições dos elementos de modelos.

Independentemente, é útil mostrar regras de negócios como notas de texto, vinculadas ao elemento de modelo que elas afetam no diagrama.

Também é útil controlar regras de negócios em Atributos de Requisitos, para fins de rastreabilidade e relatório.

Regras de Estímulo e Resposta

Esse tipo de regra de negócio afeta o fluxo de trabalho de um caso de uso de negócios e pode ser rastreada nos casos de uso de negócios aos quais se aplica. É possível mostrar um caminho condicional ou alternativo através do fluxo de trabalho. Se as ações envolvidas são menos significativas, talvez seja suficiente deixar a avaliação da regra de negócio ser incluída em um estado de atividade.

No modelo de objetos de negócios, uma regra desse tipo poderia, por exemplo, afetar a forma como você descreve o ciclo de vida de uma entidade de negócios ou ser parte da descrição de uma operação em um trabalhador de negócio.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

WHEN um Pedido é cancelado

IF um Pedido não é enviado

THEN fechar Pedido.

Essa regra de negócio é refletida mostrando dois caminhos alternativos em um fluxo de trabalho e especificamente usando condições de guarda e decisão em transições de saída.

A regra de negócio nesse caso é convertida em um caminho alternativo através do fluxo de trabalho

Regras de Restrição de Operação

Esse tipo de regra de negócio geralmente é convertida em precondições e pós-condições de um fluxo de trabalho ou em um caminho condicional ou alternativo em um fluxo de trabalho. Ele também pode ser uma meta de desempenho ou alguma outra regra não comportamental que deve ser rastreado nos casos de uso de negócios aos quais ela se aplica.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

Enviar Pedido ao Cliente

ONLY IF O cliente tiver um endereço de entrega.

A regra de negócio é convertida em um caminho alternativo no fluxo de trabalho

Exemplo:

Um outro exemplo de regra de restrição de operação é:

IT MUST ALWAYS HOLD THAT

Todas as pesquisas do cliente devem ser respondidas dentro de 24 horas do seu recebimento

Essa regra de negócio seria convertida em uma meta de desempenho de um caso de uso de negócios. Consulte a seção sobre Meta de Desempenho em Diretrizes: Caso de Uso de Negócios.

Regras de Restrição de Estrutura

Esse tipo de regra de negócio afeta as relações entre instâncias de entidades de negócios. Elas são expressas pela existência de uma associação entre duas entidades de negócios; às vezes como uma multiplicidade na associação. 

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

IT MUST ALWAYS HOLD THAT

um Pedido se refere a 1 Produto no mínimo.

Essa regra de negócio é convertida em uma associação com a multiplicidade de 1..*.

Regras de Dedução

Geralmente, as regras de dedução parecem semelhantes aos tipos de regra de estímulo e resposta, de restrição de operação ou de restrição de estrutura; a diferença é a existência de algumas etapas que precisam ser atingidas para chegar à conclusão. A regra implica um método que precisa ser refletido em um estado de atividade do fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou entidade de negócios.

Exemplo:

Talvez você tenha definido a seguinte regra para determinar o status de um cliente:

Um Cliente é um Bom Cliente IF AND ONLY IF

as faturas não pagas enviadas a esse Cliente têm menos de 30 dias.

Essa regra de negócio corresponde a um caminho alternativo através do fluxo de trabalho, e o método prescrito será parte da atividade Avaliar Cliente

Regras de Cálculo

As regras de cálculo são diferentes das regras de dedução; a diferença é que o método é mais formal e semelhante a um algoritmo. Assim como as regras de dedução, esse método precisa ser rastreado em uma atividade no fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou uma entidade de negócios.

Exemplo:

Uma regra de cálculo pode especificar cálculo de valor:

O preço líquido de um Produto IS COMPUTED AS FOLLOWS

preço do produto * (1+porcentagem de imposto/100).

A avaliação do preço líquido poderia ser parte da atividade Enviar Pedido quando você prepara a cobrança a ser enviada com o pedido. Nesse modelo de objetos de negócios, essa regra é convertida em associações e operações.

Essa regra precisa ser refletida como um método na operação de cálculo do preço líquido, mas também implica a necessidade de relacionamentos entre classes no modelo. 

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process