desarrollo de software para empresas

 MODELANDO REQUERIMIENTOS 

CON BUSINESS RULES

y su relacion con los casos de uso ...

                    (Visual modelling technique, D.Tkatch , W.Fang, A.So , IBM)

Este grafico muestra la relacion entre regla de negocio , transacciones informacion y hechos , operaciones de negocio(o procesos) y el usuario

Una regla del negocio es disparada por una transacción . una transacción puede ser iniciada por un usario , un evento o una regla del negocio.

Las transacciones son interacciones formales entre "agentes del negocio" (son aquellos que llevan adelante el trabajo del negocio, otros autores los denominan recursos , facilidades o catalizadores)

Un agente origina una transacción creando un evento de negocios.

LAs transacciones incluyen hechos compuestos de datos.Una transaccion puede considerarse un slot de negocio que tiene slots para hechos. Esos slots pueden ser llenados por uel actor o opor el sistema cuando envia o recibe, y ellos representan el dato intercambiado a traves de la transaccion.

UN  CASO DE USO  es una secuencia de transacciones encastradas para cumplir ciertos objetivos

(Robert Martin: Clean Architecture)

Para integra al ideal de "la empresa computarizada"

-reglas de negocio criticas :existen aunque no esten automatizadas

-Datos de negocio críticos: existirán aunque el sistema no este automatizado.

Son buenos candidatos para un objeto

Una ENTIDAD es un objeto dentro de nuestro sistema computarizado que abarca un pequeño conjunto de reglas criticas operando sobre los datos criticos.

Dicho objeto contiene datos críticos o tiene accesos muy fácil.

La interfaz de la entidad consiste en las funciones que implementan las reglas criticas.

-No se necesita un lenguaje orientado a objetos para crear una entidad, Todo lo que se requiere es 

unir datos críticos con reglas criticas en un único modulo aislado

-Las reglas de negocio que existen para un ambiente automatizado son "casos de uso"

Estos contienen las reglas que especifican cuando y como se invocan a las reglas de negocio criticas (dentro de las entidades)

-los casos de uso no describen como se ve el sistema , solo describen la aplicación de reglas que regulan la interacción entre el usuario y las entidades.

Los casos de uso dependen de las entidades , las entidades no dependen de los casos de uso

La clase  casos de uso acepta estructura de datos para sus entradas y responde estructura de datos como salida. NO dependen de otra cosa.

Esta independencia e critica. el modelo request-response debe ser independiente

Ud se tentara conque dichas estructuras de datos contengan referencias a los objeto "entidad" . Ud pensara que eso tienen sentido porque entidades y el modelo pedido/respuesta comparten tantos datos. PERO ... los propósitos de esos 2 objetos son muy diferentes.

El resultado seria: muchos datos vagabundos y muchas condiciones en su codigo.

CONCLUSION: el código que representa las reglas del negocio  será el corazón del sistema. DEBEN ser el código mas independiente y reusable en el sistema