Yo, como don Quijote, me invento pasiones para ejercitarme.

Voltaire (1694-1778) Filósofo y escritor francés.

1 Introducción

Este documento está destinado a proporcionar una dirección práctica

para definir las mejores practicas en la identificación, adquisición
definición y guarda de las Reglas de Negocio dentro de la solución de
un sistema de informático/de computo.

Sé breve en tus razonamientos, que ninguno hay gustoso si es largo

Miguel de Cervantes Saavedra(1547-1616) Escritor español .

1.2 Motivación

Lo que se el trabajo presente pretende es organizar las reglas de

negocio de forma coherente y que den una perspectiva más cercana a
la forma de cómo ellas influirán en el sistema propuesto al momento
de analizarlo y adquirir sus requerimientos; y que sea independiente
de la metodología, plataforma o modelo de objetos a construir,
siguiendo mejores practicas.

3 Antecedentes.

Divide et vinces
Julio Cesar (100 adC – 44 adC). Líder militar y político romano
Desde siempre el mundo va generando conocimiento llámense leyes,
reglamentos, políticas, reglas, modelos, etc., tratando de ordenar y
hacer mas productivo su vivir y hacer.

En éste tiempo en el que las empresas u organizaciones cuyas

directrices sustentan su modo de actuar en diversos y variados
estándares, modelos, frameworks y metodologías; de producción, de
calidad, de desarrollo, de arquitectura etc. cuyos contenidos
afectan su razón de ser y de actuar, políticas, directrices, leyes, reglas
y costumbres son las diferentes formas de cumplir con algún proceso
de negocio o aplicar en los pasos para realizarlo y alcanzar el éxito
deseado.

En un problema dado al momento de generar un sistema informático

que aporte soluciones o facilite la ejecución de los procesos de la
organización, la parte más difícil es saber precisamente que construir
e incluir todos los requerimientos, reglas de negocio, procesos,
interfaces e interacciones con los usuario y otros sistemas. refzyz 3
para que el sistema funcione de acuerdo a la necesidad del usuario
final.

Por tanto hay muchos factores que pueden influir en el éxito del
desarrollo de los sistemas de información que no podemos pasar por
alto, entre ellos son:

 La elección de una correcta metodología de desarrollo

 Estimación y Planificación lo mas cercana a la realidad

 El uso de herramientas de la ingeniería para la gestión del

proyecto

 La infraestructura de la organización.

 Ah! y por supuesto gente con conocimientos, habilidades y

destrezas.

En la amplitud de la elección de la correctas metodología sean XP ,

SCRUM, RUP,CMMI, SW, ISO/IEC 12207, Software 2.0 etc., una de las
principales causas de atrasos y defectos en los proyectos de
desarrollo de software tiene como origen la especificaciones de
requerimientos deficientes; en éste contexto una correcta gestión de
las reglas de negocio como parte de ellos es importante de manera
tal que afecte positivamente los siguientes productos resultantes
durante el ciclo de vida de proyecto .

En el ámbito empresarial u organizacional donde las personas no

especializadas en temas de TI y en el que se tiene una forma distinta
de hacer las cosas y organizar el pensamiento es importante que se
entienda el mismo lenguaje y se ofrezcan las herramientas para la
comprensión del ambiente, negocio o contexto que se está
analizando, estudiando o generando una solución informática. La
reglas de negocio poseen un significado diferente para las empresas
(Administradores, Contadores, Auditoría, etc.) que para los
especialistas de T.I. dependiendo de si la perspectiva de cada uno es
orientada a procesos, datos u objetos, sistemas expertos, modelos,
métodos, frameworks, paradigmas y cuanta hierba hay en el
mercado;

4 CONTEXTO

Conocimientos puede tenerlos cualquiera,

pero el arte de pensar es el regalo más escaso de la naturaleza.
Federico II (1712-1786) Emperador de Prusia.

El concepto de “Regla de Negocio” esutilizado de diferentes maneras

y por diferentes especialistas en distintas materias y ámbitos; en la
10va Conferencia del Conocimiento basado en la ingeniería de
software Ref xxyy 1 una “Regla de Negocio ” son “declaraciones de
objetivos, políticas, o restricciones en una empresa en la forma de
hacer negocios ”.

Para Gottesdiener las reglas de negocio son parte del corazón de la

organizaciones. En su publicación Bussines Rule REF xxyz 4
pregunta “ ¿No son las reglas de negocio lo mismo que los
requisitos?, ¿No son solo las descripciones de los usuarios de lo que
desea que haga el software?. Dice además que los las reglas de
Negocio son el “saber” de los requerimientos funcionales: las
decisiones, las guías, los preceptos , las hipótesis y los controles que
son la guía de la funcionalidad.

Debemos mencionar tambiíen que para el OMG en su Terms and

Definition de la especificación técnica Semántica of Bussines
Vocabulario and Bussines Rules (SBVBR) una regla de Negocio es
“una regla que esta bajo la jurisdicción del Negocio”.

El W3C ref 5 dice que las reglas como tales estan en todas partes y
que son claves para el éxito las aplicaciones del Software

“Las reglas son un elemento clave de la Web Semántica que hace posible la
integración, derivación y transformación de los datos desde distintos recursos de
forma distribuida, transparente y escalable. En un entorno de Servicios Web, las
reglas hacen posible la automatización del cumplimiento y composición de
políticas que manejen el envío de información, el acceso a servicios o la ejecución
de procesos.”

El Business Rules Group a creado el GUIDE Business Rules Project

con cuatro objetivos específicos de los cuales vale la pena resaltar
los dos primeros.

1.-Definir y describir las Reglas de Negocio así como los

conceptos asociados para determinar que lo que es y lo que no
es.

2.-Definir el model oconceptual a fin de expresar para la gente

de TI lo que es una regla de negocio y como se aplica a los
Sistema de Información

En el Enterprise Architecture Framework de Zachmann se representa

en la Motivación del ¿Porqué? Correspondiente a Modelo del Sistema
Lógico puesto que ahí se puede definir el Modelo de Reglas de
Negocio ver fig xxwed
 fig1

Para Ronald G Ross el denominado padre de las reglas de Negocio

dice acerca de:

“pensemos en el paradigma de las Reglas de Negocio como un medio

relativamente económico para construir las puertas que habrán el
potencial económico para el negocio tal que podrían ser necesarias
algún día en algún caso pues en éste mundo en cambio constante la
agilidad es el nombre del juego”

REF

Ronald G. Ross, "When Is a Door Not a Door? ~ Basic Ideas of the

Business Rules Paradigm," Business Rules Journal, Vol. 10, No. 8
(Aug. 2009), URL: http://www.BRCommunity.com/a2009/b493.html
Para UML las reglas de Negocio representan el centro sobre el cual
se mueven , interactúan , relacionan y afectan los artefactos tales
como los el Modelo de Casos de Uso , los casos de Prueba , Diagrama
de Colaboración , el Diagrama de Estados ,Los diagrams de Actividad
y por supuesto el código.

fig 2

Las reglas de negocio se utilizan en múltiples contextos y variadas

áreas pero una cosa es segura éstas las dictan Agentes del Negocio,
los gerentes, directores,vendedores contadores supervisores, y
cuanto ánima haya en el bosque organizacional; no los diseñadores,
analistas, arquitectos, lideres de proyecto o cuanto rol o especialista
en TI exista en una organización.

5 FUNDAMENTO TEóRICO

5.1 Conceptos y Definiciones

Empecemos por definir qué es un caso de uso

Es una descripción del comportamiento e interacción de un sistema o

subsistemas, de quien puede hacer qué para lograr un objetivo
particular , y se puede utilizar para capturar los requisitos de dicho
sistema (funcionales y no funcionales), tal que sus escenarios
pueden ser descritos a nivel abstracto (esencial ) o a nivel del
sistema según se requiera .

Que tiene quever aquí los Requerimientos

En ingeniería, el requisito es una necesidad documentada singular de

lo que un determinado producto o servicio debe ser o hacer. Es más
comúnmente usado en un sentido formal en ingeniería de sistemas o
ingeniería de software. Es una declaración que identifica un atributo
necesario, la capacidad, características, o la calidad de un sistema a
fin de que tengan valor y utilidad para un usuario [1].

Ref http://en.wikipedia.org/wiki/Requirement

(a) Pero qué es una regla?

El diccionario de la Real Acedmia Española ref dlskfjstiene las

siguientes definiciones.

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=regla

Regla

(Del lat. regula).

1. f. Instrumento de madera, metal u otra materia rígida, por lo común de poco grueso y de
forma rectangular, que sirve principalmente para trazar líneas rectas, o para medir la
distancia entre dos puntos.
2. f. Aquello que ha de cumplirse por estar así convenido por una colectividad.
3. f. Conjunto de preceptos fundamentales que debe observar una orden religiosa.
4. f. Estatuto, constitución o modo de ejecutar algo.
5. f. En las ciencias o artes, precepto, principio o máxima.
6. f. Razón que debe servir de medida y a que se han de ajustar las acciones para que
resulten rectas.
11. f. Fil. Conjunto de operaciones que deben llevarse a cabo para realizar una inferencia o
deducción correcta.
12. f. Ling. Formulación teórica generalizada de un procedimiento lingüístico. Regla de
formación del plural
13. f. Mat. Método de hacer una operación.
Para qué sirve una regla?

Dentro del ámbito de las organizaciones las reglas sirven para

declarar o establecer un principio, norma política o ley para guiar o
prescribir una accion , operación o conducta.

(b) Que significa negocio

Negocio ref lkfjsdl http://es.wikipedia.org/wiki/Negocio

El término negocio deriva de las palabras latinas nec y otium, es

decir, lo que no es ocio. Para los romanos otium era lo que se hacía en
el tiempo libre, sin ninguna recompensa; entonces negocio para ellos
era lo que se hacía por dinero.[1] Es una ocupación lucrativa que
cuando tiene un cierto volumen, estabilidad y organización se llama
empresa.[2] También es la consecuencia de la correcta
administración de los recursos con un resultado económicamente
positivo para las partes; es importante señalar que no solamente
puede ser dinero sino relaciones de poder.

Específicamente, negocio puede referirse a entidades individuales de

la economía. En algunas jurisdicciones legales, tales entidades son
reguladas por la ley para conducir las operaciones a favor de
empresarios. Un negocio industrial es referido comúnmente como
una industria: por ejemplo: La industria del software, del acero o
automotriz.

a+ b = Reglas de negocio

Según el the free diccitionary una Regla de Negocio o Business Rule

Un término, hecho o regla que es representada en un predicado. REF

Ronald G Ross 1997 p380 the Bussines Rules book 2d edition

Una discreta operación en la política de negocios y la práctica. La

reglas de negocio pueden ser considerada un requerimiento del
usuario(lo que es mandatario para él y su forma de hacer que se
cumplan los objetivos de la organización) que se expresa de forma no
técnica ni procedural (generalmente pronunciados en forma textual)
... representa una declaración del comportamiento empresarial. REF
Ronald G Ross 1994 p496 the bussines rules book 1st editon

“…describe las operaciones y las restricciones que se aplican en una

organización en la consecución de sus objetivos.”

Ref v http://en.wikipedia.org/wiki/Business_rule

“…es una declaración que define o restringe algún aspecto del

negocio. Su objetivo es hacer valer la estructura de negocios o para
controlar o influir en el comportamiento de la empresa… describen
las operaciones, las definiciones y las limitantes que se aplica en una
organización en la consecución de sus objetivos”.

Cual es la diferencia entre una una regla de negocio y un

requerimiento de Negocio .

Las reglas de negocio es una lista de declaraciones que contienen los

criterios o condiciones de lo que uno puede hacer o no; en cambio un
requisito de negocio es lo que se necesita (el medio )para la
aplicación, el cumplimiento o ejecución e las reglas de negocio.

Pongamos por ejemplo lo siguiente:

Recién llegué a trabajar al IMSS un regla de negocio era que debía

llegar a las 8:30 de la mañana ; sin embargo dado el nivel de
“exigencia” del lugar se me cambio por el de las 9:00 am pero como
nadie llegaba a esa hora y salía tarde de trabajar pues llegaba a las
1000 am ,.Así pues si querían que se cumpliese la regla de negocio “la
hora de entrada es a las 9am ” había un requisito de por medio
debían aumentarme el sueldo para poder comprarme un auto (el
medio) para poder llegar a tiempo.(risas)
Así pues las norma existen aún cuando no se puedan aplicar los
requisitos y la ejecución o aplicación del requisito no es necesaria
para que las reglas o el conjunto de normas se deban de cumplir.

Sin embargo la aplicación del requisito permitiría la facilidad de

aplicación de regla.

El punto importante a recordar es que las reglas de negocio son lo

que necesitamos para giuar la conducta. Sin embargo, si se decide
implementar o hacer cumplir para guiar la conducta es una cuestión
diferente. No hay que confundir los dos.

Puede haber muchas necesidades empresariales diferentes

alternativas para implementar o aplicar un conjunto de reglas de
negocio.

Las reglas de negocio son lo que son. No deben cambiar para

adaptarse a los requisitos del negocio.

Dicho esto pues, vale decir que las reglas de negocio trata de cómo
un negocio u organización toma las decisiones para lograr sus
objetivos y no acerca de cómo funciona o se ejecutan dentro de un
sistema.

Por eso es importante saber distinguir entre lo que es un

requerimiento y un regla de negocio para lo cual es necesario que la
personas adecuadas deban de definir y distinguir las reglas de
negocio de los requerimientos.

Y PORQUE CAPTURAR LAS REGLAS DE NEGOCIO EN LOS

REQUERIMIENTOS

Apartándonos un poquito del camino retomamos la teoría Económica

que es la administración de los recurso escasos de una sociedad
familia o individuo con la finalidad de satisfacer sus necesidades
luego entonces cada acción, política regulación u orientación tiene
un propósito: eficientar los recursos y reducir gastos y atender el
propósito para el que existe sea comercial social o individual.

Por tanto cada norma, acción, ley o restricción tiene un repercusión

en el todo de la Organización.

Supongamos que una Institución “X” está supeditado a las distintas

normas internas y externas rigen su vida Institucional la cual posee
un sistema que le permite capturar el registro de todos los asuntos
jurídicos del área Jurídica y en caso que uno sea de relevante
importancia políticamente hablando, dada un criterio no escrito, éste
prende un foco y es asignado como prioritario en su atención y
seguimiento; puesto que le puede generar mala impresión para la
opinión Pública entre otros resultados no positivos.

Cada de reglas de negocio se alinea con uno o más de estas grandes

políticas. Tonces si el equipo de desarrollo no logra capturar las
reglas de negocio en primer lugar es seguro que el proyecto de
software sufrirá uh reproceso y otras ineficiencias. Por eso estre
otras razones es importante captura las reglas de negocio cuando se
están capturando los requerimientos.

Gran parte del cambio en los "requisitos" en realidad proceden de

cambio de las reglas de negocios y apartándolos puede reducir
dramáticamente el cambio en los requisitos de sí mismos. Sin
embargo, la mayoría de los sistemas de pasar la mayor parte de su
cambio de vida que no se especifica, por lo que se necesita para
construir sistemas en los que las normas pueden seguir cambiando
con el tiempo.

COMO Y PORQUE

Para comprender como el modelado de Casos de Uso nos ayuda a

definir los requisitos referenciados a las Necesidades. Los requisitos
definen las capacidades operativas de un sistema sean funcionales o
no funcionales, que son la base de todo desarrollo de Software, dicho
esto algunos de los requisitos evolucionan a partir de las necesidades
de los Usuarios; por otro lado los requisitos no funcionales definen
los atributos de calidad tales como seguridad, performance,
rendimiento y las limitantes técnicas como el lenguaje (si aplica ) y el
performance o la Base de datos.

Los requisitos son le resultado de tres puntos de vista Al final de

cuentas los requisitos son los el resultado de la extracción de las
Necesidades de las tres áreas generales de interés: la de negocios, la
del usuario y la técnica. Aunqqu a veces hay que ir mas lejos de la
identificación de Necesidades / Requistos que sean independiente
dela Tecnologogia.

La literatura delas rReglas de Negocio establece quelas reglas de

egocio no deben ser ambiguas por lo que ttodos los térmiono se
deben definir apropiadamente y establece com buena pracica
necesaria que todos los conceptos

A ver papá

La literatura de Reglas de Negocio [Ros03, Mor02] establece que las reglas de negocio no
de- ben ser ambiguas, por lo que todos los t¶ermi- nos sados se de¯nen apropiadamente, y
establece como pr¶actica necesaria que todos los conceptos (t¶erminos) utilizados en las
reglas deben estar de- ¯nidos en un vocabulario de negocios. El vo- cabulario de negocios
de¯ne todos los t¶erminos y lista los signi¯cados de estos conceptos relevantes para
describir las reglas de n egocio de ese dominio en un lenguaje particular, las relaciones
entre es- tos conceptos, de manera similar a c¶omo se de¯nen los conceptos en los modelos
de ontolog¶³as.

A business rule defines or constrains one aspect of your business that is intended to assert
business structure or influence the behavior of your business. Business rules often focus
on access control issues, for example, professors are allowed to input and modify the
marks of the students taking the seminars they instruct, but not the marks of students in
other seminars. Business rules may also pertain to business calculations, for example, how
to convert a percentage mark (for example, 91 percent) that a student receives in a seminar
into a letter grade (for example, A-). Some business rules focus on the policies of your
organization, perhaps the university policy is to expel for one year anyone who fails more
than two courses in the same semester.

Figure 1. Some sample business rules (summary form).

• BR123 Tenured professors may administer student grades.

 • BR124 Teaching assistants who have been granted authority by a tenured professor may
administer student grades.
• BR177 Table to convert between numeric grades and letter grades.
• BR245 All master’s degree programs must include the development of a thesis.

Figure 1 summarizes several examples of business rules. Notice how each business rule has a
unique identifier, my convention is to use the format of BR#, but you are free to set your own
numbering approach. The unique identifier enables you to refer easily to business rules in other
development artifacts, such as class models and use cases.

In some situations you’ll discover that business rules can be described very simply, perhaps
with a single sentence. In other situations this isn’t the case. Figure 2 presents one way to
fully document BR123. There are several sections in this figure:

• Name. The name should give you a good idea about the topic of the business rule.
• Description. The description defines the rule exactly. Although I used text to describe this
rule it is quite common to see diagrams such as flow charts or UML activity diagrams
used to describe an algorithm. Other options include business rule languages such as
Object Constraint Language (OCL), the ILOG rules language, or Business
Rules Markup Language (BRML). As Agile Modeling suggests, Apply the Right
Artifact(s) for your situation.
• Example (optional). An example of the rule is presented to help clarify it
• Source (optional). The source of the rule is indicated so it may be verified (it is quite
common that the source of a rule is a person, often one of your project stakeholders, or a
team of people).
• Related rules (optional). A list of related business rules, if any, is provided to support
traceability between rules.
• Revision history (optional). An indication of the date a change was made, the person
who made the change, and a description of the change.

Figure 2. Detailed business rule.

Name: Tenured professors may administer student grades

Identifier: BR123
Description: Only tenured professors are granted the ability to initially
input, modify, and delete grades students receive in the
seminars that they and they only instruct. They may do so
only during the period a seminar is active.
Example: Dr. Bruce, instructor of “Biology 301 Advanced Uses of
Gamma Radiation,” may administer the marks of all
students enrolled in that seminar, but not those enrolled in
“Biology 302 Effects of Radiation on Arachnids,” which
is taught by Dr. Peters.
Source: University Policies and Procedures

Doc ID: U1701

 Publication date: August 14, 2000
Related rules: BR12 Qualifying For Tenure

BR65 Active Period for Seminars

BR200 Modifying Final Student Grades

Figure 2 is clearly a lot more wordy than most project teams need. A more agile approach would
be to simply write the name of the business rule, the business rule number, and the description on
an index card and leave it at that. Or you might want to get a little fancier and type the business
rule into a Wiki page (www.wiki.org) or a word processor (feel free to use this template).
Remember to keep your models as simple as possible.

Business rules are identified in the normal course of requirements gathering and analysis.
While you are usage modeling, perhaps with use cases or user stories, you will often
identify business rules. A rule of thumb is if something defines a calculation or operating
principle of your organization then it is likely a good candidate to be documented as a
business rule. You want to separate business rules out of your other requirements artifacts
because they may be referred to within those artifacts several times. For example, BR129
was referenced by the Enroll Student In Seminar use case and likely would be referenced
by your class models and perhaps even your source code. However, if you have only a
handful of business rules or use cases, you may choose to document them right in the use
cases. A rule of thumb: start out including them in the use cases until it becomes obvious, or
painful, to do so. This may be because the sheer number of business rules is dominating the
use case or because the same business rule is referenced in two or more use cases.

A good business rule is cohesive: in other words, it describes one, and only one, concept.
By ensuring that business rules are cohesive, you make them easier to define and increase
the likelihood they will be reused (every time one of your artifacts refers to a business rule,
even other business rules, it is effectively being reused). Unfortunately, because business
rules should focus on one issue, you often must identify a plethora of rules.

Ronald Ross (2003) describes several basic principles of what he calls “the business rule
approach”. He believes that rules should:

• Be written and made explicit.

• Be expressed in plain language.
• Exist independent of procedures and workflows (e.g. multiple models).
• Build on facts, and facts should build on concepts as represented by terms (e.g.
glossaries).
• Guide or influence behavior in desired ways.
• Be motivated by identifiable and important business factors.
 • Be accessible to authorized parties (e.g. collective ownership).
• Be single sourced.
• Be specified directly by those people who have relevant knowledge (e.g. active
stakeholder participation).
• Be managed.

Many business rules can actually be thought of as constraints, and in fact constraints can
apply to either technical or business issues. In the UML business rules are often described
on diagrams using the Object Constraint Language (OCL) (Warner and Kleppe 1999)
which can add to people’s confusion regarding the differences between the two concepts.
Don’t worry about it, the important thing is to identify and understand the requirement not
categorize it.

EJEMPLOS

Los siguientes son ejemplos de reglas de negocio o de

las políticas de negocio como una persona de negocios puede
inicialmente su expresión:
• Un cliente es la prima de cada cliente
cuya calificación crediticia es A o B.
10 Capítulo 1: La hoja de ruta esencial de Reglas de Negocio
• Si un cliente solicita un préstamo de la prima de
más de 500.000 dólares, permitirá un retraso en la
fecha del primer pago por 30 días.
• La fórmula para el cálculo de un estudiante
acumulativa promedio de calificaciones se encuentra en
la página 6 de la política de manual del alumno.
• El conductor debe proceder en un determinado
de dirección, si la calle tiene la etiqueta "Senso
Unico ", pero puede proceder de lo contrario
dirección sin pena a menos que el conductor
causas de un accidente.
• Si la calificación de crédito fuera de un solicitante de
préstamo es
el marginal y el solicitante también tiene un crédito
saldo de la tarjeta de más de $ 5.000, entonces es
muy probable que el solicitante no podrán pagar
un préstamo.
• Un empleado que ha cumplido cinco años
de empleo a tiempo completo con la empresa es
derecho a cuatro semanas de vacaciones pagadas.
• Las opciones sobre acciones chaleco, a razón de un tercio
cada uno
año durante tres años.
• Un cliente con pagos pendientes de pago
debe pagar en su totalidad antes de un nuevo orden que se
enviados.
• Un cliente preferido recibe automáticamente
envío expreso libre en todos los órdenes.

COMO LE VAMOS A HACER a verr aver

1.Business Rule Mining Best Practices

1.1.1From Wikibooks, the open-content textbooks collection
Current revision (unreviewed)
Jump to: navigation, search
A Wikibookian suggests that this page be broken into several subpages
Smaller pages are easier to read and edit. See best practices for more information.
You can ask for help in the projects reading room.

1.2Contents
[hide]

• 1 Business Rule Mining - Best Practices

o 1.1 Preparatory Steps
o 1.2 Rule Mining Steps
o 1.3 Subject Matter Expert Review and Approval
o 1.4 Conclusion
• 2 Footnotes

• 3 Notes and references

1.3 [edit] Business Rule Mining - Best Practices

Below is a general approach towards the semantic capture of technical rules and their
abstraction into business rules.

1.3.1[edit] Preparatory Steps

A series of preparatory help to avoid protracted rules mining exercises, ensure that rules are
valuable to the business, and speed the process of creating ‘business’ and not simply
‘technical’ rules. These steps are recommended to build the right organizational framework
and to align rule mining with business priorities.

1. Project Goals and Desired Output

It is important to define the goals and outputs of the rules mining activity. This will vary
depending on the business priorities of organizations. For some, the goal may be to address
inflexibility or high downtime in a highly valuable and customized application. This may
lead to the decision to move to a SOA-enabled packaged application.

Depending on the goal there will be two primary outcomes that can be derived from a rules
mining activity:

Documentation In some cases, the goal may be to develop business-centric documentation

of program code segments. This documentation, valuable as reference for other analysts
and subject matter experts, may also be used to decorate high-level design models for the
modernized, to-be applications. It would not normally result in executable business rules or
inputs into development environments.

Business Rules In other cases, the exact semantic behavior of edits and calculations in
applications needs to be captured as true business rules. The captured semantics will be
used as a basis for, and perhaps even directly fed into, target development environments.
The outcome of this step will drive decisions regarding technology adoption, resource
planning, and the best methods to apply for either type of rule mining.

2. Rule Mining Technology Selection

Largely Manual Approach A low-cost, low-value application of technology for rule mining
is the documentation of rules in word processing or spreadsheet applications. This approach
will not help address the most resource-intensive portions of rule mining – like analyzing
application behavior and locating rules within source code segments.

Runtime Simulation Runtime simulation technologies that facilitate the capture of user
behavior into processes and rules can help from a behavioral aspect. Their main drawback
is that they are limited to those test scenarios actually performed within a given time frame
– potentially missing out on critical exceptions not usually performed.

Scanning Tools Text scanning tools that locate patterns within sources can accelerate the
capture of rules based upon fixed patterns within source code (e.g. showing all moves to a
variable). These tools typically generate a large number of false positives and tend to lead
to technical rather than business rules.

Repository-Based Rule Mining Tools Repository-based technologies that recompile the

sources and build a syntactic parse tree can offer the highest value in rule mining. The most
advanced automatically detect rules using semantic analysis, e.g. each statement upstream
from a point of interest variable and which potentially impacts its value, is mined as a
candidate rule.

Rule mining tools may also offer rule management and auditing capabilities, facilitating
project workflow and rule maintenance activities by reviewers. They are also able to retain
rule traceability to originating sources even when those undergo change (as they often do in
a live environment).

Considering the above, the tradeoff of a low-cost approach to rule mining will be in higher
manual effort and lower quality of results. This may be acceptable in one-off, small-scale
documentation scenarios, but less likely to be so in enterprise level modernization efforts.

3. Time and Resources Allocation

Project goals and choice of technology will impact resource allocation. All too often,
expectations from the business side are to receive a precisely modeled set of business rules
derived from the application semantics, without realizing the complexity of such an effort.
On the IT side, practitioners without experience in rules mining or familiarity with the
application subject matter are ill-equipped to offer reliable estimates.

An iterative approach toward time and resource estimation may be adopted. Mining rules
for a representative sub-set of the application over the first few weeks provides insights into
the methods that work best for selected applications, as well as a yardstick by which the
overall effort can be estimated.

4. Business Processes Mapping and Alignment

The logic mined is important because of its business context. After all, logic is a subset of
an overarching business process. Mined rules will make sense only when placed into
context within the associated process. For example, assigning a prospective customer to an
income bracket based upon her zip code might have different significance in credit
approval and marketing campaign processes (witness insurance companies advertising that
they will only look at past behavior and not credit ratings to set premiums).

Further, viewing applications in a business process context is important in order to identify

priorities for rules mining activities. An enterprise commonly views itself in terms of its
processes – registering a new customer, underwriting a policy, receiving payment,
registering a claim, depositing funds into an account and so on. Some of these processes are
of critical importance to the organization, while others are simply commodity functionality.
Some processes may be meeting service level agreements set by line of business
executives, and others not. Where modernization activities will focus will vary based on
this calculus.

Once the business processes have been modeled, application elements that support the
chosen processes are identified. Historically, these applications were organized in silos,
making the high-level match a straightforward step. At a more granular level, however, a
monolithic order management application may handle customer enrollment, credit
approval, order entry, and order fulfillment. If an organization is only interested in mining
rules for the customer enrollment and order entry components, a mapping exercise between
processes and their supporting application portfolio elements will be beneficial.
With repository-based software, application objects are registered and syntactic and
semantic relationships within them are automatically captured.

Cases of overlap are noted, where a program or data store serves multiple business
processes.

Example – Customer Orders

In Figure 1 below, the Customer Master, Order Master, and Inventory data stores are within
the scope for rule mining despite the fact that they support additional processes outside of
the scope. Similarly, the Customer Handling program is monolithic and includes logic for
Credit Approval, outside of the scope of this effort.

Figure 1: Business Process Mapping to Application Objects

5. Application Analysis

In the previous steps, an application has been inventoried and it has been understood, at a
high level, where the required business processes of interest reside within application
artifacts. The next task will be to decompose the application into its constituent logical
elements. A key factor continues to be contextualization. Elements of the application that
are not relevant to organizational priorities are excluded. This scoping via context allows us
to also see the ‘boundaries’ of rules and their associated impacts.

Application Decomposition
In this step, the application is further decomposed into its detailed components. The goal is
to have a sufficiently detailed collection of artifacts to serve as input to the rule mining
step.

Here too, technology can help. Repository-based software can create a parse tree of detailed
application objects and their relationships. This information is then presented in multiple
graphical and textual views, synchronized with each other to facilitate context-sensitive
analysis.

For example, a context view will display all data field declarations, procedures, and
procedure calls within a program in a compressed and outlined mode. A detailed source
code view will display code segments corresponding to the context view, allowing for quick
navigation through the program via the context view. Traversal through the context view
will enable a user to gain quick insights into a program's structure and complexity.

Other views available at the detailed program level include diagrammatic control flow
between paragraphs, logic flowcharts within paragraphs, execution paths and runtime
simulators for chosen conditional outcomes. Such tools are used to gain detailed insights
into an application prior to actually starting the rule mining phase.

Without the benefit of automated parsing tools, value can still be gained by conducting a
manual inspection and walkthrough of application artifacts.

Identification of Exclusions

In the process of reviewing and analyzing an application, elements not to be included in the
scope of rule mining, for functional and technical reasons, are marked. These may include
standard utilities, reports, system routines and out-of-scope business processes. In the
example from Figure 1, this would include the artifacts related to Credit Approval and
Order Fulfillment, out of scope due to their nature as commodity, standardized business
processes.

The identification of exclusions illustrates a benefit to be derived from the up-front

business contextualization steps described above. If they had not been conducted, a "broad
sweep" approach would have resulted in a higher investment at the rule mining and SME
review stages, where rules from the commodity business processes would first have been
mined and then later discarded as irrelevant.

6. Glossary Creation

A major challenge with mining rules from applications is that it can be difficult to navigate
the various variables and naming conventions within. These conventions have often a
tenuous link to business terminology, and can make understanding the logic from a business
perspective difficult.

A best practice is to refine these technical terms to create more a more business-centric
view. This can be achieved through glossary of application objects and related business
terms. Objects could be data fields, paragraphs, programs, data sources, and other
application objects of interest.

Sources of information for a glossary of terms can be business documentation, data

dictionaries, database schemas, user notifications, and even source code comments.

Automated rule mining tools offer a facility to propagate values for repeating patterns
(commonly called ‘tokens’) within your application. For instance, the token 'ACCT-' may
be replaced everywhere by 'Account-'. A tool would then use the glossary business names to
replace technical terminology in the automated construction of candidate rules.

7. Rules Composition and Hierarchy Definition

The desired rules format is established in advance. The same rule to set an order discount
may take alternate forms, such as

(i) Declarative form: "Each applicant who is a senior AAA member from California
receives a 5% discount."

(ii) If-Then-Else form: If an applicant is a senior, then if she is an AAA member, then if she
resides in California, assign a 5% discount.

(iii) As an entry in a decision table:

Figure 2: Entry in Decision Table

It can be useful to attach to a mined rule additional informational and workflow attributes,
such as:

• Reviewer text annotations

• Rule type (I/O, calculation, validation, security)
• Audit status (approved, not approved)
 • Workflow status (extracted, working, accepted, rejected)
• Transition (valid, requires modification, duplicate, complete)
• Reviewer Identity
• Program derived from
• Code segment location (start, end)
• Code segment text
• Input and output data elements

A rule will also be placed within a hierarchy. All rules representing a decision or executing
under a given set of conditions may be grouped into a Rule Set. Rule Sets will be grouped
into higher level activity nodes reflecting the business processes they currently participate
in.

If you are planning to populate an executable Business Rules Management System

(BRMS), you will want to define a schema that is easily transferable into the specific target
environment chosen. If the target environment is not yet known, refer to available business
rule standards. [1] [2] [3]

8. Rule Mining Workflow

Enterprise rule mining is usually a multi-step process involving practitioners with disparate
skill sets – including consultants, developers, architects, analysts, and subject matter
experts. Often key personnel will be distracted by other projects and it is therefore crucial
that a common workflow be defined and documented.

Following the guidelines provided further in this document, a high-level workflow may
appear as:

Figure 3: Sample Rule Mining Workflow

Each step should be defined in detail, following an adopted methodology, project scope and
constraints and rule mining technology usage. There may be multiple iterations of the first
few steps until the rules are in an approved, final format.

1.3.2[edit] Rule Mining Steps

9. Mining of Candidate Rules

At this point rules are mined from the application artifacts mapped to the scope of the
business processes identified in previous steps. Rule mining tools help you assure that
excluded artifacts are not included in scope by enabling the organization of an application
into sub-groupings. Rules will be mined for a sub-grouping and not for the entire
application.

The specific rule mining approach taken is primarily driven by application patterns and the
desired output.

Top-Down Approach

A top-down, or process-oriented approach starts from an examination of the user interface

in an online application, or from the job flow in a batch application.

In an online application, a transaction may be invoked by a user selecting a menu option or

entering a value to the screen. The fields that define the message or event that is sent from
the screen to the interfacing application are identified. Each field in the triggering message
may be considered a seed field for rule mining.

Using a seed field as a starting point, all of the downstream data impacts to the field
including all conditional permutations are documented. Each data transformation (move
into another field or calculation), represents a candidate business rule to be captured.

Rule mining software tools assists in this task by visualizing a data impact path forward for
each seed field to each point where it is either populated by new values or used as input to
other fields via comparisons, value propagation and calculations. At each such point, the
tool can be used to document the underlying business rules. Automated rule detection
methods can also be applied to capture each screen field edit as a candidate rule.

In a batch application, the concept is similar. Part of a job flow, e.g. a Job Control Language
or group thereof that realizes a business process is identified, and all rules within individual
programs relevant to that process are mined.

Figure 4: Top-Down Rule Mining

In Figure 4 above, note the format of the resulting "Derived Candidate Rules".
Automatically detected from a Cobol program, they resemble its constructs, with variable
names replaced by the Glossary definitions. These will later undergo review and
transformation to a more businesslike form. While this example is demonstrated for a
Cobol application, advanced mining tools may apply to a broad array of languages from
PL/ and Natural to Visual Basic and Java.
Bottom-Up Approach

A bottom-up, or data-oriented approach starts from an examination of system outputs – data

sent to files (both batch and online), screens and output messages (online only).

Following this approach, rules are captured by starting from an interesting data point and
identifying all logic impacting that point. For example, an Order Discount field is impacted
by discounts calculated upstream from it, depending on the customer's location of
residence.

Figure 5: Bottom-Up Rule Mining

Rule mining technologies are particularly well suited to this approach. Through visual
inspection or a repository query, data outputs of interest can be quickly identified. Then,
automated rule detection routines are able to capture a candidate rule for each statement
that impacts the point of interest. Because of the pre-organization into contextualized sub-
groupings mentioned above, the search results will be constrained by the subset of business
processes deemed relevant for rule mining.

Inspection of relevant DBMS tables may also produce rules embedded in keys and any data
rules for referential integrity and value constraints. Once all data points of interest have
been covered, all application logic of interest oriented toward existing outputs has
essentially been mined.

Hybrid Approach

A hybrid approach combines the two approaches described above:

• The first step is a top-down oriented capture of the relevant transactions;

 • For each transaction, bottom-up rule mining is performed, including only data
outputs that have not yet been already mined for another transaction.

The benefit of this approach is to extend the coverage of rule mining while avoiding
repetition.

Relating to the examples shown in Figures 4 and 5 above, following a strictly top-down
approach resulted in repetitive efforts for the Quantity and Price fields since they both
traversed identical downstream data impacts. Coverage was also partial since not all of the
rules for Customer Discount were discovered.

Let’s consider an extended case involving both Order Entry and Proposal Issuance
processes. Adopting an exclusive bottom-up approach would have also resulted in
repetition, mining rules for upstream data impacts that "hit" multiple outputs (e.g. customer
discount rules). Using the hybrid approach, we would first mine rules from all outputs of
the order transaction, then only outputs of the proposal transaction particular to it.

Figure 6: Hybrid Rule Mining

10. Candidate Rules Verification

At this point, after mining candidate rules from your application, verification and correction
is a necessary step to ensure the correctness and completeness of the rules.
The candidate rules are examined for:

Accuracy Does each rule correctly reflect the underlying application behavior? If
automated rule detection technology has been used, a rule at the point of interest (seed
field) will be preceded by rules upstream from it, possibly with triggers, control conditions,
and automatic rule set groupings. Each one of them (or a chosen subset) is reviewed for
accuracy and corrections are made where needed, until the results are deemed satisfactory.

Redundancy Does a rule or rule set appear twice for the same application process? This can
occur when rules are mined separately for two separate outputs that share upstream
functionality. Or it can be a result of simple oversight like multiple team members
inadvertently mining rules from the same code base. A rule attribute is used to mark
duplication.

Another form of redundancy occurs when semantically identical rules were mined
separately and with different names from different processes (e.g. Order Detail and
Proposal). This will be dealt with in the next step, when you transform candidate rules to
business rules format.

Completeness Beyond predefined exceptions, has all of the application functionality been
covered? A rule coverage report, matching mined rule sources to overall sources, can
provide the answer.

Relevance Can each mined rule be considered a candidate business rule? Although this is
not yet the SME review step, there may be certain constructs that, upon inspection, are
clearly irrelevant and should not be included in the scope of rules for review. Security
verification rules, housekeeping routines and out-of-scope operations may all fall into this
category. Indicate relevance on one of the rule attributes.

11. Transformation of Candidate Rules to Business Rules Format

In the previous steps, candidate rules have been mined and reviewed, reflecting legacy
application behavior. These rules closely follow the application's procedural flow and
operations.

A transformational step is now required, to convert candidate rules to actual business rules
ready for review. This step is conducted either by application experts, rule architects, or
subject matter experts. After review and conversion, the business rules captured reflect the
current, as-is state to serve as a baseline or comparison to the target environment.

Reformatting to Business Rule Notation

If the candidate rules were constructed manually, they may already be in the chosen
business rules format. In other cases, they may have been captured in a technical format
(like cut and paste from source code) and will require some modification and regrouping.

If an automated rule detection tool was used, the resulting candidate rules may somewhat
resemble business rules, by using the glossary definitions to place business names within
rule names, data elements and controlling conditions. However, even after the rule
verification step, most of the approved candidate rules will need to be adapted to conform
to a chosen business rule notation.

Figure 7: Business Rule Transformation

Fact Modeling and Rule Normalization Due to their procedural nature, legacy applications
tend to lock business logic into process-specific silos. However, true business rules are
independent of process and should be maintained as such.

In our example, rules for the Order Detail Entry and Proposal Entry events have been
separately mined and placed in Rule sets. Are they all unique? Upon further examination,
most of the logic in them is identical by design. Analyzing the results from a business
perspective, there is commonality between portions of any customer document – whether
Order or Proposal.
From a tooling perspective, at this point it may make sense to switch over to a Business
Rule Management System, importing the mined rules from the rule mining tool as
described in the Integration section below.

Using a BRMS or a visual modeling tool, a Fact Model reflecting the significant business
entities and their interrelationships discovered in your existing applications is constructed.
These will link to the mined business rules and serve as a baseline for the to-be rules model.

In our example, part of the Fact Model would be:

Once this is done, the business rules are normalized to represent the desired business level
semantics:
…whereby the Customer Document Handling rules apply to both Orders and Proposals.

Grouping and Sequencing

At this point, the generated rule grouping and sequencing are considered. One point of
attention is the triggering relationships between rules and other rules and rule sets. Since
candidate rules are often derived from a 3rd generation language application (like Cobol or
PL/I), they are automatically sequenced in a procedural manner. Transformation to a
declarative mode will eliminate procedural elements that are non-business in nature.

As shown in Figure 8 below, declarative relationships that reflect true business

requirements will be modeled as triggers between rules and other rules or rule sets. In the
majority of BRMS] environments, a single rule may trigger multiple rules and rule sets,
where the sequencing of each triggered rule or rule set is pre-compiled or resolved only at
runtime.

Figure 8: As-is Business Rule Model (Event-driven)

1.3.3[edit] Subject Matter Expert Review and Approval

Once mined rules have been transformed into business rules, they are handed over to
subject matter experts (SMEs) and / or business analysts for review and approval.

Normally, SMEs will not make major changes to the rules at this point. Rule mining tools
may include rule attribution capabilities to aid the SMEs and enable them to mark up the
business rules as

• Approved or rejected;
• Reclassified to another category;
• Annotated with additional information in textual description attributes.

Rule mining tools also often offer web portals with a functional focus on predefined SME
activities. This can greatly accelerate the review and approval process.

12. Reports Production

Business rule reports are created in either hardcopy or digital formats. Rule mining tools
produce reports and diagrams depicting detailed or summary rule information within your
chosen context: hierarchy level, grouping, search result. These reports serve both as
reference in the review steps and as documentation of record.

13. Integration with a Target Environment

Depending upon the adopted modernization strategy, integration requirements with other
environments will vary.
Business Rule Development

Redevelopment with a business rule approach will typically leverage a BRMS authoring
environment. These tools typically include XML import capabilities, which will be used to
define an "as-is" business rule space, allowing rule developers to selectively re-use
candidate rules deemed relevant for the target environment. This will provide valuable (and
sometimes crucial) traceability from newly deployed rules back to their legacy origins.

Conventional Development

This approach typically involves building Java and .NET applications with comprehensive
developer toolkits. Often, UML models will be used to define logical application views
prior to actual code generation.

In these environments, mined business rules can be attached as behaviors in UML classes
that leverage them. For example, an Order_Invoice class including Order_Discount as an
attribute, may also include Calculate_Order_Discount as a class behavior. This behavior
can be derived (and potentially imported) from the mined business rule performing the
same function.

BPM

Process Management Business Process Management (BPM) tools facilitate process model
creation and linkage to underlying rules and executable services. They also include the
ability to define workflow rules (using BPEL) to govern the manual and automated
transitions between activity nodes.

In this context, each activity node may be realized by business rules. Many-to-many
relationships may exist between rule sets and supported activities. Populating BPM
processes with their relevant mined "as-is" business rules can "close the loop" for business
analysts and significantly advance IT / business alignment goals.

Requirements Management

Vendor offerings also include requirement tools that enable the definition of high level use
cases, detailed flowcharts and activities for effective application development and
management. In these environments, mined business rules can be imported and attached as
either core requirements or as textual annotations to activity nodes.

SOA Enablement
Service enablement of existing applications involves code refactoring and deployment as
service capsules. The rule mining step can be invaluable in locating fine-grained services
within source code and serving up the required service components. For example, the
results of automatic rule detection for the calculation of an order discount will include all
code segments leading up to the final calculation. By creating a component slice with that
code (and its dependents) only, the order discount calculation can be redeployed as a
service.

14. Proactive Rules Management

We expect most applications to continue and maintained for many years into the future.
Having mined rules from them, it is crucial that they continue to be updated and kept
synchronized with future application changes. Rule mining tools offer maintenance and
management capabilities, including

• Automatic alignment of rules with their original code segments even when they
have moved as a result of overall source code changes;
• Audit trails for manual rule changes;
• "Changer" routines allowing for individual or mass changes, post- rule mining.

1.3.4[edit] Conclusion

A well-defined approach to business rule mining will allow for business contextualization
early on in the process. Not only will the contextualization step help frame mined rules
correctly, it will also reduce the rule mining investment to focus only on critical and
dynamic business processes of interest. Regardless of the application modernization
strategy adopted, the best practices and tool-assisted approaches described here will help
you achieve your goals at a lower cost, with less repetition and higher quality results.

1.4[edit] Footnotes
En su libro el poder de lo simple Jack Trout y Steve Rivkin mencionan
que ser considerado simple no es una ventaja, que es mucho peor ser
considerado “simplista” según ellos (y comulgo con ellos) dice: “Es
como ser considerado ingenuo, o incluso, tonto o necio”.

A colación de la referencia, resulta que hace un par de meses cuando

mis amigos los uruguayos llegaron de la pampa creo que hubo falta de
simplicidad del lenguaje, quiero decir, refiérase a lo simple y llano
pues, a lo básico, al Diccionario de la Real Academia de la Lengua
en caso de cualquier duda o incertidumbre (duda 1. Estado de
indecisión o falta de certeza ). Resulta que teníamos una diferencia
de opiniones de cómo era o debía de ser un caso de uso, y cuales
eran o deberían ser sus componentes y cuales sus elementos
básicos.
Partiendo del principio, estábamos utilizando el modelo RUP ver Fig.
1.0 que es iterativo e incremental, había artefactos generados
puesto que la fase del proceso de Incecption, El “Business Modeling”
estaba en curso, ver Fig. 1.1

Fig. 1.0

Disciplina del Pasos Actividades Artefactos a

Proceso
Busi ne ss M odeli ng
(Entendimiento del Negocio )
producir
1. Para la iteración Inicial , Glosario de Negocio,
AD QU IR IR : R egla s d e Nego cio , Reglas de Negocio,
Nec esi sdad es del N egocio , En te nd imie nto Casos de Uso de Negocio,
del N egocio ; para las subsecuentes iteraciones Vison, Arquitectura
; Detallar R eg las de Negocio , E nt en dimie nt o Empresarial,
del N egocio .
2.
 ID ENT IF ICA R todos los Caso s d e U so de
Negocio , E spe cifica cion es s upl eme nt ari as ,
Mod elos, Regl as, Vi sio n y l a A rq uit ec tu ra;

para las subsecuentes X iteraciones

DE TALL AR los Ca sos de Uso d e Nego cio ,

Es pe cifica cion es su ple men ta ria s , Mod elos,
Regl as, Vi sio n y l a A rq uit ec tu ra

Fig. 1.1

2do Previo a ésta ya se habían generado un a lista genérica de casos

de uso de negocio como apoyo para para estimar el costo del
proyecto según la herramienta de Puntos de Función, (de la cual
hablaremos después) se tenía un avance de los Flujo de Procesos de
Negocio de alto nivel en el que inclusive se estaba aprovechando la
oportunidad de adquirir con el skateholder sus necesidades y
requerimientos de alto nivel.

Disciplina del Pasos Actividades Artefactos a

Proceso
Requi re me nt s
(Adquiriendo Requerimientos
del Usuario / Sistema)
producir
1. Para la primera iteraciion , AD QUI RI R lo s Stakeholder Requests Plan
Req ue rimie nto s( de l ato ni vel ) , & R eg las de de Adquisicion de
Negocio ; para las subsecuente x iteraciones Requeriminatops
De talla r lo s r eq ui rimin eto s y l as Regl as de , Especificacinoes
Negocio . Suplementaria s ,
Especificacjo de caso de
Uso,Modelo de Caos de
2. Para la primera iteración, IDEN TI FCA R t odos los
USo ,Glosario,Espcificacinio
ca so d e USo re lev an te s e ide ntifi ca rlos dea
de Requeriento de
cu erdo a s u ri esgo ; para todas la subseuentes
Software Storyboard, Use-
iteraciones DET AL LAR lo s c aso s d e u so
Case Package Diagrams,
(p riem er o los de ma s al to r ies go ) IL Us e-
User Interface Prototype
Ca se s ( high ri sk Us e-ca se s fir st ),
Sp ecific atio ns , M odel s, R eali za tion s to match
all lower-level A na ly sis Cla ss es a nd An al ysi s
Diag rams and higher-level Busi ne ss R ule s, &
Req ue st s.

PR IO RIT IZ E or RE PR IO RIT IZ E US E-CA SE S by

RI SK.

3ro Habíamos pasado a la segunda iteración del prrimer proceso en la

especificación de casos de uso de negocio y estabamos listos para
generar llos artefactos consecutivos y, si partimos de l apremisa que
un caso de uso es la representracion de actividades que la gente o
usuariio hace al interactuar con el sistema para al canzar sus
objetivos , luego entocndes, ellos son una herramienta eficaz para
comunicar y documentar lo que el sisterma esta destinado a hacer o
lograr. En tal caso estabamos creando los cimientos al sistema.

Proceos de Negocio

Qué es un proceso de negocio?

Esta página es un esbozo. Por favor, mejorarlo si es
posible.

Definición
Un proceso de negocio describe las relaciones y las
interacciones entre los objetos de negocio y funciones
múltiples negocios, limitada y dirigida a través de reglas de
negocio. Las relaciones pueden ser estáticas o flexibles,
como pueden ser las interacciones.

Un proceso de negocio es normalmente de larga duración

(horas, días, semanas, meses, o más), tiene un estado
almacenado, y es la mayor parte del tiempo de inactividad y
espera.

En mi punto de vista, de procesos de negocio es una colección

de ciertas actividades que tienen puntos de inicio y final
definidos, y que lograr algo de valor a múltiples
organizaciones. Por ejemplo, el proceso de negocios en el PI
y los actos CE como algunas actividades que se fulfiled.
0---------------------------------------------dgsdf---------------------------------------

A continuación se resumen las definiciones de los conceptos

relativos a reglas de negocio.

Reglas de Negocio
una declaración que define o restringe algún aspecto del
negocio. Este debe ser un término o de hecho (que se describe
a continuación como una afirmación estructural), una
restricción (que se describe a continuación como una
afirmación de la acción), o una derivación. Se trata de
"atómicas", ya que no se pueden desglosar o descompuesto aún
más en las reglas de negocio más detallada. Si se reduce en
más, no habría pérdida de información importante sobre el
negocio.
Declaración de Reglas de Negocio
una declaración declarativa de la estructura o la restricción
de que la empresa impone a sí misma o ha puesto en él.
Tipo de expresión formal de
una de las gramáticas formales para la representación de
reglas de negocio.
Declaración formal de la Regla
una expresión de una regla de negocio en una gramática formal
específico.
Política
una declaración general de la dirección de una empresa

---------------------------------tgeryyt-----------------------------------------------

Cada uno (atómica) de reglas de negocio debe ser uno de los

siguientes:

Una afirmación estructural - un concepto definido o una

declaración de un hecho que expresa un aspecto de la
estructura de una empresa. Esto abarca ambos términos y los
hechos reunidos de estos términos.

Una afirmación de la acción - una declaración de una

restricción o condición que limita o controla las acciones de
la empresa.

Una derivación - una declaración de conocimiento que se

deriva de otro conocimiento en el negocio.
La Figura 4 muestra la parte del modelo de reglas de negocio
que refleja estas ideas. Cada una de estas se describe en los
capítulos siguientes

------------------------------------------------------------------------------------------eferte--------

¿Qué reglas son Negocios

Las reglas de negocio representan sus políticas de negocio y

de decisión. Ellos controlan o forma de comportamiento y
decisiones empresariales. Indican lo que es posible o
deseable en la gestión de su negocio y lo que no lo es! Se
capturó la esencia de las empresas los conocimientos técnicos

-------------------------------------------fghdfghdgh-----------------------

Control - dictan cómo funciona el proceso, cuáles son las

actividades que realiza, cuánto tiempo tienen, qué
información necesitan, qué información se crean, etc

Visibilidad - ver rápidamente el estado de un proceso,

¿dónde está ahora, lo que se ha hecho, lo que hay que
hacer, crear informes, etc

Agilidad - El cambio es constante. Usted debe ser capaz de

cambiar rápida y fácilmente el proceso para satisfacer las
necesidades actuales.

Resultados de BPM - El rendimiento de la inversión al

reducir los costos, aumentar los ingresos y mejorar la
agilidad
Uso de un caso de uso de la información no de comportamiento.
Sucede que un escritor se le dice, "Uso
los casos son grandes. Escribir todo en casos de uso. "Pero
un caso de uso no es bueno para
todo, es en realidad sólo sirve para describir el
comportamiento. Todo lo que el sistema debe
realmente no debería ir en un caso de uso, pero todo lo demás
realmente debería ir a algún otro
formato. Algunos escritores de casos de uso a escribir los
casos de uso inmensamente la descripción pormenorizada de un
usuario de
forman la interfaz se rellena cada campo del formulario de
conseguir una o dos líneas en el uso de
caso. Un mejor enfoque es crear una Adorment (147),
simplemente conectar el
la forma a la parte posterior del caso de uso y la escritura
en el paso adecuado: "El usuario proporciona la
la información sobre la forma XYZ (véase el apéndice). "Esto
reduce tanto la escritura y la
la lectura, sin sacrificar los detalles. Requisitos de
funcionamiento, las reglas de negocio complejas,
estructuras de datos y descripciones de la línea de
productos, son valiosos, pero capturan mejor con
otros requisitos de herramientas tales como tablas, fórmulas,
máquinas de estado, o incluso simplemente se coloca
en otra sección del documento de requisitos

Los patrones son aplicables en todas las situaciones. Un

patrón es una solución a un problema dentro de un contexto
[COP1996]. La palabra clave aquí es el contexto, la idea de
que un patrón se aplica sólo dentro de una bien definida
área. Los patrones en este libro las soluciones de presente
que equilibrar cuidadosamente varias
las fuerzas que compiten en el espacio del problema. A veces,
sin embargo, una fuerza particular se convierte en
más importante y tiene un significado especial. Por ejemplo,
una organización de escritura casos de uso
información de la empresa utilizando sensibles que desee
ocultar algunos detalles, ni siquiera los actores, de sus
clientes. O, una empresa de describir un sistema que se basa
en varios bien definidos y
las reglas de negocio complicado en el que todos los
involucrados en el proyecto tiene que entender podría
desea incluir estas normas en sus casos de uso. En este caso,
podría ser más importante para el
empresa de publicar sus reglas de negocio en sus casos de uso
de lo que es que sus casos de uso sea simple
y de fácil comprensión. En ambos casos, estas organizaciones
necesitan equilibrar las fuerzas
implicados, para determinar las ventajas de seguir una
directriz específica. En estas situaciones, nuestro
recomendaciones no son necesariamente los mejores, y puede
ser necesario adaptarlos para ajustarse mejor a su
las necesidades o incluso ignoran por completo

Qué es una Regla.

La comprensión del sentido común de la "regla" es que una

regla siempre se tiende a eliminar un cierto grado de
libertad. Esto es sentido común
asesoramiento comprensión debería ser contrastada con la de
'', donde un grado de libertad nunca se quita, ni siquiera
potencialmente.
El grado de libertad removido por una norma que podría
afectar el comportamiento de las personas (en el caso de una
regla de negocio operativo), o
su comprensión de conceptos (en el caso de una regla
estructural). En este último caso, la restricción de la
libertad es incorporado (es decir,
"Estructurales" o "por definición"). En el primer caso, la
gente todavía puede potencialmente violar o ignorar la norma
- que es una cuestión de
el libre albedrío, la aplicación adecuada y, a veces la
discreción (por ejemplo, si la regla se ofrece simplemente
como una directriz o
sugerencia).

Un consejo es justo lo contrario de una norma. Considerando

que una regla siempre potencialmente elimina un cierto grado
de libertad, un consejo siempre
confirma o recuerda que cierto grado de libertad que no
existe o está permitido. Ese grado de libertad podría afectar
el comportamiento de
de personas (en el caso de una regla de negocio operativo), o
su comprensión de conceptos (en el caso de una regla
estructural).
Podría ser útil pensar en un consejo como una "norma de las
Naciones Unidas" o "no-Estado". Por ejemplo, el significado
de "Se permite que una orden de
ser pagado en efectivo "es que ese comportamiento es
permitido - que, en efecto, el pago en efectivo es aceptable.
En otras palabras, no es (o debería
BE) ninguna norma en contrari

Vocabulario de negocios + Reglas de

vocabulario de negocios, además de un conjunto de reglas de
negocio especificado en términos de que el vocabulario de
negocios

3.1 Definiciion de las reglas d negocio

3.2 Dominnio de las re3glas de negocio

Las reglas del negocio son esenciales para el fun-

cionamiento de las empresas [Ros03]. De¯nen los
t¶erminos y establecen las pol¶³ticas centrales del ne-
gocio. Controlan o in°uyen en el comportamiento
de la organizaci¶on ya que establecen qu¶e es posible
y deseable en la administraci¶on de una empresa,
y que no lo es.
Reglas de Negocio Las reglas de negocio son declaraciones
lógico que determinar y controlar las funciones de negocio de
una organización. Permiten a una organización para lograr sus
objetivos mediante la descripción de las operaciones, las
definiciones y las limitaciones. Las reglas de negocio
incluyen básicamente todo lo que tiene un negocio, por
ejemplo, los hábitos comerciales, manuales, políticas, líneas
de código informático, y las mentes de los empleados con
experiencia. Gestión de reglas de negocio, que están sujetos
a cambios frecuentes debido a un entorno ágil, es el mayor
desafío que enfrentan las organizaciones hoy en día. El
desenvolvimiento de un Business Rules Management System
(BRMS) ayuda a las organizaciones a mantener la flexibilidad
en la administración y mantenimiento y una respuesta en
tiempo real a los cambios en los requisitos de negocio. BRMS
le permite capturar, almacenar y administrar las reglas de
una manera transparente. Las reglas de negocio están
separadas del código de aplicación. Con la externalización de
las normas, las organizaciones ya no tienen que depender de
expertos en TI para aplicar los cambios a las políticas. El
uso de un BRMS conduce a las siguientes ventajas: Mayor
grado de transparencia menos esfuerzos de coordinación
entre los expertos en TI y expertos en negocios menos
pruebas y los costes de mantenimiento tiempos de ciclo
modificación Respuesta más rápida a los cambios sin
tiempo de inactividad necesario porque el cambio de código es
no se requiere una separación clara de los derechos de -
código (departamento de TI) y las reglas de negocio (experto
en negocios) el desarrollo de aplicaciones más rápido
porque las reglas de negocio son un medio poderoso para la
aplicación flexible de la personalización de conveniente
la representación gráfica de los escenarios de uso de
aplicaciones que hacen uso de BRMS como Business
Reglamentación marco más (BRFplus) están diseñados de tal
manera que las partes siguen siendo estable en la aplicación
y las partes que están sujetas a frecuentes cambios, se
delegan en el BRMS. Las partes estable puede incluir procesos
básicos y habilidades de la aplicación. Las piezas flexibles
pueden comprender algunas de las siguientes: Decisión
Servicios de Automatización de procedimientos tales como la
tramitación de reclamaciones, gestión de servicio al cliente,
la aprobación de crédito validación de datos y Detección
de errores en el diagnóstico con el seguimiento / alerta y
detección de datos no válidos y los Estados clasificación
y cálculo de Clasificación y se derivan a los clientes,
productos, o los riesgos Punto de encuentros
responsabilidades, los productos adecuados, o lugares
Cálculo Cálculo de los costes, los gastos generales, el
riesgo, el recargo de la importancia de BRMS se puede medir
por lo que los expertos Jim (Gartner Sinur) tienen para
decir: "... arquitecturas de los clientes están
interesados en el servicio, capaces de emprender rápidamente
proceso de cambio mediante el uso de normas basadas en los
motores. " " Así como cliente separados ayer interfaz de
servidor de proceso y de los datos, hoy estamos separando las
normas de flujos de trabajo y servicios . Reglamento " "
puede suavizar el impacto del cambio imparable ... " " Las
reglas pueden aprovechar los conocimientos de la acumulación
gradual de inmediato "
SAP Developer Network | sdn.sap.com Business Process Expert
COMUNIDAD | bpx.sap.com
© 2008 SAP AG 3
Reglas de Negocio marco más - los mismos fundamentos
Marco de reglas de negocio más BRFplus es un motor de reglas
desarrolladas en ABAP. Ofrece una completa interfaz de
programación de aplicaciones (API) y la interfaz de usuario
(UI) para la definición y tratamiento de reglas de negocio.
Permite que las normas que se inspira de una manera
intuitiva. Las reglas pueden ser reutilizados en diferentes
aplicaciones. BRFplus soporta características como la
simulación, la localización, transporte, exportación e
importación de XML. Las aplicaciones utilizan BRFplus en las
situaciones siguientes: de validación de datos y detección
de datos no válidos y los Estados Matching
responsabilidades, los productos adecuados, y los lugares
Cálculo de los costes, gastos generales, y los riesgos
Como técnico del motor de configuración BRFplus viene con un
componente basado en la interfaz de usuario basada en
WebDynpro ABAP que se adapte a los usuarios empresariales y
expertos en TI. Ofrece dos modos: el banco de trabajo y el
navegador de catálogo. El banco de trabajo permite a los
desarrolladores y expertos en reglas de negocio para mantener
las reglas. En la mesa de trabajo, se puede acceder a la
vista del repositorio en el que todos los objetos son
visibles y accesibles. La mesa de trabajo proporciona la
funcionalidad completa de BRFplus. En el modo de navegador de
catálogo, un usuario de negocios pueden navegar por el
contenido de un catálogo y mantener las reglas de negocio
asignado. Desarrolladores y expertos en reglas de negocio
define el contexto de los catálogos de un caso de negocio.
Las pieles catálogo navegador de la opinión de Depósito.

------------------------------klj---ñokñ------------------
Las relaciones de los tipos en el nivel indica que todos los super
tipso participarán een la relcion

La ambigüedad de ningún tipo. Por ejemplo, en el sistema de

programación de
ejemplo en la página anterior: cuando es el momento de
publicar un calendario con un
la oficina regional? ¿Quién hace esto? ¿Qué información tiene
a esta persona
(o el sistema) tienen el fin de completar esta actividad?
¿Cómo
el sistema de saber que se ha completado la actividad? ¿Qué
pasa si
la persona que intenta post no tiene un horario? Debe quedar
claro.
2. Estufa-hilo requisitos de información. Si los requisitos
se recogen y se informó
divisionally en lugar de cross-funcional, el analista se
puede determinar
conflicto entre departamentos (como en el ejemplo anterior).
3. Referenceability pobres en información. Suena simple, pero
a menudo, la información dentro de
los requisitos de los documentos es demasiado difícil de
encontrar que la documentación utilizable.

Escenarios empresariales
Escenarios de negocios son una técnica valiosa que puede ser
utilizado como insumo para la
el desarrollo de la arquitectura de negocio para ayudar a
identificar y comprender el funcionamiento de la
el negocio, y así obtener los requisitos del negocio y las
limitaciones que el
la arquitectura debe abordar. Escenarios de negocio se
utilizan para describir lo que debería ocurrir
cuando los eventos planificados y no planificados ocurren

Las reglas de negocios constituyen un concepto importante en el

proceso de
definición de los requisitos de los sistemas de información
computarizados, siendo
consideradas como “parte del corazón” de cualquier organización
[Gottesdiener’97]. Hasta
el momento han sido utilizadas mayormente en el área de Base de
Datos [Guide’96;
Diaz’97; Ross’97], existiendo pocos trabajos en el área de Ingeniaría de
Requisitos
[Rosca’97].
Durante el análisis, su objetivo es dar cuerpo a las reglas
de negocio identificadas durante la recogida de requisitos,
que a menudo se reorganiza las normas de alto nivel en las
colecciones de cohesión, las normas de uso único. Medida que
se desarrollan prototipos de interfaz de usuario, es posible
identificar a las reglas de negocio simple, mientras que las
pantallas de modelado del sistema y los informes. Por
ejemplo, una universidad puede tener una pantalla de
información del seminario que muestra el número de asientos
disponibles en el seminario, el número de personas inscritas
en el seminario y el número de personas en lista de espera
para el seminario. A medida que este modelo de pantalla, es
posible identificar a las reglas de negocio relacionadas con
el número mínimo de alumnos necesario para el seminario que
se celebrará, el número máximo de estudiantes que pueden ser
puestos en una lista de espera, y el número mínimo de
estudiantes en el lista de espera necesario antes de que el
seminario se dividió en dos secciones.

Durante el análisis, que también tienden a identificar a la

limpieza de datos y reglas de validación, especialmente si el
sistema necesita para integrarse con sistemas externos. La
integración de sistemas, ya una tarea compleja, es aún más
difícil si la integración se consigue mediante el intercambio
de datos (en oposición a la integración a través de una
interfaz bien definida de programación de aplicaciones). El
problema con el intercambio de datos-por lo general las
estrategias de transmisión de archivos compartidos o
almacenes de datos, es que a menudo han estado en uso durante
un largo tiempo, y los datos de los diseños se han degradado.
Es común ver diseños de los datos que necesitan tener los
valores de varias columnas se combinaron para obtener la
información requerida. Por ejemplo, consideremos los
siguientes datos limpieza regla: "Si el valor de la columna A
es 'AD', y el valor de la columna G 'T', entonces la columna
D representa la fecha en que el estudiante fue admitido por
primera vez a la universidad." También se determinarán las
reglas de validación de datos como "El valor de la columna D
debe ser una fecha y debe ser menor o igual a la fecha
almacenada en la columna H." Identificación y verificación de
este tipo de normas es una parte importante ya menudo difícil
de sus esfuerzos de análisis.

Las reglas de negocio también son pertinentes a su objeto las

actividades de diseño orientado. Como se muestra en la Figura
2, las reglas de negocio a menudo se define desencadenantes
en su diagramas UML Estado de gráfico. Diagramas de éxitos
del Estado son utilizados para modelar los ciclos de vida de
los objetos, que representan los distintos estados del objeto
puede ir a través, además de las transiciones posibles entre
los estados. Por ejemplo, el ciclo de vida de un objeto de
seminarios pueden incluir a los Estados como la propuesta,
abierta a la inscripción, participación plena, activa,
cancelados, cerrados a la inscripción y completado. También
podría haber transiciones entre estos estados, por ejemplo,
una transición puede ser que se convierte en un seminario
programado, moviéndolo desde el Estado se propuso al aire
libre-para-estado de inscripción. No sería potencialmente
varias reglas de negocio relacionadas con la programación de
un seminario, tal vez un seminario de las necesidades de una
ubicación y un instructor asignado antes de que se puede
añadir a la lista oficial universitaria.
• Mejores prácticas de ingeniería de software

Mejores prácticas
Declarativa: una regla de negocio es una declaración de la
verdad acerca de una organización. Se trata de un intento
de describir las operaciones de una organización, no un
intento de prescribir cómo una organización debe
funcionar.

Esta es la razón por las reglas de negocio se dice que son

descubiertos u observados, y no creado.
Atómica: Una regla o es totalmente cierto o totalmente
falso, no hay matices de gris.

Por ejemplo, una regla para una compañía aérea que los
Estados pueden actualizar a los pasajeros de primera ronda
de boletos de viaje si hay asientos disponibles y pagar el
aumento de la tarifa no implica que este acuerdo está
disponible para un solo tramo del viaje.
Distinto, independiente construcciones: Separar las cosas
que definen su negocio (las normas) de los procesos (es
decir, las estrategias y tácticas). No construir
dependencias complejas y cíclicas - simplificar y aplanar
lasconstrucciones.
Expresado en lenguaje natural: En el fin de atraer a la
audiencia más amplia, es casi siempre el mejor para
expresar las reglas de negocio en un lenguaje natural sin
el uso de un montón de jerga técnica.
Gráficos: Como alternativa, herramientas recientes
permiten una notación gráfica de reglas de negocio, en
lugar de o además de la notación del texto. Estas
notaciones basadas en semántica o modelo de evitar la
trampa de utilizar demasiado técnico o demasiadas largas
penas de texto que no se puede entender. Esto también
facilita la comprensión de la complejidad en, por ejemplo
interacción normas.
De negocios, no la tecnología, orientadas a: Por ejemplo,
las reglas de negocio de una empresa no debe ser ajeno a
un cliente bien informado.
De negocios, no la tecnología, la propiedad: Las reglas de
negocio provienen de las decisiones de negocios. Estos son
independientes de las decisiones de aplicación.

• Identificación de skateholders
• Definir sus necesidades
• Determinar el alcance del sistema
• Adquirir sus requerimientos del negocio
 • Adquirir requerimientos del usuarios
• Adquirir requerimientos del sistema
• Requerimientos wde e negocio Vs reglas de negocio vs requerimioentros del producto
• Identificación del dominio de las reglas de negocio
• Identificación de las reglas de negocio
• Búsqueda de reglas de negocio
• Redacción de las reglas de negocio
• Calidad en las reglas d negocio
• Almacen de la s reglas de negocio
• Manifiebnsto agfgil delas reglas de negocio

Manifiesto de Reglas de Negocio

Los Principios de la Independencia de las Reglas
The Business Rules Group1
1 Copyright, 2003. Business Rules Group. Version 2.0, November 1, 2003. Edited by
Ronald G. Ross. www.BusinessRulesGroup.org
La reproducción y la distribución de este documento se concede bajo las siguientes
condiciones: (a) Se debe incluir mención clara y visible del copyright y del permiso. (b) Se
debe
mencionar al Business Rules Group como la fuente del documento. (c) Se debe respetar la
integridad del documento reproducido, incluido el título, el contenido, el copyright, el
permiso,
sin ninguna modificación, abreviación, resumen, ni extensión.
Traducción a español versión 1.0, noviembre 2005, iniciada y coordinada por Antonio
Catala. (antonio.catala@theanonymousarchitect.com)
Artículo 1. Los requisitos como
elementos principales, nunca como
secundarios
1.1. Las reglas son un ciudadano de primera clase en
el mundo de los Requisitos.
1.2. Las reglas son esenciales para los modelos de
negocio y para los modelos de tecnología, y una
parte separada y especifica de los mismos.
Artículo 2. Independientes de los
procesos y no contenidas en ellos
2.1. Las reglas son restricciones explicitas de
comportamiento y/o proporcionan soporte para la
dirección de las actividades de negocio.
2.2. Las reglas no son procesos ni procedimientos. Y
por tanto no deben estar contenidas en ninguno de
ellos.
2.3. Las reglas se aplican a lo largo de los procesos y
procedimientos. Debe existir un corpus coherente de
reglas que se aplique sistemáticamente en todas las
áreas de actividad del negocio.
Artículo 3. Proporcionar conocimiento
meditado, no un sub-producto
3.1. Las reglas se construyen sobre hechos, y los
hechos sobre conceptos tal y como son expresados
mediante términos.
3.2. Los términos expresan conceptos de negocio; los
hechos realizan afirmaciones sobre estos conceptos;
las reglas restringen y apoyan estos hechos.
3.3. Las reglas deben ser explicitas. No se debe
asumir ninguna regla sobre ningún concepto o
hecho.
3.4. Las reglas son los fundamentos que definen lo
que el negocio sabe de si mismo- es decir son
conocimiento básico de negocio.
3.5. Las reglas necesitan ser alimentadas, protegidas
y gestionadas.
Artículo 4. Declarativas, no de
procedimiento
4.1. Las reglas deben expresarse de forma
declarativa en sentencias de lenguaje natural, por la
audiencia conocedora del negocio.
4.2. Si algo no puede ser expresado claramente,
entonces no es una Regla.
4.3. Una serie de enunciados solo es declarativa si no
contiene una secuencia implícita.
4.4. Cualquier enunciado de reglas que necesite de
otros elementos que no sean términos o hechos,
revelan hipótesis sobre la implementación de un
sistema.
4.5. Una regla es distinta del nivel de cumplimiento
definido para ella. La regla y su nivel de
cumplimiento son dos asuntos diferentes.
4.6. Las reglas deben definirse independientemente
de la quien tiene la responsabilidad de su
cumplimiento, y de donde, cuando o como se
refuerzan.
4.7. Las excepciones a las reglas se definen mediante
otras reglas.
Artículo 5. Expresiones bien formadas,
no expresiones creadas con fines
específicas para un caso
5.1. Las reglas de negocio se deben expresar de
manera que pueda ser validada su exactitud por el
personal conocedor del negocio.
5.2. Las reglas de negocio se deben expresar de
manera que se pueda verificar recíprocamente su
coherencia.
5.3. Las lógicas formales, como la lógica de
predicados, son fundamentales para la expresión
formal de reglas en términos de negocio, así como
para las tecnologías que implementan dichas reglas.
Artículo 6. Arquitectura basada en las
reglas, no una implementación
indirecta
6.1. Un sistema basado en reglas de negocio se
construye intencionadamente para permitir el
cambio continuo de las reglas de negocio. La
plataforma sobre la que el sistema se ejecuta debe
soportar esta evolución.
6.2. Es mejor ejecutar las reglas directamente – por
ejemplo utilizando un motor de reglas – antes que
transcribirlas en alguna forma embebida dentro de
un procedimiento.
6.3. Un sistema de reglas de negocio siempre debe
ser capaz de explicar el razonamiento por el cual
llega a una conclusión o emprende una acción.
6.4. Las reglas se basan en los valores ciertos. La
forma en la que certeza de una regla se determina,
se mantiene oculta a quienes la utilizan.
6.5. La relación entre eventos y reglas es
generalmente de muchos-a-muchos.
Artículo 7. Procesos guiados por reglas,
no programación basada en
excepciones
7.1. Las reglas definen el límite entre actividad de
negocio aceptable y no aceptable.
7.2. Las Reglas requieren a menudo de una gestión
especial o especifica de las violaciones detectadas.
Cualquier actividad derivada de la violación de una
regla es una actividad como cualquier otra.
7.3. Para asegurar la máxima consistencia y
reutilización, el tratamiento de las actividades de
negocio no aceptables, debe separarse de la gestión
de actividades de negocio aceptables.
Artículo 8. Al servicio del negocio, no al
de la tecnología
8.1. Las Reglas tratan sobre las prácticas de la gestión
y gobierno del negocio, por lo tanto son motivadas
por las metas y los objetivos de negocio y se les da
forma a través de varios factores internos y externos
a la empresa.
8.2. Las reglas suponen siempre un coste a la
empresa.
8.3. Este coste de la aplicación de las reglas debe
valorarse y balancearse, teniendo en cuenta los
riesgos asumidos por el negocio, y las oportunidades
perdidas en caso de no aplicarlas.
8.4. “Más reglas” no es mejor, la abundancia de
reglas no beneficia a su aplicación. Normalmente es
mejor un número limitado de reglas bien
reflexionadas.
8.5. Un sistema eficaz puede estar basado en un
pequeño número de reglas. Adicionalmente, se
pueden añadir reglas más discriminatorias, por las
que ha medida que pasa el tiempo el sistema mejore
y se hace más inteligente.
Artículo 9. “De, por y para” el personal
de negocio. No “de, por y para” el
personal de IT.
9.1. Las reglas deben provenir del personal con
conocimiento de negocio.
9.2. Los expertos de negocio debe tener disponibles
herramientas que les ayuden a formular, validar y
gestionar reglas.
9.3. Los expertos de negocio deben tener disponibles
herramientas que les ayuden a verificar la
coherencia reciproca entre las reglas de negocio.
Artículo 10. Gestionando la lógica de
negocio, no las plataformas de
Hardware/Software
10.1. Las reglas de negocio son un patrimonio vital
del negocio.
10.2. A largo plazo, las reglas son más importantes
para el negocio que las plataformas
Hardware/Software.
10.3. Las reglas de negocio deben organizarse y
salvaguardarse de forma que puedan ser redesplegadas
a nuevas plataformas de
Hardware/Software.
10.4. Las reglas, y la habilidad para cambiarlas de
forma eficaz, son factores clave para mejorar la
adaptabilidad de las empresas.

4.
INTRODUCCION

En un estudiio de Standish Grouop de 1997 al 200o

Las relgs de negocio pera no analistas

QUE es una regls de negofio

Las reglas de negocio son un medio para un fin - los extremos
son las decisiones de la empresa debe hacer. ¿Quieres que
esas decisiones son fiables, trazable y auditable. Para
lograr esto, es necesario crear servicios de decisión que son
altamente reutilizables, manejable y flexible

las reglas de la mayoría de los negocios están encerrados en

los sistemas antiguos, manuales de usuario o en las cabezas
de algunos trabajadores clave

Regla de negocio es una declaración que define o restringe

algún aspecto del negocio. Su objetivo es hacer valer la
estructura de negocios o para controlar o influir en el
comportamiento de la empresa.

si tienen o no alguna vez por escrito, hablado acerca de

parte o incluso de la conciencia de la organización. Sin
embargo, es una práctica bastante común para las
organizaciones que reúnen las reglas de negocio en al menos
de una manera muy informal
las reglas de negocio ocultar vínculos en los vínculos
definitionShow dentro de la definición Definición 1
Reingeniería: Generalmente supuestos no escritas y establecer
formas de trabajo que se hacen evidentes cuando se analizan
los procesos de negocio y documentado. Las reglas de negocio
(por ejemplo, cuando para aceptar o negar el crédito, cuándo
y cómo contratar o despedir empleados, cuando el inventario
reponer) el resultado de la forma de una empresa percibe y
utiliza la información. Estas normas, a su vez determinar
cómo las funciones de la empresa y lleva a cabo sus negocios.

Definición 2
Datos: Declaración que impone una restricción en la
selección, las relaciones, y la estructura de los elementos
de datos en una base de datos.

Definición 3
Temas relacionados: BR - Definiciones

La visión de proceso
Haley tiene una interesante sobre la definición de reglas de
negocio.

Regla de negocios: es una declaración que define o restringe

algún aspecto del negocio. Una regla de negocios afirma la
estructura empresarial para controlar o influir en el
comportamiento de la empresa, es decir, un proceso o
procedimiento.

Reglas de Negocio de Control de Procesos de

Tenga en cuenta que la definición de los procedimientos de

trata como una expresión legítima de conocimiento acerca de
un proceso de negocio de algún tipo. En el ámbito de Business
Process Modeling, la secuencia de las operaciones en los
procesos de negocio puede convertirse en algo así como una
regla de negocio en sí mismo.

Se trata de una distinción de importación y la visión

correcta, un proceso basado en reglas o basada en el punto de
vista, depende en gran medida de la categoría y el nivel de
interacción de las reglas de negocio en cuestión.
"Localizados" Reglas de Negocio

Las reglas de negocio tienden a aparecer a nivel de empresa.

Procesos tienden a utilizar reglas de negocio en una "forma
localizada, por ejemplo, la ubicación geográfica o por
segmento de mercado. Un determinado conjunto de reglas de
negocio pueden desempeñar un papel en algún aspecto o
'aspecto' de un proceso de negocio en particular. Incluso
podrían ser clasificados en varias dimensiones
simultáneamente, por ejemplo, la ubicación geográfica y por
segmento de mercado al mismo tiempo.

Las demandas de las grandes aplicaciones de negocio

globalizado, pueden generar un número masivo de "localizado"
las normas por la explosión combinatoria de "sub-tipos, a
veces de muchos miles de las distintas categorías de reglas
de negocio. En esas situaciones, de abajo hacia arriba, el
proceso de enfoque basado en el análisis de las reglas de
negocio pueden ser muy eficaces.

Enfoque de abajo arriba para Reglas de Negocio

Definido de oracle

Una regla de negocio es o bien

una restricción que se aplica al estado

del sistema, el cambio del estado del
sistema o el uso autorizado del
sistema,
o de una acción automática que se
desencadena por un cambio en el sistema
estatal

Mi preferido ADF BC 11g técnicas de

Reglas de Negocio
En Oracle JDeveloper 11g, alimentador
automático de BC ofrece varias
características nuevas para el apoyo
declarativo de reglas de validación
(véase también el JDeveloper 11g lista
de nuevas características):
De control cuando una regla de
validación se ejecuta mediante la
especificación de una expresión de la
ejecución condicional o desencadenantes
atributos (o mediante el aplazamiento
de la ejecución a nivel de transacción)

Crear mensajes de error y advertencias

parámetros guardados en paquetes de
recursos externos
Nuevos tipos de reglas de validación
(en el siguiente se enumeran son el
tag)
Permítaseme describir las técnicas BC
alimentador automático de documentos
(con enlaces a las secciones
pertinentes de la Guía del
desarrollador de Fusion para
alimentador automático de documentos o
de los párrafos más abajo) que me
refiero más adelante en este post, por
orden de preferencia. De hecho, tengo
dos listas de las técnicas de
preferencia, dependiendo de la
pregunta: Si la regla se aplicará en
más de una entidad?

Preferente para las Normas Técnicas que

se aplican a varias entidades
Si la respuesta es Sí, la norma debe
ser aplicado en más de una entidad,
entonces mis técnicas preferidas son:

De dominio, consulte la sección 34.1

Creación de, datos validados de tipos
utilizando dominios.
Custom Validator, también conocido como
Regla de registro, donde el código de
un nuevo tipo de validador en Java, que
luego puede asignar de forma
declarativa a una entidad (o atributo
de la entidad). Vea Cómo crear un
validador personalizado.
Imperiosas método de la superclase de
la clase java EntityImpl a nivel de
clase de base (véase la sección 33.2
Creación de una capa de Extensiones de
Marco, que usted debe hacer antes de
crear los objetos individuales de la
entidad), con clases separadas e
interfaces para la lógica de negocio
real (ver Cómo aplicar los principios
de OO en EntityImpl).
Preferente para las Normas Técnicas que
se aplican a las entidades individuales

Si la respuesta es No, la norma debe

ser aplicado en una sola entidad,
entonces mis técnicas preferidas son:

Entidad, atributo, o la Asociación de

la Propiedad, por ejemplo, la propiedad
obligatoria de un atributo o
característica de la Historia de la
columna para el seguimiento de la
creación / info última actualización.
Usted puede incluso crear su propio
tipo de historia.
Declarativa regla de validación que no
requiere ningún Groovy o codificación
de Java (para más información véase la
sección 7.3, añadir reglas de
validación para objetos de entidad y
atributos). Si es necesario aplazar la
convocatoria de la regla de dedicar
tiempo, establecer "Aplazar la
ejecución a nivel de transacción" al
añadir la regla a una entidad o un
atributo.
Collection (valida sobre la base de los
valores agregados en una colección)
Comparar (realiza una comparación
lógica entre el atributo y un valor)
Existe número (control de caché y la
base de datos para ver si existe como
un valor clave en una determinada
entidad, útil para la lógica claves
foráneas que no se verifican en la base
de datos)
Longitud (compara el carácter o la
longitud de byte de un valor de
atributo con el tamaño especificado)
Lista (compara un atributo con una
lista de valores que se pueden
especificar de varias maneras)
Range (las pruebas de valores de los
atributos mínimos especificados en los
valores máximos y)
Regular Expression (compara un valor de
atributo en contra de una máscara de
expresión)
UniqueKey (negocio equivalente capa de
lógica de una restricción única en la
base de datos)
Expresión de secuencias de comandos
(regla de validación declarativa
utiliza para la creación de expresiones
de validación Groovy). Aplicable si la
sintaxis de Groovy y construcciones,
véase la sección 3.6 Panorámica del
apoyo de Groovy, son lo suficientemente
poderosas para aplicar la norma, y la
expresión es limitado en longitud.
(Método de validación declarativa regla
utilizada para llamar a cualquier
método definido por el objeto de la
entidad que acepta un parámetro del
tipo adecuado y devuelve un valor
booleano, véase la Sección 8.2
Validación y aplicación de reglas de
negocio mediante programación). Si el
método de esta norma es más que unas
pocas líneas de código Java, prefiero
aplicar la regla como un validador
personalizado, por lo que se puede
implementar en una clase aparte con
varios métodos.
Custom Validator, también conocido como
Regla de registro, donde el código de
un nuevo tipo de validador en Java, que
luego puede asignar de forma
declarativa a una entidad (o atributo
de la entidad). Vea Cómo crear un
validador personalizado.
Imperiosas método de la superclase de
la clase java EntityImpl, en el plano
de un objeto entidad individual (ver
sección 8.2 Validación y aplicación de
reglas de negocio mediante
programación), con clases separadas e
interfaces para la lógica de negocio
real (véase cómo aplicar los principios
OO en EntityImpl).
Ahora bien, estas listas deben una
pequeña explicación. ¿Por qué prefieren
estas, y cuando se puede o no puede
utilizar una de estas técnicas?

¿Por qué estas técnicas?

Mis preferencias por ciertas técnicas
se basan en los siguientes supuestos:

Basado en XML es preferible a la basada

en código (ya sea Groovy o código de
Java). Hay varias razones para esto:
Uno de los beneficios de utilizar la
validación declarativa (frente a
escribir su propia validación) es que
el marco de validación se encarga de la
complejidad de la dosificación
excepciones de validación, que le
libera para concentrarse en específico
de la aplicación lógica de la regla de
validación. (Presupuesto de la Sección
7.1 Introducción a la validación
declarativa.)
Otro beneficio de la validación
declarativa, es la trazabilidad de las
normas. Es más fácil ver qué normas se
aplican en una entidad determinada.
Sólo tiene que abrir una definición de
la entidad, vaya a las validaciones, y
ver que las reglas declarativas se
enumeran. Incluso si no todas las
reglas pueden ser citados, es un buen
punto de partida.
En una versión posterior de JDeveloper
11g, cuando MDS (Meta Data Services) es
totalmente habilitado, será posible
personalizar estas basado en XML reglas
de negocio sin tener que cambiar los
archivos de origen (véase el capítulo
33 de la Guía del desarrollador de un
proyecto JDeveloper 11g versión
preliminar).
El recientemente comenzado ADF
Metodología Grupo examinó el término
"Java por excepción" (ver Reutilización
Extreme, una metodología de desarrollo
propuesta por ADF Avrom Roy-Faderman).
Las solicitudes se supone que son
totalmente declarativo, con excepción
de los pocos casos en los usos del
marco declarativo de no cubren la
funcionalidad necesaria. La idea es que
se puede aprovechar el poder de Java
cuando lo necesite, y evitar la
complejidad en otras épocas. En el
simposio de la Metodología de ADF,
Steve Muench, muy apropiadamente,
señaló que el alimentador automático de
documentos, así, es un "Java por
excepción" marco.
Generalizar, empuje hacia arriba, y
personalizar: Extreme Avrom de
Reutilización describe esta práctica:
En vez de escribir una pieza de código
Java a medida a una necesidad muy
particular, consideran la posibilidad
de generalizar el código y lo empuja
hasta la jerarquía de clases a una
clase de marco personalizado ,
permitiendo la personalización
declarativa de casos específicos.
Estoy de acuerdo con esta práctica: si
espera que la funcionalidad del código
de Java es probablemente va a ser
necesario en otro lugar y, posiblemente
con una pequeña variación,
generalizarlo. Este principio también
implica que incluso si se puede aplicar
una regla con un validador declarativo,
sino que hay que hacer en más de una
entidad, entonces se debería crear una
aplicación generalizada de modo a
evitar entrar en repetidas ocasiones
las mismas propiedades como el código
de mensaje de error, subtipo validador,
etc trabajo repetitivo aumenta la
probabilidad de errores, y el resultado
es difícil de mantener.
Utilice los principios de diseño
orientado a objetos cuando la lógica de
codificación de reglas de negocio en
Java (yo se las del primer capítulo del
excelente libro Jefe First Design
Patterns): encapsular lo que varía,
traducido a poner la lógica de reglas
de negocio en una clase separada -
consulte Cómo aplicar los principios de
OO en EntityImpl
Programa de interfaces, no
implementaciones, traducido a: dejar
que la clase de regla implementar una
interfaz que usted llama de la
EntityImpl - ver cómo aplicar los
principios OO en EntityImpl
Esto evita gran EntityImpl clases, en
la que es difícil seguir la pista de lo
que se generó por ADF BC y lo que se
agregó por usted. Si usted sigue estos
principios, hay sólo unos pocos métodos
de la superclase que puedan ser
personalizados (ver sección 8.1
Introducción a las Normas programáticas
de Negocios).

Cuándo usar qué técnica?

Las técnicas preferidas mencionadas
puede o no ser posible, dependiendo del
tipo de reglas de negocio que necesita
para poner en práctica. Además de la
decisión de si la norma debe aplicarse
por más de una entidad o no, lo que
importa, así es la complejidad de la
norma, y en qué momento del ciclo de
validación de objetos de la Entidad ADF
necesita ser activado.

Disparo momento
Lo que hay que recordar es que todas
las técnicas, a excepción de la
codificación directa en la clase
EntityImpl, sólo puede ser llamado en
el momento en una fila única Entidad
está validado, o en el momento en todas
las filas de la entidad se han
comprometido (este último se produce si
aplazar la ejecución a nivel de
transacción, utilizando una
configuración en la Entidad "Agregar
regla de validación" de diálogo). Ese
es el equivalente de menoscabar la
entidad superclase métodos
validateEntity o beforeCommit.

Sin embargo, a veces se necesita para

activar la regla de los métodos de
doDML superclase, quitar, o algún otro
método. El sistema de clasificación del
artículo de las reglas de negocio en el
alimentador automático de papel blanco
antes de Cristo puede ayudar: para los
tipos de norma de "Borrar",
"Recopilación, ninguno de los padres",
"Colección de los padres", "con el
evento Change LMD", y "evento de cambio
sin LMD ", puede que no sea posible
disparar ellos en validar o dedicar
tiempo.

La complejidad de la norma
Además, no las reglas de validación se
han apropiado de las normas de evento
de cambio (que conlleva una
modificación de los datos en algún otro
atributo o entidad). Puede interferir
con el ciclo de validación (ver sección
7.2 Entender el ciclo de validación).

La complejidad de la norma determina si

es posible llevar a cabo utilizando una
de las técnicas más preferido, como una
Comparar validador o un validador de
Rango. Si eso no es posible, podría ser
posible poner en práctica utilizando un
validador Groovy Script. Si eso no es
posible, podría ser posible aplicarla
con un validador método con un pequeño
número de líneas de código Java en el
método, etcétera.

Algoritmo para determinar la mejor

regla Técnica
Si se aplican todas estas directrices,
usted tiene el algoritmo de resumen
siguiente para determinar la mejor
técnica de la regla:
¿Cómo crear un validador personalizado
Consulte la Guía del desarrollador de
Fusion for Oracle Application
Development Framework Sección 34.10:
Implementar reglas de validación.
Esencialmente, se crea una nueva clase
de Java que se extiende
AbstractValidator y aplica la
JboValidatorInterface. Esto obliga a
aplicar un método de validación
(JboValidatorContext). Puede
especificar las propiedades de reglas
personalizadas para las cosas que
pueden variar si es necesario aplicar
esta regla para más de una entidad o un
atributo.

Si la regla debe ser estimulado por

dedicar tiempo a diferencia de validar
el tiempo, también se debe aplicar la
JboTransValidatorInterface. Esto obliga
a aplicar un método validateMany además
de validar, pero en nuestro caso de
prueba que nunca fue llamado, incluso
si se establece la "ejecución Retrasar
a nivel de transacción" al asignar el
Estado a una entidad o un atributo. Sin
embargo, una aplicación lógica de este
método sería para recorrer todos los
JboValidatorContexts y llamar a validar
para cada uno:

validateMany public void

(ArrayList valCtxs) (
JboValidatorContext evObj;
for (int i = 0; i
<valCtxs.size (); i + +)
(
= evObj
(JboValidatorContext) valCtxs.get (i);
validar (evObj);
)
) Cuando haya escrito la clase
Java, debe registrarse como una norma
en el proyecto de modelo y, a
continuación de forma declarativa puede
asignar a una o más entidades, y podría
establecerse alguna entidad de las
propiedades específicas de la regla.
Estas propiedades pueden ser expuestos,
simplemente mediante la creación de
métodos get y set para ellos en la
clase Java.

Nota: si la regla debe aplicarse a

todos los objetos de entidad, sin
propiedades específicas para configurar
para cada entidad individual, entonces
es más fácil utilizar la técnica de
sobreescritura de un método en
EntityImpl, por lo que no tiene que
hacer cualquier trabajo en las
entidades individuales.

Nota 2: También puede utilizar el

JboValidatorInterface cuando el tiempo
de activación no se validateEntity o
cometer, pero requiere de una instancia
de un JboValidatorContext de esta
manera:

BusinessRule
JboValidatorInterface =
MyCustomValidator nuevo ();
EntityContext
JboValidatorContext =
JboValidatorContext nuevo
(JboValidatorContext.TYP_ENTITY_OBJECT,

esto, getEntityDef (). getFullName (),

null,

null, this);
businessRule.validate
(EntityContext); me parece que esto sea
menos intuitiva entonces la técnica se
describe a continuación, y usted no
tiene el valor añadido que las reglas
declarativas tienen como la
trazabilidad, la agrupación
excepciones, y permite realizar cambios
a través de MDS. Además, este código da
una advertencia del compilador, y no me
queda claro cuál es la alternativa para
el constructor es obsoleto:

constructor JboValidatorContext
(int, java.lang.Object,
java.lang.String,
oracle.jbo.AttributeDef,
java.lang.Object, java.lang.Object) ha
sido deprecatedIt funciona bien,
aunque, así que si te gusta puedes
utilizar este enfoque en lugar de la
descrita en cómo aplicar los principios
OO en EntityImpl.

Gracias Steve Muench y Jan Kettenis por

haberme ayudado a la posición de esta
técnica en 11g.

Cómo aplicar los principios OO en

EntityImpl
Este apartado explica cómo aplicar los
principios de diseño orientado a
objetos "encapsular lo que varía" y
"Programa de interfaces, no
implementaciones", con la ayuda de mi
colega, Gaurav Malhotra. He descubierto
que ayuda a separar el código de
implementación de la regla de las
clases de componentes de negocio, y
aclara la comunicación entre las clases
por medio de interfaces para diferentes
tipos de reglas, si desea utilizar la
técnica de sobreescritura de un método
en EntityImpl. De hecho, la técnica de
Custom Validator (ver Cómo crear un
validador personalizado) también aplica
estos principios OO.

Nota: si la regla se aplica a varias

entidades, pero no exactamente el mismo
para cada entidad, se puede utilizar
propiedades personalizadas en las
entidades individuales para configurar
la regla de negocio.

Tome el código de la regla de la clase

EntityImpl
Una de las reglas más complejas que
había en un gran proyecto que
participan de una clase de ayuda
privado, varias constantes static
final, y varios métodos de ayuda que
necesitan ser llamado varias veces. Así
que usted puede imaginar que no es una
buena idea poner todo ese código en la
clase EntityImpl, mezclado con el
código de normas y / o el marco ADF BC
código generado.

Tomando prestada una frase de la

descripción de Antonio García del
patrón Estrategia, es mucho más
sencillo para hacer un seguimiento de
ellos si cada comportamiento (en
nuestro caso de reglas de negocio) es
una clase aparte, y no enterrados en el
cuerpo de algún método. Así es como
interpreta el principio de "encapsular
lo que varía".

Inyectar la fila de la entidad

Ahora, en la lógica de reglas de
negocio, probablemente tendremos que
llamar a varios métodos EntityImpl de
la fila que desencadenó la regla, como
captadores de la entidad, o el método
de la superclase getAttribute
genéricos. ¿Cómo se puede hacer eso si
la lógica de la regla se encuentra en
una clase separada?

La respuesta es: inyectar la fila de la

entidad en la clase de regla,
utilizando un método setEntity. La
clase de regla se puede llamar a los
métodos de codificación de la entidad
por getEntity (). AlgunMetodo (). De
esta manera usted también puede
recuperar los valores de propiedades
personalizadas de las entidades en caso
de las normas genéricas que se aplican
a varias entidades: getEntity ().
GetEntityDef (). GetProperty
(customPropertyName).

Definición de contrato con persona que

llama mediante una interfaz de
A continuación, aplique el "Programa de
Interfaces" principio mediante la
especificación de una interfaz que
define los métodos de la clase regla
debería ser exigible de la clase
EntityImpl y cuáles no. Si usted tiene
varias reglas que deben aplicarse en el
EntityImpl, probablemente pueda volver
a utilizar la misma interfaz de varias
reglas.

Un ejemplo de dicha interfaz es la

interfaz general EntityRule fin (nótese
el uso de un método de 5 Java
genérico):

public interface EntityRule <T> (

public void setEntity (entidad T);

proceso public void ();

) Una implementación de esta interfaz
puede ser:

public class MyComplexRuleImpl

implementa EntityRule <MyEntityImpl>
Usted llama a la regla por la
codificación en el método apropiado de
su clase MyEntityImpl:

MyComplexRule EntityRule =
MyComplexRuleImpl nuevo ();
myComplexRule.setEntity (this);
myComplexRule.process (); Por
supuesto, usted puede tener varias
clases de RuleImpl cada una
representando una norma diferente de la
entidad, que puede ser llamado desde
diferentes lugares de la EntityImpl.

Beneficios de esta técnica de

Con este enfoque puede dar las
complejas reglas de su propia clase,
mientras que todavía permite las
llamadas a los métodos de marco de
referencia como captadores de la
Entidad. En la clase de regla se puede
lanzar una excepción si la validación
falla. El uso de una interfaz hace que
sea claro cómo llamar a esa norma, sin
conocer el funcionamiento interno de la
norma.

> cambiar

Proponer una traducción mejor

Para que sirven

Par ir de abajo hacia arriba en Calidad y modelado de los proceos estrategicos.

Ofrecene una ventaja competitiva
Para la elaboración del modelado de datos y le diseño de las bases de datos
Para hacer frente a los cambiaos en las regulaciones internas o externas
Garantizar la capacidad de la auditoria.
Se utilizan para preservar la integridad de los datos
Para evitar la incongruencia en los datos
El control de corrección de los datos
Como Disparadores
Para validar datos , formulas flujo de eventos de procesos

“Para la implementación de políticas de negocios, leyes y

regulaciones, directrices y buenas prácticas, definiciones y axiomas,
traducciones de esquemas de bases de datos, dependencias de flujos
de trabajo y restricciones técnicas,

Por que
El problema con la incrustación de las normas en los
programas de aplicación es el siguiente. Como y cuando estos
cambios de reglas de negocio, a continuación, cambiar los
programas de aplicación es largo y costoso. Una solución a
este problema es expresar las reglas de negocio mediante
declaración - no sólo en la modelización de la empresa, sino
también en el sistema de información computarizado.

Cuando

Donde

Como

Reglas de Negocio La metodología es el proceso de captura de

las reglas de negocio en el lenguaje natural, en tiempo real,
mientras que faculta a los usuarios a administrar las reglas
con unos sencillos pasos.

Recopilación de reglas de negocio también se llama normas de

explotación o extracción de reglas de negocio. El analista de
negocios o consultor puede extraer las reglas de casos de
uso, código de sistema o mediante la organización de talleres
de las PYME / entrevistas, etc tecnologías de software
diseñada para capturar las reglas de negocio mediante el
análisis de código fuente o el legado del comportamiento del
usuario real, puede acelerar el proceso de recolección de
regla.

Divisionm

Definiciones de términos de negocios

El elemento más básico de una regla de negocio es el lenguaje
utilizado para expresarlo. La misma definición de un término
es en sí mismo una regla de negocio que describe cómo la
gente pensar y hablar sobre las cosas. Así, la definición de
un término es establecer una categoría de reglas de negocio.
Condiciones tradicionalmente han sido documentados en un
glosario o en las entidades de un modelo conceptual.

Hechos relativos a términos mutuamente

La naturaleza o la estructura de funcionamiento de una
organización puede ser descrito en términos de los hechos que
se relacionan los términos entre sí. Para decir que un
cliente puede realizar un pedido es una regla de negocio. Los
hechos pueden ser documentados como frases en lenguaje
natural o como las relaciones, atributos, y las estructuras
de generalización en un modelo gráfico.

Restricciones (también llamados "las afirmaciones de la

acción")
Cada empresa limita la conducta de algún modo, y esto está
estrechamente relacionado con las limitaciones en los datos
que pueden o no estar actualizados. Para evitar que un
registro de que se hizo es, en muchos casos, para evitar que
una acción tenga lugar.

Derivaciones
Las reglas de negocio (incluyendo las leyes de la naturaleza)
define como el conocimiento de una forma puede ser
transformada en conocimiento de otros, posiblemente en una
forma diferente
TEMPLATE +}

Detailed business rule.

Name: Tenured professors may administer student grades

Identifier: BR123
Description: Only tenured professors are granted the ability to initially
input, modify, and delete grades students receive in the
seminars that they and they only instruct. They may do so
only during the period a seminar is active.
Example: Dr. Bruce, instructor of “Biology 301 Advanced Uses of
Gamma Radiation,” may administer the marks of all
students enrolled in that seminar, but not those enrolled in
“Biology 302 Effects of Radiation on Arachnids,” which
is taught by Dr. Peters.
Source: University Policies and Procedures

Doc ID: U1701

Publication date: August 14, 2000

Related rules: BR12 Qualifying For Tenure

BR65 Active Period for Seminars

BR200 Modifying Final Student Grades

Instructions:
1. Use the following template for each business rule.
2. Capture all business rules in a single doc file.

1.5Business Rule Name

Identifier: BR##

Description:
Detailed description of the rule. Typically written in structured English or pseudo code.
Consider using a flowchart or UML activity diagram to depict procedural logic.

Example:
Optional section. Sometimes a business rule is easier to understand when one or more
examples are provided.

Related Rules:
Optional section.
List other business rules related to this one. Word Tip: If you mark each business rule with
a heading type (e.g. Heading 1, Heading 2, …) you can then add an automatic link to the
rule by inserting a cross-reference (Insert menu, Cross-reference item, then insert a
heading). E.g.. Instructions:.

Reference(s):
Applicable references, such as explanatory documents (printed or electronic), pertinent to
this business rule.

Notes:
Any applicable notes, issues, …
Assumptions:
1. Assumption… (indicate "None" if none)

Notes:
Optional section.
1. List an "to dos", concerns to be addressed, …
2. List any important decisions made during the development of this business rule.

Proceso de Negocios
Generar Compras
Actividad del Proceso de negocio de generar Compras
Aplicar el modelo Just in time
Evento de negocios
Calendarizar Compras ->
Tarea
Realizar Compra
EJUEMPLO 1:

Healthcare

--------------------------------------------------
------------------------------

Compañía
Compañía de Seguros de Salud

Desafío
Mejorar la gestión de la tesorería y la autonomía de los
usuarios de negocio para impulsar las iniciativas de cambio

Solución
Adoptar RuleXpress y una metodología de reglas de negocio
en toda la empresa

Resultados
Reducción del 80% en tiempo de cambio de ciclo y la gestión
eficaz de las normas de aplicación a través de tecnologías
múltiples

--------------------------------------------------
------------------------------

Este cliente, que desea permanecer en el anonimato, es un no

- salud de la compañía de seguros sin fines de lucro que ha
estado proporcionando cobertura de salud locales y nacionales
de más de 50 años. Ofrecen productos médicos, de farmacia, la
mejora de la salud y los servicios financieros a una
población de varios millones de miembros.

La información de este estudio de caso se basa en entrevistas

a clientes realizadas por James Taylor.

© Soluciones de Gestión de la Decisión

Desafío

La empresa necesitaba mejorar su proceso de gestión de

efectivo a través de una mejor administración de los créditos
calendario de pagos. Tienen que permitir que el Departamento
del Tesoro y de Operaciones de Reclamaciones para responder
rápidamente a los cambios en sus entornos de negocios, al
tiempo que garantiza el cumplimiento. Un complejo conjunto de
mandatos federales y estatales y los acuerdos de los
distintos clientes se refieren a solicitudes de pago. El
antiguo sistema significa que la empresa estaba aplicando una
norma única y rígida a todos los pagos de las reclamaciones.
Este sistema de computadora central era inflexible y difícil
de cambiar. No fue posible, por ejemplo, para definir normas
específicas para los segmentos de clientes o líneas de
productos. Por último, todas y todos los cambios necesarios
recursos de TI y la disponibilidad de esos recursos era una
grave limitación en relación con la empresa para responder
rápidamente.

Además, la empresa tenía un historial de conducción de

iniciativas dentro de la organización de TI en lugar de desde
dentro de las unidades de negocio que necesitan los cambios.
Querían establecer un enfoque para proyectos de desarrollo
que permitió a la gente de negocios a la captura de las
normas y los procesos y definir mejor las necesidades. La
gente de negocios podría entonces sus propias definiciones y
tomar el control de sus sistemas. Los intentos anteriores de
utilizar hojas de cálculo e incluso aplicaciones de bases de
datos personalizadas para capturar las normas no habían
logrado alcanzar el tipo de gestión que requerían.

Solución

La solución se basa en RuleXpress y las normas de Pegasystems

impulsada suite BPM. Tiene dos distintos mandatos
legislativos y los acuerdos personalizados con muchos grandes
clientes. La perspectiva de negocio es capturada a través de
modelos de procesos ya través de reglas de negocio
especificado en RuleXpress. Estas normas se alimentan
directamente a las empresas y los requisitos del sistema.
Este punto de vista comercial también es compatible con una
metodología de gestión del cambio y RuleXpress proporciona
una central, proveedor neutral para el repositorio de reglas
de negocio.

Normas de Gestión se encuentra dentro de la Empresa Business

Services Architecture - un grupo que los informes que el
gerente de Operaciones e indirectamente a la CIO. Este grupo
está constituido legalmente para conducir la ejecución del
negocio a través del diseño de calidad basados en soluciones
de negocio que permiten a las estrategias empresariales y
optimizar los productos y la prestación de servicios. Dentro
de este grupo es una empresa en toda la Oficina de Gestión de
Reglas o RMO. Este grupo gestiona la ejecución RuleXpress y
proporciona capacitación, mejores prácticas y apoyo a los
delegados del artículo en toda la compañía. La mitad de los
comisarios son la regla en este grupo y se centran en el
apoyo a la captura de las normas y los términos en múltiples
proyectos al tiempo que garantiza que puedan ser reutilizados
en toda la empresa. Los comisarios de Regla restantes son
expertos en negocios Materias que forman parte de la
organización empresarial. Esta estructura está apoyando
proyectos de 25-30 de muy grandes a muy pequeñas, algunas con
y otras sin normas de aplicación del sistema de gestión.

El proyecto de efectivo Claims Management tomó

aproximadamente cuatro meses a partir de principio a fin. Una
vez en marcha cambios regulares se esperaba y apoyo. Para el
proyecto de caja de Reclamaciones de gestión una RMO artículo
Analista y uno independiente artículo Steward fueron los
responsables de la captura y gestión de las normas en
RuleXpress. Algunas de las reglas comerciales son propiedad
de Operaciones de Reclamaciones y otras por el Departamento
del Tesoro. Las normas han sido la transición a dos
mayordomos artículo independiente dentro de estas áreas
funcionales de la gestión en curso.

El uso de RuleXpress como un repositorio de nivel empresarial

permite que los cambios a especificar por el negocio en un
entorno técnico. Los miembros del comité de gobierno,
importante en una industria muy regulada como la sanidad,
provienen de diferentes áreas de la empresa. Todos son
capaces de revisar los cambios RuleXpress y aprobarlos. Una
vez aprobados, los cambios se transmiten a los analistas de
integración empresarial para realizar cambios en la
aplicación en la aplicación motor de reglas. Gracias a la
capacidad de RuleXpress a contener enlaces a detalles de
implementación, análisis de impacto en profundidad puede
llevar a cabo.

Como parte de la adopción de un enfoque de reglas de negocio

y un sistema de gestión de reglas de negocio, la empresa
trabajó con soluciones de reglas de negocio y ha adoptado las
reglas de negocio de Proteus metodología. RuleXpress fue un
ajuste perfecto para este enfoque y se adoptó para gestionar
la especificación de las normas. RuleXpress está siendo
utilizado a nivel de empresa para todos basado en normas
soluciones. Como la empresa tiene tres motores de negocio,
diferentes normas en la casa, así como muchas de las normas
aplicadas en el código, RuleXpress proporciona el único
depósito que es la aplicación independiente y específica para
el negocio a nivel empresarial.
RuleXpress ofrece:

· Fácil y eficaz gestión de los Términos de

RuleXpress proporciona gestión de término completo, el apoyo

a la definición plazo, los vínculos de información y los
servicios de navegación. Los usuarios de negocio pueden ver
definiciones de términos de las normas, navegar, realizar
análisis de impacto y determinar la trazabilidad. Aspecto
integrado-up para los términos y la identificación automática
de los términos definidos hacen que sea fácil de utilizar los
términos en las normas. Y RuleXpress gestiona términos
preferidos y los sinónimos y genera un completo glosario de
términos para uso en toda la empresa.

· Facilidad de uso para gente de negocios

Intuitivo y fácil de usar, RuleXpress no tiene una interfaz

técnica que permite a los usuarios no técnicos crear y
administrar las reglas de negocio y los términos. Los
usuarios ponerse al día rápidamente y les resulta fácil de
usar día a día. RuleXpress evita cualquier uso de pseudo-
código o lenguaje técnico, y soporta la escritura en las
lenguas locales.

· Regla y término de calidad

RuleXpress proporciona incorporados para el control de

calidad de reglas de negocio y los términos. Estos controles
de calidad a mantener a todos honestos y mejorar la claridad
y facilidad de uso de las normas y condiciones. RuleXpress
hace que sea fácil de aplicar las mejores prácticas y
directrices de la organización.

Resultados

Ahorros en dólares se han logrado significativos de la

utilización de los recursos de integración de negocio en
lugar de los recursos de TI para cada actualización. Cada
iteración se multiplica este beneficio. El uso de RuleXpress
en relación con la metodología de las normas de desarrollo y
ha reducido los tiempos de ciclo de aplicación y mayor
agilidad de negocios. La empresa ha pasado de un niño de 8
semanas con el ciclo de la construcción a una empresa
impulsada por el ciclo de menos de 10 días - una reducción
del 80%. Esto ha permitido la redistribución de los recursos
de TI para centrarse en otras actividades de mayor valor.

A pesar de la necesidad de que los encuestados múltiples y

múltiples niveles de cumplimiento de la normativa, los
cambios se pueden hacer en una semana a 10 días. En un
periodo de 4 meses 11 actualizaciones importantes a las
reglas de negocio fueron identificados, diseñados, revisados
y en funcionamiento sin problemas.

El departamento de TI se compara muy favorablemente este

proceso a los enfoques anteriores, encontrando que se
reduzcan al mínimo los requisitos de perdidas y por lo tanto
"garantía" de trabajo. Algunos desarrolladores han empezado a
pedir a sus usuarios de negocio para las normas y modelos de
hecho, incluso cuando un motor de reglas no es la aplicación
de destino. Ellos valoran el aumento de la claridad de los
requisitos inherentes a este enfoque. Los arquitectos de
datos también valoro el enfoque, y prefiere un conjunto de
modelos de hecho, los términos y reglas para cada
actualización. Incluso los usuarios a tiempo parcial de la
herramienta han dado una retroalimentación positiva, resulta
accesible y fácil de usar.

"La salida de RuleXpress hace que los requerimientos de

negocio de manera clara y fácil de implementar, que nuestro
arquitecto aplicación de plomo no aboga por avanzar en nuevos
proyectos sin necesidad de utilizar los artefactos de negocio
generado fuera de RuleXpress." Dijo la iniciativa
empresarial. "Ella quiere un modelo hecho y bien definidas
las reglas de negocio antes de que el equipo de TI de
desarrollo aún comienza su trabajo".

Planes para el futuro

El departamento de TI está interesada en usar sus necesidades

herramienta - Rational RequisitePro - y RuleXpress juntos. El
departamento de TI realmente valora cómo RuleXpress puede
aportar la empresa en el proceso de necesidades de gestión y
desea ampliar eso. La compañía también planea comenzar a usar
FactXpress tan pronto como se integra con RuleXpress.

EJEMPLO 2 :

Administración de Impuestos y Aduanas

--------------------------------------------------
------------------------------

Compañía
Autoridad tributaria regional

Desafío
Mejorar la precisión de los sistemas fiscales y de permitir
a los usuarios de negocio para cumplir con su responsabilidad
de administrar las normas fiscales

Solución
Utilice RuleXpress para documentar y hacer que el código de
impuestos explícitos y modernizar los sistemas fiscales
legado

Resultados
Mejora de la precisión en la recaudación de impuestos y la
reducción de complejidad de la implementación futura de un
95%

--------------------------------------------------
------------------------------

Este cliente, que desea permanecer en el anonimato, es la

autoridad fiscal para uno de los gobiernos regionales en
Europa. Por razones históricas, el Gobierno regional tiene su
propio conjunto de normas tributarias que se coordinan con el
gobierno central.

La información de este estudio de caso se basa en entrevistas

a clientes realizadas por James Taylor.
© Soluciones de Gestión de la Decisión

Desafío

La responsabilidad primordial de la autoridad fiscal es el

cálculo de la obligación tributaria para todas las personas y
las empresas de la región local. En el pasado esto era una
función empresarial centralizada. Como el código de impuestos
se ha vuelto más compleja, la función se ha vuelto más
descentralizada. La organización cuenta ahora con una
estructura similar a la del código de impuestos con los
grupos se centró en los impuestos directos, impuestos
indirectos, etc La gente de negocios dentro de cada grupo son
responsables de garantizar la normativa fiscal se apliquen
correctamente y que las obligaciones se calculan con
precisión. Pero estos empresarios no saben exactamente cómo
los sistemas de legado calcular las obligaciones fiscales.
Como resultado de ello tienen una serie de desafíos.

El sistema de cálculo de la obligación tributaria no siempre

coincide con los reglamentos, por escrito y la gente de
negocios no se puede explicar por qué. Esto se traduce en la
imposibilidad de evaluar con precisión los impuestos. Cuando
los ciudadanos demuestren que son el derecho de sus
obligaciones fiscales se pone en una lista de exclusión.
Cuando la autoridad fiscal descubre los individuos o las
empresas tienen más obligaciones que la presente se pone en
una lista de inclusión. Pero las reglas errónea de que la
causa del problema no pueden ser fácilmente identificados y
corregidos para garantizar inconsistencias similares en el
futuro. Y la autoridad no puede adoptar políticas fiscales
más sofisticadas, algo que se ha convertido en una cuestión
crítica. En particular, la capacidad de adaptar los sistemas
para detectar posibles fraudes ha sido identificado como
cruciales para el futuro de la estabilidad de ingresos
tributarios.

Para abordar estas cuestiones, la autoridad determine que es

necesario mejorar la comunicación entre los empresarios y
personal de TI. Dada la necesidad de expertos en negocios
para interpretar la legislación y para que el desarrollo de
sistemas para recaudar impuestos, la comunicación tiene un
efecto directo sobre los ingresos percibidos y la equidad del
código tributario. Como ciudadanos, naturalmente, se centran
en los intentos de recaudar impuestos demasiado, los
problemas tienden a reducir la cantidad de impuestos
recaudados.

Para tener éxito, la autoridad tuvo que crear un vínculo

consciente y precisa entre los reglamentos y la aplicación
actual. Y tenía que crear un proceso eficaz para la mejora
continua de la normativa fiscal. Un lenguaje preciso que
pudiera describir la aplicación del código fiscal, sin la
jerga técnica es esencial. Sólo entonces la gente de negocios
pueda tener sobre su responsabilidad legal de administrar la
aplicación del código tributario.

Los intentos de utilizar los documentos para documentar las

normas no eran satisfactorias porque no se permiten las
normas que deben gestionarse. Asimismo, el uso de un sistema
de normas de gestión de negocio por sí sola no ofrece
suficiente en términos de comprensión del negocio del
usuario. En particular, los usuarios de negocio quería ser
capaz de escribir sus reglas en el lenguaje natural perfecto.
Aquellos que trabajan con la legislación, el idioma en serio
y no les gusta trabajar con las palabras o frases
artificiales. Los usuarios de negocios ver pseudocódigo como
una señal de que se trata de que funcione y que suponga un
perjuicio para el tipo de colaboración que se requería.

Solución

La autoridad adoptó RuleXpress y el enfoque RuleSpeak a

escribir las reglas. Uso RuleXpress, los usuarios
empresariales documento, los términos, los hechos y las
normas del código tributario. Cada caso o elemento del código
de impuestos es considerado. Primero un usuario de documentos
de la empresa de las normas y condiciones para el caso de
trabajo directamente de la legislación vigente. RuleXpress
permite a estas reglas y condiciones que deberán definirse en
el idioma local, exactamente como el usuario de negocios
comprende. Las normas y las condiciones creadas se remontan a
los artículos originales de la legislación de manera que es
evidente que las normas que vienen de artículos en los que
las piezas de la legislación. Un grupo de expertos en
negocios revisa estas normas, la búsqueda de un consenso.
Criterios de gestión se puede agregar a la legislación
original para documentar exactamente cómo debe aplicarse. El
código en el sistema de legado es la ingeniería inversa y en
comparación con las normas en RuleXpress. A veces, el código
refleja las directrices y criterios adicionales que deben
añadirse a la especificación. En este punto RuleXpress
contiene una especificación exacta de las normas necesarias y
las decisiones finales se pueden hacer sobre la lógica
necesaria para aplicar el artículo en particular en el código
tributario.

La documentación de toda la lógica de negocio para el código

fiscal regional de este modo ha llevado tan sólo doce meses,
con una cantidad significativa de la formación, la adopción y
el esfuerzo de gestión del cambio. Tanto los usuarios de la
consultora externa la gestión del conocimiento y del negocio
en el grupo encargado de coordinar con el uso de TI
RuleXpress. RuleXpress permite a los usuarios no técnicos
para acceder y actualizar las normas y generar los informes
que los departamentos de TI y de negocio necesitan.

RuleXpress ofrece:

· Fácil y eficaz gestión de los Términos de

RuleXpress proporciona gestión de término completo, el apoyo

a la definición plazo, los vínculos de información y los
servicios de navegación. Los usuarios de negocio pueden ver
definiciones de términos de las normas, navegar, realizar
análisis de impacto y determinar la trazabilidad. Aspecto
integrado-up para los términos y la identificación automática
de los términos definidos hacen que sea fácil de utilizar los
términos en las normas.

· Regla y término de calidad

RuleXpress proporciona incorporados para el control de

calidad de reglas de negocio y los términos. Estos controles
de calidad enfocada a mantener a todos y mejorar la claridad
y facilidad de uso de las normas y condiciones. RuleXpress
hace que sea fácil de aplicar las mejores prácticas y
directrices de la organización.

· Buscar normas

RuleXpress permite realizar búsquedas sofisticadas de las

normas y sus relaciones de negocios permite a los usuarios a
encontrar las reglas con ciertos tipos de relaciones y luego
imprimir los resultados de las búsquedas para mejorar la
colaboración y el entendimiento.

· Términos derivados

La herramienta permite conexiones eficaces entre los términos

derivados y de las normas que se derivan ellos. Esto asegura
que los usuarios pueden averiguar exactamente cómo se obtiene
un término.

· Facilidad de uso para gente de negocios

Intuitivo y fácil de usar, RuleXpress no tiene una interfaz

técnica que permite a los usuarios no técnicos crear y
administrar las reglas de negocio y los términos. Los
usuarios ponerse al día rápidamente y les resulta fácil de
usar día a día. RuleXpress evita cualquier uso de pseudo-
código o lenguaje técnico, y soporta la escritura en las
lenguas locales.

Resultados

Como los usuarios de negocios han desarrollado sus normas

modelo en RuleXpress su comprensión de ambos el código de
impuestos y su aplicación actual ha crecido. También han sido
capaces de mejorar y corregir algunos problemas en los
sistemas actuales, mejorar la exactitud de los cálculos de la
obligación tributaria. En varios casos, los sistemas tenían
errores en el código que nunca se había encontrado antes.
Estos se hizo evidente una vez hubo una definición de las
normas que tanto los usuarios de negocios y de TI de sus
homólogos podía entender. La autoridad también ha sido capaz
de mejorar el cumplimiento de la normativa vigente y han
comenzado a proporcionar información para mejorar el próximo
ciclo de la legislación.
Además de estas mejoras en la precisión de que también ven
una reducción drástica en la complejidad de implementación.
Por ejemplo, una pieza de la legislación transformado mostró
una reducción del 95% en la complejidad descriptiva. Cuando
el enfoque tradicional ha exigido 4.700 palabras para
describir el diseño y cerca de 60.000 palabras para su
aplicación, las reglas completas enfoque requiere sólo 2.800
palabras para describir y aplicar las normas.

Planes para el futuro

Nuestro cliente sigue utilizando RuleXpress para comprender,

gestionar y mejorar su sistema fiscal actual. Planes de
futuro podría ser la sustitución de este sistema con un
legado construido sobre un sistema de normas de gestión de
negocios. RuleXpress garanticen las normas de derecho se
construyen en este sistema desde el principio y tendrá un
papel clave en asegurar que cualquier caso automatizada para
un contribuyente individual puede vincularse de nuevo al
reglamento original.

EJEMOPLO 3

Seguros

--------------------------------------------------
------------------------------

Compañía
La pequeña práctica de los seguros comerciales de una
empresa de seguros establecida

Desafío
Reducir la revisión manual y aumentar la confianza de los
agentes en los precios cotizados

Solución
Desarrollo de un nuevo enfoque de desarrollo de
aplicaciones basadas en las empresas dirigidas por el
desarrollo de
las reglas de negocio y el proceso de

Resultados
Una relación nueva y mejorada entre el negocio y de TI y
verdadera propiedad de las empresas

de cambio en curso

--------------------------------------------------
------------------------------

Este cliente, que desea permanecer en el anonimato, ha estado

ofreciendo seguros de responsabilidad civil comercial y de
propiedad personal o en los Estados Unidos. Parte de su
negocio es una ventanilla única para el seguro comercial de
las pequeñas necesidades y ofrece tres veces el número de
clases de negocios elegibles que anteriormente estaban
disponibles, así como mejoras en la cobertura que satisfacen
las necesidades únicas de estos segmentos de negocio.

La información de este estudio de caso se basa en entrevistas

a clientes realizadas por James Taylor.

© Soluciones de Gestión de la Decisión

Desafío

Nuestro cliente vende seguros comerciales a través de agentes

independientes y tiene una exitosa operación de pequeños
negocios. Que proporcionar a los agentes independientes con
un programa de Internet citando a la aplicación. Estos
agentes suelen ser sentado en su oficina con un cliente
potencial y el uso de esta aplicación para obtener una
cotización, mientras que el cliente espera. Estos agentes
pueden ofrecer productos de varias empresas, por lo que
darles un gran servicio es crítico. Estos agentes quieren una
cotización rápida, precisa y comprometida - que garantiza a
nuestros clientes. El viejo sistema dio cita que no se habían
comprometido el 100% porque tenía que ser revisados
manualmente.
Las reglas de negocio para la suscripción fueron codificadas
en la aplicación. Los cambios en estas normas a menudo se 2-3
meses para poner en práctica. Sin embargo, muchos de estos
cambios se necesitan de inmediato para que demora degradadas
de la exactitud de las comillas. Esto aumentó el número de
variaciones de precios entre cotización y expedición y la
confianza de agente reducido. Además, las aplicaciones a
menudo necesitan información adicional. Mientras que los
suscriptores sabía que las respuestas a las preguntas que
significaría que los solicitantes deben proporcionar datos
adicionales de entrada, el antiguo sistema no dio prioridad a
estas cuestiones. Esto condujo a las llamadas de seguimiento
por los agentes después de que el cliente pensaba que la
aplicación fue completa.

"Queríamos ser capaces de procesar más del 25% de nuestras

pequeñas cuentas de las empresas comerciales con poca
intervención humana o no", dijo el analista de negocios de
alto nivel de procesos de nuestros clientes. "Al mismo
tiempo, hemos querido dejar que el control de los negocios de
sus normas de suscripción y las cuestiones asociadas con
ellos".

Nuestro cliente también se dio cuenta de que cualquier nueva

solicitud tenía que ser fácil de manejar para cambiar las
políticas de nueva empresa y las nuevas regulaciones, y para
que el porcentaje de Straight Through Processing aumentando
con el tiempo.

Solución

Nuestro cliente desarrollado una nueva aplicación que

automatiza las referencias de suscripción y notificaciones y
mejora la relación con los agentes. Este sistema se centra en
las primeras preguntas importantes y recoge los datos el
derecho de la primera vez. Se deja claro cuando algo es una
bandera roja para los agentes pueden resolver los problemas
rápidamente, mejorar el servicio al cliente.
Habida cuenta de la necesidad de hacer cambios regulares de
las normas de suscripción, nuestros clientes también se dio
cuenta de que esta solicitud tendría que permitir que los
cambios de reglas de negocio sin un ciclo de publicación
tradicional. Nuestro cliente vio el proyecto como una
oportunidad para crear una nueva forma de definición y
construcción de aplicaciones - que aumentaría la agilidad del
negocio y mejorar radicalmente la eficiencia del departamento
de TI. Nuestro cliente tiene un mandato corporativo para
mejorar la toma de aplicaciones centralizadas, como
comerciales y citando la suscripción, y este proyecto se
convirtió en el piloto de una nueva forma de hacer negocios.
Nuestro cliente ha adoptado un motor de proceso, un sistema
de gestión de reglas de negocio, un sistema de gestión de
contenido y un bus de servicios empresariales en apoyo de
este enfoque completamente nuevo de desarrollo de
aplicaciones.

Nuestro cliente se dio cuenta de que las herramientas de

implementación de nuevos eran sólo una parte de la solución.
Querían asegurarse de que no era el rigor en el proceso de
desarrollo regla. En el pasado se había tratado de captar las
normas como parte de los requisitos tradicionales, pero esto
había llevado a la codificación dura de la lógica de negocio
en las aplicaciones. Los intentos de administrar las reglas
por separado de los requisitos de uso de hojas de cálculo
también se insatisfactoria. Nuestros clientes participan de
Reglas de Negocio Soluciones, socio de implementación
RuleArts "en los EE.UU., y adoptado posteriormente Proteus /
RuleSpeak como una metodología de reglas de negocio y
RuleXpress para gestionar las reglas.

RuleXpress les permitió desarrollar sus reglas de negocio y

los términos asociados con el rigor, manteniendo un enfoque
comercial. Nuestro cliente tiene analistas de procesos de
negocios algunos de los cuales se centran en la definición
del proceso, algunas de las reglas de negocio. Estos
analistas uso RuleXpress para gestionar las reglas de negocio
y los términos. El acceso de las empresas a los usuarios del
mismo repositorio para buscar información, ver el impacto de
un cambio propuesto podría tener y mucho más. La aplicación
se hace en el motor de reglas y las normas ejecutables y
otros artefactos de implementación están vinculados a la
fuente en RuleXpress. Esto permite el análisis del impacto de
la obligación original hasta su aplicación final.

RuleXpress ofrece:

· Fácil y eficaz gestión de los Términos de

RuleXpress proporciona gestión de término completo, el apoyo
a la definición plazo, los vínculos de información y los
servicios de navegación. Los usuarios de negocio pueden ver
definiciones de términos de las normas, navegar, realizar
análisis de impacto y determinar la trazabilidad. Aspecto
integrado-up para los términos y la identificación automática
de los términos definidos hacen que sea fácil de utilizar los
términos en las normas. Y RuleXpress gestiona términos
preferidos y los sinónimos y genera un completo glosario de
términos para uso en toda la empresa.

· Regla y término de calidad

RuleXpress proporciona incorporados para el control de
calidad de reglas de negocio y los términos. Estos controles
de calidad a mantener a todos honestos y mejorar la claridad
y facilidad de uso de las normas y condiciones. RuleXpress
hace que sea fácil de aplicar las mejores prácticas y
directrices de la organización.

· Trazabilidad y notificación de las relaciones

RuleXpress gestiona todas las relaciones necesarias para
garantizar la trazabilidad - de los contratos o las políticas
a las normas, las reglas a los términos, la fuente de la
aplicación. La trazabilidad se mantiene en el repositorio y
RuleXpress permite que esto sea fácil de salida para el
análisis de impacto y presentación de informes.

· Open Integration
RuleXpress puede importar las reglas y las condiciones
creadas en otros entornos para poder reutilizar las
inversiones existentes, como las normas capturados en hojas
de cálculo.

Resultados
Nuestro cliente ha pasado 2 años renovando por completo su
enfoque de desarrollo de aplicaciones y la tecnología de
pila. A pesar de que las primeras aplicaciones sólo van a la
producción que ya han visto grandes beneficios, sobre todo en
la relación entre negocio y TI. Los usuarios de negocios se
han convertido en un verdadero compromiso y se sienten
responsables de sus propias aplicaciones. Ellos son los
dueños del proceso y las normas, que pueden hacer análisis de
impacto para comprender el efecto que un cambio puede tener,
y que entiendan lo que está pasando. En el pasado este tipo
de información fue enterrado en el código y lo que los
usuarios de negocios no podría realizar su propio análisis o
hacer sus propios planes. IT, mientras tanto, es capaz de
concentrarse exclusivamente en la aplicación de las reglas de
negocio. La combinación de RuleXpress y una metodología clara
y disciplinada garantiza que los desarrolladores de
aplicaciones y autores regla conseguir normas claras e
inequívocas para poner en práctica.

Planes para el futuro

Otros grupos ya están adoptando la tecnología de pila y el

enfoque para otros proyectos. Por ejemplo, una nueva
aplicación para tramitar las reclamaciones que se prepara con
ella.

EJUEMPLO #$

Utilidades

--------------------------------------------------
------------------------------

Compañía
A la agencia no lucrativa que apoya la comunidad los
servicios públicos de propiedad

Desafío
Mantener los sistemas de información sincronizada con un
mercado energético en rápida evolución

Solución
Elaborar y desarrollar un sistema basado en normas
utilizando RuleXpress y un moderno sistema de normas de
gestión empresarial

Resultados
Reducción sustancial de los costos relativos a otras
organizaciones que enfrentan los mismos desafíos

--------------------------------------------------
------------------------------

Este cliente, que desea permanecer en el anonimato, es un no-

para la articulación de competencias de la agencia sin fines
de lucro que representa y presta apoyo a 17 miembros de las
comunidades y distritos en los Estados Unidos. Nuestro
cliente fue fundada como un foro a través del cual la
comunidad de propiedad de empresas de servicios públicos
podría impedir los abusos de mercado costoso empleado por las
empresas privadas en ese momento, y realizar inversiones para
garantizar un comprable, confiable y limpia futuro
abastecimiento de energía eléctrica para los contribuyentes.

La información de este estudio de caso se basa en entrevistas

a clientes realizadas por James Taylor.

© Soluciones de Gestión de la Decisión

Desafío

El Operador de Sistema Independiente (ISO), recientemente

implementado la Reforma del Mercado y actualizar la
tecnología (MRTU), un programa integral que mejora la
fiabilidad de la red y corrige los defectos en los mercados
de la ISO. Este proyecto mantiene el estado compatible con
los modelos de mercado que están trabajando en toda América
del Norte y sustituye a la tecnología de envejecimiento con
los sistemas informáticos modernos que mantenerse a la par
con las necesidades dinámicas de la industria energética de
California. Con el fin de seguir siendo rentable en el
mercado, las organizaciones, tales como nuestros clientes
necesitan para implementar sistemas de información que
trabajan con los sistemas ISO nueva.
El diseño MRTU fue aprobado en septiembre de 2006 y se llevó
a cabo 31 de marzo 2009. A lo largo de la vida del proyecto,
más de 10.000 páginas de los requisitos fueron escritas por
la ISO y transmitido a las organizaciones, incluyendo a
nuestros clientes. Cada organización necesaria para ponerlos
en práctica para apoyar MRTU. No sólo los analistas de
nuestra necesidad de los clientes para la cosecha de los
requisitos originales de esas páginas, que también es
necesario no perder de vista a veces cambia diariamente.
Nuestro cliente tuviera que describir este trabajo a la gente
de negocios internos, a sus internos de la Comisión, a las
ciudades miembros y al departamento de TI. Para tener éxito,
nuestro cliente necesita un único conjunto de artefactos de
negocios, una buena comprensión de los requisitos y una mayor
transparencia.

Solución

Nuestro cliente se dio cuenta pronto de que el apoyo a MRTU

requiere un pensamiento innovador y un nuevo enfoque de
desarrollo de software y de negocios. Nuestro cliente inició
un proyecto de Arquitectura Empresarial para crear una
fundación para el futuro de los sistemas de TI. La adopción
de una versión modificada del marco Zachman, se centró en el
desafío particular de la gestión de reglas de negocio. En
particular, nuestro cliente sabía que necesitaba para
gestionar los documentos de origen para MRTU, las reglas de
negocio ellos mismos, los metadatos acerca de las reglas de
negocio y los términos en que se basa la normativa.

Enfoques anteriores habían llevado a las reglas de negocio

que sólo se define en los documentos de política y el código.
Estos enfoques no permiten una gestión eficaz de las normas o
proporcionar el tipo de trazabilidad necesaria en un proyecto
salpicada con los requisitos de una gran volatilidad.
Evidentemente, un nuevo enfoque era necesaria para resolver
este problema.
Nuestro cliente, adoptó una herramienta de modelado, pero su
apoyo para el modelado de reglas de negocio era insuficiente.
El uso de Word y Excel, para administrar las reglas también
fue rechazada porque no hay una gestión real de las normas
sería posible. Nuestro cliente se ha comprometido a utilizar
un sistema de normas comerciales de gestión empresarial
(BRMS) como su entorno de ejecución. Mientras que el BRMS
proporcionado un repositorio de reglas sólidas centrado en la
aplicación, nuestro cliente necesitaba un modelo de negocio
más céntrica de las reglas de negocio y los términos. Después
de evaluar otras alternativas, nuestro cliente se convirtió
en pionero en la adopción de RuleXpress.

"Queríamos una herramienta que soporte toda la organización y

pensamos que era un vendedor que era lo suficientemente
grande para ofrecer el apoyo y la longevidad, pero se centró
en este problema concreto y en el apoyo a nosotros", dijo el
Gerente de Sistemas de Información de nuestros clientes.
"RuleArts y RuleXpress encajar a la perfección".

Nuestro cliente utiliza RuleXpress como una parte fundamental

del diseño de los procesos que apoyan su negocio. Una parte
integral del enfoque de su empresa Arquitectura, se cierra la
brecha entre la TI y el negocio al garantizar un
entendimiento común de los problemas y las soluciones
propuestas. RuleXpress es la principal herramienta para
analistas de negocio para la captura de requisitos de la
regla de la perspectiva de la gente de negocios. Informes de
RuleXpress son tan precisa y completa que a menudo son
considerados documentos legales que se envían para aprobación
de la Comisión. RuleXpress proporciona trazabilidad crítico y
la vinculación entre el documento basado en los requisitos y
las normas ejecutables, no importa cómo se aplican. Además,
RuleXpress se utiliza para gestionar los términos de nuestro
cliente utiliza en la empresa. Todos estos términos están
asignados a su aplicación específica en los sistemas de
información.

RuleXpress ofrece:

§ Fácil y eficaz gestión de los Términos de

RuleXpress proporciona gestión de término completo, el apoyo
a la definición plazo, los vínculos de información y los
servicios de navegación. Los usuarios de negocio pueden ver
definiciones de términos de las normas, navegar, realizar
análisis de impacto y determinar la trazabilidad. Aspecto
integrado-up para los términos y la identificación automática
de los términos definidos hacen que sea fácil de utilizar los
términos en las normas. Y RuleXpress gestiona términos
preferidos y los sinónimos y genera un completo glosario de
términos para uso en toda la empresa.

§ Fácil de usar para gente de negocios

Intuitivo y fácil de usar, RuleXpress no tiene una interfaz
técnica que permite a los usuarios no técnicos crear y
administrar las reglas de negocio y los términos. Los
usuarios ponerse al día rápidamente y les resulta fácil de
usar día a día. RuleXpress evita cualquier uso de pseudo-
código o lenguaje técnico, y soporta la escritura en las
lenguas locales.

§ Una "biblioteca de referencia"

RuleXpress puede contener las reglas de negocio, las fuentes
de las normas, términos, documentos de apoyo, pruebas, los
detalles de implementación y de la opinión, incluso de las
personas. Con RuleXpress puede crear una biblioteca de
referencia válido para los proyectos.

Resultados

MRTU duró tres años y medio. Los cambios en el diseño del

mercado de la electricidad significó un cambio constante -
los cambios semanales de la ISO para la mayoría de los dos
últimos años. Defectos del mercado se encuentra y la ISO
cambiar las reglas en consecuencia. Esto a su vez significa
que nuestros clientes tendrían que actualizar las normas en
sus sistemas. Sin RuleXpress, como una tasa de cambio no han
sido admitidos.

En comparación con cómo otras organizaciones han puesto en

práctica MRTU los resultados han sido espectaculares.
Mientras que algunos grupos de los municipios gastaron más de
$ 10M en los componentes y la consulta de más de tres años de
aplicación de las normas, nuestro cliente pasó sólo 300.000
dólares en componentes y la consulta - una reducción
sustancial de los costes y el ahorro es en este ciclo de
desarrollo - el mantenimiento en curso seguirán siendo mucho
menos, impulsar la reducción del costo total de propiedad con
el tiempo.

Además, todo el mundo en nuestro cliente está hablando el

mismo lenguaje y el entendimiento entre sí. Miles de reglas y
más de 2.000 términos han sido definidos y documentados. Lo
más importante de estas normas y términos están localizables.
Los 2.200 términos son una guía de referencia a cómo el
negocio de habla y lo que significa. Y uno que es tan
completo que es utilizado como referencia por el departamento
legal. El uso de RuleXpress ha ayudado a difundir el
conocimiento en toda la organización, dejando en claro cuáles
son las reglas y todo el mundo ayudando a entender el negocio
de nuestros clientes.

Planes para el futuro

Nuestro cliente ha estado trabajando con su proveedor de BRMS

y RuleArts para empatar el repositorio RuleXpress a la de los
BRMS. Cerrar la brecha de comunicación entre los dos
depósitos se espera mejorar considerablemente la gestión del
cambio. La mayoría de los cambios se iniciarán dentro de
RuleXpress y luego traducido al BRMS sin la necesidad de que
reescribe la regla y la traducción manual.

Nuestro cliente también ha estado trabajando con RuleArts

para integrar perfectamente RuleXpress con Microsoft Word. La
creación de un diccionario add-on que contiene todos los
términos definidos en RuleXpress velará por la coherencia en
la terminología y permitir que cualquier persona en una
empresa para utilizar el lenguaje de la empresa.

HITOS EN EL CAMINO DE LA EXCELENCIA EN LA GESTIÓN . . .

1 Descubrir que sus reglas son difíciles de encontrar,
inconsistentes e incompletas.
2 Organizar sus reglas.
3 Corregir y validar sus reglas.
4 Verifi car la consistencia y totalidad de las reglas.
5 Publicar y comunicar las reglas clave.
6 Usar reglas clave para facilitar su rápida implementación.
7 Localizar sus reglas la próxima vez que necesite cambiarlas.
8 Proporcionar guías consistentes a lo largo de la corporación
en forma de reglas.

REPRESENTACIÓN Y COBERTURA
DE LAS REGLAS DE NEGOCIO
♦ Vocabularios para acelerar el desarrollo.
♦ Múltiples representaciones de reglas.
♦ Modelado de hechos gráfi co.
♦ Conservación de la secuencia de presentación.
♦ Testeo de la consistencia de las reglas.
♦ Testeo de la colisión de reglas.
♦ Soporte de léxico.
 The Business Rules Approach

Information Systems analysts have long been able to describe an enterprise in terms of
the structure of the data the enterprise uses and the organization of the functions it
p e r f o r m s . U n f o r t u n a t e l y, t h e r e i s o f t e n n e g l e c t o f t h e r u l e s ( c o n s t r a i n t s a n d c o n d i t i o n s )
under which the enterprise operates. Frequently these rules are not articulated until it is
time to convert them into program code. While rules that are represented by the
structure and functions of an enterprise have been documented to a degree, others have
not been articulated well, if at all. The Business Rules Group was organized to carry out
that articulation.

Key Notions of the Business Rules Approach

Key notions of the business rules approach are presented succinctly by the BRG's
Business Rules Manifesto. An extract from the Manifesto is presented here, to assist
those new to the approach in positioning some of the central notions of the Business
Rules Approach. This brief extract is followed by a figure that provides an overview of of
the way these key notions are reflected in the emerging standard, the Semantics of
Busi ness Vocabul ary and Busi nes s Rul es (S BV R) .
 P r i m a r y R e q u i r e m e n t s , N o t S e c o n d a r y. R u l e s a r e e s s e n t i a l f o r, a n d a d i s c r e t e p a r t
of, business models and technology models.

Separate From Processes, Not Contained In Them. Rules apply across processes
and procedures. There should be one cohesive body of rules, enforced consistently
a c r o s s a l l r e l e v a n t a r e a s o f b u s i n e s s a c t i v i t y.

Deliberate Knowledge, Not A By-Product. Rules build on facts, and facts build on
c o n c e p t s a s e x p r e s s e d b y t e r m s . Te r m s e x p r e s s b u s i n e s s c o n c e p t s ; f a c t s m a k e
assertions about these concepts; rules constrain and support these facts. Rules are
basic to what the business knows about itself -- that is, to basic business knowledge.
Rules need to be nurtured, protected and managed.

Declarative, Not Procedural. Rules should be expressed declaratively in natural-

language sentences for the business audience. A rule is distinct from any enforcement
defined for it. A rule and its enforcement are separate concerns.

Well-Formed Expression, Not Ad Hoc. Business rules should be expressed in such a

way that they can be validated for correctness by business people. Business rules
should be expressed in such a way that they can be verified against each other for
c o n s i s t e n c y.

F o r t h e S a k e o f t h e B u s i n e s s , N o t Te c h n o l o g y. R u l e s a r e a b o u t b u s i n e s s p r a c t i c e
and guidance; therefore, rules are motivated by business goals and objectives and are
shaped by various influences. The cost of rule enforcement must be balanced against
business risks, and against business opportunities that might otherwise be lost.

Of, By and For Business People, Not IT People. Rules should arise from
knowledgeable business people.

Managing Business Logic, Not Hardware/Softw are Platforms. Rules, and the ability
t o c h a n g e t h e m e f f e c t i v e l y, a r e f u n d a m e n t a l t o i m p r o v i n g b u s i n e s s a d a p t a b i l i t y.

The Business Rules Mantra

A core idea of the business rules approach is the following from the Manifesto:

" R u l e s b u i l d o n f a c t s , a n d f a c t s b u i l d o n c o n c e p t s a s e x p r e s s e d b y t e r m s . Te r m s e x p r e s s
business concepts; facts make assertions about these concepts; rules constrain and
support these facts."
T h i s c o r e i d e a , o r i g i n a t i n g i n t h e B R G ' s s e m i n a l 1 9 9 5 w h i t e p a p e r, h a s b e e n c a l l e d t h e
Business Rules 'mantra'. It is often abbreviated for convenience to simply:
"Rules are based on facts, and facts are based on terms."

The figure below provides an overview of how SBVR supports the 'mantra'. It requires
separation of viewpoints as follows:

Business Rule 'Mantra'. An approximation that simplifies explanation for business

people and others new to the approach.

Representation (in SBVR terminology). The SBVR notions that classify the words that
people use to express their vocabulary + rules.

Meaning (in SBVR terminology). The SBVR notions that classify the underlying
meaning of the words that people use in expressing their vocabulary + rules.
 C:\Documents and
Settings\All Users\Documents\Business_vs_SystemUseCases.pdf

1.5.1.1Dallas, October 21-23, 1997

Toronto, December 2-4, 1997

1.5.2About This Seminar

This seminar describes the emerging business rule approach in depth. It explains what business
rules are, and why they are crucial to your company.

The business rule approach seeks better ways to communicate with end users about the business.
It represents a revolutionary new approach to defining requirements. Business rules are also key to
making your company and its information systems more adaptive in the face of rapid change.

This seminar offers practical hands-on techniques for capturing, defining and modeling business
rules and examines the latest techniques for modeling data, rules, and scripts (use cases). Key
concepts are reinforced by numerous examples and exercises.

Rules offer breakthrough innovations for building better information systems. This seminar provides
a leading-edge look at what the opportunities are and how you can exploit them. Finally, the
seminar introduces the exciting new ideas of rule independence and rule normalization and
examines breakthrough insights into procedural re-usability.

1.5.2.1What's Happening

Business rules encompass the terms, facts and rules that underlie business operations.
They represent basic knowledge the business holds in common across applications, users
and platforms.

Many business rules can be addressed successfully at the implementation level by databases, and
triggers and stored procedures, or rule engines. However, these technologies fail to address that
‘how-to’ of requirements gathering, analysis, and design. Also, they do not address these activities
in platform-in-dependent fashion.

Triggers and stored procedures offer one approach for supporting business rules; rule engines offer
another. Rule-based software generators are beginning to appear; active database systems are on
the horizon. The business rule approach offers a comprehensive "front-end" for all these
technologies.

Over the next five years, people will also recognize that OO is really a programming discipline, with
little or no connection to the knowledge that managers use in running the business (i.e. there really
is more to life than messages and methods!). The business rule approach will fill the void. It also
has convincing things to say about the problems of business adaptability and the accelerating rate
of change-problems that OO is not measuring up to in the larger sense.
This seminar provides answers. The innovative ideas it presents will enable your company
to become more adaptive by means of a business rule approach. This will permit it to
achieve accelerated rates of change-a business imperative for this decade and beyond.

*Attendees receive a 20% discount on Ronald G. Ross' "The Business Rule Book:
Classifying, Defining, & Modeling Rules."*

1.5.3What Makes This Seminar Unique

This is the only seminar available on business rules. Through this seminar, you will acquire in-depth
knowledge which will help position your company as a leader in this important new area. Attendees
will have the opportunity to gain practical, hands-on experience for capturing, defining and modeling
business rules.

1.5.4Benefits of Attending:
• Understand where business rules fit with business strategy, to ensure IS projects stay on
track
• Use business rules to discover events, to ensure consistency in the editing and validating of
data
• Enhance your IS methodology, to capture and develop requirements more effectively
• Discover breakthrough innovations for building better information systems

1.5.4.1In this seminar, you will learn how to. . .

• Make your information systems and your business more adaptive through a business rule
approach.
• Express, classify and model business rules, so that you can initiate a business rule
approach at your company.
• Capture business rules in English, to enhance communication with end users.
• Develop data models, rule models, and scripts(use cases) in seamless fashion, in order to
avoid the gaps and pitfalls plaguing methodologies today.
• Understand the limitations of objects for business database applications, so that you can
decide how best to use them.
• Model user interactions where relational database is a "given," so that you can avoid the
object-relational disconnect many practitioners face.
• Use business rules to discover events, so that triggers and/or rule servers can be used
properly.
• Apply business rule ideas to BPR and workflow, opening up exciting new opportunities for
streamlining and usability.
• Re-Tool your data modeling practices for type hierarchies, objects, and scripts(use cases),
to keep your professional skills current.
1.5.4.2Who Should Attend
• Analysts responsible for developing business requirements for information systems.
• System Designers responsible for developing platform-independent models for information
system requirements.
• Data Modelers, DBAs and Database Designers responsible for database design,
including triggers and stored procedures.
• Project Leaders and Consultants responsible for selecting, developing and/or using IS
development methodologies.
• Rule Analysts responsible for specifying, managing and implementing rules using rule
servers or other techniques.

1.5.4.3Seminar Outline

1.5.4.4Part I. The Business Rule Approach

1. Business Rules: The New Approach
a. The business challenge
b. What are business rules?
c. What makes up basic business knowledge?
2. Rules: The New Idea
a. What are rules?
b. The Declaration of Rule Independence
c. Business Rule Automation
3. Developing and Modeling Business Facts
a. How to get from ramblings to facts
b. Building the data model based on facts
c. Asking the right questions
d. What makes a good business rule
e. Predicates and more predicates
f. Advanced data modeling ideas and pitfalls

Exercises

4. The Business Rule View of Business Events

a. Point-in-time vs. Points-over-time
b. Modeling business events in data
c. Time-Tunnel Vision
d. The business rule view of current state

Exercises

Part II. Specifying Rules

1. Where Rules Fit

2. Journey Into ISA
a. Type hierarchies and inheritance
 b. Applying rules
c. Subtypes and states
d. Static vs. Dynamic types

Exercises

3. Modeling Rules
a. Basing rules on facts
b. Normalizing rules
c. Modeling rules graphically
d. Sample rules

Exercises

4. Developing Rules
a. Getting the rule
b. Getting the whole rule
c. Getting nothing but the rule
d. What makes a good rule
e. Exceptions to rules

Exercises

5. Objects Under the Microscope

a. A better model of reality
b. Responsibility-driven
c. Objects for knowledge

Part III. Putting the Business Rule Approach into Motion

1. The Mechanics of Business Rule Systems

2. The Business Rule View of Update Events
a. Rules-to-update-events is M:N
b. Decomposing rules

Exercises

3. Rules in the Business Rule Approach

a. Rule enforcement options
b. Rules vs. Inference
4. Developing Scripts for User Interaction
a. The cast of actors
b. Modeling flow
c. The rate of rules

5. Business Rules and BPR

a. Business Rule Re-engineering
 b. Challenging the Rules
c. Allocating responsibility

Exercises

6. Business Rule Methodology

a. The Sponsor's view
b. Business strategy and rules
c. Facilitation
d. Getting started
7. New Horizons
a. Rule mining
b. Test-drive your business rule
c. "Smart" and "Brilliant" scripts

Mucho se ha escrito, y se sigue escribiendo, sobre las Reglas de Negocio (Business Rules).

La creciente evidencia de su importancia se ha puesto de manifiesto con la rápida difusión

de los nuevos sistemas BPMS (Business Process Management Suite) que, siendo por sí
mismos un nuevo paradigma de enfoque de la operativa empresarial, pueden ser
notablemente mejorados si las Reglas de Negocio, en lugar de estar embebidas en los
propios procedimientos operativos, se mantienen como una tribu independiente, aunque en
íntimo contacto con los Procesos.

Esto permite que los Procesos puedan mantenerse prácticamente sin cambios (excepto los
derivados de las mejoras introducidas en su diseño) ya que la mayor parte de los cambios se
derivan de las variaciones del entorno empresarial (mercado, políticas, estrategia, etc.), que
es justamente lo que queda definido en las Reglas de Negocio. Con este enfoque, los
cambios se introducen en las Reglas de Negocio y los Procesos quedan automáticamente
adaptados a las nuevas situaciones.

Para el establecimiento de procedimientos y estándares de creación y uso de las Reglas de

Negocio, han aparecido y siguen apareciendo propuestas que se centran, bien en la
semántica y sintaxis de las expresiones (prácticamente solo en idioma Inglés), bien en
sistemas de definiciones de terminologías ligadas a repositorios de datos que puedan ser
transformables a lenguaje XML y otros para la intercomunicación entre empresas. Todos
estos esfuerzos van encaminados a mejorar el intercambio informativo en el entorno multi-
empresarial que se vislumbra para los próximos años.

1.6¿Qué son realmente las reglas de negocio?

En palabras de Ronald G. Ross, uno de los más reconocidos expertos mundiales en Reglas
de Negocio:
“A business rule is simply a rule that is under business jurisdiction. Under business
jurisdiction is taken to mean that the business can enact, revise, and discontinue their
business rules as they see fit. If a rule is not under business jurisdiction in that sense, then it
is not a business rule. For example, the ‘law’ of gravity is obviously not a business rule."

Esta es una definición muy general. Pueden encontrarse otras definiciones más o menos
parecidas, pero desde la perspectiva que a nosotros interesa, que es su aplicación práctica
en un sistema de gestión empresarial por procesos (BPMS), podemos aproximar la
definición y alcance de las Reglas de Negocio con los siguientes enunciados.

1. Reglas de Negocio son los elementos individuales (atómicos) que permiten ser
definidos, delimitados y expresados de forma inteligible y que en su conjunto
componen el marco estructural, la política, la estrategia y la operativa de una
empresa u organización.
2. Podría decirse que las Reglas de Negocio se encuentran siempre presentes en la
actuación de una organización, bien de manera explícita (una política de salarios, el
horario laboral, el descuento a aplicar en función de las condiciones de la venta,
etc.) o de manera implícita no expresada (el trato cortés con los clientes, la
responsabilidad del supervisor sobre sus supervisados, etc.) siempre implicando la
participación directa o indirecta de personas. Sin embargo, el término Reglas de
Negocio queda reservado únicamente para aquellas reglas que revisten carácter
explícito y que pueden ser y son, expresadas de manera entendible,

registradas, localizables y modificables.

3. Las Reglas de Negocio deben definirse y mantenerse de manera independiente de
los modelos y los procesos con los que la empresa funciona. No es que las Reglas
de Negocio no tengan conexión con los procesos, mas bien al contrario, mantienen
una relación íntima y constante. Sin embargo, su existencia y personalidad se deriva
de la propia concepción de la empresa como ente económico-social y su misión es
definir de manera granular sus políticas y modos operativos. Las Reglas de Negocio
no están supeditadas a las definiciones o modelizaciones de los procesos ni a los
cambios de éstos.

Esta independencia frente a los procesos en cuanto a su definición y modificación es

de vital importancia para los BPMS ya que permite que los procesos queden
automáticamente actualizados con los cambios de políticas de la empresa sin
necesidad de cambiar su modelo. Basta con cambiar las Reglas de Negocio a las que
acceden.
 4. Por su función, las Reglas de Negocio se dividen en Operativas, llamadas así
porque su ejecución implica la vinculación personal y que por tanto pueden ser
violadas (no cumplidas), y Estructurales, que son las que definen condiciones y
tratamientos y que, al no depender de la acción de las personas, no pueden ser
violadas. Un ejemplo de Regla Operativa es: Los obreros deben llevar casco.
Evidentemente, si un obrero no se pone el casco, está violando esta regla. Un
ejemplo de Regla Estructural es: Se considera Cliente VIP al que haya comprado
más de 200.000 € en el último año. Esta regla no puede ser violada. Podrá ser mal
computada si el encargado de aplicarla se equivoca al consultar la ficha del cliente.
Pero eso no es una violación sino un error.
5. Por su naturaleza las Reglas de Negocio pueden ser: Textuales (interpretables) y
Mecánicas (automatizables). Las reglas Textuales muestran su contenido mediante
expresiones de texto y normalmente aceptan algo de interpretación, aunque si están
bien expresadas, su margen de desvío en la interpretación debe ser mínimo o nulo.
Su aplicación siempre será realizada por una persona que es la que lee e interpreta el
texto de la regla. Por el contrario, las reglas Mecánicas se expresan mediante
fórmulas, tablas o expresiones matemáticas y por tanto pueden automatizarse. Su
aplicación puede realizarse sin la intervención de personas si existe un dispositivo
informático capaz de evaluarlas y ejecutarlas dentro del entorno operativo en el que
actúan.

Como ejemplo de Regla Textual, tómese esta: RN.101. Destino Inversión: Para la
concesión del Préstamo es necesario, aunque no suficiente, que la inversión se
pueda acoger a la legislación vigente sobre 'Desarrollos preferentes'. Para valorar
esta Regla, se necesita una persona que conozca la legislación vigente al respecto y
pueda analizar si la inversión prevista la cumple o no. Por tanto, no puede
automatizarse fácilmente sin la intervención humana.

Un ejemplo de Regla Mecánica es: RN.236. Límite de Préstamo: El importe del

Préstamo no puede ser superior a la Cantidad Límite. La Cantidad Límite se
determina en la tabla adjunta mediante Criterios de Garantía y Disponibilidad de
Fondos que se califican en las Reglas de Negocio indicadas. Aquí sí es posible que
de forma automática, sin intervención humana, y por tanto sin interpretaciones, se
compare la cantidad solicitada (importe del Préstamo) con la Cantidad Límite
expresada en la tabla adjunta. (Esta tabla contiene Criterios que se califican en otras
Reglas de Negocio anidadas, que se indican en la misma).

Como se ha dicho, existen organizaciones dedicadas al estudio y establecimiento de

estándares para la unificación de las Reglas de Negocio. En ese sentido, publicaciones
como el SBVR (Semantics of Business Vocabulary & Business Rules) del OMG (Object
Management Group) o el BRS RuleSpeakTM de Ron Ross son ‘de facto’ unas guías
aceptadas por la comunidad interesada. Sin embargo, la documentación disponible al
respecto adolece de dos importantes restricciones:

1. La semántica y la sintaxis de estas Reglas de Negocio se estudian a fondo y se

proponen modos de expresión estructurados y literalmente correctos, pero no entran
a proponer sistemas para la automatización de las mismas. Los sistemas para la
 automatización de la creación y aplicación de las Reglas de Negocio se dejan al
criterio, conocimientos y posibilidades técnicas de las empresas que desarrollan
software, con lo que cada entorno BPMS tiene su propio sistema (si es que lo tiene)
de automatizar las Reglas de Negocio.
2. Solo se trabaja con el idioma Inglés. Los estudios y estándares se centran
exclusivamente en ese idioma, y si bien la semántica y sintaxis de las Reglas de
Negocio son traducibles a otros idiomas, pasará algún tiempo antes de que se
disponga de bases aceptadas y extendidas para el tratamiento textual de aquellas en
otros idiomas, de manera estandarizada.

1.7Una palabra sobre los automatismos en las reglas de negocio

Las organizaciones en general, incluyendo naturalmente las empresas, son entornos en los
que conviven a la vez, procesos o procedimientos mecánicos de funcionamiento automático
(ordenadores, maquinaria, instalaciones, etc.) y también procedimientos en los que las
personas desempeñan un papel primordial, no solo con la aportación de su

trabajo físico sino con la intervención de su criterio a la

hora de realizar evaluaciones, tomar decisiones y mantener la comunicación con otros.

La combinación de esos dos ‘sistemas operativos’ está presente en toda la actividad

humana. Incluso el cuerpo humano funciona, por un lado, con procesos automáticos en los
que no interviene su capacidad de raciocinio y decisión (digestión, circulación sanguínea,
etc.) y otros en los que la mente efectúa valoraciones y toma decisiones (buscar comida,
bebida, confort, relaciones, etc.).

Es cierto que cuantos más procedimientos puedan dejarse al control de mecanismos

repetitivos y automáticos, mejor para el sistema en general. Pero es muy importante no
perder de vista, por un lado, el coste económico que puede implicar (en muchas ocasiones
la automatización es de gran complejidad, cuando no imposible), y por otro, la pérdida de
flexibilidad y adaptación a cambios. Un ordenador puede llevar a cabo con suma eficacia
labores que el ser humano realizaría con gran torpeza comparativamente. Pero si cambia
algo en el entorno del ordenador que afecte a sus reglas de funcionamiento interno, éste no
sabe que hacer y, o bien se detiene o bien realiza mal su cometido, generando errores con
consecuencias que pueden ser desastrosas. Sin embargo el ser humano será capaz
(presumiblemente) de decidir qué alternativa debe seguir cuando hay cambios o
excepciones. Esa es la diferencia.

En el caso del funcionamiento empresarial por Procesos (BPMS), que es el asunto que nos
ocupa, también se da esta convivencia. Algunos procesos, o actividades dentro de los
procesos, están perfectamente definidos y son lo suficientemente repetitivos para que su
automatización sea apropiada pues ésta apenas presenta inconvenientes y sí ventajas. Pero
en otras actividades, también dentro de los procesos, la intervención humana, con su
trabajo y su toma de decisiones, es necesaria y esencial. De estas actividades, algunas
podrían también automatizarse, pero el coste de esta automatización al considerar las
consecuencias de posibles ‘errores automáticos’ en el procedimiento o la pérdida de
flexibilidad para manejar excepciones e imprevisiones, es demasiado elevado, con lo que la
automatización es indeseable.

Por tanto hay que buscar la máxima automatización, pero sin arriesgar las posibilidades de
reacción ante los imprevistos y sin que el coste económico de aquella ensombrezca los
beneficios que aporta. Esta es una sabia regla de aplicación general.

Esto ha sido tenido en cuenta en AuraPortal BPMS. El sistema provee los medios para que
la empresa pueda automatizar gran parte de los Procesos mediante Reglas de Negocio
Mecánicas, pero también permite que el empresario pueda dejar ciertas partes de los
Proceso en manos de las Reglas de Negocio Textuales para que la intervención humana
aporte mayor facilidad de uso y flexibilidad en la ejecución de los mismos.

La importante consecuencia práctica de esto es que, puesto que AuraPortal BPMS dispone
de las herramientas adecuadas para un tratamiento potente y eficaz, tanto de las Reglas de
Negocio Mecánicas como de las Textuales, es posible, e incluso aconsejable, al principio
utilizar con más frecuencia las reglas Textuales y luego, con la práctica y la consolidación
de los Modelos de los Procesos, ir migrando paulatinamente hacia la inclusión de más
reglas Mecánicas que sustituyan a las Textuales, asegurando así una transición suave de uno
a otro escenario

EL DEBE Y EL HABER

DEBE Esta palabra, o los términos "obligatorio" o "SE",

significa que el
definición es un requisito absoluto de la especificación.

2. NO DEBE Esta frase, o la frase "NO", significa que la

definición es una prohibición absoluta de la
especificación.

3. DEBE Esta palabra, o el adjetivo "recomendada", significa

que no
pueden existir razones válidas en circunstancias
particulares para ignorar a un
tema en particular, pero todas las consecuencias deben
ser comprendidos y
sopesado cuidadosamente antes de escoger un rumbo
diferente.

4. NO DEBE Esta frase, o la frase "no recomendada" significa

que
pueden existir razones válidas en circunstancias
particulares, cuando el
conducta en particular es aceptable o incluso útil, pero
el pleno
consecuencias deben ser comprendidos y el caso de sopesar
con cuidado
antes de aplicar cualquier comportamiento descrito con
esta etiqueta.

5. PUEDE Esta palabra, o el adjetivo "OPCIONAL", significa

que un elemento es
verdaderamente opcional. Un proveedor puede optar por
incluir el tema porque un
determinado mercado lo exige o porque cree que
que mejora el producto, mientras que otro proveedor puede
omitir el mismo tema.
Una realización que no incluya una determinada opción
DEBE estar
preparada para interoperar con otra realización que sí
incluir la opción, aunque tal vez con funcionalidad
reducida. En el
misma línea, una aplicación que incluye una opción en
particular
DEBE estar preparada para interoperar con otra aplicación
que
no incluye la opción (excepto, por supuesto, para la
función de la
opción proporciona.)

6. De Orientación en el uso de estos imperativos de

Imperativos del tipo definido en la presente nota se debe

utilizar con cuidado
y con moderación. En particular, sólo debe utilizarse
cuando se
realmente necesario para el funcionamiento o para limitar
el comportamiento que ha
potencial para causar daño (por ejemplo, la limitación de
retransmisssions) Para
ejemplo, no se debe utilizar para tratar de imponer un
método particular
en los ejecutores en que el método no es necesaria para
la interoperabilidad.

7. Consideraciones de seguridad
 Estos términos se utilizan frecuentemente para
especificar el comportamiento de la seguridad
implicaciones. Los efectos sobre la seguridad de no
aplicación de un mosto o
Debe, o hacer algo que la especificación dice NO DEBE o
DEBERÍA
NO se puede hacer puede ser muy sutil. Autores del
documento que debe tomar el tiempo
de elaborar las implicaciones de seguridad de no seguir
recomendaciones y requisitos como la mayoría de los
ejecutores no se han
tenía la ventaja de la experiencia y el debate que
produjo la
pliego de condiciones.

8. Agradecimientos

Las definiciones de estos términos son una amalgama de

las definiciones adoptadas
de un número de RFC. Además, se ha sugerido
incorporan de una serie de personas, entre ellas Robert
Ullmann, Thomas
Narten, Neal McBurnett, y Robert Elz.

Network Working Group S.Bradner

Request for Comments: 2119 Harvard University
BCP: 14 Marzo 1997
Categoría: Mejor Práctica Actual

Palabras clave a utilizar en RFC para Indicar Niveles de Requerimiento

Estatus de este memorándum

Este documento especifica una Mejor Práctica Actual de Internet para

la comunidad Internet, y solicita su discusión y sugerencias para
posibles mejoras. La distribución de este memorándum es ilimitada.

Resúmen

En muchos documentos de seguimiento de estándar se usan varias

palabras para indicar los requerimientos de la especificación. Estas
palabras a menudo están en mayúsculas. Este documento define cómo
deberían ser interpretadas estas palabras en documentos IETF. Los
autores que sigan estas instrucciones deberían incorporar esta frase
cerca del principio de sus documentos:

Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO

DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y
"OPCIONAL" en este documento serán interpretadas como se describe
en RFC 2119.

Nótese que la contundencia de estas palabras está modificada por el

 nivel de requerimiento del documento en el que son usadas.

1. DEBE Esta palabra, o los términos "OBLIGATORIO" o "DEBERÁ",

significa que la definición es un requerimiento insoslayable de la
especificación.

2. NO DEBE Esta frase, o la frase "NO DEBERÁ", significa que la

definición es una prohibición insoslayable de la especificación.

3. DEBERÍA Esta palabra, o el adjetivo "RECOMENDADO", significa que

pueden existir razones válidas en determinadas circunstancias para
ignorar un elemento determinado, pero se deben comprender y sopesar
detenidamente todas las implicaciones antes de tomar una decisión
diferente.

4. NO DEBERÍA Esta frase, o la frase "NO RECOMENDADO", significa que

pueden existir razones válidas en determinadas circunstancias en las
que el comportamiento en particular sea útil o incluso aconsejable,
pero se deben comprender y sopesar detenidamente todas las
implicaciones antes de tomar una decisión diferente.

Bradner Mejor Práctica Actual [Pág. 1]

RFC 2119 Palabras Clave RFC Marzo 1997

5. PUEDE Esta palabra, o el adjetivo "OPCIONAL", significa que un

elemento es realmente opcional. Un proveedor puede elegir incluir el
elemento porque un mercado en particular lo necesite o porque el
proveedor sienta que realza el producto aunque otro proveedor pueda
omitir el mismo elemento. Una implementación que no incluya una
opción determinada DEBE estar preparada para interoperar con otra
implementación que incluya la opción, aunque quizá con reducida
funcionalidad. En el mismo orden de cosas, una implementación que
incluya una opción en particular DEBE estar preparada para
interoperar con otra implementación que no incluya la opción
(excepto, por supuesto, para la característica que aporte la opción).

6. Guia de uso de estos Imperativos

Los imperativos del tipo definido en este memorándum deben ser usados
con cuidado y con mesura. En particular, sólo DEBEN ser utilizados
donde sea realmente necesario para la interoperación o para limitar
un comportamiento potencialmente dañino (p.ej., limitando
retransmisiones). Por ejemplo, no deben ser usados para intentar
imponer un método concreto a los implementadores cuando el método no
sea necesario para la interoperabilidad.

7. Consideraciones de seguridad

Estos términos se utilizan normalmente para especificar

comportamientos con implicaciones de seguridad. Los efectos sobre la
seguridad de no implementar un DEBE o DEBERÍA, o hacer algo que la
especificación dice NO DEBE o NO DEBERÍA ser hecho, pueden ser muy
sutiles. Los autores de documentos deberían tomarse su tiempo para
 eleborar las implicaciones de seguridad respecto a no seguir
recomendaciones o requerimientos, ya que la mayoría de los
implementadores no tienen el beneficio de la experiencia y de la
discusión que produjo la especificación.

8. Agradecimientos

Las definiciones de estos términos son una amalgama de las

definiciones tomadas de numerosos documentos RFC. Además, se han
incorporado sugerencias de numerosas personas incluyendo a obert
Ullmann, Thomas Nartenm Neal McBurnett, y Robert Elz.

9. Dirección del autor

http://www.rfc-es.org/rfc/rfc2119-es.txt

El repositorio –
Yo no creo que sea el aspecto más importante.
No creo que la posibilidad de reutilización se está
realizando.
No creo que las actuales herramientas de facilitación de la
re-uso es limitado.
El aspecto más importante de un repositorio es la
reutilización de conocimiento, no sólo las normas. Los tipos
de conocimiento que son más fáciles de volver a utilizar son:

el vocabulario (por ejemplo, los sustantivos, verbos y

adjetivos) y lo que significan en el dominio
la taxonomía de conceptos y la forma en que se hace
referencia al uso de (principalmente) los sustantivos y
adjetivos
la ontología de conceptos, que es la taxonomía más las
relaciones entre los conceptos, y la forma en que se
referencian mediante sustantivos, verbos y adjetivos
las definiciones de los conceptos derivados en términos de
fórmulas o ecuaciones o restricciones que definen la verdad
sin que atañe al proceso, estado o evento
las normas que especifican el comportamiento, la regulación,
la gestión pública, o la política
Y su reutilización disminuye en el mismo orden. Normas
específicas de la industria, como ACORD o MISMO ARREGLO o de
XBRL, por ejemplo, detener a los 2 o 3. Formalismo lógico
dirección 4, pero rara vez se utilizan más que las reglas de
negocio. La norma SBVR, a pesar de que representa la
semántica del vocabulario y reglas de negocio, en realidad se
detiene en 4. Son las reglas son las definiciones y las
limitaciones lógicas, no las reglas de negocio que toman
medidas, dando lugar a las transiciones de estado, las
modificaciones de datos, o de otros efectos secundarios.

El uso de SBVR o, simplemente, la ontología es bastante

limitada en el BRMS de hoy / mercados de BPM. Se insiste
demasiado poco en la separación de los modelos semánticos y
los vocabularios de negocio usando la lógica y la ontología.
La mayoría de BRMS / plataformas BPM son fijos en el
comportamiento y el proceso, en lugar de la verdad y el
conocimiento.

Claro, los arquitectos empresariales inteligentes y sistemas

de analyts pueden manipular las reglas para que sean útiles
en más de una solicitud, pero este no es el resultado típico
de una aplicación de reglas de negocio. Estoy de acuerdo en
que las decisiones que encapsula dentro de los servicios es
una forma más viable de lograr la reutilización, pero que es
un resultado arquitectónico (es decir, un beneficio SOA), no
un beneficio de un repositorio de reglas.

Tengo blogs en varias ocasiones (véase la categoría de

requisitos, por ejemplo) acerca de las limitaciones de las
herramientas actuales en relación con el vocabulario, la
separación de la ontología de la aplicación y las
definiciones de la gestión y los requisitos funcionales de la
forma natural. Los actuales instrumentos de BRMS se limitan
generalmente a un caso de mentalidad, pues, que los hace
inadecuados para la gestión del conocimiento. Si-entonces
metáforas conocimiento fuerza para expresarse y organizarse
en relación a cómo se utiliza. Esto fundamentalmente y de por
sí los límites de su reutilización.

Sólo para impulsar esta casa, si usted es técnicamente

inclinado, eche un vistazo a la norma desarrollada por los
vendedores, PRR. Se hará evidente de inmediato que su
atención se centra en las reglas en el operacional, más que
el nivel de conocimientos. RIF, por el contrario, evolucionó
a partir de la lógica de la comunidad para atender las
necesidades de la web semántica. En este sentido, es mucho
más parecido a SBVR. Se compensa sus debilidades vocabulario
con mucha más fuerza ontológica y lógica. Sin embargo, RIF,
como SBVR, es más en el nivel 4 a nivel 5.

Otra manera de ver esto es que los modelos más que las reglas
son intercambiables. Se olvida que las reglas lógicas son muy
reutilizables, pero está en conformidad con la regla del
80/20. En BPM, por ejemplo, el modelo es compartida a través
de los procesos. Con la gestión de decisiones, el modelo
también debe ser compartida a través de las decisiones. La
forma más fácil de compartir a través de las normas de
decisiones son las que son verdaderas, no las que determinan
qué hacer.

En términos prácticos, poner las reglas que determinan qué

hacer en un servicio que la cuota de lo que es cierto..

GLOSARIO

Acceptance criteria
A prioritised list of criteria that the final product(s) must meet before the customer will
accept
them; a measurable definition of what must be done for the final product to be
acceptable.

Business Case
Information that describes the justification for buying the new software. It provides the
reasons (and answers the question ‘Why?’) for the project. It is updated at key points.

Process
That which must be done to bring about a particular outcome, in terms of information
to be
gathered, decisions to be made and results that must be achieved.

Project
A temporary organisation that is created for the purpose of delivering one or more
business
products according to a specified Business Case.

Quality
The totality of features and characteristics of a product or service that bear on its
ability to
satisfy stated and implied needs. Also defined as ‘fitness for purpose’ or ‘conforms to
requirements’.

Request for Change

A means of proposing a modification to the current specification of a product.

Stakeholders
Parties with an interest in the execution and outcome of a project. They would include
business streams affected by or dependent on the outcome of a project.

las reglas de negocio" tiene un significado diferente para

las empresas y de E / S profesionales. Dentro de E / S, 'las
reglas de negocio "puede
tienen connotaciones diferentes dependiendo de si la
perspectiva es "orientados a datos ',' orientados a objetos"
o
'sistema experto orientado. La elasticidad de 'reglas de
negocio es reducido aún más por los vendedores utilizando el
término en
la literatura de marketing y World-Wide Web. Sin embargo,
"las reglas de negocio" se ha convertido en una aceptada de E
/ S
palabra de moda.
La comprensión de las reglas de negocio se está extendiendo,
aunque todavía es una nueva área de enfoque. Las reglas de
negocio son
empezando a ser reconocido como un concepto distinto, la
práctica, la metodología y / o requisitos de la técnica.
Este artículo abordará varias preguntas sobre las reglas de
negocio - ¿Qué son? ¿Por qué son importantes?
¿Cómo se utilizan? Este artículo también se examinarán los
debates y de los productos en el mundo de reglas de negocio.
¿Qué es una Regla de Negocios
Una regla de negocio es "una declaración que define o
restringe algún aspecto del negocio. Su objetivo es
afirmar la estructura empresarial o para controlar o influir
en el comportamiento de la empresa "(ver referencia 1).
Cuando una declaración de reglas de negocio se produce de una
persona de negocios, sin embargo, es a menudo redactadas en
no ambigua, formas rigurosas. En tal situación, cada
declaración de reglas de negocio en realidad se pueden
descomponer
en numerosas reglas de negocio discretas.
Por ejemplo, una persona de negocios puede afirmar: "el
número total de los productos regulados se venden en un país
debe
no superen el umbral definido por los límites de
reglamentación del país de origen ". Esta afirmación es más
como un "negocio laberíntica», un término acuñado por el
experto de reglas de negocio, Barbara von Halle, experto en
reglas de negocio
y co-fundador de Knowledge Partners Inc., Mendham, la
declaración de Senderismo de negocios NJ Este "contiene
muchas reglas de negocio discretas. Hay implícita
definiciones ( 'producto regulado', 'país',); derivaciones
( «número total de ..», «umbral», «límite de la
reglamentación); los hechos (« los productos vendidos en un
país »,« los límites definidos por país
de origen »), y las limitaciones (" total "que no exceda de«
umbral »). (Véase seis categorías de reglas de negocio, la
página
xx).
Cuando se descompone a su forma más elemental, una regla de
negocio es tan atómica (indivisible) como sea posible
sin dejar de ser incluyente como para ser un pensamiento
completo. Una regla de negocio no contiene el flujo de
control
las declaraciones se encuentran típicamente en la lógica del
programa como la notificación, las actualizaciones de la base
de datos, y la secuencia (Ver
"Procesales vs declarativa", página xx). Una regla de negocio
atómica escrito en un declarativo (no de procedimiento)
, la moda en la gramática estándar utilizando un lenguaje
natural que la gente de negocios pueda entender, no es
ambigua.
Una regla de negocio es independiente del paradigma de
modelado o de la plataforma técnica. Una regla se define y
propiedad
por gente de negocios. Para resumir, reglas de negocio
son:
• declarativa (es decir, no de procedimiento);
• Atómica (indivisible, sin embargo, ambos inclusive);
• Expresado en lenguaje natural;
• distinto, independiente construcciones;
• Negocio, no la tecnología, orientado;
• Negocio, no la tecnología, la propiedad

2.Requisito funcional
2.1.1De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda

Un requisito funcional define el comportamiento interno del software: cálculos, detalles

técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los
casos de uso serán llevados a la práctica. Son complementados por los requisitos no
funcionales, que se enfocan en cambio en el diseño o la implementación.

Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los

comportamientos del sistema.

Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los

casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software
es un proceso iterativo y algunos requisitos son previos al diseño de los CU. Ambos
elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.
Un requisito funcional típico contiene un nombre y un número de serie único y un resumen.
Esta información se utiliza para ayudar al lector a entender por qué el requisito es
necesario, y para seguir al mismo durante el desarrollo del producto.

El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y
concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o
ser descubiertas por interacción con usuarios, inversores y otros expertos en la
organización.

2.2Libros [editar]

RESUMEN. Entre el análisis orientado a objetos y los

profesionales de diseño, casos de uso se han convertido en el
método preferido para la captura de los requisitos
funcionales de las aplicaciones. Prueba de ello es su
inclusión en el Grupo Unificado de Gestión de Objetos de
Lenguaje de Modelado (UML) especificación. Aunque la versión
UML 1.1 meta-modelo incluye información detallada de las
asignaciones de casos de uso para modelar otras
construcciones que aplicar estos casos de uso, la elaboración
de casos de uso para los requisitos de recogida y análisis de
dominio es ambiguo. Flujo de trabajo de la Workflow
Management Coalition es el Modelo de Referencia (WRM) No. 1.1
proporciona mucho más detalle en la definición de un flujo de
trabajo, pero en un meta-modelo menos formal. Este documento
formaliza un caso de uso enfoque centrado en facilitar la
gestión de la evolución de las arquitecturas de dominio que
sea compatible con ambos modelos. Esto se logra a través de
la integración de los tres constructos: los marcos de
adaptación, los actos de habla y de reglas de negocio. Este
enfoque crea un conjunto de formalismos de casos de uso que
proporcionan orientación semántica en la construcción de
casos de uso de alto nivel diseñado específicamente para los
participantes en actividades de análisis de dominio en lugar
de diseño arquitectónico. A través de los marcos de
adaptación, los casos de uso son evaluados desde un contexto
más amplio que considera la evolución del modelo de dominio
de apoyo. A través de los actos de habla, el contexto de los
casos de uso se ha ampliado en la segunda dimensión que
considera que el diálogo entre un actor y el sistema como
parte de un proceso más amplio de negocio. A través de
enlaces de reglas de negocio, el caso de recurrir a la
secuencia de las plantillas se abstraen de los detalles
específicos de cualquier instancia de aplicación.

PALABRAS CLAVE: Casos de Uso formalismos, Adaptive Marcos,

Speech Acts, Dominio de Arquitectura, Workflow, Business
Process Modeling, reglas de negocio, objeto de análisis y
diseño orientado, Unified Modeling Language, Workflow
Reference Model, Objetos dinámicos

1. Introducción

Unificado de El Object Management Group's Modeling Language

(UML), la versión de especificación 1.1 sugiere varios
formatos diferentes para la representación de un caso de uso
[UML97]. Aunque la forma más común de representar un caso de
uso ha sido en texto sin formato, la guía de la semántica de
UML también identifica descripciones de los casos el uso
alternativo en forma de operaciones, diagramas de actividad y
el estado de las máquinas. Otras técnicas de descripción de
comportamiento, tales como pre-y post condiciones, también
son permitidos.

Flujo de trabajo de la Workflow Management Coalition es el

Modelo de Referencia (WRM) No. 1.1 proporciona una definición
de un proceso de negocio que es muy similar a la descripción
UML de un caso de uso [Holl94] [WFMC96]. No se especifica el
formato para la definición del proceso, limitándose a afirmar
que puede ser expresada en texto, gráficos, o formal notación
del lenguaje. Sin embargo, su meta-modelo proporciona una
estructura mediante la descripción de pasos de la actividad
discreta, las normas que regulan la progresión a través de
los pasos de la actividad, y los datos que se utiliza para
determinar las transiciones.

Representaciones de texto plano de casos de uso único que

puede variar mucho en su presentación. Ejemplos de formatos
de texto se incluyen descripciones de forma libre, tabular,
de forma estructurada las plantillas, las expresiones del
lenguaje formal, y secuencias de comandos. Además de las
representaciones gráficas de las interacciones y el estado
(para la representación de diagramas de actividad y el estado
de máquinas), las estructuras de casos de uso, normas, y las
implementaciones pueden ser representados gráficamente.
Además, las formas dinámicas de casos de uso, tales como
visualizaciones, guiones gráficos y juegos de rol son
posibles. La amplia gama de formatos posible caso de uso
permite adaptar la presentación a la audiencia adecuada en
función de su finalidad y aplicabilidad a los niveles de
diversos casos el uso y la vida la etapa del ciclo [Hurl97d].
Tecnología Frame es una técnica de reutilización del software
en torno a la definición de los arquetipos y los deltas
[Bass97]. Esto es contrario al objeto de incorporar los
lenguajes orientados a la aplicación, que requieren estricto
herencia de los atributos y las operaciones de los
antepasados en su jerarquía de clases. En lugar de centrarse
en las semejanzas, los marcos de adaptación se construyen
mediante la identificación de las diferencias. Uno de los
efectos secundarios de este cambio de énfasis es la fusión de
los conceptos de herencia y la agregación en un solo
mecanismo. Dado que el UML es esencialmente nada sobre la
manera de proporcionar una representación estructural de los
casos de uso, la tecnología marco de adaptación ofrece
orientación en la formación de un enfoque coherente para la
organización de los casos de uso estructural. De acuerdo con
la semántica de UML, casos de uso son vistos como la
recogida, por supuesto, prototipo de las acciones. El
arquetipo es designado como el curso básico de acción. Los
deltas, o cursos de acción alternativos, a continuación,
pueden ser fácilmente incorporados a evolucionar el caso de
uso como el modelo de dominio de la arquitectura subyacente y
madura. De esta forma, una funcionalidad adicional, manejo de
excepciones, y los cursos de refinado de las acciones pueden
ser acomodados.

Los actos de habla se han utilizado durante más de una década

para describir los flujos de trabajo de procesos de negocio
[WF86]. Solicitar, aceptar, declarar, retirar, y afirman, son
ejemplos de actos de habla que son pertinentes para el uso de
modelado caso. Los actos de habla pueden adoptar la forma de
los mensajes que más formalmente la estructura de la
interacción entre el actor y el sistema que está siendo
modelada por los casos de uso. El modelo de ActionWorkflow
consta de un bucle de flujo de trabajo para representar a un
diálogo entre un cliente y artista intérprete o ejecutante
[MWFF92]. Para efectos de modelado de casos de uso, siendo el
modelo de los mapas de los clientes a un actor y los mapas de
artista intérprete o ejecutante en el sistema. Este proceso
de flujo de trabajo consta de cuatro fases: preparación,
negociación, ejecución, y la aceptación. En la mayoría de los
cursos de casos de uso de la acción, uno o más de estas fases
se implícita. Sin embargo, este modelo proporciona una
excelente base para delimitar entre lo que constituye un caso
de uso nuevo y lo que es más que una variante de un caso de
uso existente.

Reglas de Negocio formalizar un método para la identificación

y articulación de las normas que definen la estructura y el
control de la operación de una empresa. El UML y WRM
proporciona la capacidad para documentar las reglas de
negocio en un grado, muchas de las limitaciones con las que
opera la empresa no se han articulado y, en todo caso. La
GUÍA Reglas de Negocio del proyecto se organizó para hacer
frente a esta situación [HH95]. Este proyecto define y
describe las reglas de negocio y conceptos asociados. También
han creado un meta-modelo de reglas de negocio
construcciones. Una de las contribuciones es la
identificación de las reglas de negocio en una de cuatro
categorías: definición de un término de negocios, los hechos
relacionados unos con otros términos, las afirmaciones de la
acción en forma de restricciones y derivaciones a través de
cálculos matemáticos o inferencia. El UML establece claras
diferencias entre los modelos estructurales y de
comportamiento, pero los modelos de política no existen. A
diferencia de los modelos de comportamiento de UML y el
modelo de definición del flujo de trabajo de la WRM, reglas
de negocio no se describen los pasos a seguir para lograr la
transición de un estado a otro, o las medidas que deben
adoptarse para prohibir una transición. Una regla de negocio
es declarativa y no de procedimiento en su naturaleza. El
proyecto GUIA diferida para el trabajo futuro el objetivo de
proporcionar una base rigurosa para la ingeniería de nuevos
sistemas basados en definiciones formales o normas de
ingeniería inversa forma los sistemas existentes.

.--------------------
Las reglas de negocio
"Las reglas de negocio descripción de las operaciones, las
definiciones y restricciones que se aplican a una
organización en la consecución de sus objetivos. Estas normas
se utilizan para ayudar a la organización para alcanzar mejor
los objetivos, la comunicación entre directivos y agentes, la
comunicación entre la organización y los terceros
interesados, demostrar el cumplimiento de las obligaciones
legales, de forma más eficiente, automatizar las operaciones,
realizar análisis sobre las prácticas actuales, etc "[2]. Las
reglas de negocio puede ser visto como un conjunto de
prácticas comerciales, la definición de las implementaciones
reales - la lógica de negocio. Aplicación de la lógica de
tal, a menudo puede simplificarse mediante el uso de
herramientas especializadas - Idiomas de reglas de negocio y
los motores de reglas de negocio.

Un lenguaje de las normas es un lenguaje de dominio

específico, con construcciones para la definición de las
reglas de negocio. Estas construcciones pueden variar mucho
dependiendo de los requerimientos de negocio. El ámbito de
aplicación de las gamas posibilidad de una descripción
textual (usando una regla de lenguaje específico o Inglés
plain) para el uso de tablas de decisión o árboles de
decisión. En algunos casos, también es posible determinar la
secuencia gráfica de la ejecución de las reglas de negocio
usando un flujo de regla. La última es a menudo la causa de
la confusión entre los procesos de negocio y reglas de
negocio. A pesar de que parecen similares, los flujos de
procesos de negocio son la definición de la secuencia de
ejecución de los servicios que puede correr a través de
muchos sistemas diferentes y heterogéneas. Por otra parte,
los flujos de reglas de negocio se limita a la orquestación
de la secuencia de las normas de ejecución.

Las reglas de negocio de motores de evaluación de las normas

de apoyo expresado en un lenguaje de la correspondiente
normativa. Su función principal es la gestión de una
colección de hechos y evaluar los grupos de reglas consta de
uno de los predicados de varios. Tratar con un gran número de
hechos y de manera eficiente la evaluación de los predicados
es uno de los retos clave de la evaluación de la regla.

Sobre la base de reglas de negocio de las definiciones,

expresado en el lenguaje de reglas de negocio, los motores de
reglas de negocio suelen ofrecer algún tipo de mecanismo de
asignación a generar código de ejecución más bajo nivel - por
lo general las clases de lenguaje de propósito general. Estas
clases se pueden utilizar como una aplicación parcial de un
mayor componente de negocios. Una consecuencia inmediata de
este enfoque es que el ciclo de vida de las reglas de negocio
"la aplicación está en consonancia con el ciclo de vida del
componente de negocio a la que pertenecen.

La flexibilidad y modificabilidad de las implementaciones de

reglas de negocio se consigue mediante el apoyo a las normas
de mantenimiento que permite cambios dinámicos (usando el
idioma original, las reglas). Esta capacidad ofrece una forma
cómoda de modificar dinámicamente las reglas de negocio, sin
la reconstrucción y la redistribución de la aplicación para
adaptarse rápidamente a los cambios del entorno de negocio.

La programación declarativa (es decir, lo que la

prescripción) representa el paradigma de la elección de las
normas: algo se ha disparado (es decir, una acción) en
función de si una norma se evalúa como verdadero o falso. El
flujo de control (es decir, la secuencia de estas
invocaciones) es implícito y emerge como el fuego fuera de
las normas.

RESUMEN. Entre el análisis orientado a objetos y los

profesionales de diseño, casos de uso se han convertido en el
método preferido para la captura de los requisitos
funcionales de las aplicaciones. Prueba de ello es su
inclusión en el Grupo Unificado de Gestión de Objetos de
Lenguaje de Modelado (UML) especificación. Aunque la versión
UML 1.1 meta-modelo incluye información detallada de las
asignaciones de casos de uso para modelar otras
construcciones que aplicar estos casos de uso, la elaboración
de casos de uso para los requisitos de recogida y análisis de
dominio es ambiguo. Flujo de trabajo de la Workflow
Management Coalition es el Modelo de Referencia (WRM) No. 1.1
proporciona mucho más detalle en la definición de un flujo de
trabajo, pero en un meta-modelo menos formal. Este documento
formaliza un caso de uso enfoque centrado en facilitar la
gestión de la evolución de las arquitecturas de dominio que
sea compatible con ambos modelos. Esto se logra a través de
la integración de los tres constructos: los marcos de
adaptación, los actos de habla y de reglas de negocio. Este
enfoque crea un conjunto de formalismos de casos de uso que
proporcionan orientación semántica en la construcción de
casos de uso de alto nivel diseñado específicamente para los
participantes en actividades de análisis de dominio en lugar
de diseño arquitectónico. A través de los marcos de
adaptación, los casos de uso son evaluados desde un contexto
más amplio que considera la evolución del modelo de dominio
de apoyo. A través de los actos de habla, el contexto de los
casos de uso se ha ampliado en la segunda dimensión que
considera que el diálogo entre un actor y el sistema como
parte de un proceso más amplio de negocio. A través de
enlaces de reglas de negocio, el caso de recurrir a la
secuencia de las plantillas se abstraen de los detalles
específicos de cualquier instancia de aplicación.

PALABRAS CLAVE: Casos de Uso formalismos, Adaptive Marcos,

Speech Acts, Dominio de Arquitectura, Workflow, Business
Process Modeling, reglas de negocio, objeto de análisis y
diseño orientado, Unified Modeling Language, Workflow
Reference Model, Objetos dinámicos

1. Introducción
Unificado de El Object Management Group's Modeling Language
(UML), la versión de especificación 1.1 sugiere varios
formatos diferentes para la representación de un caso de uso
[UML97]. Aunque la forma más común de representar un caso de
uso ha sido en texto sin formato, la guía de la semántica de
UML también identifica descripciones de los casos el uso
alternativo en forma de operaciones, diagramas de actividad y
el estado de las máquinas. Otras técnicas de descripción de
comportamiento, tales como pre-y post condiciones, también
son permitidos.

Flujo de trabajo de la Workflow Management Coalition es el

Modelo de Referencia (WRM) No. 1.1 proporciona una definición
de un proceso de negocio que es muy similar a la descripción
UML de un caso de uso [Holl94] [WFMC96]. No se especifica el
formato para la definición del proceso, limitándose a afirmar
que puede ser expresada en texto, gráficos, o formal notación
del lenguaje. Sin embargo, su meta-modelo proporciona una
estructura mediante la descripción de pasos de la actividad
discreta, las normas que regulan la progresión a través de
los pasos de la actividad, y los datos que se utiliza para
determinar las transiciones.

Representaciones de texto plano de casos de uso único que

puede variar mucho en su presentación. Ejemplos de formatos
de texto se incluyen descripciones de forma libre, tabular,
de forma estructurada las plantillas, las expresiones del
lenguaje formal, y secuencias de comandos. Además de las
representaciones gráficas de las interacciones y el estado
(para la representación de diagramas de actividad y el estado
de máquinas), las estructuras de casos de uso, normas, y las
implementaciones pueden ser representados gráficamente.
Además, las formas dinámicas de casos de uso, tales como
visualizaciones, guiones gráficos y juegos de rol son
posibles. La amplia gama de formatos posible caso de uso
permite adaptar la presentación a la audiencia adecuada en
función de su finalidad y aplicabilidad a los niveles de
diversos casos el uso y la vida la etapa del ciclo [Hurl97d].

Tecnología Frame es una técnica de reutilización del software

en torno a la definición de los arquetipos y los deltas
[Bass97]. Esto es contrario al objeto de incorporar los
lenguajes orientados a la aplicación, que requieren estricto
herencia de los atributos y las operaciones de los
antepasados en su jerarquía de clases. En lugar de centrarse
en las semejanzas, los marcos de adaptación se construyen
mediante la identificación de las diferencias. Uno de los
efectos secundarios de este cambio de énfasis es la fusión de
los conceptos de herencia y la agregación en un solo
mecanismo. Dado que el UML es esencialmente nada sobre la
manera de proporcionar una representación estructural de los
casos de uso, la tecnología marco de adaptación ofrece
orientación en la formación de un enfoque coherente para la
organización de los casos de uso estructural. De acuerdo con
la semántica de UML, casos de uso son vistos como la
recogida, por supuesto, prototipo de las acciones. El
arquetipo es designado como el curso básico de acción. Los
deltas, o cursos de acción alternativos, a continuación,
pueden ser fácilmente incorporados a evolucionar el caso de
uso como el modelo de dominio de la arquitectura subyacente y
madura. De esta forma, una funcionalidad adicional, manejo de
excepciones, y los cursos de refinado de las acciones pueden
ser acomodados.

Los actos de habla se han utilizado durante más de una década

para describir los flujos de trabajo de procesos de negocio
[WF86]. Solicitar, aceptar, declarar, retirar, y afirman, son
ejemplos de actos de habla que son pertinentes para el uso de
modelado caso. Los actos de habla pueden adoptar la forma de
los mensajes que más formalmente la estructura de la
interacción entre el actor y el sistema que está siendo
modelada por los casos de uso. El modelo de ActionWorkflow
consta de un bucle de flujo de trabajo para representar a un
diálogo entre un cliente y artista intérprete o ejecutante
[MWFF92]. Para efectos de modelado de casos de uso, siendo el
modelo de los mapas de los clientes a un actor y los mapas de
artista intérprete o ejecutante en el sistema. Este proceso
de flujo de trabajo consta de cuatro fases: preparación,
negociación, ejecución, y la aceptación. En la mayoría de los
cursos de casos de uso de la acción, uno o más de estas fases
se implícita. Sin embargo, este modelo proporciona una
excelente base para delimitar entre lo que constituye un caso
de uso nuevo y lo que es más que una variante de un caso de
uso existente.

Reglas de Negocio formalizar un método para la identificación

y articulación de las normas que definen la estructura y el
control de la operación de una empresa. El UML y WRM
proporciona la capacidad para documentar las reglas de
negocio en un grado, muchas de las limitaciones con las que
opera la empresa no se han articulado y, en todo caso. La
GUÍA Reglas de Negocio del proyecto se organizó para hacer
frente a esta situación [HH95]. Este proyecto define y
describe las reglas de negocio y conceptos asociados. También
han creado un meta-modelo de reglas de negocio
construcciones. Una de las contribuciones es la
identificación de las reglas de negocio en una de cuatro
categorías: definición de un término de negocios, los hechos
relacionados unos con otros términos, las afirmaciones de la
acción en forma de restricciones y derivaciones a través de
cálculos matemáticos o inferencia. El UML establece claras
diferencias entre los modelos estructurales y de
comportamiento, pero los modelos de política no existen. A
diferencia de los modelos de comportamiento de UML y el
modelo de definición del flujo de trabajo de la WRM, reglas
de negocio no se describen los pasos a seguir para lograr la
transición de un estado a otro, o las medidas que deben
adoptarse para prohibir una transición. Una regla de negocio
es declarativa y no de procedimiento en su naturaleza. El
proyecto GUIA diferida para el trabajo futuro el objetivo de
proporcionar una base rigurosa para la ingeniería de nuevos
sistemas basados en definiciones formales o normas de
ingeniería inversa forma los sistemas existentes.

-----------------------..
Diccionario

Definición de Diagrama de Proceso

Es una representación gráfica de los pasos que se siguen en toda una secuencia de
actividades, dentro de un proceso o un procedimiento, identificándolos mediante símbolos de
acuerdo con su naturaleza; incluye, además, toda la información que se considera necesaria para
el análisis, tal como distancias recorridas, cantidad considerada y tiempo requerido. Con fines
analíticos y como ayuda para descubrir y eliminar ineficiencias, es conveniente clasificar las
acciones que tienen lugar durante un proceso dado en cinco clasificaciones. Estas se conocen bajo
los términos de operaciones, transportes, inspecciones, retrasos o demoras y almacenajes. Las
siguientes definiciones en la tabla 5.1, cubren el significado de estas clasificaciones en la mayoría
de las condiciones encontradas en los trabajos de diagramado de procesos.

Es una representación gráfica de los pasos que se siguen en toda una secuencia de actividades, dentro
de un proceso o un procedimiento, identificándolos mediante símbolos de acuerdo con su naturaleza;
incluye, además, toda la información que se considera necesaria para el análisis, tal como distancias
recorridas, cantidad considerada y tiempo requerido.
Con fines analíticos y como ayuda para descubrir y eliminar ineficiencias, es conveniente clasificar las
acciones que tienen lugar durante un proceso dado en cinco clasificaciones. Estas se conocen bajo los
términos de operaciones, transportes, inspecciones, retrasos o demoras y almacenajes.

--------------------.,-.--------------------
En este artículo, podrás diseñar un marco de reglas de
negocio usando Java y XML. Usted aprenderá lo que constituye
un buen marco de las normas de diseño de negocio y pasar un
ejemplo que muestra cómo utilizar el marco.

Características de un marco de reglas de negocios

El diccionario declara que una regla de negocio es "un
conjunto de reglas para el ingreso de datos en una base de
datos que son específicos de los métodos de una empresa de
llevar a cabo sus operaciones". Esta definición es muy
exacta. Pero en el mundo real, todo el mundo tiene su propia
definición de una regla de negocio. Le garantizo que cada
arquitecto de software se adhiere a su versión propia más de
la definición. Así que, ¿cuál es entonces una regla de
negocio? Algunos dicen que una condición que requiere la
modificación de una base de datos es una regla de negocio.
Otros dicen que una regla de negocio puede ser cualquier
condición parámetros. Por lo tanto, necesita asegurarse de
que su marco de reglas de negocio está diseñado para ser lo
suficientemente flexible como para soportar cualquier tipo de
definición de reglas de negocio. Para el marco de la
adaptabilidad, es necesario para abarcar estas tres
características principales:

Debe adherirse a diseño orientado a objetos.

Debe ser lo suficientemente adaptables a cualquier tipo de
aplicación de una regla de negocio, ya sea una simple
declaración de una línea si la empresa o de un proceso muy
complejo.
Debe ser centralizado. Usted quiere asegurarse de que sus
reglas se definen en el mismo lugar y se invocan en la misma
forma.
Diseño e Implementación del Marco de Reglas de Negocio
Su marco de reglas de negocio utilizará XML basado en las
propiedades del archivo que se definen los grupos de reglas
de negocio. Cada grupo de reglas de negocio define una lista
de reglas de negocio. Cada regla de negocio contiene un
nombre de clase que se aplica la regla y una lista de
parámetros (ver Figura 1).

C:\Documents and
Settings\All Users\Documents\Define Business Rules - Task Guidelines.doc

Dominios

Es una buena práctica de asignar un dominio a cada atributo.

Un dominio es una regla de validación de un atributo.
Establece un contexto. Puede consistir en una lista de
valores, una serie, o una expresión de algún tipo. Un dominio
también puede ser usado para especificar un formato estándar.
Esto es conveniente, porque una vez que una regla de
validación se ha definido, se puede aplicar fácilmente a
muchos atributos. También añade la disciplina para el proceso
de atribución, ya que requiere que el analista para analizar
cuidadosamente justo lo que el atributo significa.

Además, muchos campos son en realidad ... como se especifica

los tipos de entidad TIPO. Si bien la definición de estos
tipos de entidades como tablas de suma flexibilidad y
robustez al sistema final, los valores deben determinarse por
adelantado. Orden de trabajo TIPO, INFORMES relación de tipo,
etcétera, son efectivamente los dominios, y es tarea del
analista para proporcionar al menos un conjunto inicial de
valores para estos.

Factores Clave de Éxito para los Requerimientos del Negocio

1. No pasa nada si los usuarios no conocen todas las
respuestas. En la medida en que sabemos lo que no sabemos
y puede limitar el impacto de estas imperfecciones en otras
áreas de la SDLC.
2. Un resultado válido de una asignación de requisitos de
negocio es darse cuenta de que un proyecto es simplemente
no está listo para avanzar. Es mejor para determinar este
valor de 50.000 dólares, que con 500.000 dólares.
3. Podemos tener 6 pulgadas de la documentación - Mientras no
nos tomó 6 años para obtener
y la referencia no es fácil de usar.
4. Separe siempre "qué" debe hacer el sistema (se trata de
requisitos de negocio) de "cómo" se
hará esto (este es el diseño técnico).
5. Todo lo que se cristalizan.
6. Asegúrese de que el plan interdepartamental en primer
lugar cuando se realiza la extracción de requisitos.
Sin antes trabajar en cómo los procesos de cruzar las
fronteras en un formato comparable, el
contenido es stovepiped e inutilizable.
7. Anular niveles de eliminación de contenido de la
información y de calidad

---------------gfsdgf
Desde los últimos años, las organizaciones tratan de
desarrollar sus sistemas de software con casos de uso
impulsada y objeto de procesos orientados al desarrollo. Esta
práctica no les permite sincronizar sus TI con sus objetivos
de negocio y las normas con el fin de reaccionar a los
cambios de manera rápida y coherente.

Tres razones principales se encuentran en la base del negocio

y de TI superar el fracaso.

En el caso de utilizar el desarrollo impulsado por:

expertos de las empresas no pueden mejorar las actividades de

sus procesos de negocio que se mantiene independiente de los
usuarios finales las interacciones con el sistema, porque las
reglas de negocio que rigen estos procesos se mezclan con el
actor y las interacciones del sistema dentro de casos de uso,

los usuarios finales no pueden utilizar el sistema de acuerdo

a sus responsabilidades a cambiar cuando los objetivos de
negocio o sus disposiciones de apoyo a evolucionar, ni un
enfoque preciso en sus escenarios de uso hasta la definición
detallada de sus pantallas, ya que debe hacer,
componentes de software no puede ser fácilmente adaptado a
los cambios de los requisitos de negocio debido a la relación
1 a N, la trazabilidad entre sus representaciones de objetos
funcionales y orientados.

Fsd-fasd------------------------

Desde los últimos años, las organizaciones tratan de

desarrollar sus sistemas de software con casos de uso
impulsada y objeto de procesos orientados al desarrollo. Esta
práctica no les permite sincronizar sus TI con sus objetivos
de negocio y las normas con el fin de reaccionar a los
cambios de manera rápida y coherente.

Tres razones principales se encuentran en la base del negocio

y de TI superar el fracaso.

En el caso de utilizar el desarrollo impulsado por:

expertos de las empresas no pueden mejorar las actividades de

sus procesos de negocio que se mantiene independiente de los
usuarios finales las interacciones con el sistema, porque las
reglas de negocio que rigen estos procesos se mezclan con el
actor y las interacciones del sistema dentro de casos de uso,

los usuarios finales no pueden utilizar el sistema de acuerdo

a sus responsabilidades a cambiar cuando los objetivos de
negocio o sus disposiciones de apoyo a evolucionar, ni un
enfoque preciso en sus escenarios de uso hasta la definición
detallada de sus pantallas, ya que debe hacer,
componentes de software no puede ser fácilmente adaptado a
los cambios de los requisitos de negocio debido a la relación
1 a N, la trazabilidad entre sus representaciones de objetos
funcionales y orientados.

Esta falta de visibilidad directa de las normas y la falta de

trazabilidad hasta que sus implementaciones de software son
obstáculos importantes para la alineación de las
implementaciones de TI con las estrategias de cambio y las
reglas de negocio relacionadas. Como consecuencia de ello, el
esfuerzo importante de mantenimiento es necesario para
adaptar las aplicaciones a los cambios.

Por las mismas razones, los enfoques SOA emergentes que

tratan de determinar los servicios sobre la base de casos de
uso sufren de los problemas misma agilidad.

A fin de permitir a las organizaciones a aumentar su agilidad

en los negocios, las reglas de negocio primero debe ser
capturados por separado de actor y las interacciones del
sistema que son necesarios para realizarlos. En segundo
lugar, tanto los requisitos de negocio y las limitaciones de
uso de los usuarios finales debe ser rastreado por separado
en su aplicación de software, respectivamente, en los
servicios de software y casos de aplicación.

El uso de este BMM-SOA proceso de transición, los interesados

pueden modelar los objetivos de negocio de su organización,
sus sistemas subyacentes, así como las normas que tienen que
apoyar estos objetivos como se indica en el modelo de
motivación empresarial (BMM). Después de entonces, estas
estructuras empresariales están directamente de puente a los
servicios de SOA, con el fin de adaptar las aplicaciones a
los cambios de manera rápida y coherente.

Así, la meta-Driven SOA Proceso de Desarrollo (GD-SOA) tiene

por objeto ayudar a las organizaciones a mejorar
continuamente sus procesos de negocio con el fin de aumentar
su agilidad en los negocios sin preocuparse por la adaptación
de sus aplicaciones de TI. De esta manera, los expertos de
negocio se centran en la mejora de su negocio mediante la
descripción de los comportamientos con mayor precisión los
procesos de negocio de sus sistemas, a su nivel propio
negocio, al final whilest usuarios del sistema pueden
concentrar sus esfuerzos en la especificación precisa de sus
interfaces de usuario al interactuar con los servicios de SOA
resultante.

Como parte de la GD-SOA, el Modelo de Negocios Motivación

Diagrama (BMM) que se hace referencia en la figura 1 muestra
las relaciones útiles con el fin de validar el plan de
negocios y ejecución de negocios sobre la base de los
objetivos de negocio y sus estructuras subyacentes. Sus
elementos básicos que se consideran como primarias por el GD
proceso de SOA se indican mediante los círculos de trazos.

Como se muestra en la figura, los objetivos de negocio como

parte de los extremos de la unidad de los cursos de acciones
(estrategia y táctica), las directivas (normas y políticas)
hasta procesos de negocio.
EJEMPLO

Organizaciones que gestionan sus políticas y reglas de

negocio como parte de la Administración y el funcionamiento
de su organización y / o especificar sus productos y
servicios, desea delegar la ejecución y aplicación de una
parte significativa de sus normas a los sistemas de
información.

El intercambio de las normas en este caso de uso, y el

vocabulario (términos y hechos) en términos de que las reglas
se formulan, tiene lugar entre dos clases de normas de
sistemas:

Reglas de los sistemas de transferencia de apoyo de

orientación humana Reglamento de Reglas de Negocio de
Sistemas de Apoyo a las empresas de comunicación Reglas
sistemas de edición, es decir la regla que la especificación
de apoyo, análisis, verificación y validación de las normas
en términos de negocio utilizando el lenguaje natural
controlados apuntalado por la lógica formal

Reglas para el diseño de los sistemas y / o de funcionamiento

de Sistemas de Información regla es decir, habilitado para
los entornos de TI para el desarrollo de aplicaciones, y / o
componentes del sistema de Estado de los sistemas de TI que
apoyan los procesos de negocio de la organización.

http://www.w3.org/2005/rules/wg/wiki/Rule-
based_Service_Level_Agreements_%28SLA%29_and_Web_Services

El Manifesto de Reglas de Negocio

[Man03](BRG Business Rules Manifesto) es-
tablece algunos aspectos importantes de las reglas
de negocio a tener en cuenta desde el punto de
vista de los usuarios:
Las reglas de negocio deben expresarse sepa-
radamente de los procesos de negocio.
Las reglas de negocio deben expresarse en for-
ma declarativa y no buscar formalismos pro-
cedurales.
Las reglas de negocio deben expresarse en for-
malismos que sean f¶acilmente comprensibles
por la "gente de negocios", comprensibles sin
conocimientos de programaci¶on o de lengua-
jes de programaci¶on.
Requisitos de software y reglas de negocio - Definiciones Así
que, ¿cuáles son los requisitos de software? De acuerdo a los
"requisitos de software Wikipedia.org ': Describir el
comportamiento del sistema de software a desarrollar
comprenden diversos tipos de casos de uso que describen todas
las interacciones del usuario con el sistema de software
no incluir los requisitos funcionales como calidad,
rendimiento, restricciones de diseño, etc desarrolladores de
software y arquitectos utilizar estos requisitos como insumos
para el diseño y desarrollo de actividades. Las reglas de
negocio por otro lado describir o representar las
restricciones sobre el comportamiento de la empresa. Las
reglas de negocio comprenden la lógica de negocio principal
de cada organización, orientar y controlar todos los procesos
empresariales básicos que forman la columna vertebral de
cualquier transacción comercial. Cuando se trabaja con los
desarrolladores de reglas de negocio tienen que tener en
cuenta que dichas normas son inherentes: cartas
Corporativo Las prácticas de gestión y de las fuerzas de
reglamentación Gestión de recursos humanos Estrategias
de Marketing Políticas de precios Productos y servicios
ofertas de prácticas de la relación cliente Las reglas de
negocio son la componente más dinámico de cualquier
aplicación. Por lo tanto, su identificación constante y
correcta, y mejorar la adaptabilidad de la externalización de
la organización a los cambios de la industria y la
competencia.
----------------------------------srthrt

La GUÍA Reglas de Negocio del proyecto se ha organizado con

cuatro objetivos específicos:

Para definir y describir las reglas de negocio y conceptos

asociados, lo que permite la determinación de lo que es, y no
es una regla de negocio.
Para definir un modelo conceptual de las reglas de negocio a
fin de expresar (en términos comprensibles para los
profesionales de tecnología de la información), lo que es una
regla de negocio es y cómo se aplica a los sistemas de
información.
Para proporcionar una base rigurosa de normas de ingeniería
inversa de los sistemas existentes.
Para proporcionar una base rigurosa para la ingeniería de
nuevos sistemas basados en definiciones formales de reglas de
negocio.
Los dos primeros objetivos se han cumplido, y los resultados
se presentan en este documento. El proyecto se articula lo
que constituye una regla de negocio y qué pasa con la norma
debe ser capturado y descrito. Los debates que condujeron a
este punto han proporcionado las bases para los dos últimos
objetivos, pero queda mucho trabajo por hacer en estas áreas.

ELEMENTOS GÏA

Elements of Guidance

What is an Element of guidance? According to SVBR it is:

a “directive that is actionable, whose purpose is to advise or inform with a goal of

resolving a problem or difficulty, especially as given by someone in authority”.
where
Directive is a “means that defines or constrains some aspect of an enterprise”
and
“‘Actionable’ means that a person who knows about the directive could observe a relevant
situation (including his or her own behavior) and decide directly whether or not the
business was complying with the directive.”

and according to SPEM2 it is:

“Guidance is a Process Element that provides additional information related to process

elements such as Roles, Activities, and Work Products. The particular Guidance is
classified with a guidance kind that indicates a specific type of guidance....”

Here is a list of key Elements of Guidance

Checklist A Checklist is a specific type of guidance that identifies a series of items that
need to be completed or verified. Checklists are often used in reviews such as walkthroughs
or inspections.

Concept A Concept is a specific type of guidance that outlines key ideas associated with
basic principles underlying the referenced item. Concepts normally address more general
topics than Guidelines and span across several work product and/or activities.

Estimate (metric kind) An Estimate is a specific type of Guidance that provides sizing
measures, or standards for sizing the work effort associated with performing a particular
piece of work and instructions for their successful use. It may be comprised of estimation
considerations and estimation metrics.
Estimation Considerations (metric kind) Estimation Considerations qualify the usage
and application of estimation metrics in the development of an actual estimate.

Estimating Metric (metric kind) Estimation Metric describes a metric or measure that is
associated with an element and which is used to calculate the size of the work effort as well
as a range of potential labor.

Example An Example is a specific type of Guidance that represents a typical, partially

completed, sample instance of one or more work products or scenario like descriptions of
how Task may be performed. Examples can be related to Work Products as well as Tasks
that produce them as well as any other Content Element.

Guideline A Guideline is a specific type of guidance that provides additional detail on how
to perform a particular activity or grouping of activities (e.g. grouped together as iterations)
or that provides additional detail, rules, and recommendations on work products and their
properties. Amongst others, it can include details about best practices and different
approaches for doing work, how to use particular types of work products, information on
different subtypes and variants of the work product and how they evolve throughout a
lifecycle, discussions on skills the performing roles should acquire or improve upon,
measurements for progress and maturity, etc.

Practice A Practice represents a proven way or strategy of doing work to achieve a goal
that has a positive impact on work product or process quality. Practices are defined
orthogonal to methods and processes. They could summarize aspects that impact many
different parts of a method or specific processes. Examples for practices would be "Manage
Risks", "Continuously verify quality", "Architecture-centric and component-based
development", etc.

Report A Report is a predefined template of a result that is generated on the basis of other
work products as an output from some form of tool automation. An example for a report
would be a use case model survey, which is generated by extracting diagram information
from a graphical model and textual information from documents and combines these two
types of information into a report.

Reusable Asset A Reusable Asset provides a solution to a problem for a given context. The
asset may have a variability point, which is a location in the asset that may have a value
provided or customized by the asset consumer. The asset has rules for usage which are the
instructions describing how the asset should be used.

Roadmap A Roadmap is a special Guidance Kind which is only related to Activates. A

Roadmap represents a linear walkthrough of a Process. An instance of a Roadmap
represents important documentation for the Activity or Process it is related to. Often a
complex Activity such as a Process can be much easier understood by providing a
walkthrough with a linear thread of a typical instantiation of this Activity. In addition to
making the process practitioner understand how work in the process is being performed, a
Roadmap provides additional information about how Activities and Tasks relate to each
other over time. Roadmaps are also used to show how specific aspects are distributed over a
whole process providing a kind of filter on the process for this information.

Supporting Material Supporting Materials is catch all for other types of guidance not
specifically defined elsewhere. It can be related to all kinds of Process Elements, i.e.
including other guidance elements.

Template A Template is a specific type of guidance that provides for a work product a
predefined table of contents, sections, packages, and/or headings, a standardized format, as
well as descriptions how the sections and packages are supposed to be used and completed.
Templates cannot only be provided for documents, but also for conceptual models or
physical data stores.

Term Definition Term Definitions define concepts and are used to build up the Glossary.
They are not directly related to Process Elements, but their relationship is being derived
when the Term is used in the Process Elements description text.

Tool Mentor A Tool Mentor is a specific type of guidance that shows how to use a specific
tool to accomplish some piece of work a Work Product either in the context of or
independent from an Activity.

Whitepaper Whitepapers are a special Concept guidance that has been externally reviewed
or published and can be read and understood in isolation of other process elements and
guidance.

Elementos de la Orientación

¿Qué es un elemento de orientación? Según SVBR es:

una directiva que es susceptible de recurso, cuya finalidad

es asesorar o informar con el objetivo de resolver un
problema o dificultad, sobre todo dada por alguien con
autoridad ".
dónde
Directiva es un "medio que define o restringe algún aspecto
de una empresa"
y
" 'Medios de recurso de que una persona que sabe acerca de la
Directiva puede observar una situación de referencia
(incluida su propia conducta) y decidir directamente si la
empresa cumple con la directiva".

y de acuerdo con SPEM2 es:

"Orientación es un elemento del proceso que proporciona

información adicional relacionada con los elementos del
proceso tales como las funciones, actividades y productos de
trabajo. Orientación particular se clasifica con un tipo de
orientación que indica un tipo específico de orientación
...."

Aquí está una lista de los elementos clave de la orientación

Lista de verificación de una lista de comprobación de un tipo

específico de orientación que identifica una serie de
elementos que deben ser realizadas o verificadas. Listas de
verificación se utilizan a menudo en revistas como tutoriales
o inspecciones.

A Concept Concept es un tipo específico de orientación que

describe las ideas clave asociadas con los principios básicos
del punto de referencia. Conceptos que normalmente tratan de
temas más generales que las Directrices y extenderse a lo
largo de varios productos de trabajo y / o actividades.

Estimación (tipo métricas) una estimación es un tipo

específico de orientación que proporciona el tamaño de
medidas o normas para determinar el tamaño del esfuerzo de
trabajo relacionados con la realización de una determinada
pieza de trabajo y las instrucciones para su uso con éxito.
Puede estar compuesto por consideraciones de estimación y
métricas de estimación.

Consideraciones de estimación (tipo métricas) Consideraciones

Estimación calificar el uso y aplicación de métricas de
estimación en el desarrollo de una estimación real.

La estimación de métricas (tipo métricas) Estimación Métrica

describe una métrica o medida que se asocia con un elemento y
que se utiliza para calcular el tamaño del esfuerzo de
trabajo, así como una serie de mano de obra potencial.

Ejemplo Un ejemplo es un tipo específico de orientación que

representa un típico, parcialmente construida, ejemplo de
muestra de uno o más productos de trabajo o de una situación
como la descripción de la forma de tarea se puede realizar.
Algunos ejemplos son los relacionados con productos de
trabajo, así como las tareas que los producen, así como
cualquier otro elemento de contenido.

Una guía directriz es un tipo específico de orientación que

proporciona detalles adicionales sobre cómo realizar una
determinada actividad o grupo de actividades (por ejemplo, el
grupo formado por iteraciones), o que proporciona detalles
adicionales, normas y recomendaciones sobre productos de
trabajo y sus propiedades. Entre otros, puede incluir
información sobre las mejores prácticas y enfoques diferentes
para hacer el trabajo, cómo usar determinados tipos de
productos de trabajo, información sobre diferentes subtipos y
variantes del producto del trabajo y su evolución a través de
un ciclo de vida, los debates sobre las habilidades del
desempeño de roles debe adquirir o mejorar, las mediciones
para el progreso y la madurez, etc

Una práctica práctica representa una forma comprobada o la

estrategia de hacer el trabajo para lograr un objetivo que
tiene un impacto positivo sobre el producto del trabajo o la
calidad del proceso. Prácticas se definen ortogonal a los
métodos y procesos. Se podría resumir los aspectos que muchas
piezas de diferente impacto de un método o procesos
específicos. Ejemplos de prácticas sería "Administrar los
riesgos", "continua de verificar la calidad", "Arquitectura
de desarrollo basado en componentes y céntrica", etc

Informe de un informe es una plantilla predefinida de un

resultado que se genera sobre la base de otros productos de
trabajo como una salida de algún tipo de herramienta de
automatización. Un ejemplo de un informe sería un caso modelo
de encuesta sobre el empleo, que se genera al extraer
información de diagrama de un modelo gráfico y la información
textual de los documentos y combina estos dos tipos de
información en un informe.

Reutilizables activo A reutilizables de activos ofrece una

solución a un problema en un contexto dado. El activo puede
tener un punto de variabilidad, que es un lugar en el activo
que puede tener un valor proporcionado o adaptados por el
consumidor de bienes. El bien tiene reglas para el uso que
son las instrucciones que describen cómo los activos deben
ser utilizados.

Plan de trabajo Hoja de Ruta es un tipo especial de

orientación que sólo está relacionado con Activa. Un plan de
trabajo representa un recorrido lineal de un proceso. Una
instancia de un plan de trabajo representa la documentación
importante para la actividad o proceso que está relacionado.
A menudo, una actividad compleja, como un proceso puede ser
mucho más fácil de entender, proporcionando una guía con un
hilo lineal de una ejemplificación típica de esta actividad.
Además de hacer que el profesional proceso de entender cómo
el trabajo en el proceso se está realizando un plan de
trabajo proporciona información adicional acerca de cómo las
actividades y tareas se relacionan entre sí con el tiempo.
Planes de trabajo también se utilizan para mostrar los
aspectos específicos de cómo se distribuyen por todo un
proceso creando una especie de filtro en el proceso de esta
información.

Material de apoyo de Materiales de Apoyo es la captura de

todos los otros tipos de orientación no está definida
específicamente en otra parte. Puede estar relacionado con
todo tipo de elementos de proceso, es decir, incluidos los
elementos de orientación de otros.

Plantilla Una plantilla es un tipo específico de orientación

que proporciona un producto de trabajo de una tabla
predefinida de los contenidos, secciones, paquetes y / o
partidas, con un formato estandarizado, así como
descripciones de cómo las secciones y los paquetes que se
supone que deben utilizarse y completado . Las plantillas no
sólo pueden ser prestados para los documentos, sino también
para los modelos conceptuales o datos físicos tiendas.

Definiciones de términos Término Definición definir conceptos

y se utilizan para construir el Glosario. Ellos no están
directamente relacionados con los elementos del proceso, pero
su relación se deriva que el término se utiliza en el texto
de la descripción de los elementos del proceso.

Herramienta de Mentor una herramienta de Mentor es un tipo

específico de orientación que se muestra cómo utilizar una
herramienta específica para llevar a cabo algún trabajo un
producto de trabajo, ya sea en el contexto de independencia o
de una actividad.

Whitepapers Libro blanco son un concepto especial de

orientación que ha sido revisado o publicado en el exterior y
pueden ser leídos y entendidos de manera aislada de otros
elementos del proceso y la orientación.

Rferencias bibliograficas

XYZ 1
9. D. Rosca, S. Greenspan, C. Wild, H. Reubenstein, K. y M.
Maly Feblowitz. La aplicación de un mecanismo de apoyo a las
decisiones a las reglas de negocio Lifecycle10th Knowledge-
Based Software Engineering Conference (KBSE95), Boston, MA
(1995) 9],

XYZ2 H. Herbst, Business Rule Oriented Conceptual Modelling, PhD Thesis, Physica-
Verlag, 1996.

Xyz 3 Frederick P. Brooks, 1987]

REF xxyz 4

Ref 5 http://www.w3c.es/prensa/2005/nota050427_RuleLanguage
Reglas de Negocio y el Proceso Racional
Periódicamente me preguntan por poner las reglas de negocio en el Proceso Racional
Unificado o RUP. RUP y el Proceso Unificado de empresa están diseñados para aplicar
UML y las mejores prácticas de una manera formal. , Formalmente no administrar las
reglas de negocio, pero los considera parte de los casos de uso o de los requisitos. Para
el diseño de servicios de decisión con éxito, usted necesita para administrar las reglas
de negocio de forma más coherente. RUP establece seis mejores prácticas que las
reglas de negocio realmente de apoyo:

Desarrollar software iterativamente

Mediante el diseño de servicios de decisión para encapsular sus reglas de negocio y la
gestión de dichas normas como elementos atómicos, se puede desarrollar y probar las
reglas de negocio independiente de otros componentes de software. Esta capacidad
para iterar continúa en "tiempo de cambio" una vez que el software se implementa
gracias a las capacidades regla de mantenimiento de la mayoría de los sistemas de
gestión de reglas de negocio.
Verificar continuamente la calidad del software
Las reglas de negocio son fáciles de verificar, ya que están cerca de la empresa. Las
normas de gestión fomenta un control constante y esto mejora la calidad del software.
Los usuarios de negocio realmente pueden darle sugerencias acerca de las normas de
una manera que nunca podría hacer con el código.
Controlar los cambios al software
Sistemas tradicionales de software puede ser "frágil" - los pequeños cambios pueden
romper. Los servicios de decisión construido con las normas de usiness se espera que
el cambio y se puede actualizar de forma individual, incluso en entornos 24x7.
Gestionar los requisitos
Aunque las normas comerciales no deben ser gestionados como los requisitos, deben
ser gestionados en paralelo con ellos. Gestión de reglas proporciona un medio de
gestión de los "requisitos", como las reglas de negocio explícitas, a través y más allá el
desarrollo de aplicaciones.
Uso de arquitecturas basadas en componentes
Decisión de servicios separados en la lógica de negocio reutilizables, componentes
manejables.
Visualmente el modelo de software
Si "una imagen vale más que 1000 palabras", entonces las reglas de negocio tendrá un
valor de muchas líneas de código. Las reglas de negocio y sus interrelaciones se
pueden visualizar y una gestión más fácil que el código, resultando en más de la
aplicación que gestiona de forma más visual.
Varios cambios se requieren típicamente:

Agregar una regla de negocios o una decisión junto con la actividad de modelado
Modelado de Negocios que hace hincapié en la recopilación y organización de las
reglas de negocio. Esto sustituye a un enfoque singular sobre los casos de uso con una
visión más equilibrada de los casos de uso como medio de descubrimiento de regla,
pero no un lugar para gestionar ellos [véase más arriba no no en requisitos de
normas]. Esta actividad también tiene muy comprimida, las interacciones entre el
modelado de reglas y análisis / diseño / aplicación. Es necesario gestionar estas "reglas
de origen", y asignar estos a los casos de uso y requisitos de diseño que está
documentando. Normas de origen son por lo general en la lengua de sus usuarios que
el uso - tanto en términos de estar en Inglés, por ejemplo, y en términos de usar frases
de negocios y la terminología. La gestión eficaz de los términos y el vocabulario de
estas normas hará que sea más fácil marcarlos y más fácil de ubicarlas en los
artefactos de análisis adicionales. En general, las normas de origen debe mantenerse
en un nivel alto. I blogged recientemente acerca de un gran puesto en el uso de casos
de uso y diagramas de estado para encontrar las reglas de negocio por Scott, que ha
publicado algunos atinados comentarios aquí. También examinó un gran libro sobre
casos de uso y las normas de aquí.
Identificar formalmente los servicios de decisión como los componentes que aplicar las
reglas de negocio y gestión de estos como un tipo de componente. Los servicios de
decisión deberá tener objeto de normas específicas (que las normas está escrito
formalmente para actuar contra los objetos en su sistema) que conducen a la decisión.
A medida que desarrolla su objeto o modelo de datos, usted puede comenzar a
desarrollar las normas que se ejecutan en esos datos. Estas normas deben ser
gestionados en un repositorio, versionados y estructurado para permitir la
reutilización a través de servicios de decisión. Estas reglas de negocio se asignarán de
nuevo a las normas de origen, aunque no suele ser de una manera simple, y se puede
recolectar en conjuntos de reglas.
Usted tendrá que desarrollar un proceso de mantenimiento por separado fuera de su
imperio proceso ordinario, especialmente si los usuarios de negocio son el
mantenimiento de algunas de las reglas en su Decisión de servicio. Aunque tendrá que
pasar por muchas de las pruebas habituales y las medidas de control de calidad, de
manera realista, necesitará un proceso diferente que el plazo será más corto y los
cambios más frecuentes de lo que las expectativas de un típico proyecto de TI.

John Zachman ha proporcionado un marco útil para discutir la

arquitectura de un sistema de información. Su "Zachman Marco"
<3> es una matriz que describe las diversas maneras las
partes interesadas de una visión empresarial del negocio y
sus sistemas. It characterizes 'architecture' in terms of the
perspectives of the different stakeholders (represented by
rows in the matrix) and focuses on the different aspects of
architecture (represented by the columns). Las filas
representan, sucesivamente, el planificador, el dueño,
diseñador, constructor, y las perspectivas de subcontratista.
Las columnas reflejan los aspectos de los datos, procesos,
ubicación, función, la oportunidad y la motivación.

El Proyecto de Reglas de Negocio se ha elegido inicialmente

para abordar los aspectos primera y sexta (es decir, los
«datos» y «columnas de motivación») desde la perspectiva del
diseñador (es decir, "la fila tres '). En otras palabras, el
dominio de los esfuerzos actuales es específicamente la
estructura de un negocio de datos, junto con las limitaciones
y la motivación de otros aspectos relacionados con el sistema
de información de la empresa. Si bien la documentación de
"datos" se conoce bastante bien, el Proyecto de Reglas de
Negocio está añadiendo el aspecto de la "motivación". No
habrá alguna referencia al aspecto de "proceso" en las reglas
de negocio, pero esto será mínimo.

La posición del proyecto en la fila "tres" significa que

tiene que ver con las reglas de negocio que afectan el
almacenamiento de la persistencia de valores de datos, que se
describe en una tecnología de forma neutral. En este momento,
el proyecto no se refiere a las normas de un negocio que no
tienen un componente de sistema de información. Esa
perspectiva se abordará en el trabajo futuro.

Resumen: Este artículo analiza las reglas de negocio en un

entorno de modelado y desarrollo.

Una de las preguntas comunes acerca de cualquier UML [1]

proyecto de base es, donde pongo las reglas de negocio?
Cuando pensamos en un proyecto basado en UML, pensamos a
menudo en caso de uso proceso impulsado por los que utiliza
la clase, la secuencia y diagramas de estado. El más común de
estos procesos es el Proceso Unificado. Sin embargo, como
veremos, el enfoque que damos trabajará con otros procesos,
como de características de desarrollo impulsado.

Las reglas de negocio son la forma especializada de la lógica

que expresa una restricción sobre la forma en que un sistema
o de la gente que lo utiliza se comportan. Estas normas se
rigen por una variedad de elementos, como las agencias
reguladoras, las normas de la industria, perspicacia
comercial, o simple sentido común. A menudo varían de país a
país, una industria a otra, e incluso de empresa a empresa.
Un ejemplo de una regla de negocio en el sector bancario
puede ser que cualquier transacción en efectivo superior a $
10.000 en efectivo debe ser reportado al gobierno. Así pues,
si usted está escribiendo un depósito bancario sistema de
retiro, debe aprovechar esta regla de negocio en
consideración.

Las reglas de negocio suceder en una variedad de niveles.

Algunos de impacto de todo el sistema y, de hecho, están
escritos los sistemas de todo para hacer cumplir las reglas
de negocio. El impacto de las reglas de negocio también puede
ser muy localizado. Pero todas las reglas de negocio tienen
una cosa en común; que gobiernan algún elemento de la
empresa. Por una regla de negocio es, por definición, una
limitación a la persona, empresa, elemento de la empresa, o
la acción realizada. Los lenguajes de modelado unificado
tiene algunas cosas concretas que decir acerca de estas
cosas.

Los requisitos del negocio

Las reglas de negocio Muchos son descubiertos en el curso de
la recopilación de requisitos. El deseo natural es la de
agregar una sección a las descripciones de casos de uso y
añadir las reglas de negocio allí. Sin embargo, a menos que
una regla de negocio es intrínsecamente relacionados con la
función descrita por el caso de uso, que normalmente abarcan
casos de uso múltiple. Así pues, la regla de negocio 10.000
dólares en efectivo abarcaría Hacer un depósito en efectivo?
y el? hacer un retiro de efectivo? casos de uso.

Cada uno de estos casos de uso tiene la oportunidad de?

Fuego? el Estado o para hacer que la regla se invoca. Como
resultado, usted puede tener la tentación de añadir esta
regla a cada uno de estos casos de uso. De hecho, el caso de
usar muchas plantillas tienen una sección de reglas de
negocio. Pero lo que si el gobierno cambia la norma a partir
de $ 10.000 a $ 15.000? Usted tendría que estar seguro de
cambiar esta situación en ambos casos de uso.

Algunas de las reglas de negocio realmente pertenecen a un

caso de uso. Estas normas resultado de las condiciones de
excepción que deben abordarse para el caso de uso de
proceder. Por ejemplo, el gran depósito en cuestión puede
requerir alguna información del cliente de un banco como el
origen de este dinero en efectivo. Esta información
potencialmente tendrían que ser suministrados como parte del
caso de uso. Sin duda, tendría que ser parte si influyó si el
objetivo de depositar el dinero en efectivo se lograra o no.

Sin embargo, las reglas de negocio son muchos los elementos

de validación simple como asegurarse de que el estado y el
partido de código postal. Menudo pasamos por alto estas
reglas de negocio mientras escribía el caso de uso ya que es
un detalle de la validación de la dirección. Sin embargo, hay
otro lugar que podamos poner estas restricciones. Que,
lógicamente, pertenecen a la clase de direcciones en el
diagrama de clase. Al poner estas reglas de negocio en la
clase en el diagrama de clases, estamos asegurando que se
reutilizan en los casos de uso de la misma manera que la
clase se reutiliza en todo el modelo de casos de uso.

Tipos de reglas
En general, existen tres tipos de normas. La primera es la
regla de derivación [Francisco de 2003]. La regla de
derivación transforma la información recibida en los valores
devueltos. Por ejemplo, los descuentos se puede calcular
mediante un algoritmo determinado en función del tamaño de un
orden, promoción especial, o para un cliente valioso. Este
tipo de regla está sujeta a cambios y por lo tanto deben ser
aislados por lo que puede ser manipulada.

El segundo tipo de regla es la regla de restricción de

[Francisco de 2003]. La regla de restricción se utiliza para
determinar si los valores de una transacción u operación son
consistentes. Por ejemplo, el estado y código postal debe
coincidir para que el cliente pueda proceder. También se
puede utilizar para examinar las relaciones de objeto, como
cada cliente debe tener un objeto en la dirección de una
tienda de video de Internet. Las normas de restricción se
puede aplicar con resultados booleanos. Si no se cumplen, no
podemos continuar o terminar la operación.

Por último, están las reglas invariables [Francisco de 2003].

Reglas invariables vistazo a los múltiples cambios y
garantizar que los resultados compuestos son consistentes.
Por ejemplo, el saldo de cuenta de ahorro debe ser igual al
saldo anterior, más el crédito o menos las de débito. Si
logras algo diferente, el sistema tiene una fuga de dinero y
que? S tiempo para plantear una excepción a los niveles más
altos.

------------------rtwertwercuando una puerta no es una puerta

Cuando una puerta no es una puerta?
Las ideas básicas del paradigma de Reglas de Negocio

por Ronald G. Ross

Una de las cosas interesantes de consulta con diferentes

organizaciones en las reglas de negocio y la publicación de
una revista sobre el tema es que muchas de las normas
realmente tonto cruz mi escritorio. A veces se siente como un
desfile de Dilbert!

Uno de nuestros lectores envió recientemente una norma que

plantea algunas preguntas interesantes. Él observa que en su
edificio de apartamentos a las puertas de las escaleras
tienen indicios sobre ellos diciendo: puerta deberá
permanecer cerrada en todo momento. Su pregunta era: "es una
puerta que nunca debe abrir realmente la puerta?" Si la regla
se sigue religiosamente, observó, la puerta, como bien podría
ser considerado parte de la pared.

Bueno, obviamente no del todo! Antes de abordar esa lengua en

cuestión de la mejilla, vamos a hacer un análisis de esta
norma.

Creo que podemos suponer con seguridad que la norma tal como
se indica en realidad es una forma abreviada. Una versión más
completa y exacta que sea, puede usar esta puerta de entrada,
pero debe ser cerrado detrás de usted. Si quisiéramos ser muy
completo, que podría explicar la motivación básica del
Estado, añadiendo, Fire Door.

Un análisis más detallado de esta simple regla revela las

ideas básicas del paradigma de las reglas de negocio:

La norma fue publicada, es decir, por escrito. ¿Por qué? La

respuesta está en la motivación de la norma - que su
propósito es proteger a la población contra los peligros de
incendio. Cuando una norma se convierte en lo suficientemente
importante, siempre es por escrito.

La norma fue escrito en la llanura Inglés. Si la norma son

difíciles de entender, o codificada de tal manera que muchos
de los habitantes no era fácil interpretarlo, no serviría
para su propósito muy bien. Una regla lo suficientemente
importante como para escribir vale la pena escribir
claramente.

Un procedimiento de esta situación no es realmente necesario.

Se podría escribir uno, por supuesto, pero en este caso,
probablemente sería trivial (puerta de aproximación; captar
pomo de la puerta con la mano, pomo de la puerta es la
dirección de giro en sentido horario; Pull / Push con cuidado
...). Sin embargo, el Estado sigue siendo crucial. Las reglas
pueden existir independientemente de los procedimientos.

Esta norma - como todas las reglas - sirve para moldear el

comportamiento. La publicación de la norma recuerda a los
habitantes, el personal, y otros, para cerrar la puerta, y,
presumiblemente, por lo tanto son menos propensos a olvidar,
o tal vez incluso bloquear la puerta abierta. El propósito de
una norma es siempre para guiar o influir en el
comportamiento de manera deseada.

La norma responde a un propósito - que no es ni frívolo ni

arbitraria. El fuego es un riesgo mortal, y todas las medidas
razonables deben ser tomadas para proteger contra ella. Las
reglas de negocio nunca surgen en el vacío, siempre hay
identificables y los factores importantes de negocios
motivarlos.

La norma se envió justo donde está la acción - es decir,

donde la entrada efectiva puede ocurrir. Esta proximidad a la
acción de ayuda a garantizar que la norma se observa como se
desarrollan los acontecimientos en realidad. La mejor manera
de garantizar unas normas se siguen es conseguir que justo en
frente de la gente en el punto exacto donde la orientación es
pertinente.

La regla es, sin duda, parte de un conjunto más amplio de

reglas del código de incendios para edificios. A pesar de que
la regla puede ser publicado miles de veces para fines de
aplicación, estas publicaciones surgen de una sola fuente.
Esto asegura la coherencia. Si las normas son lo
suficientemente importantes para ser aplicadas, son lo
suficientemente importantes para ser de un solo origen.

El cuerpo de fuego reglamentarias, sin duda, el código fue

elaborado por expertos con experiencia en el campo, y está
respaldado por la autoridad política de la ciudad o estado.
Los cambios deben ser revisados, Incorporated, y difusión de
cuidado. Debido a nuevos peligros y responsabilidades pueden
ser descubiertos en cualquier momento, este proceso debe ser
ágil y eficiente. En otras palabras, las reglas deben ser
gestionados.
Estas observaciones de sentido común representan las ideas
básicas del paradigma de reglas de negocio. Su empresa tiene
varios miles de estas normas la orientación de sus decisiones
operativas. Sin embargo, en la práctica, estos principios
regla básica de negocios rara vez se siguió. ¿Puede usted
hacer algo al respecto? Sí! El paradigma de reglas de negocio
ofrece soluciones probadas.

Ahora, de regreso a esa pregunta, "es una puerta que nunca

debe abrir realmente la puerta?" La respuesta es obvia - Sí,
por supuesto que es. Una pared sin puerta siempre, será en
una pared. Si necesita una puerta en algún momento del
futuro, tiene que remodelar, y eso significa tiempo y dinero
(por no hablar de la interrupción de los habitantes). Si
alguna vez ha remodelado su casa, usted sabe exactamente lo
que quiero decir.

El muro con una puerta que actúa como un muro hasta el

momento en que el deber-seguir la regla de cierre se
interrumpe. Luego, con un retraso relativamente poco, gasto,
o la interrupción, se convierte en una puerta funcional.

Piense en el paradigma de las reglas de negocio como un medio

relativamente económico para construir las puertas de
potenciales para su negocio en todos los muchos casos que
podrían un día ser necesario. De esta manera usted puede
evitar muros mismo pulg En un mundo de constante cambio y la
aceleración, la agilidad es el nombre del juego!

--------------------------dfgsldfkgjdfkl
motor de reglas de negocio
Un motor de reglas de negocio es un sistema de software que
ejecuta una o más reglas de negocio en un entorno de
producción en tiempo de ejecución. Las normas pueden provenir
de la regulación legal ( "Un empleado puede ser despedido por
cualquier razón o sin razón, pero no por una razón ilegal"),
política de la empresa ( "Todos los clientes que gastan más
de $ 100 de una sola vez recibirán un descuento del 10%" ), o
de otras fuentes.

Software de motor de reglas es comúnmente usado como un

componente de un sistema de gestión de reglas de negocio que,
entre otras funciones, proporciona la capacidad de: registro,
definir, clasificar y gestionar todas las reglas, verificar
la coherencia de las definiciones ( "reglas de oro a nivel de
clientes elegible para el envío libre cuando la cantidad de
pedidos> 10 "y" Cantidad máxima de oro a nivel de clientes =
10 "), define las relaciones entre las diferentes normas, y
relatar algunas de estas normas a las aplicaciones que se ven
afectados o necesidad de aplicar una o más de las normas.

En cualquier aplicación informática, las reglas de negocio

cambian con más frecuencia que el resto del código de
aplicación. Los motores de reglas de inferencia o de los
motores son los componentes de software que se ejecutan
conectable reglas de negocio que se han externalizado de
código de la aplicación como parte de un enfoque de reglas de
negocio. Esto permite que los usuarios de negocios para
modificar las reglas con frecuencia sin la necesidad de la
intervención de TI y por lo tanto permite que las
aplicaciones sean más adaptables a las normas dinámico.
Aunque la garantía de calidad y otras pruebas sería necesario
en cualquier sistema de la empresa.

Conectando las reglas de negocio con los procesos

2.2.1Harvesting Business Rules in a Process Context
Harvesting business rules from a legacy application has benefits ranging from
simple documentation to application modernization. We provide a practical
approach for collecting rules in a process context.
• By Mike Oara
• 01/09/2007

Harvesting business rules from a legacy application has many benefits, from simple documentation to
application modernization. Most approaches to business rule mining recover rules from the code in a bottom-
up fashion. This creates difficulties in classifying and understanding the context in which the rules are used.
This article suggests a practical approach for collecting rules in a process context. Process information is
collected top-down, rules are collected bottom-up, but there is a way to connect processes and rules such that
the analyst can create a better picture of the business functions of the application.

Why Collect Business Rules from an Existing Application?

Harvesting business rules from a legacy application has many benefits. In the code of a traditional legacy
application, the business and technical aspects are in most cases mixed together in a way that makes it very
hard to distinguish the technical mechanisms from the implementation of the company’s business rules and
processes. Collecting the real business rules in a methodical and (if possible) exhaustive manner will render
multiple advantages:

• Business rules may simply serve as documentation of the application, useful both for those who
maintain the application and for the end-users.
• In a more complex scenario, business rules collected in a well-organized repository may serve as a
means of communication between the IT people and the end-users. For example, if the rule
repository has accurate information on the location of the rule implementation in the code, the
developers may quickly locate the code that would be impacted by a rule change requested by
business users.

• The collection of business rules is also useful if the application is implemented in a new
environment. The rules serve as documentation as well as a checklist, ensuring that no rules are
left behind.

Classification of Rules
10 razones por que son indispensables los casos de uso

10 reasons why use cases are indispensable to your software development project
REF http://blogs.techrepublic.com.com/programming-and-
development/?p=544&tag=nl.e606

Well-written use case narratives (or simply “use cases”) offer the analysis, development,
and testing teams an invaluable guidebook. A use case (different from a UML use case
diagram) is a formalized story that describes how someone procedurally interacts with an
existing or proposed system and they should be part of every project managers’ permanent
tool set.

2.3Introducing use cases

Imagine flying to an unfamiliar foreign country where you plan to rent a car and tour the
sights. Most people wouldn’t consider starting this trip without a good guidebook. Despite
the obvious value of a guidebook’s roadmaps and narratives, we information technologists
too often embark on software development projects without them. As a result, development
teams often wander far from the project objectives - at considerable expense and delay.

Use case narratives were most notably popularized in Writing Effective Use Cases, by
Alistair Cockburn.

What does a use case look like? The document, Customer gets cash from an ATM, available
in the download version of this post, represents a detailed description of a business process.
The structure of this sample use case reflects a framework I’ve designed and used in several
large projects. While the structure of my use cases differs somewhat from Cockburn’s, it
accommodates what my analysis teams have generally needed to capture process
requirements.

The TechRepublic download version of this blog post is in the PDF format and includes the
example use case.

2.410 reasons

I routinely encourage analysis teams to develop use cases. Here are ten reasons why they
are part of my permanent toolset.

2.4.1Use cases help the analysis team…

1. Improve communication among team members

Collaborative effort enhances the success of any team. As the team members work to
describe business processes, use cases provide a repository of team members’ business
knowledge. As a written document, each use case spawns meaningful discussion within the
group. The axiom, “the whole is greater than the sum of the parts”, applies here. Group
discussion exposes in-depth viewpoints that would otherwise remain hidden. With use
cases, the team captures these perspectives while identifying the related business goals,
conditions, and issues. The result is a comprehensive and meaningful story about each
business process.

2. Encourage common agreement about system requirements

The process of writing and revising use cases produces three important outcomes in the
analysis team — clarity, consensus, and commitment. Remarkably, it is common for
stakeholders to be uncertain about how a process they own actually works! Writing a use
case helps stakeholders align the narrative with the details of an existing process.

In a recent project, it became clear that stakeholders could not agree about the specifics of
several core processes. However, consensus came quickly as the team wrote and revised
use cases. For many stakeholders, these written documents offer a foothold on a sometimes
bewildering mountain of complex business processes.

Remarkably, use cases often help stakeholders reach common agreement on “best practice”
processes as well. In a facilitated group setting, divergent perspectives are welcomed,
understood, and appreciated. As a by-product of this agreement, team members inevitably
commit to support improved processes to both management and peers.

3. Reveal process alternatives, process exceptions, undefined terms, and outstanding

issues

I always have the analysis team start a use case by developing the “Main Course of Events”
(see the sample use case). As the group develops a coherent and ordered set of process
steps, team members tend to volunteer statements that begin with the words “what about…”
- a clue to previously unidentified “Alternative Paths” to a successful outcome. The
“Exception Paths” often arise in a similar way. More of these become obvious when the
team considers what happens if any step in the “Main Course” fails.

As the facilitator of team meetings, carefully listen for any jargon used by stakeholders.
Write these terms down in front of the group and ask for a definition for each one. Later,
you’ll add these definitions into the project glossary. Also, listen for issues as they arise. Is
a process step fuzzy? Is there an area that needs more research, or an item on which team
members disagree? Write these down as well and later include them in a project issue log.

4. Expose what belongs outside project scope

Constraints on the project may limit resources and/or the project timeline. As a result, the
analysis team may need to prioritize development work, or separate project deliverables
into phases. You can help the analysis team by creating a catalog of the use case titles, and
arranging them into some meaningful order (e.g., by sub-system or umbrella process). With
this catalog, the analysis team can prioritize the use cases. They may decide that some fall
outside the project scope, or that some are not needed in the first project phase. Either way,
you have given the stakeholders an opportunity to declare which functions they need the
most, or which ones they need first.

5. Transform manual processes into automated processes

When software is being designed to automate aspects of an existing system, the analysis
team usually begins by writing “as is” use cases to describe the current business processes.
While this effort is time consuming, the result is valuable. Besides revealing the details of
an existing business process (including business rules, alternative paths, and exception
paths), you will create a launching pad for the team’s imagination. As they are writing the
use cases, they often discover an improved process, recognize unnecessary steps, or reach
agreement on “best operational practices”.

The “as is” use cases may also allow the system architect to propose high-level process
flow diagrams that represent how the new system could work. While the first attempts may
not be viable, iterative review and revision by the analysis team may generate a workable
architecture for the new system.

2.4.2Use cases help the development team…

6. Understand business processes

Software developers often lack an understanding of the customer’s business. It is easy to

forget that software systems should help business people get work done — effectively,
efficiently, and inexpensively. To achieve these objectives, the development team must
understand not only the business process the software must support, but also the process’
alternatives and exceptions. Use cases provide this information in clear, structured language
that developers can readily understand. Use cases also offer a valuable perspective on the
stakeholders’ business goals, assumptions, and operational rules. These features provide
developers with a solid foundation for developing cost-effective solutions to business
challenges.

7. Recognize patterns and contexts in functional requirements

Developers may view a set of use cases horizontally. For example, one use case requires a
customer lookup function. Another use case requires a similar function but with customer
data sorted in a different order. The clever development team can find such patterns within
a set of use cases. Patterns are often discovered in the “Business Rules” section of use cases
as well. Developers may transform these patterns into universal software objects.

As another aid to developers, use cases also reveal operational context. The “Stakeholders
Goals”, “Pre-Conditions”, “Assumptions”, and “Post-Conditions” give developers a sense
of how the software will be used. By reading these sections, the developer understands
what the role identified in the use case is trying to accomplish, and what motivates him or
her.

8. Prioritize work

Although the analysis team may have prioritized and winnowed the use cases, the
development team views them from a far different perspective. As a good development
teams writes code, they search for coding efficiencies. While the analysis team may want
12 use cases completed in phase one, the technical manager and the development team may
see cost-savings in delivering phase one software for the 12 use cases, plus two more from
phase two that are cheaper to build as part of phase one. Of course, the analysis team and
the development should jointly consider the effect of this change.

2.4.3Use cases help the testing team…

9. Discover gaps between the requirements and the delivered software

Some years ago, I was asked to join a troubled project in which the system design phase
was nearly complete. Unfortunately, detailed functional requirements were no where to be
seen, and the developers had already begun writing code! In order to catch up, I taught a
team of functional users to write use cases themselves. Although we completed the
narratives quickly, the developers largely ignored our use cases.

That condition changed, however, after the developers installed their first software release.
It was clear to us that critical features were missing. The rooky analysis team and I
compared the delivered software to our use cases. Although we created a long list of
missing features, we challenged the developers to close the gaps rapidly. The next
installation was acceptable.

10. Ensure the delivered software works properly

While use cases significantly differ from test cases, the former may be used to derive the
latter. The “Assumptions”, “Pre-Conditions”, and “Post-Condition”, “Main Course”,
“Alternative Paths”, “Exception Paths”, and “Business Rules” sections are all source
material for creating good test scripts. Bundles of use cases organized into system-wide
process flows become a source for writing comprehensive end-to-end test scripts. As an
added bonus, the testing team develops test scripts from the use cases as the development
team begins its work. The test scripts are now ready for use as developers complete
programs.

2.5Lessons Learned

While writing use cases may seem time consuming and tedious, the result is a foundation
for work by the analysis team, the development team, and the testing team. Use cases
provide a valuable return on the analysis team’s investment in time and resources.
2,4 10 razones
Rutinariamente animar a los equipos de análisis para
desarrollar casos de uso. Aquí van diez razones por las que
son parte de mi conjunto de herramientas permanente.
2.4.1 Los casos de uso ayudan al equipo de análisis ...
1. Mejorar la comunicación entre los miembros del equipo
Los esfuerzos de colaboración refuerza el éxito de cualquier
equipo. Como los miembros del equipo de trabajo para
describir los procesos de negocios, casos de uso proporcionar
un repositorio de conocimiento de los miembros del equipo de
negocios. En un documento escrito, cada caso de uso genera
debate significativo dentro del grupo. El axioma, "el todo es
mayor que la suma de las partes", se aplica aquí. Discusión
en grupo expone en los puntos de vista en profundidad que de
otro modo permanecerían ocultos. Con los casos de uso, el
equipo de captura estas perspectivas, mientras que la
identificación de los objetivos de negocio relacionados, las
condiciones y problemas. El resultado es una historia
completa y significativa acerca de cada proceso de negocio.
2. Alentar a un acuerdo común acerca de los requisitos del
sistema
El proceso de redacción y revisión de casos de uso produce
tres resultados importantes en el equipo de análisis - la
claridad, consenso y compromiso. Sorprendentemente, es común
que las partes interesadas a tener dudas sobre cómo un
proceso que poseen realmente funciona! Escribir un caso de
uso ayuda a las partes interesadas alinear la narración con
los detalles de un proceso existente.
En un proyecto reciente, se hizo evidente que las partes
interesadas no pudieron ponerse de acuerdo sobre los detalles
de los procesos básicos de varios. Sin embargo, el consenso
no se hizo esperar ya que el equipo escribió y revisó los
casos de uso. Para muchos participantes, estos documentos
escritos ofrecen un punto de apoyo en una montaña a veces
desconcertante de procesos de negocio complejos.
Sorprendentemente, los casos de uso con frecuencia ayudan a
las partes interesadas lleguen a un acuerdo común sobre las
"mejores prácticas" procesos. En un ambiente de grupo
facilitado, perspectivas divergentes son bienvenidas,
entendido y apreciado. Como un subproducto de este acuerdo,
los miembros del equipo, inevitablemente, se comprometen a
apoyar los procesos de mejora tanto para la dirección y los
compañeros.
3. Alternativas de proceso revela, excepciones proceso, los
términos no definidos, y las cuestiones pendientes
Siempre tengo el equipo de análisis de iniciar un caso de uso
mediante el desarrollo del Curso "principal de los
acontecimientos" (véase el caso de uso de la muestra). A
medida que el grupo desarrolla un conjunto coherente y
ordenado de los pasos del proceso, los miembros del equipo
suelen hacerse las declaraciones que comienzan con las
palabras "¿qué pasa ..." - una pista previamente no
identificados "Alternative Paths" a un resultado exitoso. Los
"Caminos de Excepción" surgen a menudo en una manera similar.
Más de estos a ser evidente cuando el equipo considera que lo
que ocurre si cada paso en la "Main Course" falla.
Como facilitador de reuniones de equipo, para escuchar
atentamente la jerga utilizada por los interesados. Escriba
estos términos en el frente del grupo y solicitar una
definición para cada uno. Más tarde, vamos a añadir estas
definiciones en el glosario del proyecto. Además, la escucha
de las cuestiones que puedan surgir. Es un paso en el proceso
borroso? ¿Hay un área que necesita más investigación, o un
elemento en el que los miembros del equipo no están de
acuerdo? Anotar éstos, así y luego incluirlos en un registro
de edición del proyecto.
4. Expone lo que es el alcance del proyecto fuera de
Restricciones en el proyecto podrán limitar los recursos y /
o los plazos del proyecto. Como resultado, el equipo de
análisis puede ser necesario dar prioridad a la labor de
desarrollo, o las prestaciones del proyecto en fases
separadas. Usted puede ayudar al equipo de análisis mediante
la creación de un catálogo de los títulos de casos de uso, y
la organización de ellos en un orden significativo (por
ejemplo, por sub-sistema o proceso de coordinación). Con este
catálogo, el equipo de análisis puede dar prioridad a los
casos de uso. Pueden decidir que algunos quedan fuera del
alcance del proyecto, o que algunos no son necesarios en la
primera fase del proyecto. De cualquier manera, usted ha dado
a las partes interesadas la oportunidad de declarar que las
funciones que más necesitan, o que los que necesitan en
primer lugar.
5. Transformar los procesos manuales en procesos
automatizados
Cuando el software es diseñado para automatizar los aspectos
de un sistema existente, el equipo de análisis por lo general
comienza por escrito "como es" casos de uso para describir
los procesos de negocio actuales. Aunque este esfuerzo es
mucho tiempo, el resultado es valioso. Además de revelar los
detalles de un proceso de negocio existentes (incluyendo las
reglas de negocio, las rutas alternativas y caminos de
excepción), se creará una plataforma de lanzamiento para la
imaginación del equipo. Como que están escribiendo los casos
de uso, a menudo descubren un proceso de mejora, reconocer
los pasos innecesarios, o llegar a un acuerdo sobre las
"mejores prácticas operativas".
El "tal como es" casos de uso también puede permitir que el
arquitecto del sistema de proponer proceso de alto nivel de
los diagramas de flujo que representan cómo el nuevo sistema
podría funcionar. Aunque los primeros intentos no puede ser
viable, la revisión iterativo y revisión por el equipo de
análisis puede generar una estructura viable para el nuevo
sistema.
2.4.2 Los casos de uso ayudan al equipo de desarrollo ...
6. Entender los procesos de negocio
Los desarrolladores de software a menudo carecen de una
comprensión del negocio del cliente. Es fácil olvidar que los
sistemas de software debe ayudar a la gente de negocios que
hagan su trabajo - de manera eficaz, eficiente y económica.
Alternativas para lograr estos objetivos, el equipo de
desarrollo debe comprender no sólo el proceso de negocio debe
ser compatible con el software, sino también el proceso "y
las excepciones. Los casos de uso de esta información con un
lenguaje claro y estructurado que los desarrolladores puedan
comprender fácilmente. Los casos de uso también ofrecen una
perspectiva valiosa sobre los objetivos de los actores
empresariales, los supuestos y normas de funcionamiento.
Estas características proporcionan a los desarrolladores una
base sólida para el desarrollo de soluciones rentables a los
retos empresariales.
7. Reconocer patrones y contextos en los requisitos
funcionales
Los desarrolladores pueden ver un conjunto de casos de uso en
horizontal. Por ejemplo, un caso de uso requiere de una
función de búsqueda de los clientes. Otro caso de uso
requiere una función similar, pero con datos de los clientes
clasificados en un orden diferente. El equipo de desarrollo
inteligente puede encontrar patrones en el plazo de un
conjunto de casos de uso. Patrones se han descubierto en las
reglas de negocio "," sección de casos de uso también. Los
desarrolladores pueden transformar estos patrones en los
objetos de software universal.
Como otro de ayuda a los desarrolladores, los casos de uso
también revelan contexto operacional. Los "Objetivos de las
partes interesadas", "pre-condiciones", "Hipótesis" y "Post-
condiciones" dar a los desarrolladores una idea de cómo el
software se utilizará. Al leer estas secciones, el
desarrollador entiende cuál es el papel identificados en el
caso de uso está tratando de lograr, y lo que motiva a él o
ella.
8. Priorizar el trabajo
Aunque el equipo de análisis puede tener prioridad y se
selecciona en los casos de uso, el equipo de desarrollo de
puntos de vista desde una perspectiva muy diferente. Como los
equipos de desarrollo bien escribe el código, que la búsqueda
para la codificación de la eficiencia. Si bien el equipo de
análisis puede querer 12 casos de uso terminado en la primera
fase, el director técnico y el equipo de desarrollo pueden
ver ahorros de costos en la entrega de la primera fase de
software para los 12 casos de uso, además de otros dos de la
segunda fase que son más baratas de construir, como parte de
la primera fase. Por supuesto, el equipo de análisis y la
elaboración conjunta debe considerar el efecto de este
cambio.
2.4.3 Los casos de uso ayudan al equipo de pruebas ...
9. Descubre las diferencias entre los requisitos y el
software entregado
Hace algunos años, se me pidió participar en un proyecto con
problemas en los que la fase de diseño del sistema era casi
completa. Lamentablemente, detallada los requisitos
funcionales no estaban donde se ve, y los desarrolladores ya
había comenzado a escribir código! Con el fin de ponerse al
día, me enseñó un equipo de los usuarios funcionales para
escribir casos de uso de sí mismos. Aunque hemos completado
las descripciones de forma rápida, los desarrolladores en
gran medida ignorado nuestras casos de uso.
Esta condición cambió, sin embargo, después de los
desarrolladores de software instalado su liberación en primer
lugar. Es claro para nosotros que las características
críticas estaban desaparecidos. El equipo de análisis y
comparación rooky el software entregado a nuestros casos de
uso. A pesar de que hemos creado una larga lista de
características que faltan, desafiamos a los desarrolladores
para cerrar las brechas rápidamente. La próxima instalación
era aceptable.
10. Asegúrese de que el software entregado funciona
correctamente
Si bien los casos de uso difieren significativamente de los
casos de prueba, la primera puede ser utilizada para obtener
el último. Las "hipótesis", "pre-condiciones", y "post-
Estado", "Main Course", "Alternative Paths", "Excepción
Caminos", y "Reglas de Negocio" se encuentran todos los
materiales de base para la creación de scripts de prueba
buena. Paquetes de casos de uso organizan en proceso en todo
el sistema de flujos de convertirse en una fuente para la
escritura completo e integral a scripts de prueba final. Como
un bono adicional, el equipo de pruebas desarrolla scripts de
prueba de los casos de uso como el equipo de desarrollo
comienza su trabajo. Los scripts de prueba ya están listos
para su uso como desarrolladores de programas completos.
2.5 Lecciones aprendidas
Mientras escribe los casos de uso puede parecer largo y
tedioso, el resultado es una base para el trabajo por el
equipo de análisis, el equipo de desarrollo, y el equipo de
pruebas. Los casos de uso proporcionar un retorno de valor de
la inversión del equipo de análisis en el tiempo de

por que si es cierto

ya que integrar las normas que cambian y evolucionan.
Utilizando un enfoque de reglas de negocio para gestionar las
reglas de negocio independiente de los requisitos de ayuda a
mantener los requisitos más limpios y menos chapucero (aunque
todavía se puede hacer un mal trabajo de ellos, obviamente).
El uso de reglas de negocio para gestionar las decisiones de
esta manera también ayuda con "# 4: El arrastramiento del
alcance", como las normas pueden evolucionar y cambiar y se
vuelven más complejos sin afectar el principal proyecto de
desarrollo de software o los requisitos de alcance. Todo esto
ayuda con "# 2: Deslizamiento de la Lista" y "# 3:
Presupuesto de rebasamiento" como uno de los impulsores
principales para estos dos es el flujo constante inherente a
las reglas de negocio. Apartándolos y la gestión de ellos por
separado ayuda a evitar problemas en ellas.

Los otros dos son dignas de mención - "# 6: Documentación de

pobres" y "# 8: Las malas comunicaciones". Las conversaciones
posteriores sobre estos en términos de documentación
deficiente de los proyectos y la comunicación deficiente de
los proyectos, en el que las reglas de negocio no puede
ayudar mucho, pero también son relevantes en un sentido más
amplio - si los participantes del negocio en el proyecto no
se puede ver en la documentación de lo que se está
construyendo y no se comunican con el proyecto tendrá
problemas. El uso de reglas de negocio para especificar las
decisiones que significa que los usuarios de negocio pueden
leer y entender la lógica de negocio que se propone, e
incluso práctica, resultando en una mejor documentación y
mayor comunicación entre los dos "lados".

Reglas de negocio escondidas en los casos de uso

September 3rd, 2007
3.Business Rules Hidden in Use Cases

Business rules are not requirements. Yet they are often gathered at the same time as
requirements, from the same sources, by the same business analysts. And unfortunately,
often documented in the same artifacts. In this article we look at some of the ways that
business rules are commonly hidden inside use cases.

3.1Separate Business Rules from Use Cases

As we’ve discussed before, business rules need to be separated from requirements. James
Taylor and I continue to explore how best to isolate rules from requirements. To quickly
summarize (and dramatically oversimplify) one of the points from James’ book, Smart
Enough Systems, isolating the implementation of business rules allows you to update the
way your business runs on your software much more quickly. And the first step to driving
this isolation at the implementation layer is to isolate rules from requirements at the
documentation layer.

3.2Types of Business Rules

In our earlier article, we touched briefly on how business rules are used to define decisions
within a use case or process flow. David Wright wrote an article, The Business Rules
Approach, where he identifies five classes of business rules:

• Constraints – mandated criteria such as “the applicant must not be a felon”

• Guidelines – suggestions such as “the applicant should not have been rejected
previously”
• Action Enablers – rules that initiate or trigger behavior, like “when the customer’s
card has been rejected, it must be confiscated”
• Computations – the embodiment of calculations, like “pay 1.5 times the wager for a
two-card total of 21″
• Inferences – the canonical “if…then” statements

These types of business rules can easily be hidden in different elements of a use case.

3.3Where Business Rules Can Lurk

When we look at the structure of a formal use case, we see several areas where business
rules can be hidden.

Description
Since the description acts as a summary or overview of the entire use case, any of the
different types of business rules might be captured within it. Looking at an example from
one of our old articles:

A pilot performs an FAA mandated list of equipment and operational inspections prior to
every flight. All inspections must pass before the flight is allowed to take off per corporate
policy.

“All inspections must pass…” is a constraint, and therefore a business rule. “Prior to every
flight” is also a constraint. It would be better to write the description as follows:

A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-
1] prior to flights.

We’ve removed both business rules from the description, and added an explicit reference to
the FAA mandated list. If the list of inspections defined by the FAA should change, we
should not have to update our use case.

Triggers

Very often, these are action enabler rules. A trigger of “Student submits college
application” is a trigger for the “Evaluate student application” use case. Although you could
possibly argue that this is a business rule, there doesn’t seem to be much value in making
the distinction. However, a trigger could also be “It is Friday at 5pm” for the use case
“Process pending orders.” This represents a company-specific business decision to process
orders at the end of the week. The order-processing use case would not change if the
frequency were changed to every day, or every other week. The trigger really represents an
implicit decision – “Is it time to process pending orders?” Using language that is more
correct for a trigger, we would write:

It is time to process pending orders [See BR021, Order-processing time].

This would allow us to change the way our business operates more quickly. We could start
processing on any frequency – or even start processing whenever more than 10 orders have
queued up, or whenever outstanding orders represent $1000 in revenue (or profits). The key
point is that by abstracting out the decision, Is it time yet?, we again can change how we
run our business without having to update and re-validate the use case.

Preconditions

Business rules that represent constraints very often show up as preconditions to a use case.
Since preconditions describe “what must be true” before the use case starts, this is
understandable. Imagine we were writing a use case named “Process New Car Loan
Application.” An obvious precondition might be that the amount to be borrowed has been
resolved for the new car.
This would reduce labor, by only processing loan applications (which include running
credit checks, etc), after a buyer has been locked in to a price, their trade-in value has been
agreed to, and any deposit has been defined. However, this represents a linear process. An
interesting business decision might be to immediately process a loan application as soon as
the buyer agrees to start negotiations. The car dealer could use a conservatively estimated
amount to get approval from the financing institution for a loan for “up to amount X.”
Then, once negotiations have been completed, the only step remaining would be to fill in
the exact amount and get the buyer’s signature. A much improved shopping experience for
the new car buyer.

We could write this as follows:

A maximum amount for the loan has been identified [See BR033, Determining loan-
application amount].

And then, within that business rule we can define heuristics like “Subtract Kelly Blue Book
value of indicated trade-in from 5% below the sticker price” or use the average selling price
for the particular model car + 5%, or any of a number of rules. Those rules can easily be
changed without affecting the loan-application use case.

Normal and Other Flows

There are many opportunities within the normal course of a use case to hide business rules.
Every point in the use case that could cause branching to an alternate or exception flow
represents a decision. Each of those decisions represents the combination of one or more
business rules. To be more precise, each decision represents a set of rules that are applied
together to reach a conclusion (stay in the normal flow, or branch to another flow).

A use case named “Review conversation transcript” for a CIA analyst would have a normal
course that probably documents that the transcript has been reviewed, and follows some
archiving procedure. If the transcript identifies a “red flag” word or phrase like
“Blackbriar” or “Touchstone”, then an alternate flow would be initiated. [Yes, I did watch
the Bourne Ultimatum this weekend.] The trigger for this alternate flow could be written as:

3. Review of the transcript identified a red-flag word or phrase [See BR US-21744.6,

Identification of red-flag words and phrases].

Then this business rule could be defined as a lookup into a database, it could be filtered –
so that counter-terrorism analysts look for different words and phrases than people looking
for drug dealers. This allows the “review a transcript” use case to remain stable while the
rules for identifying onerous phrases are modified on a regular basis. This also allows the
“review a transcript” use case to be changed without impacting the phrase-identification
business rules.
3.4Key Element

The key element of this reworking of use cases is to reference the sets of business rules that
make up individual decisions, constraints, and action enablers. Those rules are maintained
in separate documents. These other documents may be distinct documents, top-level objects
within a requirements repository, or rule sets managed in a rules repository.

Most importantly, the rules are not hidden within the use case. Hiding the rules in this way
makes it more difficult for developers to interpret the documents. It makes it all but
impossible for the developers to abstract the rules into abstract decision services. It also
slows down the approval process of the requirements and the rules – both initially, and
when managing changes.

Las reglas de negocio no son requisitos. Sin embargo, a

menudo se reunieron en el mismo tiempo que las necesidades,
desde las mismas fuentes, por los analistas de negocio mismo.
Y, por desgracia, a menudo documentado en los artefactos
mismos. En este artículo examinamos algunas de las formas en
que las reglas de negocio normalmente se oculta dentro de
casos de uso.
3,1 separado de Reglas de Negocio de Casos de uso
Como hemos explicado antes, las reglas de negocio deben ser
separados de los requisitos. James Taylor y yo siga
estudiando la mejor manera de aislar a las normas de los
requisitos. Para resumir rápidamente (y simplificar
drásticamente) uno de los puntos del libro de James, Smart
suficientes sistemas, aislando la aplicación de reglas de
negocio le permite actualizar la forma en que su negocio
funciona con su software mucho más rápidamente. Y el primer
paso a la conducción de este aislamiento en la capa de
aplicación es aislar a las normas de los requisitos en el
nivel de documentación.
3.2 Tipos de Reglas de Negocio
En nuestro artículo anterior, nos hemos tocado brevemente
cómo las reglas de negocio se utilizan para definir las
decisiones en un caso de uso o de flujo del proceso. David
Wright escribió un artículo, el enfoque de Reglas de Negocio,
donde se identifica cinco clases de reglas de negocio:
• Limitaciones - mandato de criterios tales como "el
solicitante no debe ser un delincuente"
• Directrices - sugerencias tales como "el solicitante no
debería haber sido rechazado anteriormente"
• Acción de Facilitadores - normas que inician o el
comportamiento de activación, como "cuando la tarjeta del
cliente ha sido rechazada, debe ser confiscada"
• Cálculos - la realización de los cálculos, como "pagar 1,5
veces la apuesta de un total de dos tarjetas de 21"
• inferencias - el canónico "si ... entonces"
Estos tipos de reglas de negocio puede ser fácilmente oculta
en los diferentes elementos de un caso de uso.
3.3 Cuando las reglas de negocios pueden estar al acecho
Cuando miramos la estructura de un caso de uso oficial,
podemos ver varias áreas en las reglas de negocio se puede
esconder.
Descripción
Desde la descripción actúa como un resumen o un resumen del
caso de uso conjunto, cualquiera de los diferentes tipos de
reglas de negocio puede ser capturado dentro de ella. En
cuanto a un ejemplo de uno de nuestros artículos de edad:
Un piloto de la FAA realiza un mandato de lista de equipo y
las inspecciones de este tipo antes de cada vuelo. Todas las
inspecciones deben pasar antes de que el vuelo se le permite
despegar por la política corporativa.
"Todas las inspecciones deben pasar ..." es una restricción,
y por lo tanto una regla de negocio. "Antes de cada vuelo" es
también una limitación. Sería mejor para escribir la
descripción de la siguiente manera:
Un piloto de la FAA realiza un mandato de lista de equipo y
la inspección de operaciones [véase la FAA-1] antes de los
vuelos.
Hemos eliminado las reglas de negocio, tanto de la
descripción, y añadió una referencia explícita a la FAA el
mandato de lista. Si la lista de los controles definidos por
la FAA debe cambiar, no deberíamos tener que actualizar
nuestros casos de uso.
Triggers
Muy a menudo, se trata de normas facilitador de acción. Un
disparador de "El estudiante presenta solicitud de la
universidad" es un disparador para la aplicación de la
"Evaluación de los" casos de uso. Aunque se podría argumentar
que ésta es una regla de negocio, no parece ser mucho valor
para hacer la distinción. Sin embargo, una activación también
podría ser "Hoy es viernes a las 5pm" para el caso de uso
"Proceso de órdenes pendientes." Esto representa una empresa
de decisiones empresariales específicas para procesar los
pedidos al final de la semana. La orden de procesamiento de
casos de uso no cambiaría si la frecuencia se cambia a cada
día, o cada dos semanas. El disparador en realidad representa
una decisión implícita - "¿Es hora de procesar los pedidos
pendientes?" Uso de lenguaje que es más correcto para un
disparador, nos escribe:
Es hora de procesar los pedidos pendientes [véase BR021,
Orden tiempo de procesamiento].
Esto nos permitirá cambiar la forma en que nuestro negocio
funciona más rápidamente. Podríamos empezar a procesar en
cualquier frecuencia - o incluso iniciar el procesamiento de
cada vez más de 10 órdenes tienen cola, o cuando los pedidos
pendientes representan $ 1000 en ingresos (o ganancias). El
punto clave es que haciendo abstracción de las decisiones, ya
es hora todavía?, Podemos volver a cambiar la forma en que
manejamos nuestro negocio sin tener que actualizar y volver a
validar el caso de uso.
Condiciones previas
Las reglas de negocio que representan limitaciones muy a
menudo aparecen como condiciones previas para un caso de uso.
Dado que las condiciones previas describir "lo que debe ser
verdad" antes de que comience de casos de uso, esto es
comprensible. Imagínese que estábamos escribiendo un caso de
uso llamado "Proceso de Autos Nuevos Solicitud de Préstamo".
Una condición obvia podría ser que el importe que se prestan
ha sido resuelta por el nuevo coche.
Esto reduciría la mano de obra, sólo por la tramitación de
solicitudes de préstamos (que incluyen la ejecución de
controles de crédito, etc), después de que un comprador se ha
encerrado en un precio, su comercio en valor se ha acordado,
y cualquier depósito ha sido definida. Sin embargo, esto
representa un proceso lineal. De una decisión de negocios
interesante podría ser de inmediato un proceso de solicitud
de crédito tan pronto como el comprador se compromete a
iniciar las negociaciones. El concesionario de automóviles
podría utilizar una cantidad estima conservadoramente en
obtener la aprobación de la entidad financiera para un
préstamo de "hasta una cantidad X" Entonces, una vez han
concluido las negociaciones, el único paso restante sería
para llenar la cantidad exacta y obtener el la firma del
comprador. A mucho mejor experiencia de compra para el
comprador de automóviles nuevos.
Se podría escribir de la siguiente manera:
Un importe máximo del préstamo ha sido identificado [Ver
BR033, Determinación de préstamo-importe solicitud].
Y luego, dentro de reglas de negocio que se puede definir la
heurística como "restar valor Kelly Blue Book de Comercio
indicó en un 5% por debajo del precio de etiqueta" o utilizar
el precio medio de venta de la maqueta de automóvil
particular, + 5%, o cualquiera de número de reglas. Estas
normas se pueden cambiar fácilmente sin afectar a los
préstamos caso de uso de aplicaciones.

Normal y otras corrientes

Hay muchas oportunidades en el curso normal de un caso de uso
para ocultar las reglas de negocio. Cada punto en el caso de
uso que podrían hacer que la ramificación de un suplente o el
flujo de excepción representa una decisión. Cada una de estas
decisiones representa la combinación de una o más reglas de
negocio. Para ser más precisos, cada decisión representa un
conjunto de normas que se aplican en conjunto para llegar a
una conclusión (estancia en el flujo normal, o rama a otra de
flujo).
Un caso de uso llamado "transcripción de la conversación de
Examen" para un analista de la CIA tendría un curso normal
que, probablemente, los documentos que la transcripción se ha
revisado, y sigue algún procedimiento de archivo. Si la
transcripción se identifica una "bandera roja" palabra o
frase como "Blackbriar" o "piedra de toque", entonces un
flujo alterno se pondría en marcha. [Sí, lo hice ver The
Bourne Ultimatum este fin de semana.] El desencadenante de
este flujo alternativo puede ser escrito como:
3. Revisión de la transcripción identificado una bandera roja
palabra o frase [Ver US-BR 21744.6, identificación de rojo
las palabras y frases del pabellón].
Entonces esta regla de negocio podría ser definida como una
búsqueda en una base de datos, podría ser filtrada - de modo
que la lucha contra el terrorismo, los analistas buscan
diferentes palabras y frases que la gente en busca de
traficantes de drogas. Esto permite que la revisión de la
transcripción "caso de uso de permanecer estable, mientras
que las reglas para identificar las frases onerosas son
modificados en una base regular. Esto también permite que la
"revisión por una transcripción" de casos de uso que ser
cambiado sin afectar la frase-las reglas de negocio de
identificación.
3,4 elemento clave
El elemento clave de esta reformulación de los casos de uso
es para hacer referencia a los conjuntos de reglas de negocio
que conforman las decisiones individuales, las limitaciones,
y los capacitadores de acción. Estas normas se mantienen en
documentos separados. Estos otros documentos pueden ser
distintos documentos, objetos de nivel superior dentro de un
repositorio de requisitos, o los grupos de reglas gestionados
en un repositorio de reglas.
Más importante aún, las reglas no están ocultos en el caso de
uso. Ocultación de las normas de esta manera hace que sea más
difícil para los desarrolladores para interpretar los
documentos. Se hace casi imposible para los desarrolladores
de resumen de las normas en los servicios de decisión
abstracta. También retrasa el proceso de aprobación de los
requisitos y las normas - tanto inicialmente, y en la gestión
de cambios.
------------------------gfsdgsdf

Separar las reglas de negocio de los requerimientos increneta la agilidad

REF http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/

Separating Business Rules From Requirements Increases Agility

We’ve written in the past about why it is important to gather and manage requirements. In
short, you avoid some costly mistakes, and fix others before they become too expensive.
We’ve also started exploring how business requirements and business rules live and play
together. But why should we bother to separate business rules from requirements? One
reason is to increase your company’s agility.

3.5Benefits of Separating Business Rules

There are some significant benefits to separating business rules from requirements, and we
learn many of them in our interview with James Taylor from a couple weeks ago. James’
new book, Smart (Enough) Systems, focuses on the benefits of automating decisions, but
some of those benefits can be achieved to a lesser extent, just by isolating the business rules
that would then ideally be automated. The main benefit that comes to mind is the increased
agility of the company when it comes to changing their rules and processes. By isolating
the business rules, they become easier to change and manage.

David Wright recently wrote an article at RQNG titled The Business Rules Approach. In it,
he also points to the speed with which a company can change rules – not only as a benefit
of managing business rules separately, but as a need to adapt and respond to today’s
markets.

3.6How Is Agility Increased?

There are two main ways in which agility is increased when separating business rules from
requirements. First, the requirements management process will take less time. Second, the
company can implement changes to their solution more quickly.

3.7Less Time Managing Requirements

One best practice in writing requirements is to write concise requirements. You can’t just
write the requirements with fewer words – that might lead to ambiguity. But you can
dramatically simplify the writing, reviewing, and interpreting of requirements by isolating
the business rules that represent decisions within a requirements document.
As an example, a process flow might include a decision – “Do we have the needed
paperwork to approve the loan?” And that decision might represent a series of rules:

• If the applicant’s credit rating is above 700, we only need a valid driver’s license
and SSN.
• If the applicant’s credit rating is between 600 and 700, we need a recent credit
check, driver’s license, and SSN.
• If the applicant’s credit rating is below 600, we need a cosigner on the loan.
• If a co-signer is required, the co-signer’s credit rating must be above 600.
• If the applicant’s credit rating is below 600, we must run a new credit check, and
have a valid driver’s license and SSN.
• If the co-signer’s credit rating is below 700, we must have a recent credit check for
the co-signer, as well as a valid driver’s license and SSN.
• If the co-signer’s credit rating is above 700, we only need a valid driver’s license
and SSN for the co-signer.
• If a recent (within 6 months of application date) is not available, a new one must be
run.

In a process flow diagram, we could create a series of decision boxes – always requiring the
applicant’s SSN and driver’s license, sometimes requiring a credit check (and some of those
times requiring the credit check to be new), and sometimes requiring a co-signer. We would
then have more branches for the co-signer.

This flow diagram would be pretty complicated. This can be simplified by embedding a
decision tree into the requirements documents. However, you still are applying the
(potentially) heavyweight requirements approval and validation process to this decision
tree. You are also asking your developers to review this decision tree and determine how to
implement it. A great developer will see when it makes sense to abstract these decisions
from the code, and a less-great developer will embed them. In either situation, you’re
asking your developer to spend time thinking about this abstraction – and thinking about
how mutable the particular decisions are.

As an analyst, you are better informed about the mutability of the decisions. By
documenting the decision as a single decision in the requirements document (”Do we have
the needed paperwork?”) that references the enumerated business rules. It is also easier to
review the rules and validate them when they are isolated. Business people who don’t have
backgrounds designing software do find it easier to review these steps when presented in
the context of a decision – and it is easier to grab the context of the decision from a simpler
process flow diagram.

3.8Less Effort To Change

Even if you don’t automate the decision, you still make it much easier to review changes. If
the thresholds change from 700 and 600 to 650 and 550, it is trivial to update the isolated
business rules. It is also an easier process to approve those changes when you are only
updating and reviewing the business rules – and not a broader requirements document.
Developers abstract “magic numbers” like 700 and 600 (in this example) into variables and
constants when they embed them into code. We are doing the same thing by isolating the
business rules from the requirements (which then reference the rules).

What about changes that are more structural in nature? Imagine that we redefine the criteria
– eliminating the 700+ rules, and changing the 600 rule to 650 – and always require a new
credit check for co-signers. Then we also decide to add a new document – say proof of
residence, or proof of employment. If we were managing this within our requirements
document, it would take extra time to validate – and possibly re-implement the solution.
With a solution like James proposes in his book, the business analyst could make the
changes directly into the rules-processing engine and the software would not even need to
be modified. In either case, the approval and change process is faster.