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. Podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos. Há duas maneiras de capturar regras de negócios:

• Baseadas em modelos - São regras de negócios capturadas como limites estereotipados em modelos UML. A regra pode ser declarada utilizando linguagem natural ou uma notação mais formal, como OCL (Object Constraint Language). A vantagem dessa técnica é que as regras de negócios são capturadas e exibidas na origem onde se aplicam. A maior desvantagem é que elas se espalham por todo o modelo, o que torna difícil visualizar as regras de negócios relacionadas. O Relatório: Relatório Sintético de Regras de Negócios fornece uma visão geral de todas as regras de negócios no modelo. 
• Baseadas em documentos - São regras de negócios capturadas em um documento separado. O documento contém regras de negócios, mas estas não são as regras utilizadas na abordagem baseada em modelos. Uma abordagem baseada em documentos é útil quando um grande número de regras de negócios é aplicável (tal como para produtos financeiros). Uma desvantagem é que as regras de negócios são capturadas em um artefato diferente da origem onde se aplicam.

Capturando Regras de Negócios

As regras de negócios podem ser capturadas na forma de modelo e de documento. Se você deseja obter uma visão geral de regras de negócios em modelos, poderá gerar um Relatório: Relatório Sintético de Regras de Negócios.

Um Documento de Regras de Negócios é útil especialmente para regras de negócios que com descrições longas, como legislação. A desvantagem das regras de negócios baseadas em documento é que ainda pode ser necessário rastrear a regra em todas as partes do modelo onde ela se aplica (no caso de mais de uma). Isso pode ser superado com a opção pelas regras de negócios baseadas em modelos, que podem ser capturadas diretamente nos modelos onde se aplicam. Entretanto, isso traz a desvantagem de estar "oculta no modelo", tornando mais difícil obter uma visão geral de todas as regras de negócios que tenham uma característica comum (como pertencente a uma determinada categoria).

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 seria utilizar a OCL (Object Constraint Language) conforme especificado na UML (Unified Modeling Language) [RUM98].  Considere sempre quem lerá as regras de negócios. Manter o foco no leitor ajuda a garantir que a maneira na qual você captura as regras de negócios (documentos ou modelos), o estilo selecionado e o nível de formalismo sejam adequados ao público-alvo. Regras de negócios que não podem ser entendidas por aqueles que devem lê-las são um desperdício de tempo para qualquer projeto.

Exemplo: 

Talvez você prefira indicar um limite de menos de 10 membros para uma equipe. Com a OCL, é possível definir essa regra de negócio com uma invariante:

context Team inv:

    self.numberOfMembers <= 10

Entretanto, lembre-se de que esse tipo formal de linguagem pode ser difícil de ser interpretado por muitos de seus investidores; por isso, um estilo de linguagem mais natural talvez seja preferível. É 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 anterior seria:

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

Categorias de Regras de Negócios

As regras podem ser classificadas de várias maneiras, embora seja comum dividi-las entre regras de limitação e de derivação. [ODL98] Ambas as categorias podem ser subdividias ainda mais da seguinte maneira: 

• Regras de limite especificam políticas ou condições que restringem a estrutura e o comportamento dos objetos. Regras de limite sempre podem ser aplicáveis ou aplicáveis somente sob determinadas condições. Os limites que sempre são aplicáveis são referidos como invariáveis.

• Regras de estímulo e resposta limitam o comportamento especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado. 
• Regras de limite de operação especificam as condições que devem ser verdadeiras antes e depois de uma operação para garantir que ela seja executada corretamente. 
• Regras de limite de estrutura especificam políticas ou condições sobre classes, objetos e suas relações que não devem ser violados. 

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

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

Essa classificação de regras de negócios é prática ao explicar o que são regras de negócios, como localizá-las e como trabalhar com elas. Entretanto, não há necessidade de considerá-las agrupamentos fixos os quais você sempre precisará consultar. Por essa razão, nosso gabarito para o artefato de regras de negócios não mostra essa classificação - em seu projeto, muito provavelmente, haverá outros agrupamentos (por domínio, por usuário ou por grupo de produtos) muito mais importantes de serem mostrados. Para obter informações adicionais sobre como classificar e aplicar regras de negócios, consulte [ROS97].

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

Uma regra de negócio afeta a aparência do modelo. Ela pode afetar também a seqüência das tarefas no diagrama de atividades e pode ainda afetar as associações que você possui entre as entidades de negócio. Não é fácil converter diretamente algumas regras para a aparência de um diagrama - elas podem precisar estar presentes nas descrições dos elementos de modelo. 

As regras de negócios em um diagrama da UML devem ser vinculadas ao elemento de modelo que afetam. 

É útil também rastrear regras de negócios nos Atributos de Requisitos para fins de rastreabilidade e geração de relatórios.

Regras de Estímulo e Resposta

Esse tipo de regra de negócios afeta o workflow de um caso de uso de negócios e pode ser rastreada no caso de uso de negócios ao qual se aplica. Você poderá mostrar um caminho condicional ou alternativo através do workflow. Se as ações envolvidas forem menos significativas, pode ser suficiente deixar a avaliação da regra de negócios ser incluída em um estado de atividade. 

No Modelo de Análise 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.  Examinar os eventos de negócios identificados é uma fonte muito útil para definir esses tipos de regras de negócios. Geralmente um evento de negócios é identificado porque alguém ou algo tem interesse em que o evento ocorra. Faça a pergunta, "Quais condições ou comportamento se aplicam depois que o evento ocorre?"

Exemplo: 

Em uma organização de gerenciamento de pedidos, você poderá localizar a seguinte regra: 

WHEN um Pedido é cancelado

IF um Pedido não é enviado

THEN fechar Pedido. 

Essa regra de negócios é refletida mostrando dois caminhos alternativos em um workflow e especificamente utilizando uma condição de proteção e decisão em transições de saída.  

A regra de negócios nesse caso é convertida para um caminho alternativo através do workflow.

Regras de Limite de Operação

Esse tipo de regra de negócios geralmente é convertida em pré-condições e pós-condições de um workflow ou em um caminho condicional ou alternativo em um workflow.   Também pode ser uma meta de desempenho ou alguma outra regra não comportamental que deve ser rastreada nos casos de uso de negócios aos quais se aplica.  

Exemplo: 

Em uma organização de gerenciamento de pedidos, você poderá localizar a seguinte regra: 

Enviar Pedido ao Cliente

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

A regra de negócios é convertida em um caminho alternativo no workflow.

Exemplo: 

Aqui está outra regra de limite 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 Diretriz: Caso de Uso de Negócios. 

Regras de Limite de Estrutura

Esse tipo de regra de negócio afeta as relações entre instâncias de entidades de negócios. 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, você poderá localizar a seguinte regra: 

IT MUST ALWAYS HOLD THAT

um Pedido se refere a pelo menos 1 Produto.  

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

Regras de Conclusão

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

Exemplo: 

Você poderá definir 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ócios 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 semelhantes às regras de conclusão. A diferença é que o método é mais formal e semelhante a um algoritmo. Assim como as regras de conclusão, esse método precisa ser rastreado em uma tarefa no fluxo de trabalho e, eventualmente, em uma operação em um trabalhador de negócio ou uma entidade de negócio.  

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 tarefa Enviar Pedido quando você prepara a cobrança a ser enviada com o pedido. No Modelo de Análise de Negócios, essa regra é convertida em associações e operações. 

Essa regra precisa ser refletida como um método na operação Calcular Preço Líquido, mas também implica na necessidade de relações entre as classes no modelo.