PATO es el acrónimo de Procesos, Actividades, Tareas y Operaciones y es una metodologia para el diseño, especificacion y generación automática de una aplicación
Este Modelo permite descubrir los componentes basicos de un sistema y definir como se articulan para componer así la aplicación.
Decimos entonces que la aplicación tiene 4 visiones o perspectivas bajo las cuales se diseña, se entiende. Estas son:
- Visión de Datos
- Visión de Procesos
- Articulación u orquestamiento
- Visión de explotación
Definir estas 4 visiones trae como resultado poner de manifiesto (exponer) un conjunto de "Operaciones Básicas" o "Servicios" asociados a mis Entidades de Negocio y que son la materia prima para la construcción de una aplicación bajo el paradigma SOA .
El uso de este Modelo persigue los siguientes Objetivos:
- Es una forma sencilla, formal y esquemática de representar la funcionalidad que tendrá una aplicación y dice mucho de cómo la misma se implementará.
- Consigue que las operaciones básicas sean mas autónomas. Encapsula la lógica de las operaciones del sistema, de forma de lograr: reusabilidad y mantenibilidad (orientación SOA) . Las operaciones son pensadas de forma independiente a la forma de ser accedidas o a la forma de que participan en los proceso. Esto permite que sean reusables, mantenibles
- Dado que la lógica de los procesos se implementan en un Motor de Workflow (GXFLOW), es posible modificar los procesos sin necesidad de modificar la lógica de las operaciones.
- Permite definir patrones de comportamiento de la operaciones básicas y patrones para la articulación de las mismas de forma tal de poder industrializar la construcción Software (generar en forma automatica gran parte de los objetos de una aplicación) .
Esta metodología es usada para el desarrollo de los Productos K2B (Knowledge to Business, ERP), y Proyectos de GeneXus Consultingy está en continua evolución.
Es importante tener en mente estos objetivos y verificar que todo lo que se hace permita cumplir con ellos. Esto será el gran diferenciador en la construcción de Productos y además creemos que será la base para el desarrollo de una metodología genérica de construcción de aplicaciones, y a partir de esto desarrollar tecnología (GeneXus) para soportarla en mejor forma.
Para conseguir entonces estos objetivos, diseñamos la aplicación bajo un modelo que lo llamamos PATO (Process-Activity-Task-Operation).
La especificación de la aplicación se hace bajo 4 perspectivas o visiones:
La visión de datos es la primera que se aborda y consiste en identificar las entidades de negocio más importantes de la aplicación y su clasificación en actores, objetos y eventos. ( Marco de referencia)
Las entidades de Negocio son estructuras de datos en las cuales persisten los datos asociados a estos actores, objetos y eventos.
Actores: Los Actores son aquellos objetos de la aplicación que pueden tener iniciativa en el sistema (Usuarios, Clientes, Proveedores).
Objetos: Los Objetos son los que no la tienen y pueden ser objetos tangibles de la realidad (ej: Producto, Monedas) u objetos que se crean para clasificar, definir comportamientos del sistema en base a ellos, tener un mejor grado de flexibilidad y capacidad de explotación de la aplicación, por ejemplo (ej: Término de Pago, Tipo de Transacción, Centros operativos, Centros de costo).
Eventos: Las entidades de tipo: "Evento", son aquellas que materializan los eventos que ocurren en la aplicación: Solicitud de compra, Orden de Compra, Factura, etc.
Los Objetos y los Actores constituyen el "marco de referencia de los eventos de la aplicación".
Ejemplo:
ENTIDADES DE NEGOCIO
- Actores
- Objetos
-
- Producto
- Tipo de Producto
- Termino de Pago
- Eventos
-
- Solicitud
- Orden de Compra
- Factura del Proveedor
Muchas de estas Entidades de Negocio se definirán en el arranque y algunas otras serán descubiertas durante el proceso de diseño.
Finalizado el proceso de diseño tendremos para cada una de las entidades de Negocio la siguiente información:
- Nombre de la Entidad de negocio
- Define el nombre con que se invoca a la Entidad, debe ser único en términos de universalidad
- Tipo de entidad de Negocio
- Clasifica a la Entidad en algunos de estos tipos: Actor, Objeto , Evento
- Componentes de la Entidad de Negocio
- Refiere a una agrupación lógica (no física : no refiere a tablas) de los grupos de datos que componen la Entidad.
| Entidad de Negocio |
Tipo de Entidad |
Componente |
| Producto |
Objeto |
Datos generales |
| |
|
Datos contables |
| |
|
Datos de logistica |
| |
|
Datos para manejo de Stocks |
Factura |
Evento |
Datos del Cabezal |
| |
|
Términos y condiciones generales |
| |
|
Datos de las líneas |
| |
|
Afectación de Costos |
| |
|
Términos y condiciones de las líneas |
| Persona |
Actor |
Datos generales |
| |
|
Direcciones |
| |
|
Telefonos |
- Si la Entidad es extensible o no
- Define si va a tener OAV (si se le pueden agregar atrubutos en run-time)
- Reglas de la Entidad
- Define las reglas de la Entidad de negocio. Estas reglas deberán ser disparadas en todas las operaciones que tienen como entidad Base, esta Entidad
- Servicios/ operaciones de la Entidad
- Una vez terminado el proceso de diseño (definición del PATO) se obtiene como resultado un conjunto de operaciones, asociadas a cada Entidad
Ejemplo:
Entidad |
Operaciones |
| Orden de compra |
Ingreso |
| |
Actualicación |
| |
Anulación |
| |
Impresión |
| |
Finalización |
Consiste en identificar los procesos de negocio y para cada uno de ellos el conjunto de actividades que invoca.
Un Proceso de negocio es una secuencia de actividades que se ejecutan según una lógica de procesos. Esta lógica de procesos es definida y controlada por un Motor de Workflow.
Extraer la lógica de Procesos de los componentes de una aplicación y encapsularlos en un motor de Workflow, es uno de los elementos que le da mayor flexibilidad a los sistemas pues en general es el componente mas dinámico.
De esta manera es posible cambiar la lógica de procesos de negocio sin cambiar una línea de código de mis sistemas.
El análisis orientado a procesos descubre o deja de manifiesto las actividades. Estas actividades son los elementos atómicos del Sistema desde el punto de vista del usuario final (se ejecutan toda la lógica asociada o nada)
Sin embargo estas actividades no son atómicas desde el punto de vista de costrucción de SW y contienen un conjunto Tareas
Esas Tareas a su vez contienen un conjunto de operaciones elementales que se articulan en base al siguiente Patrón:
- Actividad:
- Tareas (Transacciones desde el punto de vista GeneXus):
- Operación Principal o Tarea
- Operaciones secundarias de la Tarea
- Operaciones de Apoyo a la Tarea
Si juntamos esto con la visión de Procesos tenemos :
- Procesos
- Actividades
- Tareas
- Operaciones
El Modelo resulta de combinar todos estos elementos en base a Patrones predefinidos de forma tal de poder generar la mayor parte de la aplicación en forma automática.
Actividad
Una actividad representa un caso de uso de mi aplicación . Es realizada por un usuario cuando se lo demanda el motor de WF o cuando hay hecho externo que provoca dicha actividad.
El mecanismo de acceso a esa actividad puede ser el Inbox, o un mecanismo de acceso WW (Objeto acción).
Una actividad puede diseñarse en forma simple (Una sola Tarea = un objeto GeneXus) o puede requerir de la articulación de varias Tareas
Identificamos hasta ahora 3 Patrones para articular una Tarea.
- Entity Manager: Es un articulador que permite acceder a todas las Tareas de la actividad mediante el uso de Tabs.
- Wizard: Es un articulador que permite definir una la secuencia de tareas que conforman una actividad.
- Workflow: Varios actores realizan esa actividad según una secuencia dada por lo que esto es articulado por un Workflow.
Ejemplo 1: Entity Manager (Producto)
La actividad : Ingreso de Producto tiene varias Tareas que lo componen
- Datos Generales
- Datos Contables
- Datos de Almacen
El Patron "Entity manager" me permite generar la Actividad te forma tal que las Tareas asociadas se presentan en forma de Tabs.
En este caso, el órden de dichas Tareas no es importante y podrán ejecutarse en cualquier orden.
Ejemplo2: Wizard (Proveedor)
Para ejecutar la actividad Crear un Proveedor es necesario ejecutar las siguientes tareas:
- Ingresar los datos generales
- Ingresar los datos contables
- Definir los Productos que provee
- Definir los convenios para esos productos
Este proceso requiere un orden por lo cual voy a implementar la ejecución de la secuencia de dichas Tareas con un articulador: Wizard
Ejemplo3: Workflow (Proveedor)
Para ejecutar la actividad Crear un Proveedor es necesario ejecutar las siguientes tareas, pero por usuarios diferentes por lo que la actividad es comandada y articulada por el WF.
- Ingresar los datos generales
- Ingresar los datos contables
- Definir los Productos que provee
- Definir los convenios para esos productos
Tarea
Las tareas se asimilan con el concepto de Transación en GeneXus En general una Tarea persiste en una Entidad de Negocio , tienen un conjunto de reglas de consistencia (Business Rules) , si se confirma ejecuta una cantidad de acciones (operaciones de la Tarea) y el usuario requiere un conjunto de Operaciones de apoyo para ejecutarl
Operaciones
Las operaciones son los componentes elementales desde el punto de vista de construcción de software y constituyen los servicios basicos de una aplicación.
- Las operaciones que hemos descubierto en el proceso anteriormente especificado tienen un criterio de desarrollo y propiedades que definimos a continuación:
- Tienen una función específica, lo más elemental posible.
- Tiene un input y output bien definido (dentro del output se debe preveer errores posibles). Se describe conceptualmente los parámetros (o los elmentos de contexto) de entrada y salida de la operación. Una operación esta claramente definida cuando están definidos sus in y outs. Lo importante es definirlos a nivel conceptual (no es necesario llegar a nivel de detalle de estructuras o variables) O sea, si sabemos que una operación recibe como input un término comercial, no es necesario detallar la estructura que representa el mismo, pero si saber que recibirá una estructura o un conjunto de variables (que se definirá luego) que describe exactamente un término comercial.
- Persiste en una entidad de negocio base
- La operación no implementa nada sobre la forma de acceder a ella o del proceso en el que participa.Una misma operación debe poder ser accedida a través de diferentes mecanismos, sin que esto afecte en absoluto la lógica de la operación. (desde WorkFlow, desde WorkWith , desde otra operación, etc.
- Propiedades a definir para una operación:
- Nombre de la operación- : Debe ser unico en sentido universal (deberá identificarse únicamente por su nombre)
- Descripción - Descripción extendida de la operacion para complementar su descripción. Puede incluirse archivos....
- Propietario - Persona o grupo responsable de desarrollar la operación
- Pública - Si otros módulos necesitan esa operación
- Privada - Si solamente mi módulo va a referenciarla.
Como especifico la explotación de una aplicación?
Básicamente decimos que existen 2 patrones bajo los cuales se diseña la explotación de una aplicación:
- Explotación multidimensional
- Explotación en cascada
Explotación multidimensional
Consiste en la definición de Dimensiones e indicadores que componen un modelo de medición.
Ese Modelo puede ser utilizado por el Query ( Va sobre la base de Datos operacional) o Bajo GXplorer ( va sobre un Datawarehouse)
Los componentes de explotación generados bajo este patrón constituyen servicios en si mismo y podrá invocarse desde cualquier actividad de la aplicación.
Cada "Evento" es la materia prima para las Fact tables y podrán inferirse en forma automatica las dimensiones e indicadores que analizan ese hecho.
Un patron es capaz de generar automaticamente los modelos multidimensionales tomando como entrada la base de conocimiento de una aplicación y generando ademas:
- Cubos multidimensionales
- Mecanismos de carga de los cubos
- Accesos a los cubos desde las Entidades de negocio que están reperesentadas en sus dimensiones o el evento principal.
- Generación de los Metadatos para poder analizar esta info desde GXquery o GXplorer.
Explotación en cascada (Patrón View)
El segundo patrón utilizado para la explotación es el que llamaremos "Explotación en cascada"
Este Patrón sigue basicamente las siguientes reglas:
Para cada Entidad de Negocio :( Actores, Objetos, Eventos), se genera el acceso a :
- Los datos mas significativos de la Entidad de negocio
- Eventos claves asociados a la Entidad
- Eventos asociados al evento clave (tracking del evento Main)
- Otra información elaborada asociada a la Entidad
Ejemplo:
- Entidad de Negocio = Proveedor
- Datos mas significativos de la Entidad= Datos del Proveedor
- Eventos claves asociados a la Entidad = Facturas del Proveedor
- Eventos asociados al evento clave =Ordenes de Pago
- Recibos asociados a la Orden de Pago.
- Otra información elaborada asociada a la Entidad = Posición del Proveedor
Esto es generado automáticamente por el Pattern.
¿Cómo resulta la arquitectura de una aplicación generada bajo este Modelo?
El Portal proporciona el mecanismo de acceso a cualquiera de los paradigmas de la aplicación ( WF, Mecanismos Objeto acción, Modelo multidimensional) y encapsula la seguridad y el control de acceso a los diferentes recursos de la aplicación.
Los objetos que son articuladores de los servicios básicos son generados automáticamente por k2b Entity Services.
Los servicios básicos de las entidades de negocio son generados automaticamente por k2bEntity Services.
Este modelo da semántica a una aplicación y permite apoyar la generación basada en PAtrones.
Una vez identificadas las Entidades de Negocio que componen mi sistema e identificados los comportamientos genéricos de una aplicación (Mecanismos de acceso, mecanismos de selección, mecanismos de explotación, mecanismos para hacer extensible una aplicación en tiempo de ejecución, etc.) , es posible tener una herramienta que genere automaticamente a partir de las Entidades Basicas, los servicios Basicos y los articuladores de estos servicios basicos, para ensamblar así la aplicación final.
Podriamos decir que estamos industrializando la construcción de SW . ¿Cómo?
A partir de las materias primas ( Entidades de Negocio) , Exiten máquinas que generan todos las partes (componentes y componentes de componentes ) del Producto final que es la aplicación
En k2b Entity services permite generar las máquinas que construyen las Productos Básicos y los PRoductos compuestos que se van a articular para la construcción de la aplicación final.
Ejemplo 1:
Los eventos pueden ser llamados desde un proceso de Workflow por lo tanto deben contener la lógica necesaria para heredar el contexto del proceso de Workflow y comunicar al workflow el resultado de la operación,
Dado que esto se conoce, es posible generar para estos objetos en forma automaticamente esta lógica.
Yendo a los datos, la Orden de Compra debe conocer del WF a que Solicitud refiere para poder afectar costos según lo indicado en la Solicitud, por lo que la orden de compra debe ser dato relevante del WF y la Factura debe conocerlo para poder llamar a un servicio de la Orden de compra que le comunique esa información.
Ejemplo 2:
El Modelo de k2B está basado en un núcleo que declara el comportamiento de las Entidades de Negocio básicas que a su vez pueden tomar representaciones o roles diferentes en los diferentes contextos de la aplicación.
Un ejemplo Claro de esto es la Persona. Una Persona (Fisica o Juridica) tiene propiedades genéricas independientemente del rol que tome en los diferentes contextos ( Cliente, Proveedor, usuario, etc.)
Es posible definir un patrón que cuando se defina la Entidad Cliente y se defina como "Actor", automáticamente genere la lógica que lo asocia con el modelo de personas y organizaciones del Modelo Nucleo) y por lo tanto hereda todo el comportamiento de una persona ( Direcciones , telefonos, identificación como empresa o como persona juridica,etc.)
La imágen que sigue muestra los servicios basicos y compuestos generados por el Pattern k2b Entity services.
Luego de especificada la aplicación mediante este modelo, definiremos el mismo en una KB GeneXus .
En GeneXus X podemos especificar el concepto de Entidad de Negocio mediante las categorias y la clasificación de Entidades en Actores, Objetos o Eventos (esto hoy lo tenemos en el Pattern)
Esto nos permite generar algunos comportamientos dependiendo de esta semántica.
En GeneXus no tenemos herramientas específicas para reflejar este modelo , en principio solo podríamos representar las operaciones y mecanismos de accesos. (que son objetos GeneXus)
Pero definiremos algunas convenciones, de forma de póder representar el modelo en una KB. Si somos estrictos en seguir estas convenciones podremos precindir de la planilla y tener toda la info en la KB. A eso apuntamos.