guÍa metodolÓgica para la especificaciÓn semi-formal

GUÍA METODOLÓGICA PARA LA ESPECIFICACIÓN SEMI-FORM AL

DE PROBLEMAS EMPRESARIALES COMPLEJOS

Documento presentado por:

Jorge Humberto Guío Romero

Con la dirección académica de:

Víctor Manuel Toro Córdoba

al

Departamento de Ingeniería de Sistemas y Computación

Como requisito para la obtención del grado de

MAGISTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Universidad de los Andes Bogotá, Colombia

Julio -2012

ii

DEDICATORIA

A Dios, quien me ha iluminado y dado la fortaleza para alcanzar las metas propuestas

A mis padres Edelmira Romero y Jorge Alfredo Guío (q.e.p.d), a quien les debo lo que soy, gracias

por su amor, dedicación y ejemplo; sin ellos no estaría disfrutando de este momento.

A mis hermanos, sobrino y a mi novia, quienes han motivado la lucha permanente para afrontar

con éxito los retos en mi vida y seguir siendo fuente de inspiración para alcanzar mis sueños.

A mi tía Teresa (q.e.p.d), quien falleció recientemente, por su entereza y carácter para afrontar las

situaciones y mantener unida a la familia Romero.

Jorge H. Guío Romero

iii

AGRADECIMIENTOS

Expreso mis más sinceros agradecimientos a mi Director de Tesis, Dr. Víctor Manuel Toro

Córdoba, por su asesoría, orientación y apoyo, que facilitó el cumplimiento de los objetivos

propuestos para esta investigación.

iv

ÍNDICE GENERAL

ÍNDICE GENERAL ...................................................................................................................... iv

ÍNDICE DE FIGURAS .................................................................................................................. vi

RESUMEN .................................................................................................................................... 8

1 INTRODUCCION ................................................................................................................. 9

1.1 OBJETIVO GENERAL .................................................................................................. 9

1.1.1 Objetivos Específicos ............................................................................................ 10

1.2 OBJETO DE EVALUACIÓN ...................................................................................... 10

2 MARCO TEÓRICO ............................................................................................................. 11

2.1 ANTECEDENTES ....................................................................................................... 11

2.2 QUÉ ES UN MÉTODO FORMAL? ............................................................................. 11

2.3 LENGUAJES DE ESPECIFICACIÓN FORMAL ........................................................ 12

2.3.1 Enfoque basado en modelos .................................................................................. 13

2.3.1.1 VDM-SL ........................................................................................................... 13

2.3.1.2 Z ....................................................................................................................... 15

2.3.1.3 B ....................................................................................................................... 18

2.4 BENEFICIOS DE LOS MÉTODOS FORMALES ........................................................ 19

2.5 INCONVENIENTES DE LOS MÉTODOS FORMALES ............................................. 20

2.6 SITUACIÓN ACTUAL ................................................................................................ 21

3 ENFOQUE METODOLÓGICO ........................................................................................... 22

3.1 JUSTIFICACIÓN ......................................................................................................... 22

3.2 ALCANCE ................................................................................................................... 22

3.3 FINALIDAD ................................................................................................................ 22

4 PROCESO DE DESARROLLO DE LA GUÍA METODOLÓGICA DE ESPECIFICACIÓN SEMI-FORMAL .......................................................................................................................... 25

4.1 ESTIMACIÓN ALCANCE Y OBJETOS DE NEGOCIO ............................................. 25

4.2 ENFOQUE ESTRICTAMENTE FORMAL .................................................................. 25

4.3 ENFOQUE INTERMEDIO .......................................................................................... 27

4.3.1 Descripción del Negocio en Lenguaje Natural ....................................................... 28

4.3.2 Especificación Semi-Formal ................................................................................. 28

v

4.3.2.1 Definición de Tipos ........................................................................................... 28

4.3.2.2 Definición de Esquemas .................................................................................... 29

4.3.2.3 Espacio de Estados ............................................................................................ 30

4.3.2.4 Inicialización de Esquemas ............................................................................... 31

4.3.2.5 Operaciones/Métodos de Esquemas ................................................................... 32

4.3.2.6 Consideraciones Finales .................................................................................... 36

5 CASO DE ESTUDIO: COMPENSACIÓN ELECTRÓNICA NACIONAL INTERBANCARIA ..................................................................................................................... 37

5.1 ANTECEDENTE ......................................................................................................... 37

5.2 ALCANCE E IDENTIFICACIÓN OBJETOS DE NEGOCIO ...................................... 37

5.3 DESARROLLO ESPECIFICACIÓN COMPENSACIÓN ELECTRÓNICA INTERBANCARIA ................................................................................................................. 38

5.3.1 Esquemas y Operaciones Básicos .......................................................................... 39

5.3.1.1 Entidad Autorizada ........................................................................................... 39

5.3.1.2 Usuario - Rol .................................................................................................... 44

5.3.1.3 Ciclos de Operación .......................................................................................... 44

5.3.1.4 Tipo Operación ................................................................................................. 46

5.3.1.5 Operaciones Permitidas ..................................................................................... 48

5.3.1.6 Código de Transacción ...................................................................................... 50

5.3.1.7 Transacción ....................................................................................................... 51

5.3.1.8 Estado Transacción ........................................................................................... 53

5.3.2 Operaciones Esenciales del Negocio ...................................................................... 56

5.3.2.1 Procesar Entradas .............................................................................................. 56

5.3.2.2 Compensación................................................................................................... 61

5.3.2.3 Posición Multilateral Neta ................................................................................. 63

5.3.2.4 Liquidación ....................................................................................................... 69

5.4 Resultados de la Especificación ..................................................................................... 71

6 RESUMEN DE LA GUÍA METODOLÓGICA .................................................................... 72

7 CONCLUSIONES ............................................................................................................... 74

8 TRABAJOS FUTUROS ....................................................................................................... 75

9 REFERENCIAS ................................................................................................................... 75

ANEXO 1. INTERRELACIÓN DE OBJETOS COMPENSACIÓN INTERBANCARIA ............. 77

vi

ÍNDICE DE FIGURAS

Figura 1. Estructura Lenguaje VDM............................................................................................. 14

Figura 2. Especificación reserva habitación. ................................................................................. 14

Figura 3. Esquema de una agenda de cumpleaños en Z. ................................................................ 16

Figura 4. Estado inicial de la agenda ............................................................................................ 16

Figura 5. Adición fecha de cumpleaños ........................................................................................ 17

Figura 6. Demostración exactitud invariante ................................................................................. 17

Figura 7. Especificación consejo estudiantil en B. ........................................................................ 19

Figura 8. Representación Esquema Entidad .................................................................................. 26

Figura 9. Espacio de Estado Entidad ............................................................................................ 26

Figura 10. Método Suspender Entidad Autorizada ........................................................................ 27

Figura 11. Estructura de un Esquema .......................................................................................... 29

Figura 12. Estructura detallada de un Esquema ............................................................................. 30

Figura 13. Estructura Espacio de Estado ....................................................................................... 31

Figura 14. Estructura Inicialización Esquema ............................................................................... 32

Figura 15. Estructura de un Método/Operación............................................................................. 34

Figura 16. Método/Operación Exitoso ......................................................................................... 35

Figura 17. Métodos/Operaciones Fallidos..................................................................................... 35

Figura 18. Objetos de Negocio Compensación Interbancaria ........................................................ 38

Figura 19. Esquema Entidad con identificador .............................................................................. 41

Figura 20. Espacio de Estado Semi-formal Esquema Entidad ....................................................... 41

Figura 21. Inicialización Esquema Entidad Autorizada ................................................................. 41

Figura 22. Método Adicionar Entidad .......................................................................................... 42

Figura 23. Método Entidad Existe ................................................................................................ 42

Figura 24. Método Retirar Entidad ............................................................................................... 43

Figura 25. Método Obligación Pendiente de la Entidad ................................................................ 43

Figura 26. Método General Exitoso .............................................................................................. 43

Figura 27. Método semi-formal Suspender Entidad ...................................................................... 44

Figura 28. Esquema Usuario ........................................................................................................ 44

Figura 29. Espacio de Estado Usuario-Rol ................................................................................... 44

Figura 30. Esquema de Horario según el Tipo de Evento .............................................................. 45

Figura 31. Esquema Ciclo de Operación ....................................................................................... 46

Figura 32. Método Adicionar Ciclo .............................................................................................. 46

Figura 33. Esquema Tipo de Operación ........................................................................................ 46

Figura 34. Espacio de Estado Tipo de Operaciones ....................................................................... 47

Figura 35. Inicialización Tipo de Operaciones .............................................................................. 47

vii

Figura 36. Método Adicionar Tipo de Operación .......................................................................... 47

Figura 37. Método Tipo de Operación Ya Existente ..................................................................... 48

Figura 38. Método Código de Operación Reservado ..................................................................... 48

Figura 39. Esquema Operaciones Permitidas ................................................................................ 49

Figura 40. Método Adicionar Operación a un Ciclo ..................................................................... 49

Figura 41. Método Operación en Ciclo No Permitida ................................................................... 50

Figura 42. Método Consultar Operaciones Permitidas .................................................................. 50

Figura 43. Esquema Código de Transacción ................................................................................. 51

Figura 44. Espacio de Estado Código de Transacciones ................................................................ 51

Figura 45. Inicialización Código de Transacciones ....................................................................... 51

Figura 46. Esquema Transacción .................................................................................................. 53

Figura 47. Esquema Estado Transacción ...................................................................................... 53

Figura 48. Espacio de Estado del Estado de Transacciones ........................................................... 54

Figura 49. Método Adicionar Nuevo Estado de Transacción......................................................... 54

Figura 50. Método Consultar Estado Actual de una Transacción................................................... 54

Figura 51. Método Consultar Estados de una Transacción ............................................................ 55

Figura 52. Esquema Estado de Transacción1 ................................................................................ 55

Figura 53. Esquema Entidad con Atributo Histórico de Transacciones .......................................... 55

Figura 54. Método Adicionar Estado de Transacción a una Entidad .............................................. 56

Figura 55. Método Consultar Estados de una Transacción de una Entidad .................................... 56

Figura 56. Método Procesar Entrada............................................................................................. 58

Figura 57. Esquema Cuenta de Depósito ...................................................................................... 62

Figura 58. Espacio de Estado Cuentas de Depósito ....................................................................... 62

Figura 59. Inicialización Cuentas de Depósito de las Entidades .................................................... 63

Figura 60. Método Consultar Saldo Cuenta de Depósito ............................................................... 63

Figura 61. Esquema Posición Multilateral Neta ............................................................................ 63

Figura 62. Inicialización Posición Multilateral Neta ..................................................................... 64

Figura 63. Método Adicionar Posición Multilateral Neta .............................................................. 64

Figura 64. Método Actualizar Monto Posición Multilateral Neta .................................................. 64

Figura 65. Método Consultar Posición Multilateral Neta de una Entidad....................................... 65

Figura 66. Método Calcular Posición Multilateral Neta ................................................................ 67

Figura 67. Método Re-cálculo Posición Multilateral Neta ............................................................. 68

Figura 68. Método Liquidación .................................................................................................... 70

8

RESUMEN

Con frecuencia los sistemas de información empresariales están inmersos en una lógica de negocio compleja. Para estos casos se requiere de metodologías que, sin caer en extremos puristas, permitan expresar la lógica y los requerimientos de una manera sólida y clara. Se busca un punto medio entre, el poco rigor de métodos como los casos de uso tradicionales, y las complejas especificaciones matemáticas que exageran en el formalismo.

Se necesitan metodologías de especificación semi-formal para representar las entidades del problema y sus propiedades, así como los comportamientos que el sistema debe satisfacer, sin entrar aún en los detalles de cómo lo va a hacer.

Este documento pretende ser una guía metodológica para la construcción de especificaciones semi-formales de problemas empresariales complejos. La propuesta se ilustra sobre un caso del sector financiero colombiano, específicamente del Banco de la República, en su papel de banco central de Colombia.

La finalidad es que esta guía sea una base de ideas para la formulación de especificaciones semi-formales de problemas empresariales complejos.

Lo anterior, para que las personas encargadas de conducir este proceso, vayan construyendo una práctica ingenieril de especificación semi-formal, dentro de las primeras etapas del ciclo de vida de desarrollo de software. teniendo como base el marco metodológico propuesto.

9

1 INTRODUCCION

Para suplir las cada vez más complejas y apremiantes necesidades de las organizaciones, se implementan sistemas de información que requieren para su operación un alto nivel de abstracción y especificación del mundo real.

Dentro de ese proceso se buscan metodologías que apoyen la descripción y representación de las necesidades de la empresa, y especialmente, que puedan enfocarse en los objetivos misionales para las cuales fueron creadas y que enmarcan su competitividad en el sector en el cual se desempeñan.

Estas herramientas y metodologías deben tener un sustento en elementos formales, que facilitan el proceso del diseño y construcción de software y complementan la descripción en lenguaje natural, que por sí sola no es suficiente para expresar de manera precisa los requerimientos.

Los lenguajes de especificación formal, que se soportan en la rigurosidad de la notación matemática, han tenido un resurgimiento mediante su utilización de proyectos complejos dentro de la industria en general. [5] [10]

La presente guía está dirigida a facilitar el proceso de desarrollo de especificaciones semi-formales, ofreciendo un marco conceptual y metodológico sobre el cual un analista se apoye, cuyo producto final se convierta en una fuente válida para la construcción de un sistema de información.

No se pretende establecer una guía rígida, sino plantear un espacio de ideas, teniendo como base la utilización del lenguaje natural, así como las estructuras y reglas de los lenguajes de especificación formal, en particular la notación Z. [8][9]

Para ilustrar lo anterior, se plantea un problema misional complejo, relacionado con la compensación electrónica nacional interbancaria, sobre el que se realiza un caso de estudio de aplicación de la guía.

En su primera parte este trabajo presenta los objetivos y resume el marco conceptual en torno a los métodos y lenguajes de especificación formal; luego, ilustra el proceso de desarrollo y definición específico de la guía metodológica junto con el caso de estudio; finalmente, presenta las conclusiones de los resultados obtenidos y trabajo futuro.

1.1 OBJETIVO GENERAL

Formular y aplicar elementos conceptuales y metodológicos para la elaboración de especificaciones semi-formales de problemas empresariales complejos, que apoyen de manera efectiva el proceso de comprensión y descripción de necesidades de una organización, requeridas para la construcción de sistemas de información.

10

1.1.1 Objetivos Específicos

• Proponer un marco conceptual sobre la especificación semi-formal de problemas complejos.

• Aplicar el marco en el análisis del mecanismo de la compensación electrónica interbancaria utilizado por el banco central de Colombia.

• Hacer un aporte en el campo de la ingeniería de software, de manera que especificaciones semi-formales se vayan convirtiendo en una práctica ingenieril usual. Lo anterior, de manera más acorde con las necesidades actuales, dadas las restricciones de tiempo, costo y alcance de los proyectos de desarrollo de software.

• Plantear recomendaciones para llevar a cabo especificaciones semi-formales buscando un balance entre la teoría y la práctica.

1.2 OBJETO DE EVALUACIÓN

El objeto de la evaluación está relacionado con la especificación del proceso de la compensación electrónica nacional interbancaria, ilustrando la guía metodológica propuesta, que involucra la utilización del lenguaje natural, junto con la rigurosidad matemática ofrecida por el lenguaje de notación Z.

11

2 MARCO TEÓRICO

2.1 ANTECEDENTES En la medida que los problemas del mundo real se complican, el software sobre el que se apoyan para su tratamiento se vuelve más complejo y por lo tanto la probabilidad de error es mayor, produciendo en las organizaciones incremento en costos, tiempo invertido e inclusive pérdidas humanas, por fallas en los componentes del sistema.

Las equivocaciones en el desarrollo de sistemas pueden obedecer a interpretaciones erradas en la fase de especificación de los requerimientos, ya que la documentación, en relación con el entendimiento del problema, si es plasmada solo en lenguaje natural, puede generar ambigüedad sobre el comportamiento esperado de un sistema.

Esas decisiones fallidas son detectadas solo en la fase de pruebas o cuando el sistema ya se encuentra en funcionamiento. Entre más tardío un error es detectado, más difícil suele ser su corrección.

Ante esta perspectiva, el analista tiene que acudir permanentemente a las fuentes de información del negocio, que generalmente se encuentran dispersas a través de procedimientos, normatividad o las mismas personas, lo que dificulta la labor de ingeniería.

Para reducir el riesgo de detección tardía de defectos en los sistemas, se necesitan metodologías y herramientas aplicables en las primeras etapas de desarrollo del software, que describan las necesidades del cliente con una mayor precisión y entendimiento, pero sin los detalles de estructuras de datos y algoritmos.

Estos aspectos conducen a la búsqueda y diseño de mecanismos para elaborar especificaciones acordes con las necesidades de las organizaciones, donde se expresen los requerimientos que intentan solucionar algún problema.

Por lo anterior y considerando que una de las metas de la ingeniería de software es la construcción de sistemas de información que funcionen confiablemente, a pesar de su complejidad, para lograr un entendimiento más preciso de las necesidades se utilizan los métodos formales [1].

2.2 QUÉ ES UN MÉTODO FORMAL?

Cuando se habla de manera general de un método, se hace referencia a un proceso racional que apunta al logro de algún resultado, que en términos de ingeniería de software contempla una perspectiva metodológica, en función de ofrecer un marco estandarizado para adelantar el desarrollo de un sistema.

12

Un método es formal si posee una base matemática estable, soportada por un lenguaje de especificación formal, que permite definir, de manera precisa, nociones como consistencia y completitud.

Entonces, se pueden definir los métodos formales como técnicas que se apoyan en notación matemática rigurosa para especificar y verificar las propiedades y el comportamiento deseado de un sistema. [2]

El uso de este tipo de técnicas ofrece la posibilidad de crear especificaciones claras de las funciones esperadas de un sistema complejo, así como un alto grado de confianza de que un sistema estará conforme a las necesidades que lo motivaron.

En términos generales debe cumplir con un propósito de facilitar la comunicación entre los diferentes actores que intervienen en el desarrollo de un sistema, como son los usuarios, gerentes de proyecto, analistas, ingenieros desarrolladores, entre otros.

Los métodos formales no se aplican solo dentro del contexto de la fase de especificación del ciclo de vida de desarrollo de software y pueden ser utilizados en otras fases, donde la rigurosidad y formalidad también son necesarias para lograr un producto fiable.

El principal componente es un lenguaje formal de especificación, el cual viene con una bien fundamentada y segura semántica, especialmente si está basado sobre teorías matemáticas bien tratadas.

2.3 LENGUAJES DE ESPECIFICACIÓN FORMAL

Una especificación formal debe poder representar en algún nivel de abstracción el conjunto de elementos del problema y sus propiedades, así como los comportamientos que el sistema debe satisfacer, sin entrar aún en el detalle de cómo lo va hacer, a través de un lenguaje formal, teniendo en cuenta para su formalidad tres componentes [3]:

• “reglas para determinar la gramática bien formada de las sentencias (sintaxis)”. • “reglas para interpretar la sentencias en una forma precisa y significativa dentro del

dominio considerado (semántica)”. • “reglas para inferir información útil de la especificación (demostración)”.

Para propósitos de una especificación, los lenguajes de especificación formal se fundamentan en la notación matemática, que está basada en principios de teoría de conjuntos, lógica de predicados, relaciones y funciones.

La importancia de la especificación, dentro del ciclo de vida de desarrollo de un sistema de información, radica en su capacidad de precisar con claridad los requerimientos

13

identificados y sirve como puente de comunicación para analistas, diseñadores y desarrolladores.

Si los requerimientos no son bien entendidos y plasmados, se abrirán brechas entre lo documentado y lo que realmente se quiere. Esto es más evidente cuando nos enfrentamos a problemas complejos que requieren un gran nivel de abstracción.

Si bien en la literatura es posible encontrar diferentes clasificaciones de lenguajes formales, de manera general se pueden agrupar en dos categorías: Enfoque basado en modelos y orientado a propiedades [5]. Para efectos del presente trabajo solo nos centramos en el primer enfoque.

2.3.1 Enfoque basado en modelos

En este enfoque los objetos matemáticos se utilizan para construir un modelo del sistema, describiendo de manera abstracta el estado del mismo, así como las operaciones que inciden sobre el estado. Los objetos son estructuralmente similares al software requerido por lo que son de gran utilidad al momento de utilizarlos en fases de diseño y desarrollo.

Los lenguajes más representativos que pertenecen a esta categoría son: VDM-SL, Z y B, junto con sus derivaciones, como consecuencia de la evolución que han tenido y que describimos a continuación.

2.3.1.1 VDM-SL

El Vienna Development Method – Specification Language (VDM-SL) es un lenguaje estandarizado desarrollado a mediados de la década de los 70, en el laboratorio de desarrollo de IBM en Vienna. Es reconocido por la International Standard Organization (ISO) (13817-1:1996) [4] y utilizado para la especificación formal y el desarrollo de sistemas de software secuencial.

Maneja la abstracción en 2 niveles:

• Representacional: Describe los objetos matemáticos en el dominio de un sistema de software, cuyo modelo es construido a partir de los tipos de datos definidos en el lenguaje.

• Operacional: Describe el comportamiento observable del modelo a través de funciones y operaciones.

Por su estructura en bloques (figura 1), posibilita un refinamiento que está más próximo a la implementación final de un sistema.

A nivel de types maneja 2 categorías: simples y compuestos. Los primeros, son los elementos básicos que se definen en el lenguaje y corresponden a tipos como números

14

enteros, números reales, booleanos, entre otros. Los segundos, se construyen a partir de tipos previamente incluidos en la especificación.

En values se definen variables pertenecientes a un dominio sobre el cual se asocia un valor. Las funciones y operaciones son similares, con la diferencia de que la función no accede variables globales, en cambio las operaciones sí y las puede cambiar. En state se manifiestan los cambios sobre el modelo, de acuerdo con los requerimientos del problema.

Figura 1. Estructura Lenguaje VDM.

Teniendo en cuenta su significado, una especificación VDM para un problema consiste de un estado, el cual refleja el modelo del problema a través de sus tipos de datos representados y de operaciones sobre el estado, que ponen de manifiesto el comportamiento del sistema [5].

Los valores de las salidas, en un momento dado, no dependen exclusivamente de los valores de las entradas, sino también del estado anterior. A manera de ejemplo, veamos en la figura 2 un caso de un sistema de reserva de hotel.

Figura 2. Especificación reserva habitación.

En este caso el estado del sistema consiste de un número determinado de habitaciones con sus posibles estados, donde el estado de cada habitación es available o occupied. La operación registrar un cuarto (book-room) está especificada a través de dos conjuntos de

15

aserciones: pre y post condiciones, que son invariantes1 que deben cumplirse antes y después de ejecutada la operación en el modelo.

Su aplicabilidad sobre aplicaciones industriales, han conducido a ampliar el uso de VDM para soportar el manejo de sistemas concurrentes y orientado a objetos a través de una notación extendida, VDM++.

Algunos de los casos en los cuales VDM ha sido aplicado: [6]

• Especificación de control de municiones, para describir los requerimientos de seguridad en la adición y retiro de explosivos en sitios de almacenamiento.

• Modelamiento de sistemas de enclavamiento de trenes, sus requerimientos de seguridad

• Especificación de un algoritmo para el esquema Voto Único Transferible (STV) en la realización de elecciones.

• Especificación del estándar MAA para la autenticación de mensajes, usado en el área de seguridad de datos en la banca.

• Sistema de negociación del Back-office del sistema CSK.

Para soportar la especificación en VDM-SL algunas de las herramientas comerciales que se pueden encontrar son: IFAD, SpecBox, Cornell Synthetizer.

2.3.1.2 Z

Z fue originado en el laboratorio de cómputo de la Universidad de Oxford a finales de la década de los 70, con el propósito de apoyar el diseño y desarrollo de especificaciones claras, basado en la teoría de conjuntos y la lógica matemática. Es un lenguaje de especificación conceptualmente claro y bien definido matemáticamente que al igual que VDM ha sido reconocido por la ISO como lenguaje estándar (ISO/IEC 13568:2002). [7]

Z también maneja dos niveles de abstracción: el representacional, a través de la definición de tipos, constantes globales y declaraciones de espacio de estados, donde los tipos son interpretados como conjuntos o funciones y el operacional, a través de las definiciones de funciones y operaciones.

En la notación Z se distinguen dos lenguajes: un lenguaje matemático, el cual es usado para describir varios aspectos de diseño como son los objetos y las relaciones entre ellos, y el lenguaje de esquema, que es usado para estructurar y componer las descripciones como son: recopilación de piezas de información, encapsulamiento y el nombramiento para su reutilización. [8]

1 Una invariante sobre un objeto es una aserción que restringe el comportamiento de ese objeto, pero que no cambia al aplicar una serie de transformaciones.

16

En su estructura básica, los objetos matemáticos y sus propiedades se definen en lo que se denomina un esquema (schema), a través del cual puede describir el estado del sistema a especificar, y las formas a través de los cuales ese estado puede cambiar.

Un esquema tiene un nombre, que es único; una estructura, descrita a través de un conjunto de declaraciones y una propiedad descrita por un conjunto de predicados, a través de los cuales se relacionan los invariantes entre los componentes de su estructura.

El nombre del esquema puede ser usado en cualquier momento de la especificación, posterior a su declaración. A través de esta estructura se posibilita dividir la especificación en piezas más pequeñas y manejables, lo que facilita realizar especificaciones modulares. [8]

Para su entendimiento general, se presenta un ejemplo sencillo, a través de una agenda, que permite el registro de cumpleaños de las personas y genera un recordatorio cuando llega el día de celebración.[9] La estructura del sistema descrito es:

Figura 3. Esquema de una agenda de cumpleaños en Z.

La variable known es el conjunto de nombres con cumpleaños registrados y birthday es una función que, aplicada a ciertos nombres, retorna la fecha de cumpleaños asociada a ellos. En la parte de abajo se expresa una invariante en la que el conjunto known pertenece al dominio de la función birthday, en este caso el conjunto NAME.

El estado inicial del sistema, donde el conjunto inicial de la agenda es vacio, se define bajo el siguiente schema:

Figura 4. Estado inicial de la agenda

Si se quiere ampliar la funcionalidad se definen operaciones, que de acuerdo con la sintaxis permiten o no el cambio de valores en las variables, por ejemplo, adicionar una fecha de cumpleaños:

17

Figura 5. Adición fecha de cumpleaños

Recibe un nombre y una fecha, y a través de las invariantes especifica las condiciones que deben cumplirse, por ejemplo, como precondición, que la persona no esté incluida previamente en el conjunto known, para adicionar su nombre y fecha de cumpleaños.

A través de Z es posible expresar la exactitud de una especificación. Para el ejemplo en cuestión, la invariante knwon = dom birthday debe mantenerse luego de adicionar un nuevo nombre, entonces si tomamos los valores de la condición después de aplicada la operación AddBirthday, tendríamos que known’= dom birthday’.

Por teoría de conjuntos se demuestra que knwon′= known U {name?}, que indica que el conjunto de nombres nuevo (known′) es la unión del conjunto anterior (known) adicionado con el nuevo nombre, como se muestra a continuación:

Figura 6. Demostración exactitud invariante

La utilización de invariantes entre el universo de estados no forman parte de la implementación futura del sistema, pero son claves para su entendimiento en la organización y posterior utilización para el diseño y desarrollo de sistemas. Los objetos de datos son descritos en tipos de datos matemáticos como son conjuntos y funciones.

Derivaciones del lenguaje Z han llevado a la creación de lenguajes como Mooz, Object-Z y Z++ para el manejo de estilos orientados a objetos. Algunas aplicaciones en los cuales Z ha sido utilizado:

• Modelamiento y verificación de arquitectura para administración de firmas digitales.

• Sistemas de facturación automatizados para empresas de consultoría.

• Especificación y refinamiento de sistemas de tiempo real: Artris, UNX File system.

• Proyectos de software de computación distribuida, en el diseño de servicios de red.

• El proyecto Customer Information Control System (CICS) de IBM.

18

Herramientas de soporte para la especificación del lenguaje Z que se utilizan actualmente son: ProofPower, Zeta word tools, Zeta, entre otros.

2.3.1.3 B

Desarrollado por Jean-Raymond Abrial a comienzo de la década de los 90, es un lenguaje que está diseñado para cumplir la meta de especificación y refinamiento junto con demostración. Está basado sobre formalismo de máquinas abstractas, a través de teoría de conjuntos y lógica de predicados de primer orden, donde cada máquina incluye datos y operaciones encapsuladas e invariantes.

La especificación está definida como una colección de máquinas abstractas, tal como se puede apreciar en el siguiente caso ejemplo de un consejo estudiantil, que consiste de un conjunto de estudiantes, donde uno de sus miembros es presidente del mismo (figura 3).

Cada máquina abstracta tiene un nombre único, que puede incluir parámetros, los cuales pueden tener restricciones, especificados a través de la clausula CONSTRAINTS, que para el ejemplo, es el parámetro limit que se utilizará para validar que el número de estudiantes del consejo no sea mayor al valor de limit.

La definición de tipos básicos se realiza dentro de la estructura SETS, que en este caso define el conjunto de estudiantes. A través de council y president define las variables de estado de la máquina y con la clausula INVARIANT se especifican las relaciones entre las variables de estado, conjuntos y parámetros, las cuales deben cumplirse siempre.

El estado inicial de la máquina viene definido con el consejo estudiantil como un conjunto vacio. Al igual que en los otros lenguajes se definen operaciones, como en este caso la adición de una persona al consejo.

Cada operación debe satisfacer una(s) precondición(es), como en el caso de ejemplo, donde la persona debe ser estudiante, no pertenecer al consejo y la cantidad de estudiantes del consejo ser menor al límite establecido para poderla adicionar.

Estas condiciones si se cumplen permiten incorporar el estudiante al consejo después de la clausula THEN, y si es el primer miembro del consejo, es asignado como presidente[5].

Como se puede apreciar B tiene un poder expresivo para la especificación y se apoya en la demostración de exactitud del sistema que está siendo especificado.

Algunos ejemplos de su uso en la industria son:

• Especificación y desarrollo sistema de control del metro de Paris.

• Aplicaciones de tarjetas inteligentes.

19

• Validación de estrategias en aplicaciones del espacio.

• Evaluaciones de seguridad.

• Sistemas de facturación automatizado para empresas de consultoría.

Figura 7. Especificación consejo estudiantil en B.

Al igual que con Z y VDM, ha habido extensiones de B a través del lenguaje Event-B. Algunas de las herramientas de soporte para B son Atelier-B y B-Toolkit.

Los lenguajes anteriormente descritos son usados para definir tipos de datos y mostrar el efecto de las operaciones sobre esos tipos; sin embargo, carecen de aspectos para expresar el orden en el cual las operaciones son ejecutadas.

Otros lenguajes, como CSP pueden mostrar el orden de ocurrencia de los eventos, pero carecen de la habilidad para manejar tipos de datos y operaciones abstractas complejas.

2.4 BENEFICIOS DE LOS MÉTODOS FORMALES

Los métodos formales permiten escribir de manera rigurosa, precisa y completa especificaciones para facilitar el desarrollo de software.

Permiten demostrar que el sistema bajo consideración satisface las propiedades que intenta satisfacer, al nivel de especificación de un lado (semántica) y al nivel de código del otro (sintaxis).

20

Ayuda a la organización a validar que están trabajando con especificaciones correctas; a que el producto entregado cumple con las especificaciones dadas. Un producto puede ser entregado con la demostración de que satisface las propiedades esperadas a realizar.

Los esfuerzos posteriores de pruebas, mantenimiento y hasta de código pueden reducirse significativamente, ya que se obtiene un mejor control sobre esas etapas y la documentación llega a ser más confiable.

Permiten condensar en un solo documento la información en torno a un problema o necesidad, que puede estar disperso a lo largo de una organización a través de políticas, normas, procesos, guías e inclusive las mismas personas.

2.5 INCONVENIENTES DE LOS MÉTODOS FORMALES

Si bien los métodos formales ofrecen indicadores del soporte para mejorar varias etapas del ciclo de vida de desarrollo de software este no es un remedio, especialmente cuando nos enfrentamos a problemas complejos. Se debe mantener presente que siempre hay distancias entre una especificación formal y el objeto que está supuesto a representar.

La certeza de lo correcto o apropiado de una especificación puede ser aceptado como relevante si ha sido validado por un proceso que involucra una cuidadosa lectura, reformulación y confrontación.

Cuando un nuevo método formal es considerado, el primer obstáculo es llegar a estar completamente familiarizado con la notación. Si bien los conceptos utilizados por los lenguajes formales de lógica y teoría de conjuntos son básicos, el débil conocimiento de estas nociones, puede ser un obstáculo a la hora de expresar las especificaciones en términos matemáticos.

Más allá de esta consideración, se requiere de una apropiada aplicación, el cual incluye aspectos pragmáticos – manipulación de las herramientas- y aspectos teóricos.

Muchos de los obstáculos que se encuentran cuando se está usando un método formal, son de hecho un reflejo de las dificultades que son inherentes del problema que se pretende solucionar.

Modelar un problema ocurre justo porque la situación es de hecho más complicada de lo que puede aparecer a simple vista. Por eso se recurre a la introducción de conceptos abstractos o complejos, denotados por símbolos matemáticos, que ofrecen varios grados de nivel de abstracción y complejidad.

La elaboración de una especificación a través de métodos formales puede requerir de amplia dedicación para formular los conceptos de negocio en términos matemáticos y dadas

21

las restricciones de tiempo, espacio y alcance existente hoy en día en los proyectos de desarrollo de software, puede ser un inconveniente a la hora de su aplicación.

Hoy en día hay una mayor inmediatez para generar productos en cada etapa de construcción de software y no es fácil contar con la disposición de recursos para el desarrollo de especificaciones formales, ceñidos rigurosamente al concepto matemático.

2.6 SITUACIÓN ACTUAL

Los métodos formales han estado ligados con la aparición de los computadores y su estudio se ha dado desde la segunda mitad del siglo XX, tiempo en el cual han alcanzado un nivel de madurez que les ha permitido ser usados en diferentes sectores como el de transporte, telecomunicaciones, biología, energía, seguridad, entre otros.

Por ejemplo, en los últimos años ha habido una mayor demanda por desarrollar aplicaciones más complejas y críticas para la seguridad en áreas como navegación y control aeroespacial, empresas de vigilancia y plantas nucleares. El Common Criteria for Information Techonology Security2, ha venido recomendando su aplicabilidad en los diferentes niveles de evaluación de seguridad.

Desde el primer congreso mundial sobre métodos formales, realizado en 1999, periódicamente se vienen realizando simposios organizados por la asociación de Métodos Formales de Europa (FME) en los cuales se ha confirmado el interés creciente en otras áreas de aplicación emergentes, como comercio electrónico, robótica, tarjetas inteligentes y ha permitido retroalimentar en los conceptos y sus herramientas de aplicación.

Los lenguajes de especificación formal conservan su vigencia y utilidad y si bien luego de un período de auge en las décadas de los 80 y 90, tuvieron un descenso a comienzos del 2000 y han venido retomado su camino.

Lo anterior, en razón a que la industria ha visto las ventajas de aplicabilidad sobre el desarrollo de aplicaciones grandes y complejas, como en la parte de modelamiento y simulación, que son necesarios dentro de las buenas prácticas en la industria de la ingeniería como lo reseña Bowen[10].

Todo esto va de la mano con la rigurosidad y disciplina que se debe tener en la aplicación de los métodos formales, aspectos que pueden ser recompensados al final de un proyecto.

2 El Common Criteria (CC) es un esfuerzo conjunto de países de Europa y Norte América para definir un marco de trabajo, basado en 7 niveles de requerimientos de seguridad, que permite evaluar sistemas de información y determinar cuan satisfactorio es un producto. Ha estado vigente como un estándar internacional (ISO/IEC15408) desde 1999.

22

3 ENFOQUE METODOLÓGICO

3.1 JUSTIFICACIÓN

Hay problemas empresariales complejos que no se pueden describir correcta y suficientemente con el mecanismo de casos de uso, los cuales tienen debilidades para describir como los objetos cambian en términos de transformaciones de un estado a otro, entre otras.

El análisis realizado con base en la revisión bibliográfica mostró que las especificaciones formales son demasiado complejas y accesibles solo a especialistas, lo cual motiva a que se necesiten herramientas que describan las necesidades del cliente con un mayor entendimiento.

Se quiere buscar un punto intermedio entre la utilización del lenguaje natural y las bondades ofrecidas por las estructuras matemáticas.

Si bien se han diseñado lenguajes de notación formal, como Z, B, VDM, entre otros, que han evolucionado según su orientación, no se encontraron investigaciones que aborden de manera metodológica la forma como se debe desarrollar una especificación, objeto de la presente investigación.

Si bien cada lenguaje de especificación formal ofrece alternativas para el modelamiento de una especificación, se carece en la industria de un instrumento de apoyo que, independiente del lenguaje utilizado, establezca pautas a seguir para describir problemas complejos.

Por lo anterior, se plantea el desarrollo de una guía metodológica para el soporte de especificaciones formales de problemas empresariales complejos y que se ejemplifica en el desarrollo de un caso dentro del sector financiero junto con otras consideraciones para hacer un uso efectivo y que se pueda aplicar de manera general.

3.2 ALCANCE

Con la guía metodológica se busca suministrar un marco de actuación en el desarrollo de sistemas de información, que pueda ser utilizado por los analistas en el entendimiento y especificación de problemas de negocio, en términos más concretos y entendibles, cuyo producto final sea consultado por las áreas del negocio, a fin de validar la especificación de sus necesidades y por los desarrolladores en la construcción de los sistemas de información.

3.3 FINALIDAD

Como se desee una descripción más precisa sobre las propiedades y comportamientos de un sistema, adquiere mayor importancia los métodos de especificación formal, que aprovechan

23

la rigurosidad matemática para ayudar a describir lo que el sistema debe hacer, sin necesidad de indicar cómo se debe llevar a cabo, partiendo de unas reglas de negocio.

Establecer una buena especificación implica un conocimiento de las necesidades del usuario, quien no siempre tiene claro desde el principio cuales son los requerimientos a satisfacer.

La escogencia de un lenguaje de especificación es un factor importante para el éxito de un desarrollo completo, el cual debe contemplar o recoger muchos aspectos de los requerimientos y tener un modelo apropiado para estudiar el comportamiento del sistema y establecer la validez de las propiedades deseadas.

Teniendo en cuenta las implicaciones en el desarrollo de una especificación formal, atada a la notación matemática requerida por los lenguajes de especificación, se quiere buscar un equilibrio entre la utilización del lenguaje natural y las bondades ofrecidas por las estructuras matemáticas.

Lo anterior, motivado en que una especificación formal debe relacionar los objetos matemáticos a las características futuras del diseño como son: estructuras de datos, estados del sistema, propiedades y operaciones, los cuales van acompañados con descripciones en lenguaje natural para ayudar a explicar el propósito de las estructuras y objetos matemáticos especificados.

Esto posibilita que se logre una especificación entendible, no solo por quien efectúa la documentación de la especificación, sino por las personas relacionadas con el problema, que en algún momento pueden requerir consultar el producto especificado. Enfocarse en un solo extremo de la balanza puede no lograr el entendimiento de una especificación por parte de los interesados.

Si bien las estructuras matemáticas no están orientadas a una representación en términos de programación, permiten razonar efectivamente acerca de la manera en que el sistema se debe comportar.

Teniendo en cuenta que todos los lenguajes de especificación formal analizados, hacen uso de la teoría de conjuntos y la notación matemática, se tuvo en cuenta la valoración sobre la claridad conceptual de la notación Z y el manejo de sus estructuras, para efectos de la propuesta metodológica a presentar.

Z utiliza la lógica de predicados para describir el efecto de cada operación, pero valerse de la notación matemática para lograr mayor precisión y evitar ambigüedad, no es lo suficientemente práctico para expresar las invariantes del sistema, y al contrario, puede haber reglas de negocio que al ser modeladas matemáticamente confunden al lector.

24

Por ello, no se va a utilizar Z en toda su extensión, dado que más que la notación matemática en sí, lo que interesa es el rigor de su estructura.

Lo que se busca es una forma “simplificada pero rigurosa” de especificación semi-formal, que usa aspectos de la notación, pero que se da ciertas licencias en los aspectos estrictamente formales, apoyándose en el lenguaje natural para expresar reglas de negocio, que posibilite un equilibrio entre lo formal y lo no formal y enriquezca la especificación.

Lograr ese equilibrio no es fácil y llegar a plantear hasta donde se es formal y hasta donde informal, requiere un uso efectivo y práctico tanto de la notación formal, sin ser “esclavo” de la expresión matemática, como de la notación textual. Lo anterior, involucra un proceso iterativo de revisión hasta lograr el nivel de especificación deseada.

La notación informal es útil en la medida que permite a la gente ser más claro sobre los puntos delicados, apoyado en la notación formal, sin ser dependiente de esta y en sí misma no debe ser un obstáculo pero requiere un esfuerzo para expresar claramente lo que se quiere. Una explicación debe llegar al nivel de detalle donde no queden puntos difusos pero no más allá.

Es difícil evidenciar a nivel de especificación formal aquellos requerimientos no funcionales como disponibilidad, desempeño, portabilidad, escalabilidad, entre otros. Para ello, se deben utilizar otro tipo de herramientas.

Finalmente, dada la complejidad que involucra para una organización el desarrollo efectivo de sistemas de información, en torno a problemas misionales de la organización, el presente trabajo pretende establecer un modelo sobre la elaboración de especificaciones semi-formales, que pueda aplicarse sobre problemas empresariales complejos, independiente del tipo de necesidad a resolver.

25

4 PROCESO DE DESARROLLO DE LA GUÍA METODOLÓGICA DE ESPECIFICACIÓN SEMI-FORMAL

4.1 ESTIMACIÓN ALCANCE Y OBJETOS DE NEGOCIO

Como requisito previo al desarrollo propio la especificación, está el entendimiento claro de las reglas del negocio, para determinar el alcance y establecer los conceptos básicos importantes dentro de ese alcance. En este momento es importante establecer qué es lo que se requiere y qué no se va a considerar, para su acotamiento.

Luego se identifican los objetos del negocio con sus atributos, es decir, aquellos elementos representativos indispensables que interactúan con otros objetos y sobre los cuales se definen los métodos que ejercen acciones sobre los estados de esos objetos.

En la determinación de los objetos es importante valorar que tengan características propias, que los hace únicos y que son requeridos para obtener información o modificar aspectos del mundo que se quiere modelar.

Estos se encuentran a través de la normatividad existente de la organización que se está analizando, así como su identificación con entrevistas con las personas relevantes del área de negocio. Una clave para su caracterización es a través de los sustantivos.

La identificación de las operaciones o métodos, asociados a los objetos de negocio, van de la mano con las acciones requeridos a realizar, por parte de los objetos. En la literatura de la organización o a través del levantamiento de información se encuentran relacionados como verbos.

Se debe tener clara la importancia de cada objeto identificado y su existencia con otros objetos, de manera que tenga sentido darle “vida” en una especificación. Objetos aislados no deben desarrollarse.

La interrelación entre los objetos es importante porque permite establecer las futuras dependencias y relación de atributos clave cuando se lleguen a crear las estructuras de datos.

4.2 ENFOQUE ESTRICTAMENTE FORMAL

Una vez determinado el alcance, identificado los objetos con sus atributos, así como las propiedades e interrelaciones, se empieza a desarrollar la especificación.

Como punto de partida, se hizo un primer intento basado estrictamente en la rigurosidad matemática tanto del lenguaje matemático, como del lenguaje de esquema de la notación Z, referidos en el numeral 2.3.1.2, teniendo como base los objetos de negocio sus operaciones.

26

A manera de ejemplo, está el caso en el que se define un esquema Entidad, que contiene un conjunto de atributos que caracterizan su definición con su correspondiente tipo, los cuales se dan como previamente definidos. Estos atributos se distinguen porque su primera letra viene en letra minúscula. Los tipos de los atributos vienen en mayúsculas.

Entidad calidadEA : CALIDADEA

codigoCompensacion : STRING

codigoPlaza : STRING

codigoSebra : STRING

estadoEntidad : ESTADOENTIDAD

fechaVinculacion : FECHA

fechaRetiro : FECHA

nombreEA : STRING

codigoPlaza ≠ codigoSebra

codigoCompensacion ≠ codigoSebra

codigoPlaza ≠ codigoCompensacion

Figura 8. Representación Esquema Entidad

Como es necesario establecer el conjunto de todas las Entidades dentro del sistema de compensación, se define un esquema EntidadAutorizada para describir su “espacio de estado” del esquema.

EntidadAutorizada entidadesAutorizadas : ℙEntidadAutorizada

∀ea1, ea2 : EntidadAutorizada | ea1 ∈ entidadesAutorizadas ∧ ea2∈entidadesAutorizadas ⦁

ea1 = ea2 ⇔ ea1.codigoSebra = ea2.codigoSebra ∧

ea1. codigoCompensacion = ea2. codigoCompensacion ∧

ea1.nombreEA = ea2.nombreEA

Figura 9. Espacio de Estado Entidad

Una de las operaciones asociadas, es la de suspender una entidad autorizada, a través del cambio de estado de la misma a Suspendido, con lo cual se impide el recibo y procesamiento de las órdenes de transferencia electrónica de fondos que dicha entidad genere.

A nivel de las propiedades, dentro de la precondición se debe cumplir que la entidad asociada al nombre de Entidad que se recibió de entrada, pertenezca al conjunto de Entidades Autorizadas y que no se encuentre previamente suspendida.

27

La post-condición se expresa en términos de que en el nuevo estado del conjunto de entidades autorizadas, la Entidad a suspender es eliminada del conjunto actual y una nueva entidad autorizada es creada, con el mismo nombre y el nuevo estado asociado, la cual se une al conjunto actual.

Lo anterior, basado en la expresión µ, de la notación Z, cuya semántica es similar a la requerida en la comprensión de conjuntos, excepto que µ retorna un único valor, el cual es determinado por la expresión que viene después del símbolo ⦁. [5]

(µ<declaración> / <predicado> ⦁ <expresión>)

SuspenderEA Δ EntidadAutorizada

nombreEA? : STRING

∃ ea : Entidad | ea ∈ entidadesAutorizadas ∧

ea.nombreEA = nombreEA? ∧

ea. estadoEntidad ≠ Suspendido ⦁

entidadesAutorizadas′ = entidadesAutorizadas ∖ {ea} ∪

{( μea:EntidadAutorizada | ea.nombreEA = nombreEA? ∧

ea.estadoEntidad = Suspendido)}

Figura 10. Método Suspender Entidad Autorizada

En este caso, la notación matemática a nivel de los predicados, es precisa, sin embargo no resulta ser lo suficientemente intuitiva y clara para un lector que no esté familiarizado con la notación Z. Lo anterior , entendiendo que de acuerdo con la sintaxis y semántica de Z, para suspender una entidad, hay que realizar la sustracción de la entidad ea, dentro del nuevo conjunto de entidades autorizadas, y luego crearla con el nuevo estado.

Adicionalmente, para expresar un concepto relativamente sencillo, el proceso y tiempo requerido para formular de esta forma la especificación no es el ideal y probablemente se requiere de una mayor experiencia en el desarrollo de especificaciones para que este proceso sea más expedito para quien realiza la especificación.

Con lo anterior, se entra a cuestionar la relación costo/beneficio de ceñirse exclusivamente a la notación matemática, puesto que no se está buscando el concepto matemático como tal, sino lograr un mejor entendimiento para todos los interesados en la especificación.

4.3 ENFOQUE INTERMEDIO

De acuerdo con los resultados encontrados en el numeral anterior, se hizo necesario plantear un enfoque intermedio, donde se busca lograr un equilibrio entre el lenguaje natural y las bondades de la estructura matemática planteada en Z. Bajo esta perspectiva,

28

se hizo un análisis de la situación que un lector espera encontrar, como se desarrolla a continuación.

4.3.1 Descripción del Negocio en Lenguaje Natural

En primera instancia se hace una descripción intuitiva del negocio en términos del lenguaje natural, para explicar la parte del problema que se está atendiendo, así como introducir la descripción formal de los componentes del esquema u operación a representar, basados en Z.

Esta narrativa no debe ser extensa, pero sí lo suficientemente clara para contextualizar al lector de la parte del negocio que se está analizando en ese momento, de manera que los usuarios no técnicos, puedan evidenciar que está plasmado en el texto la descripción de la necesidad que se espera solucionar.

4.3.2 Especificación Semi-Formal

En segundo término, se representa la especificación “semi-formal” introducida en la descripción narrativa, con base en los elementos del lenguaje de esquemas de la notación Z, que ayudan a promover un buen estilo de especificación, pero sin entrar en la rigurosidad matemática como se describe a continuación.

Cada objeto de negocio identificado, junto con sus operaciones, se representa en la especificación de manera independiente, utilizando de manera adaptada la caracterización de esquemas de Z. De esta manera se posibilita que el desarrollo se pueda presentar objeto por objeto y se facilite la relación entre los esquemas definidos.

4.3.2.1 Definición de Tipos

Cada atributo de los objetos de negocio identificados pertenece a algún tipo, el cual se deben definir previamente para poder referenciarlo en los esquemas. Dentro de sus características se encuentran:

• Siempre se escribe en mayúsculas. Si el nombre del tipo básico es una palabra compuesta, las palabras pueden ir seguidas o unidas entre sí por el símbolo “_”.

• Si el tipo es un conjunto dado o un tipo básico, entonces se escribe su nombre entre brackets:

[<nombre tipo>]

• Si el tipo básico tiene valores predeterminados, se define de la siguiente forma:

<nombre tipo> ::= <valor1> | <valor2> | …… | <valorN>

29

• Si el tipo corresponde a un conjunto existente, lo asocia un objeto existente y establece que los 2 son iguales.

<nombre tipo> == <identificación o declaración del conjunto>

• Otra forma de establecer un tipo es a través de una definición axiomática, que incluye una restricción sobre el objeto que está siendo introducido y se representa así: [8]

declaracion: Define el nombre de la constante, junto con su tipo

predicado: Expresa las retricciones sobre el objeto(s) introducido en declaracion

4.3.2.2 Definición de Esquemas

Luego de declarados los tipos básicos, se hace la definición de los esquemas, que vienen a representar los objetos de negocio identificados. En la organización de un esquema se distinguen las siguientes partes: el nombre que identifica al esquema, la estructura donde se relacionan las declaraciones y la parte de propiedades asociadas con las invariantes.

<Nombre Esquema> declaraciones

propiedades

Figura 11. Estructura de un Esquema

• El nombre es único y la primera letra debe estar en mayúscula. Si el nombre del esquema es una palabra compuesta, las siguientes también deben comenzar con una letra mayúscula. Las palabras pueden ir seguidas o unidas entre sí por el símbolo “_”.

Cuando se está definiendo un esquema se sabe que se está refiriendo a objetos de negocio, por lo que el nombre que lo representa se debe escribir como un sustantivo, para que se permita su identificación de una manera más intuitiva.

• Las declaraciones relacionan los atributos que cada objeto de negocio tiene, junto con el tipo al que pertenecen y se escriben con la primera letra en minúscula. Si el nombre del atributo es una palabra compuesta, las palabras restantes también deben comenzar por una letra en mayúscula. Las palabras pueden ir seguidas o unidas entre sí por el símbolo “_”.

Debe indicarse el atributo(s) que hace único la identificación del objeto, de manera que permita al ingeniero desarrollador ir estableciendo pautas que le ayuden a establecer las posibles llaves, dentro del esquema de estructura de datos al momento del diseño e

30

implementación futura. En la estructura de esta guía se distingue el atributo identificador colocando al frente del mismo la notación [único].

Ejemplo de atributo y su tipo:

estadoEntidad : ESTADOENTIDAD

• En el área de propiedades, se describen las invariantes relacionadas con los atributos del esquema creado y que restringen su comportamiento, condiciones que deben ser mantenidas conforme el sistema cambie de un estado a otro. Para hacer referencia al atributo de un esquema, solamente se escribe el nombre del atributo.

Estas invariantes por lo general se escriben en términos de notación matemática para expresar sus relaciones, sin embargo, como lo que se busca es un mayor entendimiento, se da libertad para describir estas invariantes en lenguaje natural, cuando se considere que al utilizar la notación matemática se puede confundir al lector3.

Una representación más detallada de la estructura del esquema es como sigue:

<NombreEsquema> <idEsquema> : <TIPO1> [único]

<nombreAtributo1 >: <TIPO2>

……

<nombre_Atributo_n>: <TIPOM>

Invariante (en términos de los atributos)

Figura 12. Estructura detallada de un Esquema

Esta estructura es utilizada de manera equivalente en el espacio de estado, inicialización y métodos de un esquema, que se describen a continuación.

4.3.2.3 Espacio de Estados

La definición de un esquema con sus atributos, caracteriza la definición del objeto que se pretende representar, no obstante, como se quiere construir un modelo matemático en el que la teoría de conjuntos forma parte, se necesita tener una estructura donde se disponga el conjunto de todos los esquemas.

Al responder la pregunta sobre un esquema en qué mundo vive, Z establece un único espacio de estado para definir el sistema como un todo; sin embargo, para el caso de esta guía metodológica, se permite que cada esquema tenga su propio espacio de estado, sobre

3 Se fue llegando al extremo en el que había que realizar muchísimo esfuerzo para lograr especificar cosas sencillas con solo la notación matemática; por ello, se empezó a reducir el uso de la rigurosidad matemática exigida por la teoría de conjuntos, permitiendo introducir lenguaje natural, para explicar las mismas cosas.

31

el cual se modela la información, con el fin de posibilitar un mayor entendimiento y claridad al lector, sobre donde los esquemas están siendo utilizados.

Esto permite interpretar los esquemas como componentes de un sistema, que se manejan de manera independiente y pueden ser usados individualmente en métodos que requieren referenciar varios esquemas.

Por lo anterior, el concepto de espacio de estado se define como el conjunto de esquemas de un mismo tipo que pueden operar en el sistema y sobre el cual se llevan a cabo operaciones asociadas al estado y comportamientos de un objeto perteneciente a un esquema.

Aunque no hay una forma generalizada para la definición del espacio de estado de un esquema, se enfatiza que:

• El nombre que identifica el espacio de estado es una generalización del esquema sobre el que se está haciendo la definición.

• El nombre del atributo que permite la definición del conjunto debe terminar en plural.

• El tipo al que pertenece el atributo anteriormente referido, debe representar una agrupación o conjunto del esquema sobre el que se hace la definición del espacio de estado.

<NombreEspacioEstadoEsquema> <atributo> : ℙ<nombreEsquema> ∨ en términos de una función o relación

invariante

Figura 13. Estructura Espacio de Estado

4.3.2.4 Inicialización de Esquemas

En un comienzo, dentro del espacio de estado de un esquema no existen objetos, por lo tanto el estado inicial es un conjunto vacio, el cual se debe especificar para los esquemas que representan los objetos de negocio.

La inicialización también se representa a través de la estructura de un esquema, por ello, en su identificación la primera palabra es Init, cuya primera letra debe comenzar en mayúscula, seguido por el nombre con el que se definió el espacio de estado del esquema. Las palabras pueden ir seguidas o unidas entre sí por el símbolo “_”.

En la parte de declaración se coloca el nombre del espacio de estado del esquema.

En la invariante se hace referencia al atributo del espacio de estado del esquema cuyo valor es el conjunto vacio.

32

Init<NombreEspacioEstadoEsquema> <NombreEspacioEstadoEsquema>

<atributo> = ∅

Figura 14. Estructura Inicialización Esquema

4.3.2.5 Operaciones/Métodos de Esquemas

Como los objetos de negocio tienen operaciones o métodos asociados que permiten describir las funcionalidades de un objeto, de manera análoga, se representan esos métodos bajo la estructura de esquemas, en el que se hace referencia al esquema o los esquemas requeridos.

La estructura para un método es similar al de la definición de un esquema, sin embargo, tiene características adicionales.

• La sintaxis para escribir el nombre del método es similar a cuando se establece en la definición de un esquema (numeral 4.3.2.2). Cuando se habla de operaciones o métodos se sabe que se está haciendo referencia a acciones sobre el o los objetos a utilizar, por lo que el nombre del método se debe escribir en infinitivo para indicar la acción que se pretende realizar.

• En la parte de las declaraciones, los atributos involucrados en el método son distinguidos, de acuerdo con su procedencia y utilización.

En primer lugar se debe hacer referencia al esquema “dueño” del método y de acuerdo con la sintaxis y propósito del mismo, se debe poder distinguir si se presenta algún cambio de valor en alguno de los atributos del esquema referenciado. Por ello, se utilizan estas notaciones:

o Δ <nombre esquema>: Indica que el esquema puede tener un cambio de valor en alguno de sus atributos, con respecto a sus valores iniciales, por lo que contempla el manejo de estados antes y después de la operación. Aplica para operaciones sobre los que se realice modificación o borrado de algún objeto perteneciente al esquema.

o Ξ <nombre esquema>: Indica que el esquema mantiene sus valores originales, después de finalizada su operación. Aplica básicamente en situaciones donde se requiere consultar información de un esquema.

Si un método requiere hacer uso o referencia a más de un esquema, estos se deben declarar anteponiendo el símbolo “∆” ó “Ξ”, según la acción requerida sobre cada esquema declarado.

33

Un método puede tener parámetros de entrada y la sintaxis para su escritura es similar al de los atributos en la definición de un esquema, solamente que para su distinción, se adiciona el símbolo de interrogación “?” al final del nombre del parámetro.

o Un esquema tiene un espacio de estado, en el cual se agrupan todos los esquemas del mismo tipo y en los métodos se puede necesitar acceder un objeto en particular de ese conjunto. Por lo anterior, se asume que al especificar el método, ya se tiene identificado de antemano el objeto sobre el cual se realiza la acción, por lo que se deja como parámetro de entrada.

o Con esto, se evita tener que especificar en la parte de propiedades del método, cual es el objeto dentro del conjunto que satisface las condiciones para su manipulación.

Nota: Cuando no se puede tener previamente identificado el objeto sobre el que se realiza la acción en un método, porque por ejemplo, se puede requerir acceder no solo uno sino varios objetos del mismo tipo que cumplen ciertas condiciones, no se considera pertinente establecer esos objetos como parámetros de entrada. En estos casos, dentro de las propiedades del método se debe identificar las condiciones y selección de los objetos que las cumplen para su referencia.

o Si bien un objeto se puede definir como un parámetro de entrada, dentro de las libertades permitidas se permite que alguno de sus atributos cambie, aspecto a tener en cuenta en la parte de propiedades y que se manifiesta más adelante.

Aparte de los cambios en los atributos del esquema al que se está haciendo referencia, se puede requerir parámetros de salida, por ejemplo, para retornar un tipo de objeto específico o generar un mensaje de salida. Estos parámetros en su definición se distinguen con el signo de admiración “!” después del nombre del atributo.

• En un método, el área de propiedades hace referencia a las pre-condiciones y post-condiciones, las cuales se identifican en la estructura como Pre y Post, respectivamente.

La pre-condición se expresa en términos de las condiciones que deben satisfacer tanto los parámetros de entrada, como los atributos de los objetos definidos de entrada. Asimismo, se puede requerir identificar objetos que no están definidos como parámetros de entrada, por lo que se especifican las condiciones que se cumplen y bajo la cuales se seleccionan los objetos, para su posterior referencia.

La post-condición se expresa en términos de los valores esperados resultantes, como resultado de las acciones realizadas en el método, tanto de los parámetros de salida, de los atributos del esquema(s) que fueron modificados o sobre los atributos de los objetos definidos como parámetros de entrada.

34

Para hacer referencia al atributo de un objeto en particular o de un esquema, se escribe el nombre del objeto al cual pertenece el atributo, seguido por un punto “.” y luego el nombre del atributo.

Para expresar y diferenciar el atributo modificado con respecto a su valor anterior, al atributo modificado se le adiciona al final el símbolo “ ′ ” .

Así como a nivel de las invariantes se concede cierta licencia para expresar en lenguaje natural su descripción, de igual manera se otorga esta libertad en la pre y post-condición, en procura de facilitar el proceso y buscar una mayor claridad.

Dentro de los propósitos de una especificación se busca identificar todos los posibles casos relacionados con el cumplimiento de las condiciones para que un método pueda ejecutarse. No obstante lo anterior, cuando en un método la pre-condición no se cumple el método no se lleva a cabo, por lo que se debe considerar las condiciones que se incumplen para indicar las acciones del caso.

Esto conlleva a que se debería distinguir en la Pre, algo del estilo como Pre ∨ ¬Pre y de acuerdo con cada condición se desarrolla la operación.

Si bien, la identificación de todos los casos posibles se pueden especificar en un solo esquema, el cumplimiento o no de las condiciones puede hacer que se pierda el foco de atención sobre algunas propiedades que no se cumplen, omitiéndose a la hora de la implementación del sistema. Esto, puede volver más compleja la especificación cuando la cantidad de condiciones son numerosas.

La estructura de una operación o método, cuando esta expresada en un solo esquema es la siguiente:

<NombreOperación Xi>

Δ <EsquemaX>

Ξ <EsquemaY>

<ObjetoX>? : <TIPOEsquemaX>

<parametroEntrada>? : <TIPO1>

<parametroSalida>! : <TIPO2>

Pre: Condiciones que (se cumplen ∨ no se cumplen ) al iniciar la operación

Post: (se cumple la Pre ∧ se relacionan los valores esperados resultantes, atributos modificados)

∨

( ¬ se cumple la Pre ∧ nada cambia ∧ genera mensaje de salida)

Figura 15. Estructura de un Método/Operación

Teniendo en cuenta lo anterior, se considera como un mecanismo más expedito, dividir la especificación del método en esquemas más pequeños, donde se pueda diferenciar el caso

35

en el que se satisface completamente las reglas de negocio de la pre-condición y los casos que no se cumplen.

De acuerdo con la condición que se incumple, se puede generar un mensaje de salida para dar un tratamiento diferente, por ello, se debe contemplar la definición de un esquema por cada condición incumplida, de manera que se identifiquen todos los posibles casos, de manera independiente.

En esta situación, el nombre de cada esquema debe hacer referencia a la condición que ocasiona la falla, lo cual va a facilitar su comprensión al momento de expresar la definición consolidada de todos los esquemas creados.

Finalmente, se hace una única definición del método especificado, agrupando los esquemas creados relacionados con el método, tanto el que contiene el esquema exitoso, como los que hacen explícito cada causal de falla.

La segmentación del método en varios esquemas se visualiza a continuación, donde los puntos suspensivos en el área de las declaraciones indican que su contenido es similar al de la estructura de la OperacionXi expresada anteriormente y no hay necesidad de volverlo a escribir:

<NombreOperación Xi Exitosa> ……….

Pre: condiciones que se cumplen al iniciar la operación

Post: se cumple la Pre ∧ se relacionan los valores esperados resultantes, atributos modificados

Figura 16. Método/Operación Exitoso

Se define de 1 a N esquemas, según la cantidad de condiciones que no se cumplen.

<NombreOperación Xi Fallida1> ……….

Pre: condición1 que NO se cumple al iniciar la operación pero es válida en este esquema

Post: se cumple la Pre ∧ nada cambia ∧ genera mensaje de salida 1

……….. ………..

<NombreOperación Xi FallidaN> …………

Pre: condición N que NO se cumple al iniciar la operación pero es válida en este esquema

Post: se cumple la Pre ∧ nada cambia ∧ genera mensaje de salida N

Figura 17. Métodos/Operaciones Fallidos

36

Al final el método OperaciónXi se describe en los siguientes términos:

OperaciónXi := <NombreOperación Xi Exitosa> ∨<NombreOperación Xi Fallida1> ∨ …..

<NombreOperación Xi FallidaN>

De esta forma se obtiene más claridad y se puede asegurar tener un tratamiento sobre las condiciones que ocasionan una falla en el sistema a desarrollar.

4.3.2.6 Consideraciones Finales

El orden indicado para realizar la especificación es comenzar por describir cada esquema básico con sus métodos individuales, los cuales están asociados con la adición, consulta, modificación o eliminación de objetos del espacio de estados del esquema.

Estos métodos si bien no son los más complejos, ni sobre los cuales se desarrollan las operaciones esenciales del problema, van a ser posteriormente referenciados por otros métodos que involucran la interacción de más de un esquema y que son los que abordan el problema a solucionar.

Una vez se han definido los métodos básicos, se especifican los que atienden los problemas de negocio primordiales a resolver.

Al final se debe contar con un documento consolidado que contiene la especificación, en donde se explica:

• En lenguaje natural, las características relevantes del negocio de cada objeto identificado con sus operaciones relevantes, junto con la introducción de la representación de esos objetos en función de los esquemas con sus métodos.

• La especificación en términos formales de los esquemas y métodos, siguiendo el marco de especificación propuesto.

El documento resultante debe ser validado y refinado con los dueños del negocio hasta tener el visto bueno de que la especificación es completa, clara y satisface las expectativas del cliente.

37

5 CASO DE ESTUDIO: COMPENSACIÓN ELECTRÓNICA NACIONAL INTERBANCARIA

Un tema de negocio vital para los bancos centrales de los países es la compensación interbancaria, que hace parte de la infraestructura del sistema de pagos4 del sector financiero.

Dentro del universo de componentes que comprende la compensación interbancaria, se tomará un subconjunto de sus elementos y operaciones para ilustrar la especificación en el desarrollo de la guía metodológica.

5.1 ANTECEDENTE

Dentro del contexto colombiano, el objetivo principal del Banco de la República, como banco central de Colombia, es el mantenimiento de la capacidad adquisitiva de la moneda y por ello desempeña un papel primordial en la búsqueda de un buen funcionamiento del sistema de pagos para el sector financiero.

Los sistemas de pagos se pueden clasificar en dos categorías: de alto y bajo valor, cuya diferencia radica en la cuantía y la oportunidad pronta del pago. Independiente de los montos, se centra la importancia en la naturaleza de las operaciones, los instrumentos de pago y los canales por los que se realizan las transferencias de dinero.

Los subsistemas creados tienen una importancia sistémica para permitir el equilibrio financiero5. Uno de ellos es el relacionado con la compensación automatizada, que tiene como objetivo ejecutar mediante movimientos electrónicos, transferencias de fondos entre clientes del sistema financiero.

La compensación electrónica, que se ha consolidado en detrimento de los pagos con cheques, va orientado a que las transferencias de fondos electrónicas se pueden realizar entre cuentas de ahorro o corrientes, de diferentes instituciones financieras, que pueden estar o no localizadas en ciudades diferentes.

5.2 ALCANCE E IDENTIFICACIÓN OBJETOS DE NEGOCIO

El Banco de la República, como ente regulador y participante activo del sistema financiero requiere contar con mecanismos que le permitan prestar el servicio de compensación

4 Un sistema de pago se define como “…una serie de instrumentos, procedimientos bancarios y, por lo general, sistemas interbancarios de transferencia de fondos que aseguran la circulación del dinero.” [11] 5 Sistemas de pago cuyas cantidades manejadas son de cierta magnitud, que ante la imposibilidad de cumplimiento, por parte de alguna entidad financiera de sus obligaciones, puede poner en riesgo la estabilidad del sector y afectar la actividad económica en general.

38

interbancaria6 a las entidades financieras, posibilitando la ejecución de las operaciones débito y crédito que se efectúan entre las entidades, de manera que pueda:

Recibir y procesar cada instrucción de pago generada; realizar el proceso de compensación de las transacciones en los ciclos de operación establecidos y remitir las instrucciones de pago recibidas a las respectivas contrapartes, luego de la afectación de las cuentas de depósito que las entidades tienen en el Banco Central. [12] [13]

El esquema de compensación electrónica tiene definidas unas reglas de negocio, a partir de las cuales se identifican los objetos de dominio con sus relaciones, base para el desarrollo de la especificación, a saber:

Figura 18. Objetos de Negocio Compensación Interbancaria

La interrelación de los objetos identificados se puede visualizar en el Anexo 1. Interrelación de Objetos Compensación Interbancaria.

5.3 DESARROLLO ESPECIFICACIÓN COMPENSACIÓN ELECTRÓNICA INTERBANCARIA

Teniendo en cuenta los objetos de negocio identificados para la compensación, la especificación se presenta de manera gradual comenzando por los esquemas básicos y en la medida que se establecen relaciones entre los mismos, se van definiendo los esquemas y operaciones más complejas.

6 Según lo establecido en el Art. 23 de la ley 31 de 1992, el Art. 24 del Decreto 2520 de 1993 y el Art. 1 del Decreto 1207 de 1996 el Banco de la República está autorizado para prestar el servicio de compensación interbancaria.

class Modelo de domi...

Objetos del dominio

+ CicloOperacion

+ CodTransaccion

+ EntidadAutorizada

+ Estado

+ EstadoTransaccion

+ OperacionesPermitidas

+ OperadorCENIT

+ TipoOperacion

+ Transaccion

+ UsuarioRol

39

5.3.1 Esquemas y Operaciones Básicos

5.3.1.1 Entidad Autorizada

Las entidades financieras generan o reciben órdenes de transferencia, como consecuencia de instrucciones expedidas por sus clientes, para el traslado de fondos a través del Sistema de Compensación Electrónica Nacional Interbancaria ACH del Banco de la República – CENIT7, hacia o desde una cuenta de otro usuario en otra entidad.

Estas entidades se encargan de acreditar o debitar la cuenta que el originador y receptor de la operación tienen en su respectiva entidad, de acuerdo con las instrucciones impartidas en la orden de transferencia y para hacer uso del sistema, las entidades deben estar autorizadas por el Operador del CENIT8.

Para construir la noción de una Entidad se deben considerar unos conceptos elementales asociados al conjunto de roles existentes dentro del sistema para las entidades, así como los estados de una entidad, elementos que son considerados como tipos básicos y se denominan:

CALIDAD_EA ::= Originador | Receptor | Originador_Receptor

ESTADO_ENTIDAD ::= Activa | Retirada | Suspendida

Asimismo, cada Entidad cuenta con: un código de compensación; nombre de la entidad; un código SEBRA9; un código de plaza; así como las fechas para determinar su vinculación o retiro. Por ello, se establecen otros tipos básicos, sin valores predeterminados.

[CODIGO_COMPENSACION_ENTIDAD]

[CODIGO_SEBRA]

[NOM_ENTIDAD]

[CODIGO_PLAZA]

[FECHA]

Para efectos de generar información de salida, según las operaciones que se realicen, se define un tipo básico MSG_ENTIDAD.

7 El CENIT pertenece a los sistemas de pago de bajo valor y de acuerdo con el reglamento Operativo del Servicio de Compensación Interbancaria del Banco de la República es uno de los componentes del Servicio de Compensación Interbancaria, a través del cual se compensan y liquidan las transferencias electrónicas de fondos. [12] 8 Rol que desempeña el Banco de la República como operador de la ACH CENIT para compensar y liquidar el efecto monetario de las instrucciones de pago en las cuentas de depósito de las entidades participantes en la operación del CENIT recibidas [13] 9 Servicios Electrónicos del Banco de la República. Sistema que permite el acceso seguro a los servicios electrónicos del Banco de la República y que permite efectuar las transacciones y las comunicaciones entre el entre el Banco y el Sector Financiero.

40

MSG_ENTIDAD ::= Entidad_Adicionada | Codigo_Ya_Existe | Op_NoPermitida | Ok |

Codigo_Reservado | Obligaciones_Pendientes

Al ser las entidades quienes dan inicio y fin a las órdenes de transferencia de fondos, es importante materializar el concepto de una Entidad, con el cual se mantiene y valida la información sobre sus características y estado, así como se posibilita el procesamiento de las órdenes recibidas. Las entidades cuentan con los siguientes atributos:

• calidadEA: Describe el rol que la entidad desempeña dentro del sistema.

• codigoCompensacion: Referencia única que identifica a una entidad en las órdenes

de transferencia.

• codigoPlaza: Referencia de la ciudad a la que pertenece la entidad

• codigoSebra: Código exigido como requisito de vinculación, para tener acceso a los

servicios electrónicos del Banco de la República.

• nombreEA: Nombre bajo el cual está constituida formalmente la entidad.

• estadoEntidad: Referencia el estado de una entidad, para determinar si está

autorizada para operar.

• fechaVinculacion: Fecha a partir de la cual la entidad es autorizada para hacer uso

del sistema, para el envío y recibo de órdenes de transferencia de fondos.

• fechaRetiro: Fecha a partir de la cual la entidad queda retirada del sistema, e

imposibilitada para el envío y recibo de órdenes de transferencia.

• usuarios: Contiene la relación de las personas de Entidad con sus perfiles

autorizados, cuyo tipo, UsuarioRol, se especifica más adelante.

El esquema completo de Entidad es:

41

Entidad calidadEA : CALIDAD_EA

codigoCompensacion : CODIGO_COMPENSACION_ENTIDAD [único]

codigoPlaza : CODIGO_PLAZA

codigoSebra : CODIGO_SEBRA

nombreEA : NOM_ENTIDAD

estadoEntidad : ESTADO_ENTIDAD

fechaVinculacion : FECHA

fechaRetiro : FECHA

usuarios : UsuarioRol

codigoPlaza ≠ codigoSebra

codigoCompensacion ≠ codigoSebra

codigoPlaza ≠ codigoCompensacion

Figura 19. Esquema Entidad con identificador

El espacio de estado que define el conjunto de todas las Entidades Autorizadas para operar en el sistema y sobre el cual se llevan a cabo operaciones asociadas al estado y comportamientos de una Entidad se establece a través del esquema EntidadAutorizada.

EntidadAutorizada

entidadesAutorizadas : ℙEntidad

2 Entidades Autorizadas son iguales ⇔

códigoSebra ∧ códigoCompensación ∧ nombre de ambas entidades son iguales

Figura 20. Espacio de Estado Semi-formal Esquema Entidad

En un comienzo, no existe entidad alguna dentro del conjunto de Entidades Autorizadas, por lo tanto su estado inicial es un conjunto vacío.

InitEntidadAutorizada EntidadAutorizada

entidadesAutorizadas = ∅

Figura 21. Inicialización Esquema Entidad Autorizada

Cuando una entidad se va a registrar por primera vez y ha cumplido con los requisitos para hacer uso del sistema, esta es autorizada por el operador del sistema y se adiciona al conjunto de entidades autorizadas, asignándole el estado Activo, con la fecha del día en que se hace la adición.

42

Se debe tener en cuenta que el código de compensación para la nueva Entidad Autorizada sea diferente a otros que ya han sido asignados y se genera un mensaje de salida indicando la adición de la nueva Entidad.

AdicionarEntidad_

Δ EntidadAutorizada

nueva_ea? : Entidad

mensaje! : MSG_ENTIDAD

Pre: nueva_ea? ∉ entidadesAutorizadas

nueva_ea?. estadoEntidad = ┴

nueva_ea?.fechaVinculacion = ┴

Post nueva_ea?.estadoEntidad = Activo

nueva_ea?.fechaVinculacion = fecha del día

entidadesAutorizadas′ = entidadesAutorizadas ∪ { nueva_ea?}

mensaje! = Entidad_Adicionada

Figura 22. Método Adicionar Entidad

Como es importante considerar los casos en los cuales las condiciones normales no se cumplen, se incorpora una validación en torno a la existencia previa de la Entidad en el sistema, a través de la operación EntidadExiste.

EntidadExiste Ξ EntidadAutorizada

nueva_ea? : Entidad


Pre: nueva_ea? ∈ entidadesAutorizadas

Post: mensaje! = Codigo_Ya_Existe

Figura 23. Método Entidad Existe

Finalmente, la adición de una nueva entidad queda completa expresando en una sola operación las operaciones AdicionarEntidad y EntidadExiste, que generan los mensajes de salida de acuerdo con el resultado de las validaciones.

AdicionarEA ≙ AdicionarEntidad ∨ EntidadExiste

Una Entidad Autorizada puede solicitar su retiro, pero es posible que en un futuro quiera reincorporarse, por lo que no se elimina sino se realiza un cambio de estado, con el cual se impide el trámite de operaciones desde o hacia la Entidad a partir de la fecha del día.

43

RetirarEA0 Δ EntidadAutorizada

entidad? : Entidad

Pre: entidad? ∈entidadesAutorizadas

entidad?. estadoEntidad ≠ Retirada

Post: entidad?. estadoEntidad ′ = Retirada

entidad?. fechaRetiro ′ = fecha del día

Figura 24. Método Retirar Entidad

Si al momento del retiro, la Entidad no ha dado cumplimiento a sus obligaciones, no se puede hacer efectivo su cambio de estado, por lo que se define la operación ObligacionPendiente para generar un mensaje de salida indicando que está pendiente saldar una obligación.

ObligacionPendiente

ΞEntidadAutorizada

entidad? : Entidad


Pre: entidad? ∈entidadesAutorizadas

entidad?. estadoEntidad ≠ Retirada

Post: Si tiene obligaciones pendientes de liquidar de órdenes recibidas ⇒

mensaje! = Obligacion_Pendiente

Figura 25. Método Obligación Pendiente de la Entidad

Con el fin de completar y dejar explícito el resultado de una operación, se define un esquema Exitoso, que indica la ejecución correcta de una operación, el cual se puede utilizar de manera combinada e independiente con otras operaciones.

Exitoso mensaje! : MSG_ENTIDAD

Post: mensaje! = Ok

Figura 26. Método General Exitoso

Se puede tener una composición de RetirarEA0 con Exitoso, por lo que la nueva operación RetirarEA, expresa de manera completa la funcionalidad requerida para informar el retiro de una entidad.

RetirarEA ≙ (RetirarEA0 ∧ Exitoso) ∨ Obligacion_Pendiente

Producto de un requerimiento de un organismo de control, una entidad puede quedar suspendida, momento en el que se debe impedir el recibo y procesamiento de órdenes de

44

transferencia electrónica de fondos que dicha entidad genere, mientras se resuelven los motivos que causaron la suspensión.

Lo anterior se expresa en la operación SuspenderEA, que recibe como parámetro la Entidad a suspender, la cual está Activa.

SuspenderEA Δ EntidadAutorizada

entidad? : Entidad

Pre: entidad? ∈entidadesAutorizadas ∧

entidad?. estadoEntidad = Activo

Post: entidad?.estadoEntidad ′ = Suspendido

Figura 27. Método semi-formal Suspender Entidad

5.3.1.2 Usuario - Rol

Como se mencionó anteriormente, el esquema Entidad tiene un atributo usuarios, de tipo UsuarioRol, que permite establecer los usuarios asignados por cada entidad y los perfiles que pueden desempeñar dentro del sistema. Para ello, se definen los tipos básicos.

[NOMUSUARIO]

[ROL]

Para representar las características básicas de un usuario, como la identificación y nombre de la persona, estas se se agrupan en el esquema Usuario.

Usuario idUsuario : ℤ [único]

nombre: NOMUSUARIO

Figura 28. Esquema Usuario

Como debe haber una relación entre los usuarios y el conjunto de roles que cada uno puede tener, esta se expresa a través del esquema UsuarioRol.

UsuarioRol usu_rol : Usuario ↔ROL

Figura 29. Espacio de Estado Usuario-Rol

5.3.1.3 Ciclos de Operación

El sistema de compensación opera todos los días bancarios del año, por ello, se requiere establecer ciclos de operación independientes, con horarios de atención definidos, en lo

45

que se denomina tipo de evento, para recibir y procesar las órdenes de transferencia remitidas por las Entidades Originadoras, así como la publicación de las salidas correspondientes para las Entidades Receptoras.

Los diferentes tipos de eventos que ocurren en cada ciclo son: uno de Atención, para procesar las instrucciones de pago recibidas y otro de PublicacionArchivos, para poner a disposición de las Entidades Receptoras los archivos una vez se han procesado, por lo que se define un tipo básico NOMBRE_TIPOEVENTO.

Igualmente, dado que en cada ciclo los tipos de evento se realizan en períodos de tiempo específicos, se define un tipo básico HORA.

NOMBRE_TIPOEVENTO ::= Atencion | PublicacionArchivos

[HORA]

Cada tipo de evento, tiene establecido un tiempo para su atención; por ello, se define el esquema HorarioTipoEvento, que asocia un tipo de evento con una hora de inicio y una hora de finalización, donde la primera es mayor que la segunda.

HorarioTipoEvento idTipoEvento: 1..2 [único]

nomTipoEvento : NOMBRE_TIPOEVENTO [único]

horaInicio : HORA

horaFin : HORA

horaInicio < horaFin

Figura 30. Esquema de Horario según el Tipo de Evento

Actualmente se tiene establecido 5 ciclos durante el día, pero es posible modificarlo según las necesidades operativas dentro del sistema; por ello, se define una constante, MAXCICLOS.

MAXCICLOS : ℕ1

MAXCICLOS = 5

Como cada ciclo de operación tiene dos tipos de eventos relacionados, es necesario definir una función entre un ciclo, delimitado por la máxima cantidad de ciclos permitidos, y el conjunto de tipos de eventos, con sus respectivos horarios de inicio y fin, a través del esquema CicloOperacion.

CicloOperacion cicloEvento : [1..MAXCICLO] →ℙHorarioTipoEvento

46

Figura 31. Esquema Ciclo de Operación

La adición de un nuevo ciclo con su correspondiente conjunto de eventos y horarios se establece bajo la operación AdicionaCiclo.

AdicionaCiclo Δ CicloOperacion

nuevo_ciclo? : ℕ1

evento? : ℙHorarioTipoEvento

Pre: nuevo_ciclo?∉ dom(cicloEvento)

la relacion {nuevo_ciclo? ↦ evento?} ∉ cicloEvento

Post: cicloEvento′ = cicloEvento ∪ { nuevo_ciclo? ↦ evento?}

Figura 32. Método Adicionar Ciclo

5.3.1.4 Tipo Operación

La compensación contempla el procesamiento de diferentes tipos de operaciones, que pueden o no generar movimientos de dinero, como las asociadas a prenotificaciones10, débitos o créditos, ya sea de cuentas corrientes o de ahorros.

Cada tipo de operación tiene un código para su identificación, sin embargo, se tiene definido un conjunto de códigos exclusivos, que no pueden ser utilizados como identificadores de un tipo de operación; por ello, se define una variable, RESERVADO, correspondiente al conjunto de códigos reservados; asimismo, como cada tipo de operación tiene un nombre, se define el tipo básico NOM_TIPOPERACION.

RESERVADO == Conjunto de códigos reservados

[NOM_TIPOPERACION]

Cada tipo de operación se identifica por un código y el nombre, elementos que se integran a través del objeto TipoOperacion.

TipoOperacion codTipoOperacion : 20..99 [único]

nomTipoOperacion: NOM_TIPOPERACION

Figura 33. Esquema Tipo de Operación

10

Son órdenes de transferencia crédito o débito de valor $0.00, cuya finalidad es enviar, en forma previa a la iniciación de la primera orden débito o crédito a una cuenta, una notificación mediante la cual se informa a la Entidad Autorizada Receptora la intención de iniciar una o más órdenes a la cuenta de un receptor, así como obtener una validación acerca de la existencia y condiciones de la cuenta del receptor.[ x]

47

Para describir el conjunto de todos los tipos de operaciones existentes, tanto para órdenes de transferencia débito o crédito, se define el esquema TipoOperaciones.

TipoOperaciones tipoOperaciones : ℙTipoOperacion

2 tipos de operación son iguales ⇔ tienen el mismo codigo ∧ nombre

Figura 34. Espacio de Estado Tipo de Operaciones

En un comienzo, no hay tipos de operación dentro del conjunto tipoOperaciones, por lo tanto su estado inicial es:

InitTipoOperaciones TipoOperaciones

tipoOperaciones = ∅

Figura 35. Inicialización Tipo de Operaciones

Si bien los tipos de operación son estables y no se presentan mayores novedades, la dinámica del sistema financiero puede hacer posible que se requiera incorporar nuevos tipos de operación, que se enlazan con los ya existentes.

AdicionarTipoOp0

Δ TipoOperaciones

nuevo_TipoOp? : TipoOperacion

Pre: nuevo_TipoOp? ∉ tipoOperaciones ∧

nuevo_TipoOp?. codTipoOperacion no está contenido dentro de RESERVADO

Post: tipoOperaciones ′ = tipoOperaciones ∪ { nuevo_TipoOp?}

Figura 36. Método Adicionar Tipo de Operación

No obstante lo anterior, se deben considerar ciertas validaciones en torno a un nuevo tipo de operación, como es que el tipo de operación ya exista dentro del conjunto de tipo de operaciones, lo cual se especifica en la operación TipoOperacionExiste.

TipoOperacionExiste ΞTipoOperaciones



Pre: (∃ top : TipoOperacion | top ∈ tipoOperaciones ⦁

top.codTipoOperacion = nuevo_TipoOp?.codTipoOperacion)

Post: mensaje! = Codigo_Ya_Existe

48

Figura 37. Método Tipo de Operación Ya Existente

Asimismo, es posible que el nuevo tipo de operación tenga asociado un código reservado, por lo que se define la operación CodigoOpReservado.

CodigoOpReservado ΞTipoOperaciones



Pre: nuevo_TipoOp?.codTipoOperacion está contenido dentro de RESERVADO

Post: mensaje! = Codigo_Reservado

Figura 38. Método Código de Operación Reservado

Teniendo en cuenta lo anterior, la adición de un nuevo tipo de operación queda completa con la siguiente operación

AdicionarTipoOperacion ≙ (AdicionarTipoOp0 ∧ Exitoso) ∨ TipoOperacionExiste ∨

CodigoOpReservado

Las demás operaciones sobre TipoOperaciones, como consultar, eliminar o modificar un tipo de operación, son similares en su estructura a las definidas para EntidadAutorizada.

5.3.1.5 Operaciones Permitidas

Dentro de la compensación interbancaria se estipula que dependiendo del ciclo de operación, solo algunos tipos de operaciones son permitidos. Por ejemplo, en el primer ciclo se aceptan las órdenes recibidas con anterioridad, cuya fecha valor11 coincida con el día de operación respectivo así como todo tipo de operaciones, exceptuando las que corresponden a devoluciones.

Estas reglas de negocio hacen necesario que se establezca una relación entre el tipo de operaciones aceptadas, con cada uno de los ciclos existentes; por ello, se define un esquema que integra los esquemas TipoOperaciones y CicloOperacion, y que cuenta con el siguiente atributo:

• opsPermitidaEnCiclo: Relaciona el conjunto de operaciones permitidas para realizar la compensación y liquidación según el ciclo de operación.

11 Fecha en que se liquida efectivamente una operación financiera

49

OperacionesPermitidas opsPermitidaEnCiclo : TipoOperaciones ↔ CicloOperacion

(∃ cicloOp: CicloOperacion ⦁ ∀ top : TipoOperaciones ⦁ top ↦ cicloOp ∈ opsPermitidaEnCiclo)

Figura 39. Esquema Operaciones Permitidas

El tipo de operaciones permitidas en los ciclos de negocio tiene restricciones que deben ser tenidas en cuenta, al momento de adicionar una nueva relación TipoOperaciones con CicloOperacion, acción en la que se recibe como entrada un tipo de operación y un ciclo de operación, donde el tipo de operación es permitido dentro del ciclo que se va a relacionar

AdicionarOpACiclo1 Δ OperacionesPermitidas

tipoOp? : TipoOperaciones

ciclo? : CicloOperacion

Pre: tipoOp? ∈ dom opsPermitidaEnCiclo

cicloOp? ∈ ran opsPermitidaEnCiclo

tipoOp? es permitido para el ciclo que se va a relacionar

Post: opsPermitidaEnCiclo′ = opsPermitidaEnCiclo ⊕ {tipoOp? ↦ ciclo?}

Figura 40. Método Adicionar Operación a un Ciclo

Es importante diferenciar cuando un tipo de operación no es permitido: en el ciclo 1 no se aceptan operaciones relacionadas con devoluciones; en los ciclos 2, 3 y 4 no se consideran operaciones relacionados con pre-notificaciones y en el último ciclo solo se aceptan operaciones de devoluciones del mismo día bancario.

Lo anterior, se especifica en la operación OpEnCicloNoPermitida, que retorna un mensaje de operación no permitida.

OpEnCicloNoPermitida ΞOperacionesPermitidas

tipoOp? : TipoOperaciones

ciclo? : CicloOperacion


Pre: tipoOp? ∈ dom opsPermitidaEnCiclo

ciclo? ∈ ran opsPermitidaEnCiclo

Post: Si ((dom (ciclo?) = 1y tipoOp? está asociado con devoluciones) ∨

(dom (ciclo?) ≠ 1 y tipoOp? está asociado con prenotificaciones ) ∨

(dom (ciclo?) = 5 y tipoOp? no está asociado con devoluciones del anterior ciclo)) ⇒

mensaje!: Op_NoPermitida

50

Figura 41. Método Operación en Ciclo No Permitida

Teniendo en cuenta lo anterior, la adición de un tipo de operación en un ciclo es completa si definimos la operación AdicionarOpACiclo como:

AdicionarOpACiclo ≙ (AdicionarOpACiclo1 ∧ Exitoso) ∨ OpEnCicloNoPermitida

La consulta de operaciones permitidas, recibe como entrada un número de ciclo, el cual debe ser válido dentro del ciclo de operaciones para que se pueda retornar los tipos de operaciones asociados.

ConsultarOperacionesPermitidas Ξ OperacionesPermitidas

numciclo? : ℕ1

tipoOps! : TipoOperaciones

Pre: ∃ cicloOp:CicloOperacion; top : TipoOperaciones |

numciclo? ∈ dom cicloOp.cicloEvento∧

top ↦ cicloOp ∈ opsPermitidaEnCiclo

Post: tipoOps! = top

Figura 42. Método Consultar Operaciones Permitidas

5.3.1.6 Código de Transacción

El envío de las órdenes de transferencia, está basado de acuerdo con lo establecido en el formato internacional NACHA12, de tal forma que las órdenes deben ir acompañadas de un código de transacción, con el cual se distingue la entidad originadora y la característica del tipo de operación permitida.

Para el sector financiero colombiano, se utilizan algunos de esos códigos, por ejemplo, el código PPD (Pago Preacordado y Depósito Directo) debe ser utilizado por todas las entidades bancarias al momento de enviar órdenes de transferencia débito, crédito o prenotificaciones, o el código CCD (Concentración y Desembolso en Caja), que está relacionado con las operaciones para el pago de seguridad social. Así, se pueden presentar órdenes crédito o débito que pueden ser PPD o CCD.

Como es importante definir el concepto de código de transacción, se define un tipo básico, NOMCODTX, para identificar el tipo al que pertenece el nombre, asociado al código de transacción.

12 Asociación Nacional de Cámaras automatizadas de los Estados Unidos de América (www.nacha.org). Entidad que define los estándares de las cámaras de compensación de los EE.UU y gestiona el desarrollo, administración y gobernabilidad de la red ACH, base para los movimientos electrónicos de datos y dinero.

51

[NOMCODTX]

Un código de transacción está representado por un código identificador, idCodTx, y un nombre, nomCodTx, atributos que se agrupan en el esquema CodTransaccion

CodTransaccion

idCodTx : ℕ1 [único]

nomCodTx : NOMCODTX

Figura 43. Esquema Código de Transacción

El conjunto de todos los códigos de transacción, con su estado inicial se define en CodTransacciones e InitCodTransacciones

CodTransacciones

codTransacciones: ℙCodTransaccion

Figura 44. Espacio de Estado Código de Transacciones

InitCodTransacciones CodTransacciones

codTransacciones = ∅

Figura 45. Inicialización Código de Transacciones

5.3.1.7 Transacción

Las órdenes de transferencias de fondos se materializan a través del concepto de Transacción, que integra la información necesaria para tramitar una orden enviada por una Entidad y que incluye: identificación de las entidades originadora y receptora, fecha y hora de envío, monto, fecha valor, código de transacción y tipo de operación, entre otros.

Para delimitar algunos de sus atributos, se definen unos tipos básicos que permiten identificar el código de la transacción, número de cuenta e identificación del receptor.

[ID_TRANSACCION]

[NUM_CUENTA]

[NOM_RECEPTOR]

El contenido de una transacción es validado por el operador del sistema, para posteriormente llevar a cabo la afectación de las cuentas de depósito de las entidades autorizadas relacionadas. Las transacciones cuentan con los siguientes atributos:

• idTransaccion: Código identificador de una transacción, cuyo valor es único.

52

• codCompensacionEAO: Referencia que identifica a la Entidad Autorizada Originadora de la orden de transferencia, a quien se le afecta su cuenta de depósito, según la naturaleza del tipo de operación.

• codCompensacionEAR: Referencia que identifica a la Entidad Autorizada Receptora de la orden de transferencia a quien se le afecta su cuenta de depósito, según la naturaleza del tipo de operación.

• codTransaccion: Código con el cual se distingue la entidad originadora y la característica del tipo de operación permitida.

• fechaEnvio: Fecha de envío de la transacción por parte de la Entidad Originadora.

• horaEnvio: Hora de envío de la transacción por parte de la Entidad Originadora

• fechaValor: Fecha en que se debe liquidar de manera efectiva la orden de transferencia.

• idReceptor y nomReceptor: Identificación y nombre del usuario final a quien la Entidad Receptora le debe afectar el monto, de la cuenta de ahorros o cuenta corriente que el usuario mantiene en la Entidad Receptora.

• numCtaReceptor: número de la cuenta de ahorros o corriente, que el usuario receptor mantiene en la Entidad Receptora, y sobre la que esta le debe afectar su saldo.

• monto: Valor total por el que la orden de transferencia es solicitada y por el que se afectan las cuentas de depósito tanto de la Entidad Autorizada Originadora como de la Receptora.

• tipoOperacion: Tipo de operación, que determina la naturaleza de la orden de transferencia, si es una operación monetaria con movimiento débito o crédito, o no monetaria asociada a prenotificaciones o devoluciones.

Para enmarcar sus atributos se define el esquema Transaccion.

53

Transaccion idTransaccion : ID_TRANSACCION [único]

codCompensacionEAO : CODIGO_COMPENSACION_ENTIDAD

codCompensacionEAR : CODIGO_COMPENSACION_ENTIDAD

codTransaccion : ℕ1

fechaEnvio : FECHA

horaEnvio: HORA

fechaValor : FECHA

idReceptor : ℤ

nomReceptor : NOM_RECEPTOR

monto: ℝ

numCtaReceptor : NUM_CUENTA

tipoOperacion : 20..99

codCompensacionEAO ≠ codCompensacionEAR

Figura 46. Esquema Transacción

5.3.1.8 Estado Transacción

Dentro del esquema de compensación, se requiere conservar los estados por los que ha pasado una transacción, para efectos de analizar el proceso que ha tenido, la generación consolidada de reportes o la consulta de información histórica.

Teniendo en cuenta lo anterior, se define un tipo básico ESTADO_TX que contiene los valores predeterminados de los posibles estados que una transacción puede tener durante su ciclo de vida, desde su recepción hasta la liquidación.

ESTADO_TX ::= Recibido | Procesado | Compensado | Liquidado | Rechazado

Para manejar la información histórica del estado de una transacción se define el esquema EstadoTransaccion.

EstadoTransaccion idEstadoTransaccion: ℤ [único]

fecha : FECHA

hora : HORA

estado : ESTADO_TX

transaccion : Transaccion

Figura 47. Esquema Estado Transacción

Con el fin de mantener en un solo espacio la información histórica de todos los estados asociados a todas las transacciones en el sistema, se especifica el esquema EstadosTransacciones.

54

EstadosTransacciones estadosTxs : ℙ EstadoTransaccion

Dos estados de transacción son iguales si tienen la misma fecha, hora, estado y

la transaccion son iguales

Figura 48. Espacio de Estado del Estado de Transacciones

Conforme se va avanzando en el procesamiento de una transacción, se requiere agregar los cambios de estado que va teniendo la transacción, para mantener la información histórica de una orden de transferencia de fondos.

Ante esto, se define la operación AdicionarEstadoTransaccion que recibe un nuevo estado de una transacción, nuevoEstTx?, validando que para dicha transacción previamente no esté registrado el nuevo estado en el conjunto de estados de transacciones y lo adiciona al conjunto.

AdicionarEstadoTransaccion Δ EstadosTransacciones

nuevoEstTx? : EstadoTransaccion

Pre: Para la transacción relacionada en nuevoEstTx?, el nuevoEstTx?.estado no se encuentra registrado

en el conjunto estadosTxs.

Post: estadosTxs ′ = estadosTxs ∪ { nuevoEstTx?}

Figura 49. Método Adicionar Nuevo Estado de Transacción

Una de las consultas básicas, es obtener el estado en que se encuentra una transacción a una fecha y hora determinada, requerimiento que se define en la operación ConsultarEstadoTx

ConsultarEstadoTx Ξ EstadosTransacciones

fechacons? : FECHA

horacons? : HORA

txcons? : Transaccion

estado! : ESTADO_TX

Pre: ∃et : EstadoTransaccion | et ∈ estadosTxs ⦁

txcons? ∈ et.transaccion ∧

la fecha y hora válida dentro de et es la combinación inferior más cercana a fechacons? y horacons?

Post: estado! = et.estado

Figura 50. Método Consultar Estado Actual de una Transacción

Adicional a la anterior operación de consulta, uno de los requerimientos más importantes en el proceso de compensación, es que de acuerdo con una fecha, un rango de horas y un estado específico de transacción, se obtenga el conjunto de todas las transacciones que cumplen las condiciones de esos parámetros. Por ello, se define una función consultarTxs2

55

consultarTxs2 : FECHA × HORA × HORA × ESTADO_TX → ℙTransaccion

∀ fechacons : FECHA; horaInicio: HORA; horaFin : HORA; estado_tx:ESTADO_TX ⦁

∀ et : EstadoTransaccion ⦁

et.fecha = fechacons ∧ et.estado = estado_tx ∧ horaInicio ≤ et.hora ≤ horaFin ⇒

consultarTxs2(fechacons, horaInicio, horaFin) = dom(et.txconAdenda)

Figura 51. Método Consultar Estados de una Transacción

De otra parte, dado que se requiere particularmente para cada entidad, tener la historia de sus transferencias asociadas, basado sobre EstadoTransaccion, se hace una modificación en el que ya no se incluye el atributo transacción, y se crea un nuevo esquema EstadoTransaccion1.

EstadoTransaccion1 fecha : FECHA

hora : HORA

estado : ESTADO_TX

Figura 52. Esquema Estado de Transacción1

Teniendo en cuenta las estructuras Transaccion y EstadoTransaccion1, se incorpora dentro del esquema Entidad un nuevo atributo, historiaTxs, con el cual se registra la secuencia de todas las transacciones de una entidad con sus estados, a lo largo del tiempo. Con esto, se facilita las consultas particulares de información de las transacciones de una entidad

Entidad …….

codigoCompensacion : CODIGO_COMPENSACION_ENTIDAD

nombreEA : NOM_ENTIDAD

historiaTxs: seq (Transaccion ↔ EstadoTransaccion1)

…….

∀ transacciones registradas en historiaTxs

el codigoCompensacion de la Entidad = (codCompensacionEAO de Transaccion ∨

codCompensacionEAR de Transaccion)

……..

Figura 53. Esquema Entidad con Atributo Histórico de Transacciones

Como se requiera adicionar a una transacción asociada con una entidad, un nuevo estado de transacción, se define la operación AdicionarEstadoTransaccionEntidad.

56

AdicionarEstadoTransaccionEntidad


entidad_in?: Entidad

transaccion? : Transaccion

nuevoEstTx? : EstadoTransaccion1

Pre: transaccion? está relacionada con Entidad_in?

Post: entidad_in?.historiaTxs′ = ea.historiaTxs ⁀ (transaccion?↔ nuevoEstTx?)

Figura 54. Método Adicionar Estado de Transacción a una Entidad

Como se requiera consultar el registro histórico de una transacción asociada con una entidad, se define una operación que retorna el conjunto de estados que ha tenido.

ConsultarEstadoTxEntidad

Ξ EntidadAutorizada

entidad? : Entidad

txconsulta? : Transaccion

estadosTx! : seq EstadoTransaccion1

Pre: la transacción txconsulta? se encuentra dentro de la secuencia de transacciones de entidad?

Post: en estadosTx! se retorna la secuencia de estados asociados a txconsulta?

Figura 55. Método Consultar Estados de una Transacción de una Entidad

5.3.2 Operaciones Esenciales del Negocio

Hasta este momento la especificación ha desarrollado la definición de los esquemas esenciales del negocio, así como las operaciones básicas asociados a cada esquema. A partir de ahora, se definen las operaciones del negocio, basados en los esquemas definidos y que son el núcleo de la compensación interbancaria.

5.3.2.1 Procesar Entradas

El primer paso importante es el procesamiento de las órdenes de transferencia de fondos, recibidas de las entidades autorizadas originadoras, en las cuales se valida la estructura de formato de las transacciones, junto con algunas reglas de negocio, asociadas a las responsabilidades del Operador.

Una transacción puede representar una entrada monetaria, cuyo monto máximo es de cien millones de dólares americanos (US $100 millones). Para determinar su equivalencia en moneda legal colombiana se toma como referencia la Tasa Representativa del Mercado (TRM) que publica la Superfinanciera el primer día hábil de cada semana. Por lo anterior, se define la constante MONTOMAXIMO.

57

MONTOMAXIMO : ℤ

MONTOMAXIMO = 100 millones * TRM

En el procesamiento, se reciben como parámetros de entrada: la transacción y las dos entidades involucradas en la misma, tanto la originadora como la receptora, sobre las cuales se afectará su información histórica de transacciones recibidas.

Al final, se modifica el estado de la transacción, tanto en el conjunto general de estados de transacciones, como a nivel individual en el registro de transacciones de cada entidad afectada; de lo contrario, se generan un mensaje de salida indicando la condición que no se cumple.

Las validaciones incluyen:

• Que las dos entidades implicadas se encuentren activas.

• El monto de la transacción no sea superior al MONTOMAXIMO permitido. • Todos los campos vengan diligenciados y en el formato requerido. • La hora de envío de la transacción este dentro de lo permitido en el sistema.

• El código de transacción para la entidad autorizada originadora sea válido. • Validez de la fecha valor con respecto a la fecha del día y si corresponde a día

bancario, para procesar la transacción.

Para procesar la orden de transferencia se define la operación ProcesarEntrada0:

58

ProcesarEntrada0

ΞCicloOperacion


Δ EstadosTransacciones

eao? : Entidad

ear? : Entidad

tx? : Transaccion

estadoTx_out! : EstadoTransaccion

estadoTx1_out! : EstadoTransaccion1

Pre: las 2 entidades eao? y ear?, cuyos códigos de compensación corresponden a los de la

Entidad Originadora EAO y la Entidad Receptora EAR en tx? son válidas y en estado Activa ∧

tx?.monto ≤ MONTOMAXIMO ∧

todos los campos de tx? vienen diligenciados y en el formato requerido ∧

la hora de envío de tx? está dentro de los rangos establecidos del tipo de evento Atencion

de alguno de los ciclos del día ∧

el código de transacción de tx? es válido para la Entidad Originadora ∧

el tipo de operación de tx? está dentro de las operaciones permitidas en el ciclo

Post: estadoTx_out!.estado = Procesado ∧

estadoTx_ out!.fecha = fecha del día ∧

estadoTx_ out!.transaccion = tx? ∧

estadoTx1_out!.estado = Procesado ∧

estadoTx1_out!. fecha = fecha del día ∧

if (tx?.fechaValor = fecha del día ∧ es día bancario ∧

(tx?.fechaEnvio≤ tx?.fechaValor≤ tx?.fechaEnvio+30días))

then

(estadoTx_ out!.hora = hora del día en que se realiza el procesamiento ∧

adicionarEstadoTransaccion (estadoTx_out!))

else if ((fecha del día > tx?.fechaValor) ∧ es día bancario) then

(estadoTx_ out!.hora = hora de inicio del primer ciclo del tipo de evento asociado a Atención ∧

adicionarEstadoTransaccion (estTx!))

else

estTx! = ∅

estadoTx1_out!. hora = estadoTx_ out!.hora ∧

eao?. historiaTxs′ = eao?.historiaTxs ⁀ (tx?↔ estadoTx1_out!) ∧

ear?. historiaTxs′ = ear?.historiaTxs ⁀ (tx?↔ estadoTx1_out!)

Figura 56. Método Procesar Entrada

Si alguna de las validaciones no permite el procesamiento de la entrada, ya sea porque la hora de recibo del archivo está fuera el rango o por exceder el monto máximo permitido para una entrada, entre otros, es importante extender la definición de la operación.

59

Por ello, se establece un tipo básico de reporte que permite definir salidas sobre las diferentes posibilidades en el procesamiento de una entrada.

A

REPORTE ::= ok | formato_campo_no_coincide |hora_fuera_rango | diaNoBancario |

valorTxExcede_Monto_Maximo | Error_en_el_monto |

Entidad_NoPermitida_Para_Participar | fechavalorfuera_del_TiempoEstablecido |

tipoOperacion_NoPermitido | CodigoTransaccion_No_Permitido_A_Entidad_Originadora

De otro lado, un procesamiento erróneo produce un reporte de salida, de acuerdo con la causa que lo genera, lo que induce a definir el siguiente esquema, el cual es referenciado en las operaciones de validación.

ErrorEntrada ΞTransaccion

tx? : Transaccion

r! : REPORTE

El error en el procesamiento puede deberse a que algún campo incluido no corresponde con la estructura del formato establecido.

EntradaFormatoNoCoincide ErrorEntrada

Pre: Un campo de tx? no viene diligenciado en el formato requerido

Post: r! = formato_campo_no_coincide

Si la transacción fue recibida en un horario que no está dentro de las horas de los ciclos establecidos para la atención de recepción de entradas, esta se procesa en el siguiente ciclo.

EntradaHoraFueraCiclo ErrorEntrada

Pre: La horade envio no está dentro de las horas establecidas de un ciclo

Post: r! = hora_fuera_rango

Procesamiento se realiza en ciclo n + 1 o en el primer ciclo del siguiente día hábil bancario

Si la transacción excede el monto máximo establecido, se define:

EntradaMontoTxExcedido ErrorEntrada

Pre: valor tx? excede monto maximo permitido

Post: r! = valorTxExcede_Monto_Maximo

60

Si el tipo de operación corresponde a una entrada no monetaria, como por ejemplo, una pre-notificación, pero el monto de la transacción es distinto de cero, se define:

EntradaErrorMonto ErrorEntrada

Pre: tipo de operación es de entrada no monetaria con valor tx? ≠ ∅

Post: r! = Error_en_el_monto

Si alguna de las entidades dentro de la transacción no se encuentra activa dentro de la estructura de entidades autorizadas:

EntradaEntidadNoAutorizada ErrorEntrada

ΞEntidadAutorizada

eao? : Entidad

ear? : Entidad

Pre: para alguna de las 2 entidades relacionadas en tx?, su valor de estado

(eao?.estado ∨ear?.estado) ≠ Activa

Post: r! = Entidad_NoPermitida_Para_Participar

Si la causal es porque la fecha valor no está dentro del número de días permitido:

EntradaFechaValorNoPermitida ErrorEntrada

Pre: la fecha valor para procesar tx? es mayor a 30 días hábiles bancarios

Post: r! = fechavalorfuera_del_TiempoEstablecido

Si la causal es porque la fecha valor no está dentro de un día bancario, la fecha valor efectiva será el día hábil inmediatamente siguiente, en la cual se efectuarán los registros que corresponden a la liquidación de la operación.

EntradaDiaNoBancario ErrorEntrada

Pre: La fecha valor de tx?es igual a la fecha del día pero no es día bancario

Post: r! = diaNoBancario

Procesamiento se realiza primer ciclo del siguiente día hábil bancario

Si el código de transacción asociado no le es permitida a la entidad originadora de la transacción, no se permite el procesamiento.

61

EntradaCodigoTransaccionNoPermitido ErrorEntrada

Pre: El código de transacción de tx? no está permitido a la entidad originadora

Post: r! = CodigoTransaccion_No_Permitido_A_Entidad_Originadora

Finalmente, si el tipo de operación no es permitido dentro del ciclo en el que se envió la transacción no es aceptada la orden de transferencia.

EntradaTipoOpNoPermitido ErrorEntrada

Pre: El tipo de operación de tx? no está dentro de las operaciones permitidas en el ciclo que corresponde

Post: r! = tipoOperacion_NoPermitido

Si la entrada es procesada correctamente se genera un mensaje con el valor de aprobación:

Aceptada ErrorEntrada

r! = ok

Con estas definiciones podemos tener una única definición de ProcesarEntrada que tiene en cuenta las causales de rechazo de una entrada

ProcesarEntrada ≙ (ProcesarEntrada0 ∧ Aceptada) ∨

(EntradaFormatoNoCoincide ∨EntradaEntidadNoAutorizada∨

EntradaDiaNoBancario ∨EntradaHoraFueraCiclo ∨

EntradaMontoTxExcedido ∨EntradaErrorMonto ∨

EntradaFechaValorNoPermitida ∨EntradaCodigoTransaccionNoPermitido ∨

EntradaTipoOpNoPermitido)

5.3.2.2 Compensación

El esquema de compensación se fundamenta en el cálculo de la posición multilateral neta (pmn) de cada entidad, donde, al finalizar un ciclo determinado, se efectúa la sumatoria de montos de sus transacciones débito y crédito recibidas y procesadas, correspondientes a ese ciclo, para generar un valor consolidado total, el cual se almacena y usa para afectar posteriormente la cuenta de depósito de cada entidad que tenga un monto a modificar.

Se define un tipo básico MSG_COMPENSACION para generar información de salida.

MSG_COMPENSACION := Compensacion_exitosa |Transaccion_ Pendiente_Compensar

62

Previo a la definición de la posición multilateral neta, es necesario especificar lo relacionado con el concepto de cuenta de depósito

5.3.2.2.1 Cuenta Corriente de Depósito

Una Entidad Autorizada debe poseer una cuenta corriente de depósito en el Banco Central, el cual es un contrato que se establece con personas jurídicas, públicas o privadas, para permitir, entre otros, el servicio de compensación interbancaria y tiene como fin garantizar el normal funcionamiento de los pagos generados por la economía, así como promover su eficiencia.

La cuenta de depósito tiene un saldo que es afectado en la liquidación de las órdenes de transferencia de pagos, las cuales, posterior a la afectación de la cuenta, son remitidas a las entidades receptoras o rechazadas a la entidad originadora. Por lo anterior, la estructura de una cuenta de depósito cuenta con los siguientes atributos.

• codigo_Entidad: Referencia que identifica a la Entidad Autorizada de la orden de transferencia, a quien se le afecta su cuenta de depósito.

• num_Cuenta: Número de la cuenta de depósito que la Entidad mantiene en el Banco Central, y sobre el que se debe afectar su saldo.

• saldo: Valor que la Entidad mantiene en la cuenta y que refleja el resultado de los diferentes movimientos débito y crédito realizados producto de las transacciones realizadas.

Estos atributos se agrupan bajo el esquema Cuenta_Deposito:

Cuenta_Deposito codigo_Entidad: CODIGO_COMPENSACION_ENTIDAD [único]

num_Cuenta: CODIGO_CUENTA [único]

saldo: ℤ

Figura 57. Esquema Cuenta de Depósito

Para tener el conjunto todas las cuentas de las Entidades Autorizadas se define su espacio de estado

CuentaDepositoEntidad cuentas_Deposito_Entidades: ℙCuenta_Deposito

Figura 58. Espacio de Estado Cuentas de Depósito

En un comienzo no existen cuentas de depósito asociadas a entidades, por lo tanto se define su estado inicial

63

InitCuentaDepositoEntidad Cuenta_Deposito_Entidad

cuentas_Entidades = ∅

Figura 59. Inicialización Cuentas de Depósito de las Entidades

Como es necesario consultar de manera recurrente el saldo de una cuenta de depósito, para efectos de determinar si la entidad tiene recursos suficientes para su afectación, se define la operación ConsultarSaldo.

ConsultarSaldo Ξ CuentaDepositoEntidad

cuenta_Deposito_Entidad? : cuenta_Deposito

monto!: ℤ

Pre: cuenta_Deposito_Entidad? existe dentro del conjunto de cuentas de depósito de la entidad

Post: monto! = cuenta_Deposito_Entidad?. saldo

Figura 60. Método Consultar Saldo Cuenta de Depósito

5.3.2.3 Posición Multilateral Neta

Como se indicó anteriormente, se requiere almacenar para cada Entidad Autorizada, el monto total correspondiente a las entradas que debitan o acreditan su cuenta de depósito, en un ciclo; por ello, se crea el esquema PosicionMultilateralNeta que define una función pmn para asociar a una entidad un monto y que tiene los siguientes atributos:

• codEntidades: contiene el conjunto de códigos de las entidades involucradas en la compensación.

• pmn: función parcial que asocia a cada entidad el monto resultante de la compensación multilateral neta, que va a ser el valor a afectar en el saldo de la cuenta de depósito de la entidad.

PosicionMultilateralNeta codEntidades : ℙ CODIGO_COMPENSACION_ENTIDAD

pmn : CODIGO_COMPENSACION_ENTIDAD ⇸ ℝ

codEntidades = dom(pmn)

Figura 61. Esquema Posición Multilateral Neta

En su estado inicial el conjunto de entidades es vacio:

64

InitPosicionMultilateralNeta PosicionMultilateralNeta

codEntidades = ∅

Figura 62. Inicialización Posición Multilateral Neta

La adición de una nueva posición recibe el código de una Entidad Autorizada, que no pertenece previamente al conjunto de entidades y un monto, que es el que se va a asociar como valor de la posición a esa entidad.

AdicionarPosicionMultilateralNeta Δ PosicionMultilateralNeta

codEA? : CODIGO_COMPENSACION_ENTIDAD

monto? : ℝ

Pre: codEA? ∉ codEntidades

Post: pmn′ = pmn ∪ {codEA? ↦ monto?}

Figura 63. Método Adicionar Posición Multilateral Neta

Teniendo en cuenta que una Entidad puede tener varios movimientos de entradas débito o crédito en un mismo ciclo, el valor del monto total asociado para esa entidad en el atributo pmn puede variar, por lo que es necesario contar con una función que permita actualizar esa variable.

Lo anterior, conlleva a definir la función ActualizarMontoPMN, que dado un código de entidad autorizada y una cantidad, adiciona la cantidad al monto actual que tiene la entidad como posición multilateral, devolviendo esta información dentro de una variable de tipo PosicionMultilateralNeta.

ActualizarMontoPMN : CODIGO_COMPENSACION_ENTIDAD × ℝ → PosicionMultilateralNeta

Δ PosicionMultilateralNeta

codEA?: CODIGO_COMPENSACION_ENTIDAD;

cantidadAActualizar?: ℝ;

posMultNeta! : PosicionMultilateralNeta

ActualizarMontoPMN (codEA, cantidadAActualizar) = posMultNeta ⇒

Pre: codEA? ∈ posMultNeta.codEntidades

Post: posMultNeta! .pmn(codEA)′ = posMultNeta!.pmn (codEA) + cantidadAActualizar?

Figura 64. Método Actualizar Monto Posición Multilateral Neta

Como se requiera consultar el valor de la posición multilateral neta para una entidad específica, se define la operación ConsultarPMN.

65

ConsultarPMN: CODIGO_COMPENSACION_ENTIDAD → ℝ

Ξ PosicionMultilateralNeta

codigoEntidad?: CODIGO_COMPENSACION_ENTIDAD;

montoPMN!: ℝ ;

ConsultarPMN (codigoEntidad?) = montoPMN ⇒

Pre: codigoEntidad? ∈ codEntidades

Post: montoPMN! = pmn (codigoEntidad?)

Figura 65. Método Consultar Posición Multilateral Neta de una Entidad

El cálculo de la posición multilateral neta (pmn) efectúa, en un ciclo determinado, la

sumatoria de montos para cada entrada débito y crédito, estableciendo un valor total de la

posición para cada entidad autorizada involucrada y se registra el nuevo estado dentro del

historial de cada transacción.

Con el fin de garantizar que posteriormente, durante la liquidación, no se modifiquen los

saldos de las cuentas de depósito de las entidades involucradas en el ciclo de compensación

ejecutado, se instaura una posición provisional, en el que se congelan de manera temporal

las cuentas de depósito por el valor arrojado en la posición multilateral neta.

66

CalcularPosicionMultilateralNeta

Ξ Transaccion

Ξ CicloOperacion

Ξ CuentaDepositoEntidad



Δ PosicionMultilateralNeta

numciclo? : ℕ1

txs! : ℙTransaccion

estadoTx! : EstadoTransaccion

estadoTx1! : EstadoTransaccion1

Pre: la fecha del día corresponde a un día hábil bancario ∧

el ciclo numciclo? es válido dentro del ciclo de operaciones ∧

inicio del cálculo es inmediatamente posterior a la finalizacion del horario del tipo de evento Atencion

perteneciente a numciclo?

let txs! = consultarTxs2(fechaDia, horario.horaInicio, horario.horaFin, Procesado) ⦁

(∀ tx : Transaccion | tx está dentro del conjunto de txs! ⇒

∃ ea1, ea2 : EntidadAutorizada; posmn1, posmn2: PosicionMultilateralNeta |

tx.codCompensacionEAO = ea1.codigoCompensacion ∧

tx.codCompensacionEAR = ea2.codigoCompensacion ⦁

if el tipo de operación de tx es de naturaleza débito then

(posmn1 = ActualizarMontoPMN (tx.codCompensacionEAO, tx.monto) ∧

posmn2 = ActualizarMontoPMN (tx.codCompensacionEAR, -tx.monto))

else

(posmn1 = ActualizarMontoPMN (tx.codCompensacionEAO, -tx.monto) ∧

posmn2 = ActualizarMontoPMN (tx.codCompensacionEAR, tx.monto)) ∧

Post: codEntidades ′ = codEntidades ∧

pmn ′ = (pmn ⊕ posmn1.pmn) ⊕ posmn2.pmn ∧

estadoTx!.estado = Compensado ∧

estadoTx!.fecha = fecha del día ∧

estadoTx!.hora = hora del día en que se realiza la compensación ∧

estadoTx!.transaccion = tx ∧

adicionarEstadoTransaccion (estadoTx!) ∧

estadoTx1!. estado = estTx!.estado ∧

estadoTx1!. fecha = estTx!.fecha ∧

estadoTx1!. hora = estTx!.hora ∧

ea1. historiaTxs′ = ea1.historiaTxs ⁀ (tx↔ estadoTx1!) ∧

ea2. historiaTxs′ = ea2.historiaTxs ⁀ (tx↔ estadoTx1!) ∧

saldo congelado de la cuenta de depósito de cada Entidad Autorizada en la compensación

) )

67

Figura 66. Método Calcular Posición Multilateral Neta

Cuando se lleva a cabo la liquidación, en el cual se afecta el saldo de la cuenta de depósito de cada Entidad, se puede requerir hacer un re-cálculo de la posición multilateral neta, teniendo como límite el saldo congelado de la cuenta de depósito, por ello se hace una variación de recálculo sobre la operación CalcularPosicionMultilateralNeta.

En el recálculo, se hace un ordenamiento ascendente de todas las transacciones procesadas de un ciclo, según el monto de las mismas, y luego se valida para cada orden de transferencia, que el saldo de la cuenta de depósito de la Entidad Originadora o Receptora, dependiendo de la naturaleza de la transacción, sea mayor al monto de la transacción.

De ser correcta la validación, se actualiza el valor de la posición multilateral neta para las entidades involucradas en cada transacción, que queda en estado Compensado y dejando el saldo liberado para las cuentas de depósito, de las Entidades que se les va afectar su saldo.

De no cumplirse la validación, la transacción no es compensada y se genera un mensaje de salida y se mantiene el saldo congelado para esas Entidades.

68

RecalcularPosicionMultilateralNeta …………….

msgCompensacion!: MSG_COMPENSACION

Pre: ………..

saldo congelado de la cuenta de depósito de cada Entidad Autorizada en la compensacion

en txs! se deja el conjunto de transacciones Procesadas en orden ascendente según el monto

(∀tx : Transaccion | tx está dentro del conjunto de txs! ⇒

∃ ea1, ea2 : EntidadAutorizada; posmn1, posmn2: PosicionMultilateralNeta |

…………

Post: if el tipo de operación de tx es de naturaleza débito then

(if saldo de la cuenta de depósito entidad con código tx.codCompensacionEAR ≥ tx.monto then

(posmn1 = ActualizarMontoPMN (tx.codCompensacionEAO, tx.monto) ∧

posmn2 = ActualizarMontoPMN (tx.codCompensacionEAR, -tx.monto) ∧

codEntidades ′ = codEntidades ∧

pmn ′ = (pmn ⊕posmn1.pmn) ⊕ posmn2.pmn ∧

estadoTx!.estado= Compensado ∧

………….


………….

ea1. historiaTxs′= ea1.historiaTxs ⁀ (tx↔ estadoTx1!)


saldo liberado de la cuenta de depósito de Entidad Autorizada )

else

msgCompensacion! = Transaccion_Pendiente_Compensar)

else

(if saldo de la cuenta de depósito entidad con código tx.codCompensacionEAO ≥tx.monto then

( posmn1 = ActualizarMontoPMN (tx.codCompensacionEAO, -tx.monto) ∧

posmn2 = ActualizarMontoPMN (tx.codCompensacionEAR, tx.monto) ∧

codEntidades ′ = codEntidades ∧

pmn ′ = (pmn ⊕posmn1.pmn) ⊕ posmn2.pmn ∧

estadoTx!.estado= Compensado ∧

……….


……….



saldo liberado de la cuenta de depósito de Entidad Autorizada )

else

msgCompensacion! = Transaccion_Pendiente_Compensar) ) )

Figura 67. Método Re-cálculo Posición Multilateral Neta

69

5.3.2.4 Liquidación

Una vez se ha determinado la posición multilateral neta para cada entidad financiera referida en un ciclo, es necesario afectar su cuenta corriente de depósito que posee en el Banco de la República, según la disponibilidad de fondos. Se define un tipo básico MSG_LIQUIDACION para generar información de salida.

MSG_LIQUIDACIÓN := Liquidación_exitosa |Fondos_Insuficientes

Ante insuficiencia de fondos de la cuenta de depósito de una Entidad Autorizada, se establece un lapso de tiempo para que la entidad abone los recursos necesarios y se reintente la liquidación de las posiciones multilaterales netas. Por lo anterior, definimos la constante TIEMPO_ESPERA_ABONO_RECURSOS

TIEMPO_ESPERA_ABONO_RECURSOS: ℤ

TIEMPO_ESPERA_ABONO_RECURSOS = 2 HORAS

En la liquidación se toma el monto de la posición multilateral neta de cada Entidad y de acuerdo con la suficiencia de fondos, su cuenta de depósito es afectada, de lo contrario las transacciones en las cuales está involucrada la Entidad que no pudieron ser afectadas, al finalizar el día son rechazadas.

Se obtienen las transacciones que se encuentran en estado Compensado en un ciclo, y para cada Entidad Autorizada que tenga alguna transacción en trámite, se consulta su posición multilateral neta cuyo valor se compara con el saldo disponible de su cuenta de depósito.

Si el saldo de la cuenta es suficiente para su afectación, se actualiza el saldo por el valor de la posición multilateral neta y las transacciones asociadas de la Entidad quedan en estado Liquidado.

Si el saldo es insuficiente, después de un tiempo de espera se reintenta la liquidación para dar tiempo a las Entidades faltantes de abonar a la cuenta de depósito el recurso faltante.

De persistir la insuficiencia de recursos y si no se está en el último ciclo del día, se hace un recálculo de la posición multilateral neta para que se posibilite liquidar la mayor cantidad de pagos, y nuevamente se intenta la liquidación, dejando para el siguiente ciclo las transacciones que no alcanzan a ser liquidadas.

De llegar al último ciclo del día y el saldo de la cuenta de depósito no es suficiente, las transacciones asociadas son rechazadas. De acuerdo con el resultado se genera un mensaje de salida.

70

Liquidar

Ξ Transaccion

Ξ CicloOperacion

Ξ PosicionMultilateralNeta



Δ CuentaDepositoEntidad

numciclo? : ℕ1

txs! : ℙTransaccion

estadoTx! : EstadoTransaccion

estadoTx1! : EstadoTransaccion1

msg!: MSG_LIQUIDACIÓN

Pre: la fecha del día corresponde a un día hábil bancario ∧

el ciclo numciclo? es válido dentro del ciclo de operaciones ∧

la liquidacion corresponde al horario asociado al tipo de evento Atencion perteneciente a numciclo?

let txs! = consultarTxs2(fechaDia, horario.horaInicio, horario.horaFin, Compensado) ⦁

para cada Entidad Autorizada, ea, involucrada en txs! se tiene una variable montoPMN

montoPMN = ConsultarPMN (ea.codigocompensacion )

Post: saldo de la cuenta de depósito de ea es afectada según criterios:

if saldo disponible de la cuenta de depósito de ea ≥ montoPMN then

actualiza saldo de la cuenta de depósito de ea por el valor montoPMN ∧

las transacciones asociadas de ea quedan en estado Liquidado ∧

las transacciones se adicionan al conjunto de estados de transacciones con su nuevo estado ∧

msg!= Liquidación_exitosa

else

reintenta Liquidar después de TIEMPO_ESPERA_ABONO_RECURSOS ∧

if continua insuficiencia de recursos then

if numciclo? ≠ penultimo o último del día then

RecalcularPosicionMultilateralNeta(numciclo?) ∧

intenta Liquidar

else if numciclo? = penultimo o último del día then

las transacciones asociadas no compensadas quedan en estado Rechazado ∧

msg! = Fondos_Insuficientes

else

actualiza saldo de la cuenta de depósito de ea por el valor montoPMN ∧

las transacciones asociadas de ea quedan en estado Liquidado ∧

las transacciones se adicionan al conjunto de estados de transacciones con su nuevo estado ∧

msg!= Liquidación_exitosa

Figura 68. Método Liquidación

71

5.4 Resultados de la Especificación

El resultado de este ejercicio de especificación, es producto de un largo proceso que implicó varias etapas de revisión y afinamiento, desde la utilización únicamente de la notación formal rigurosa de Z, hasta llegar al punto en el que fue necesario tomarse las libertades del caso para expresar un mejor dimensionamiento de las necesidades del negocio.

La utilización del lenguaje natural dentro de las invariantes, pre-condiciones y post-condiciones, facilitó el proceso de elaboración de la especificación, el cual en términos estrictamente matemáticos resulta muy dispendioso de elaborar y a la hora de los resultados finales poco beneficioso, salvo que se quisiera para efectos de demostración matemática.

La compensación interbancaria, tiene muchas variables e interrelaciones, que no se manejan de manera independiente, están conectadas con los componentes de otros sistemas y dada la complejidad del tema, solo se contemplaron las reglas de negocio esenciales.

Si bien, no se expresa toda la problemática asociada a la compensación electrónica interbancaria, se logró plasmar en la especificación las reglas de negocio y condicionantes que resaltan la importancia sistémica dentro de la infraestructura del sistema de pagos.

El proceso de desarrollo de la especificación permitió precisar y conceptualizar elementos que en la normatividad existente son abstractos y que inclusive solo están claros por las personas que manejan el día a día de las operaciones, pero cuyos conceptos no siempre son homogéneos.

De igual manera, la especificación resultante facilita la comprensión de las necesidades a cubrir en términos, tanto del usuario de negocio como de los analistas e ingenieros desarrolladores.

Uno de los inconvenientes a la hora de entender las necesidades es que la documentación base, está expresada en términos de los sistemas actuales, por consiguiente, se dificulta la identificación real de la problemática asociada con la compensación interbancaria, al ser un problema empresarial complejo dentro del sector financiero.

Esta situación ocurre, por ejemplo, con la parte reglamentaria, que está expresada en términos del sistema utilizado hoy en día y muchas veces se pretende, por los mismos usuarios de negocios, sistematizar los procesos operativos tal como están funcionando y no se da paso a una verdadera solución de ingeniería.

Para lograr un mejor entendimiento y completitud hay situaciones donde es necesario especificar objetos, que así no formen parte del futuro sistema a implementar, ya sea porque el objeto de negocio en cuestión pertenece a otro sistema o porque no está dentro del alcance establecido, es importante desarrollar su concepto.

72

6 RESUMEN DE LA GUÍA METODOLÓGICA

La guía metodológica plantea un enfoque intermedio, donde se mezcla el lenguaje textual con las bondades del lenguaje de esquemas a través del manejo de estructuras y comprende:

1. Entendimiento de las reglas de negocio, para determinar el alcance del problema o necesidad a especificar; identificar los objetos de negocio con sus características distintivas, así como las operaciones asociadas e interrelaciones entre los objetos.

2. Introducción en narrativa del concepto de negocio que se está analizando, junto con los objetos identificados que representan el mundo real y que está orientado principalmente para el entendimiento por las personas del negocio. Adicionalmente, se describen algunos de los elementos a ser utilizados en la especificación, como es la definición de tipos, significado de los atributos del objeto de negocio identificado.

3. Inicio especificación “semi-formal”, orientada al ingeniero desarrollador o personas técnicas, a través de la definición de esquemas, que representan los objetos de negocio identificados previamente. Un esquema está compuesto de 3 partes:

• Un nombre que identifica el esquema.

• Una zona de declaraciones, donde se describen los atributos con sus tipos, del esquema que se está definiendo. Se debe distinguir el atributo identificador del esquema.

• Una zona de propiedades, donde se relacionan las invariantes relacionadas con los atributos del esquema. En esta parte se da libertad para describir las invariantes en lenguaje natural, cuando se considere que al utilizar la notación matemática se puede confundir al lector.

La visualización de un esquema es:

4. Cada esquema tiene asociado un espacio de estado, que debe ser definido e inicializado, por el cual se establece el conjunto de esquemas de un mismo tipo que pueden operar en el sistema.

Esta noción permite interpretar cada esquema como componentes independientes del sistema, que pueden ser referenciados individualmente en los métodos.

73

5. Enseguida viene la definición de las operaciones o métodos asociados a los esquemas, que describen las funcionalidades asociadas a uno o varios objetos del negocio. La estructura es similar a la de un esquema, pero contiene elementos adicionales en la parte de las declaraciones:

• Invocación de esquemas, utilizando los símbolos “∆” ó “Ξ”, dependiendo si se requiere o no hacer cambio de valores en algún atributo, seguido del nombre del esquema.

• Declaración de parámetros de entrada, distinguidos al final con el símbolo “?”, en los cuales se puede referenciar un objeto particular de un esquema, sobre el cual se pueden llevar a cabo acciones de modificación o de consulta.

• Parámetros de salida, distinguidos por el signo de admiración “!” después del nombre del atributo.

En el área de propiedades, se referencian las pre-condiciones y post-condiciones. En los primeros se especifican las condiciones que deben satisfacer tanto los parámetros de entrada. En los segundos, se expresan los valores esperados resultantes, como resultado de las acciones realizadas en el método.

Ante un cambio en el valor de un atributo, se distingue el atributo modificado adicionando al final del mismo el símbolo “ ′ ”.

Se otorga libertad en la pre-condición y post-condición, para la utilización de lenguaje textual, en procura de brindar una mayor claridad.

Cuando en un método la pre-condición no se cumple, se debe considerar las condiciones que se incumplen para indicar las acciones que el sistema debe realizar en cada caso.

Bajo esta perspectiva, se divide la especificación del método en esquemas más pequeños, donde se pueda diferenciar el caso en el que se satisface completamente las reglas de negocio, de aquellos casos que no se cumplen.

Se define un esquema por cada condición incumplida, de manera que se identifiquen todos los posibles casos, con su mensaje de salida de manera independiente.

Finalmente, se expresa la definición única del método, agrupando los esquemas creados relacionados, invocados por el nombre de cada método definido.

OperaciónXi := <NombreOperación Xi Exitosa> ∨ <NombreOperación Xi Fallida1> ∨ …..

<NombreOperación Xi FallidaN>

De esta forma se obtiene más claridad y se puede asegurar tener un tratamiento sobre las condiciones que ocasionan una falla en el sistema a desarrollar.

74

7 CONCLUSIONES

Esta guía metodológica fue elaborada a partir de la experiencia obtenida con el desarrollo del caso práctico, no obstante lo anterior, es pretensioso, a partir de un ejemplo, llegar a establecer una metodología, para esto se requiere un proceso de afinamiento, a través de su aplicación en varios casos, que permitan confirmar o refutar la presente propuesta.

Una especificación en términos matemáticos, requiere un mayor esfuerzo y complejidad para expresar la precisión y exactitud de la notación matemática y la relación costo/beneficio se ve disminuida, con respecto a realizar la especificación incluyendo lenguaje natural.

El lenguaje natural puede carecer de exactitud, pero permite acercar más al lector en lo que pretende una especificación, de plasmar las reglas y necesidades de negocio de una manera más sencilla y entendible, lo que fortalece la idea de sacrificar algo del rigor de la notación matemática.

Lograr el equilibrio entre la utilización de la notación matemática y la del lenguaje natural, no es fácil y plantear hasta donde se debe ser formal y hasta donde no, requiere un uso efectivo y práctico de ambas notaciones. Lo anterior, involucra un proceso iterativo de revisión hasta lograr el nivel de especificación deseada.

No obstante la reducción en la utilización del lenguaje matemático, ofrecido por Z, el manejo del lenguaje de esquemas, para representar los objetos de negocio, se convierte en un mecanismo poderoso que un desarrollador puede tomar como punto de partida, para convertirse en los elementos de la estructura de datos del futuro sistema.

La inmediatez requerida para la generación de productos, incide en la asignación de recurso humano para el desarrollo de especificaciones formales.

La aplicación de la guía debe obedecer a un convencimiento, por parte de los gerentes de las empresas desarrolladoras de software, así como de las áreas de negocio, de los beneficios que trae para un proyecto el elaborar especificaciones siguiendo un marco metodológico de trabajo, que se pueda aplicar de manera homogénea en todos los proyectos.

La especificación de problemas, si bien no es la única forma, debe irse desarrollando de manera gradual, teniendo en cuenta el nivel de complejidad y la relevancia de los objetos a modelar; por ello, para lograr un mejor entendimiento, se debe tener como punto de partida los objetos de negocio básicos.

Es difícil evidenciar a nivel de la presente propuesta la especificación de requerimientos no funcionales como disponibilidad, desempeño, portabilidad, escalabilidad, entre otros. Para ello, se debe acudir a la utilización de otro tipo de herramientas.

75

8 TRABAJOS FUTUROS

Probablemente hay muchas maneras de expresar y mejorar el resultado del ejercicio planteado y en la medida que se aplique para otras especificaciones se podrá mejorar el estilo.

La guía metodológica se definió tomando como referencia la especificación de un caso complejo dentro del sector financiero, no obstante, dado el nivel de generalización bajo la cual está concebida, se plantea la posibilidad de su aplicación en trabajos futuros relacionados con áreas de negocio diferentes al sector financiero.

La finalidad es que esta guía se constituya en un generador de ideas, para que pueda ser utilizado como una práctica ingenieril, por las personas encargadas de conducir un proceso de especificación formal, teniendo como base el marco metodológico propuesto.

9 REFERENCIAS

[1] Monin, J-F. Understanding formal methods. New York: Springer. (2003).

[2] Clarke, Edmund M., Wing Jeannette M, Al Et, Formal Methods: State of the Art and Future Directions. ACM Computing Surveys, Vol. 28, No. 4, Diciembre 1996.

[3] Lamsweerde Axel van, Formal Specification: A Roadmap, Département d’Ingénierie Informatique, Université catholique de Louvain, Belgium.

[4] International Estándar ISO/IEC. Information technology – Programming languages, their environments and system software interfaces - Vienna Development Method - Specification Language – Part 1. ISO/IEC 13817-1:1996.

[5] Alagar V.S., Periyasami K., Specification of Software Systems. Springer, 2da edición, 2011.

[6] VDM Portal. The VDM-SL examples. Tomado de la página http://www.vdmportal.org/twiki/bin/view/Main/VDMSLexamples

[7] International Estándar ISO/IEC. Information technology — Z formal specification notation — Syntax, type system and semantics. ISO/IEC 13568:2002.

[8] Woodcock Jim, Davies Jim. Using Z Specification, Refinement, and Proof, 1a Edición, Prentice Hall, 1996.

[9] Spivey J. M., The Z notation - Reference Manual. 2da Edición, Prentice Hall, 1992.

[10] Boca P., Bowen J., Siddiqi J., Formal Methods: State of The Art and New Directions. Springer, 2010.

[11] Comité de Sistemas de Pago y Liquidación (CPSS) del Bank for International Settlements, Glosario de términos utilizados en los sistemas de pago y liquidación, Marzo de 2003. Tomado de la página http://www.bis.org

76

[12] Banco de la República, Reglamento Operativo del Servicio de Compensación Interbancaria. Tomado de la página http://www.banrep.gov.co/documentos/reglamentacion/CEDEC/reg_comp_inter.pdf.

[13] Banco de la República, Circular Reglamentaria Externa DSP-152. Compensación Electrónica nacional Interbancaria – CENIT, 12 de Octubre de 2011.

77

ANEXO 1. INTERRELACIÓN DE OBJETOS COMPENSACIÓN INTERBANCARIA

class Objetos del domi...

Transaccion

- codCompensacionEAO: texto- codCompensacionEAR: texto- codTransaccion: numerico- fechaHoraEnvio: fechaHora- fechaValor: fecha- IdentificacionReceptor: texto- idOperacion: numerico- indicadorAdenda: texto- monto: numerico- nombreReceptor: texto- numCtaDepositoO: texto- numCtaDepositoR: texto- numCtaReceptor: texto- tipoTransaccion: texto

OperadorCENIT

+ confirmarRecibido(archivo)+ consultaTx(fecha, fecha, EntidadAutorizada, Transaccion, lista(Adenda))+ enviarConfirmacionEAO(archivo)+ enviarDevolucionDeDevolucionEAR(archivo)+ enviarDevolucionEAO(archivo)+ enviarOrdenEAR(archivo)+ establecerPosicionMulti lateralNetaEA(Transaccion, fecha, CicloOperacion)+ l iquidar(CicloOperacion)+ procesarEntrada(Transaccion)+ recibirConfirmacionEAR()+ recibirDevolucionDeDevolucionEAO(archivo)+ recibirDevolucionEAR(archivo)+ recibirTransaccion(archivo)

CicloOperacion

- evento: l ista = Atención, Publi...- horaFin: numerico- horaInicio: numerico- numCiclo: numerico

+ adicionarCiclo(CicloOperacion)+ consultarCiclo(CicloOperacion)

EntidadAutorizada

- calidadEA: l ista = Originador,Rece...- codigoCompensacion: texto- codigoPlaza: texto- codigoSebra: texto- estadoEntidad: l ista = Activo,Retirado...- fechaRetiro: fecha- fechaVinculacion: fecha- nombreEA: texto- numCuentaDeposito: texto- usuarios: UsuarioRol

+ crearEA(EntidadAutorizada)+ retirarEA(EntidadAutorizada)+ suspenderEA(EntidadAutorizada)

Estado

- codigoEstado: numerico- nombreEstado: texto

+ consultarEstado(Estado)+ crearEstado(Estado)+ eliminarEstado(Estado)+ modificarEstado(Estado)

EstadoTransaccion

- estado: Estado- fechaHora: fecha- transaccion: Transaccion

+ adicionarEstadoTransaccion(EstadoTransaccion)+ consultarEstadoTx(Estado)

CodTransaccion

- codigoTransaccion: numerico- nombreCodigoTx: texto

+ consultarCodTx(CodTransaccion)+ crearCodTx(CodTransaccion)+ el iminarCodTx(CodTransaccion)+ modificarCodTx(CodTransaccion)

TipoOperacion

- codTipoOperacion: numerico- nomTipoOperacion: texto

+ consultarTipoOperacion(TipoOperacion)+ crearTipoOperacion(TipoOperacion)+ el iminarTipoOperacion(TipoOperacion)+ modificarTipoOperacion(TipoOperacion)

OperacionesPermitidas

- ciclo: CicloOperacion- tipoOperacion: TipoOperacion

+ adicionarOpACiclo(OperacionesPermitidas)+ consultarOperacionesPermitidas(CicloOperacion)

UsuarioRol

- idUsuario: int- nombre: texto

1

Pertenece

1

1

Estaen1..*

1

puedeestar

1..*

1

Estaen

1..*

1

Tiene

1..*

1

Recibe

1..*

1

Origina

1..*

1

Tiene

1..*

1Tiene

1..*

1

Seprocesaen

1..*

1

Verifica

1..*

1

Atiende

1..*

1

Gestiona

1..*

1

puedetener

1..*

guÍa metodolÓgica para la especificaciÓn semi-formal

Documents