Hacia la obtención de Clases de Análisis y Casos de Uso desde modelos de Procesos de Negocio

Hacia la obtención de Clases de Análisis y Casos de Uso desde modelos de Procesos de Negocio Alfonso Rodríguez Departamento de Ciencias de la Computación y Tecnologías de Información Universidad del Bío Bío Chillán Chile alfonso@ubiobio.cl Eduardo Fernández-Medina y Mario Piattini Grupo de investigación ALARCOS Departamento de Tecnologías y Sistemas de Información Universidad de Castilla-La Mancha Ciudad Real España Eduardo.FdezMedina,Mario.Piattini@uclm.es Abstract A business process model, specified with UML or BPMN, is a description of a problem from which it is possible to obtain requirements which can be integrated in a software development process. On the other hand, model transformation is currently a great influence upon software engineering because it is orientated towards solving the problems of time, cost and quality associated with software creation. In this context, the Model Driven Architecture (MDA) provides the conceptual frame that allows us to describe these transformations. In an MDA scope it is possible to move from models described at a high level of abstraction to models which are closer to implementation. In this paper, we propose a set of transformations between computation independent models (CIM) and platform independent models (PIM). In the first place we make CIM to CIM transformations, in which a relation between BPMN and UML concepts is established. Later, we make a CIM to PIM transformation in which Analysis-Level Classes and Use Cases from a business process model description are obtained. Finally, we present an illustrative example in which it is possible to observe the results of the transformations. Keywords: Business Process, UML, BPMN, MDA, Analysis-Level Class, Use Case, CIM, PIM. Resumen Un modelo de proceso de negocio, especificado con UML o BPMN, corresponde a una descripción de un problema desde la cual es posible obtener requisitos que se pueden integrar en un proceso de desarrollo de software. Por su parte, la transformación de modelos, está influyendo en la ingeniería de software ya que apunta a resolver problemas de tiempo, costos y calidad asociados con la creación de software. En este contexto, la arquitectura dirigida por modelos (MDA) proporciona el marco conceptual que permite describir dichas transformaciones. Bajo este enfoque es posible pasar desde modelos descritos en un alto nivel de abstracción hacia modelos más cercanos a la implementación. En este artículo proponemos un conjunto de transformaciones entre modelos independientes de computación (CIM) y modelos independientes de plataforma (PIM). En primer lugar hacemos transformaciones desde CIM hacia CIM, en que se establece una relación entre conceptos especificados con BPMN y sus equivalentes en UML. Posteriormente, hacemos una transformación desde CIM hacia PIM en que se obtienen Clases de Análisis y Casos de Uso a partir del modelo de proceso de negocio. Finalmente presentamos un ejemplo ilustrativo en donde es posible observar los resultados de las transformaciones. Palabras clave: Procesos de Negocio, UML, BPMN, MDA, Clases de Análisis, Casos de Uso, CIM, PIM.

1 Introduction En los últimos años los procesos de negocio (BP, Business Process) han ido adquiriendo importancia para las empresas ya que se han consolidado como un recurso que les permite diferenciarse y alcanzar ventajas competitivas en el mercado. También son importantes para la ingeniería de software puesto que la descripción de un proceso de negocio es una fuente de requisitos que permitirá complementar las tareas que actualmente se llevan a cabo para la captura de requisitos. Para representar procesos de negocio existen variadas notaciones. No obstante, en los últimos años UML (Unified Modeling Language) ha actualizado y reenfocado el Diagrama de Actividad permitiendo una mejor representación de procesos de negocio. Paralelamente, ha aparecido BPMN (Business Process Modeling Notation), la notación propuesta por BPMI (Business Process Management Initiative) que cumple un objetivo similar. Ambas notaciones son consideradas como estándares de la industria [15]. Con esta mejora en la descripción de procesos es posible contar un conjunto importante de requisitos que pueden ser transformados en conjunto de diagramas útiles para la construcción del software [10]. Por su parte, la ingeniería del software está siendo influenciada por la transformación de modelos, ya que con ello se apunta a resolver los problemas de tiempo, costes y calidad asociados a la creación de software. La propuesta de OMG (Object Management Group) en relación con la transformación de modelos se denomina Arquitectura Dirigida por Modelos (MDA, Model-Driven Architecture) [16]. La idea principal de MDA es permitir la creación de modelos totalmente independientes de la implementación tecnológica. Con este enfoque debe ser posible (i) especificar un sistema independiente de plataforma, (ii) especificar plataformas, (iii) seleccionar una plataforma para el sistema y (iv) transformar la especificación del sistema en una especificación para una plataforma en particular. Dado que un aspecto fundamental en MDA es la transformación de modelos dichas especificaciones se deben expresar en un lenguaje definido con ese propósito, como por ejemplo, ATL (Atlas Transformation Language) [3] o QVT (Query View Transformation) [20]. En nuestra propuesta consideramos un enfoque MDA en que la descripción del proceso de negocio corresponde a un modelo independiente de computación (CIM, Computation Independent Model). Dado que el BP puede ser descrito con UML o BPMN en primer lugar hemos definido transformaciones desde CIM hacia CIM. En esta transformación se establece una equivalencia entre los elementos de BPMN y UML para obtener un modelo CIM descrito en UML. En el segundo tipo de transformaciones se toma como entrada el modelo BP descrito con UML y se obtienen Clases de Análisis y Casos de Uso. Ya que estos dos artefactos forman parte de un modelo independiente de plataforma (PIM, Platform Independent Model) el segundo tipo de transformaciones se hace desde CIM hacia PIM. Para la especificación todas las transformaciones hemos usado el lenguaje QVT. Tanto la descripción del proceso de negocio como las clases de análisis y casos de uso deben ser utilizadas en un proceso de desarrollo de software. Consecuentemente, proponemos usar el Proceso Unificado (UP, Unified Process) [11] por ser un proceso consolidado y exitoso [8]. Para presentar nuestra propuesta hemos organizado este artículo de la siguiente forma: en la Sección 2 presentaremos los principales aspectos relacionados con el Diagrama de Actividad de UML y el Diagrama de Procesos de Negocio de BPMN, en la Sección 3 describiremos las transformaciones necesarias para obtener clases de análisis y casos de uso a partir de la especificación de un proceso de negocio, en la Sección 4 mostraremos un ejemplo ilustrativo y, finalmente, en la Sección 5 presentaremos nuestras conclusiones. 2 Modelado de Procesos de Negocio En el modelado de proceso de negocio el objetivo principal es producir una descripción de la realidad, por ejemplo la forma en que se lleva a cabo una transacción comercial, que permita entenderla y eventualmente modificarla con el propósito de incorporar mejoras. Por lo tanto, es importante contar con una notación que permita modelar con la mayor claridad posible la esencia del negocio. Las empresas han estado modelando procesos por muchos años aunque no siempre les han llamado modelos de procesos de negocio. Las técnicas que utilizaban describían cómo la empresa hacía su trabajo. Entre las técnicas utilizadas se pueden mencionar: diagramas de flujo, diagramas de flujo de datos, diagramas entidad-relación, diagramas de transición de estado, la familia IDEF (Integration DEfinition for Function modeling), redes de Petri, técnicas basadas en el conocimiento (inteligencia artificial) y diagramas de actividad de roles (Rol Activity Diagrams) [1, 9]. En la actualidad, y de acuerdo con el estado de la industria del modelado de procesos de negocio [14], es posible identificar a UML y BPMN entre los principales estándares. 2

Desde la perspectiva de la ingeniería de software, la descripción de un proceso de negocio es una fuente de requisitos que son necesarios, concisos, libres de perturbaciones propias de la implementación y no ambiguos. De manera que esos requisitos pueden ser transformados en conjunto de diagramas útiles para la construcción del software [10]. Nuestra propuesta está basada en descripciones de procesos de negocio que se pueden hacer con el Diagrama de Actividad de UML 2.0 (UML 2.0-AD) o con el Diagrama de Procesos de Negocio de BPMN (BPMN-BPD). Por ello mostraremos principales aspectos de cada notación, el metamodelo y una breve descripción y representación gráfica de los principales elementos que la componen. UML se divide en especificaciones estructurales y de comportamiento, con lo que permite el modelado de los aspectos estáticos y dinámicos de un sistema. Los modelos de comportamiento especifican cómo los aspectos estructurales de un sistema cambian en el tiempo. UML tiene tres modelos de comportamiento: actividades, máquinas de estado e interacciones. Las actividades se enfocan a representar secuencias, condiciones y entradas y salidas para invocar otros comportamientos. [4]. UML 2.0-AD se usa para representar procesos de negocios y flujos de trabajos [12, 19]. Para ello, el modelado de las actividades pone énfasis en la secuencia y en las condiciones para la coordinación del comportamiento de bajo nivel tanto como de la propia clasificación de esos comportamientos. Una actividad especifica la coordinación de ejecución de una secuencia de unidades subordinadas cuyos elementos individuales son acciones. Las acciones pueden ser ocurrencias de funciones primitivas tales como funciones matemáticas, invocaciones a comportamiento, acciones de comunicación, envío de señales, entre otras [17]. La notación gráfica de una actividad, aunque opcional ya que puede ser reemplazada por una notación textual [17], es una combinación de nodos y conectores que permiten formar un flujo completo. En la Tabla 1, hemos incluido una descripción y la representación gráfica de los elementos de UML 2.0-AD que usaremos en nuestra propuesta. Tabla 1: Elementos de UML 2.0-AD Elementos Notación Partición de actividad (ActivityPartition): Una partición normalmente indica qué o quién es responsable por acciones que agrupa. En UML responsable es equivalente a la clase que soporta el comportamiento invocado por las acciones en una partición Account payable Accounting Order Department Acción (Action): Una acción es la unidad fundamental de funcionalidad ejecutable. La ejecución de una acción representa algunas transformaciones o procesamiento en el sistema modelado, sea este computacional o no. Almacén de datos (DataStoreNode): Un almacén de datos cumple la función de almacenamiento intermedio de información no transitoria. «DataStoreNode» Región (InterruptibleActivityRegion): Una región es una agrupación de actividades cuya característica principal es que toda la ejecución de la región termina cuando el arco de término sale de la región, independiente del flujo que tengan las actividades que están agrupadas en la región. El metamodelo de UML 2.0-AD se muestra en la Figura 1. La clase Activity se vincula con ActivityNode, ActivityGroup y ActivityEdge por medio de una relación de composición. El resto de los elementos que componen UML 2.0-AD son heredados desde esas clases. Classifier (from Kernel) ActivityPartition InterruptibleActivityRegion Class (from Kernel) Behavior (from BasicBehavior) +group subsets ownedelement +activity subsets owner 0..1 Activity +activity 0..1 +activity subsets owner 0..1 +node ActivityGroup +/ingroup +containednode ActivityNode +source 1 +/ingroup 0.. +target 1 Action ExecutableNode ObjectNode +outcoming +edge subsets ownedelement ActivityEdge +incoming +containededge 0.. CentralBufferNode ObjectFlow ControlFlow DataStoreNode Figura 1: Metamodelo de UML 2.0-AD 3

Por su parte, BPMN es una propuesta nueva cuya notación considera un único diagrama para la representación de los procesos BPD (Business Process Diagram), el cual fue diseñado pensando en facilitar su uso y entendimiento y para ofrecer una fuerza expresiva que permita modelar complejos negocios, asignándolos con naturalidad a lenguajes de ejecución como BPEL4WS (Business Process Execution Language For Web Services). Para ello se complementa la notación con un lenguaje de modelado (BPML, Business Process Modeling Language) y un lenguaje de consulta (BPQL, Business Process Query Language)[18]. Por otra parte, BPMN está limitado para soportar la representación de conceptos que son aplicables al modelado de procesos, lo que implica que otro tipo de modelado que usan las organizaciones con propósitos de negocios quedan excluidos del alcance de BPMN, como por ejemplo, estructuras organizacionales y recursos, descomposiciones funcionales, datos y modelos de información, estrategias y reglas de negocios [5]. En la Tabla 2 se muestra una breve descripción y la representación gráfica de los elementos de BPMN- BPD que usaremos en nuestra propuesta. Tabla 2: Elementos de BPMN-BPD Elementos Notación Participante (Pool): Representa a un actor o rol en un proceso de negocio. Gráficamente, es una banda en que están contenidos otros elementos del BPD como por ejemplo una Actividad. División (Lane): Corresponde a subdivisiones de un Participante y se extienden a lo largo de él en forma horizontal o vertical. La división es utilizada para organizar y categorizar Actividades. Objeto de datos (Data object): Proporciona información acerca de lo que hace el proceso. Puede tomar la forma de documentos, datos y otros objetos que son usados y actualizados por el proceso. Por lo general aparece asociado a Actividades o Flujos de Secuencia. Agrupación (Group): Es un mecanismo visual que reúne elementos de un proceso de negocio. El objetivo principal es destacar ciertas secciones del diagrama con propósitos de documentación y/o análisis. Actividad (Activity): Es el término genérico que se usa para identificar el trabajo que realiza una empresa. Esta categoría incluye procesos, subprocesos y tareas BPMN-BPD se compone de un pequeño conjunto de categorías de tipos básicos de elementos del diagrama que resultan fáciles de reconocer cuando se leen estos diagramas. Estos cuatro tipos básicos son: Flow Objects, Connecting Elements, Aritifacts y Swimlanes (compuestos por Pool y Lane) [6]. Hemos creado un metamodelo de BPMN-BPD (ver Figura 2) en que mostramos las principales relaciones entre los elementos centrales que componen este diagrama. Para ello hemos creado la clase BusinessProcessDiagram. Esta clase nos permite relacionar todos los elementos usados en BPMN-BPD para la representación de procesos de negocio. Pool +mpool 1 1.. 1 BusinessProcessDiagram ConnectingElement Artifact FlowOject SequenceFlow MessageFlow +ingroup 0..1 Group TextAnnotation Gateway Event 1.. Lane +mlane 0..1 Association Activity DataObject Start Intermediate End Figura 2: Metamodelo de BPMN-BPD 3 Nuestra propuesta: clases de análisis y casos de uso desde procesos de negocio Creemos que un proceso de negocio, construido por un analista de negocios, junto con ser útil en el ámbito del negocio propiamente dicho, es de gran utilidad en un proceso de construcción de software. Desde allí se pueden obtener requisitos del sistema, una etapa contemplada en todos los procesos de desarrollo de 4

software modernos. Esta etapa básicamente consiste en obtener desde el cliente o los interesados los requisitos del sistema para, a partir de ese punto, emprender la construcción del software. Hemos elegido QVT para especificar las transformaciones porque es compatible con el estándar MDA ya que su sintaxis abstracta es definida como un metamodelo MOF 2.0 (Meta Object Facility). En la Figura 3 se muestra un esquema general con los principales elementos de nuestra propuesta. En la primera columna (izquierda) se muestran los modelos que componen MDA. En la última columna se muestran los flujos de trabajo del Proceso Unificado. En la parte central se muestra nuestra propuesta. En gris oscuro se identifican: la transformación de modelos desde CIM hacia CIM (C2C) que permite incluir modelos descritos con BPMN-BPD. El modelo de proceso de negocio, especificado con BPMN-BPD o UML 2.0-AD, es un modelo CIM y puede ser usado en el flujo de trabajo Modelo del Negocio del proceso unificado las transformaciones desde CIM hacia PIM (C2P) a partir de las cuales se obtienen clases de análisis (C2P-1) y casos de uso (C2P-2). Tanto las clases de análisis como los casos de uso son modelos PIM y pueden ser usados en los flujos de trabajo Requisitos y Análisis & Diseño del proceso unificado. Arquitectura Dirigida por Modelos Modelo Independiente de Computación Nuestra Propuesta BPMN-BPD C2C UML 2.0-AD Modelo de Proceso de Negocio C2P - 1 C2P - 2 Proceso Unificado (Flujos de Trabajo) Modelo del Negocio Modelo Independiente de Plataforma Clases de Análisis Casos de Uso Requisitos Análisis & Diseño Modelo Especifico de Plataforma Diagrama de Estado, de Paquete (Java/J2EE,.NET, CORBA) Componente Software Implementación Figura 3: Esquema general de nuestra propuesta El conjunto de reglas de transformación C2C, especificadas en el lenguaje QVT textual, se describen en la Tabla 3. En [24] se hace una comparación de ambas notaciones en que se considera la capacidad técnica que tiene cada una para representar patrones y su legibilidad. No obstante, en este trabajo consideramos la equivalencia de elementos de una y otra notación en función del objeto del proceso de negocio que es representado. Por ejemplo un Pool o Lane en BPMN-BPD representa un área en que se pueden agrupar un conjunto de actividades que lleva a cabo un determinado actor en un proceso de negocio. El elemento equivalente es ActivityPartition de UML 2.0-AD. Tabla 3: Transformaciones C2C: desde BPMN-BPD hacia UML 2.0-AD transformation BPMN-BPD2UML-AD top relation R1 // from Pool to Activity Partition checkonly domain bpmn_businessprocessdiagram p:pool name = n enforce domain uml_activitydiagram ap:activitypartition name = n top relation R2 // from Lane to Activity Partition checkonly domain bpmn_businessprocessdiagram l:lane name = n enforce domain uml_activitydiagram ap:activitypartition name = n top relation R3 // from Group to Interruptible Activity Region checkonly domain bpmn_businessprocessdiagram g:group name = n enforce domain uml_activitydiagram ir:interruptibleactivityregion name = n top relation R4 // from Activity to Action checkonly domain bpmn_businessprocessdiagram ac:activity name = n enforce domain uml_activitydiagram act:action name = n top relation R5 // from Data Object to Data Store Node checkonly domain bpmn_businessprocessdiagram do:data Object name = n enforce domain uml_activitydiagram dsn:datastorenode name = n top relationr6 // from Start Event to Initial Node checkonly domain bpmn_businessprocessdiagram s:starevent name = n enforce domain uml_activitydiagram act:action name = n 5

Para llevar a cabo las transformaciones hemos desarrollado una herramienta que ha sido construida usando una arquitectura de tres capas en que se separan los componentes relacionados con la presentación, aplicación y almacenaje. La descripción del proceso de negocio se hace mediante MS-Visio (presentación). Para las trasformaciones desde el proceso de negocio hacia clases de análisis y casos de uso utilizamos C# (aplicación) y, finalmente, la actualización y consulta del repositorio que contiene los procesos de negocio, clases de análisis y casos de uso se hace con MS-Access (almacenaje). En las secciones 3.1 y 3.2 se describe en detalle las transformaciones desde un proceso de negocio hacia clases de análisis y casos de uso respectivamente. En cada caso se mostrará el conjunto de reglas y su especificación en modo textual de QVT. 3.1 Clases de análisis desde procesos de negocio (C2P-1) En esta sección se presenta el conjunto de reglas que permiten obtener clases de análisis a partir de una especificación de un proceso de negocio. En la revisión de la literatura hemos encontrado dos trabajos que abordan de manera directa este tipo de transformaciones. En el primero de ellos [2] se transforman diagramas de actividad en clases de análisis. La transformación no se hace en forma automática y se utiliza una versión previa a UML 2.0. Y en el segundo trabajo [22], el diseñador de software examina el modelo del BP, descrito con BPMN, extrayendo las clases UML que son refinadas posteriormente. Nuestra propuesta se diferencia de las anteriores porque usamos un lenguaje especialmente diseñado para especificar transformaciones entre modelos (QVT), las transformaciones se hacen en forma automática (a través nuestra herramienta) y el resultado, esto es las clases de análisis, se relacionan con un proceso de desarrollo de software. Las transformaciones desde un modelo de proceso de negocio especificado con UML 2.0-AD (o su equivalente en BPMN-BPD) a clases de análisis se describen con el lenguaje QVT textual en la Tabla 4. Tabla 4: Transformaciones entre UML 2.0-AD y Clases de análisis transformation ActivityDiagram2ClassDiagram top relation R1 // from Activity Partition to Class checkonly domain uml_activitydiagram ap:activitypartition name = n enforce domain uml_classdiagram c:class name = n where ap.containednode forall(cn:action R4(cn)) top relation R2 // from Interruptible Activity Region to Class checkonly domain uml_activitydiagram iar:interruptibleactivityregion name = n enforce domain uml_classdiagram c:class name = n where ap.containednode forall(cn:action R4(cn)) top relation R3 // from Data Store Node to Class checkonly domain uml_activitydiagram dsn:datastorenode name = n enforce domain uml_classdiagram c:class name = n relation R4 // from Action to Operation in Class checkonly domain uml_activitydiagram ac:action name = n, inpartition=ap enforce domain uml_classdiagram op:operation name = n, ownerclass=c:classname=ap.name Adicionalmente, presentamos un conjunto de reglas de refinamiento (ver Tabla 5). Esas reglas se deben aplicar después de haber aplicado las reglas QVT. El objetivo es enriquecer el modelo de clases incorporando nombre significativos a las regiones, identificando las relaciones entre las clases obtenidas y eliminando la redundancia. Tabla 5: Reglas de refinamiento para clases de análisis RR 1: RR 2: RR 3: El nombre de las regiones se obtiene concatenando los nombre de las particiones en donde la InterruptibleActivityRegion está contenida Las relaciones de composición entre las clases se generan a partir de las ActivityPartitions que contienen a otras ActivityPartitions La redundancia que se pueda producir, por ejemplo por relaciones de composición, debe ser eliminada 3.2 Casos de uso desde proceso de negocio (C2P-2) En esta sección se presenta el conjunto de reglas que permite obtener casos de uso a partir de la descripción de un proceso de negocio. En la revisión de la literatura hemos encontrado que en [21] se sugiere la posibilidad obtener, en forma manual, casos de uso a partir una especificación de BP hecha con BPMN. En [13] se propone la obtención 6

automática de artefactos UML a partir de una descripción del BP que se hizo usando BPMN. Los autores extienden BPMN (Extension Level 1) para agregar información acerca de la secuencia y los flujos de entrada y salida, lo que les permite aplicar reglas a partir de las cuales se obtienen casos de uso, diagramas de estado, secuencia y colaboración. En [23] se presenta una transformación en forma manual desde un BP descrito con AD-UML 2.0 hacia casos de uso y finalmente, en [7] se obtienen casos de uso a partir de modelos de procesos de negocio que no están representados con diagramas de actividad. Las diferencias con nuestra propuesta residen básicamente en que (i) aun en los trabajos en que hay transformaciones automáticas, se requiere intervención manual previa, (ii) las transformaciones no están descritas usando lenguajes especialmente diseñados con ese propósito y (iii) finalmente, el resultado de las trasformaciones no aparece encadenado con un proceso de desarrollo de software. Las transformaciones desde un modelo de proceso de negocio especificado con UML 2.0-AD (o su equivalente en BPMN-BPD) hacia casos de uso se llevan a cabo de acuerdo con las reglas QVT que se describen en la Tabla 6. Tabla 6: Mapping between Activity Diagrams and Use Case elements transformation ActivityDiagram2UseCaseDiagram top relation R5 // from Activity Partition to Actor checkonly domain uml_activitydiagram ap:activitypartition name = n enforce domain uml_usecasediagram a:actorname = n where ap.containednode forall(cn:action R7(cn)) top relation R6 // from Interruptible Activity Region to Actor checkonly domain uml_activitydiagram iar:interruptibleactivityregion name = n enforce domain uml_usecasediagram a:actor name = n where ap.containednode forall(cn:action R7(cn)) relation R7 // from Action to UseCase checkonly domain uml_activitydiagram ac:action name = n, inpartition=ap enforce domain uml_usecasediagram uc:usecase name = n, subject= ACTORS: Set(Actor); where ACTORS including (a:actorname=ap.name) En la Tabla 7 presentamos un conjunto de reglas que permiten refinar los casos de uso obtenidos previamente. Las reglas de refinamiento se aplican después de las reglas QVT. El principal objetivo es enriquecer los casos de uso incorporando el nombre del sujeto y nombres de regiones, identificando el actor principal y eliminando elementos redundantes. Tabla 7: Reglas de refinamiento para casos de uso RR 4: RR 5: RR 6: RR 7: RR 8: El nombre del sujeto se obtiene desde el nombre del proceso de negocio El nombre de un actor relacionado con una región se obtiene concatenando los nombre de las particiones en donde la InterruptibleActivityRegion está contenida El Actor principal se identifica por la presencia de un nodo de inicio en una partición o región La generalización de actores se s se generan a partir de las ActivityPartitions que contienen a otras ActivityPartitions La redundancia en las especificaciones, por ejemplo la que se produce por la generalización, debe ser eliminada 4 Ejemplo ilustrativo El proceso de negocio, relacionado con la admisión de pacientes en una institución médica, se inicia con una Solicitud de Atención que es rellenada por un Paciente. Este documento, es enviado al Área de Administración para capturar la información relacionada con los seguros médicos y verificar la existencia de una Ficha Clínica asociada al paciente. Una vez que se verifica que la documentación del paciente sea válida y este completa es enviada al Área Médica. El área de Evaluación Médica determina, a través de un conjunto de pruebas de pre-admisión, la condición medica del paciente. Si fuera necesario se harán exámenes adicionales que deberán ser registrados desde el punto de vista clínico y económico. Finalmente se completa el documento Evaluación Médica con información acerca del paciente, el cual se le envía. El proceso de negocio termina cuando el paciente ha recibido la Evaluación Médica. El proceso de negocio descrito con BPSec-Tool se muestra en la Figura 4 y el resultado de la aplicación de las reglas QVT y las reglas de refinamiento se muestran en la Tabla 8. 7

Figura 4: Descripción del proceso de negocio para la Admisión de Pacientes Tabla 8: Resultado de la aplicación de las reglas QVT y reglas de refinamiento Regla R1 Elemento derivado y su correspondencia en el ejemplo Clases: Paciente, Área Administración, Admisión, Contabilidad, Área Médica, Evaluación Médica, Exámenes R2 Clase: Región 01 R3 Clase: Solicitud Admisión, Evaluación Médica, Datos Contables, Ficha Clínica Operaciones: Rellenar Solicitud, Recibir Evaluación Médica, Capturar Información de Seguros, Verificar Ficha Clínica, Enviar Ficha Clínica, Crear R4 Ficha Clínica, Rellenar Información de Costos, Almacenar Datos, Hacer Pruebas Pre-Admisión, Evaluación Exámenes Paciente, Rellenar Ficha Clínica, Rellenar Informe Paciente, Rellenar Datos Contables, Realizar Exámenes y Rellenar Ficha Clínica R5 Actor: Paciente, Área Administración, Admisión, Contabilidad, Área Médica, Evaluación Médica y Exámenes R6 Actor: Region 01 R7 RR1 Caso de uso: Rellenar Solicitud, Recibir Evaluación Médica, Capturar Información de Seguros, Verificar Ficha Clínica, Enviar Ficha Clínica, Crear Ficha Clínica, Rellenar Información de Costos, Almacenar Datos, Hacer Pruebas Pre-Admisión, Evaluación Exámenes Paciente, Rellenar Ficha Clínica, Rellenar Informe Paciente, Rellenar Datos Contables, Realizar Exámenes y Rellenar Ficha Clínica Clase: AdmisiónContabilidad RR2 RR3 RR4 RR5 RR6 RR7 RR8 Clase compuesta: Área Administración compuesta por Admisión y Contabilidad y Área Médica compuesta por Evaluación Médica y Exámenes Elimina redundancia de operaciones en las clases compuestas Sujeto: Admisión Paciente Actor: AdmisiónContabilidad Actor Principal: Paciente Actor generalizado: Área Administración compuesto por Admisión y Contabilidad y Área Médica compuesta por Evaluación Médica y Exámenes Elimina redundancia de casos de uso para los actores compuestos En la Figura 5 se muestran en forma gráfica las clases de análisis obtenidas a partir de la especificación del proceso de negocio para la admisión de pacientes y en la Figura 6 se muestra el caso de uso en forma gráfica. En este último se ha enriquecido puesto que hemos agregado la identificación del sujeto, identificado el actor principal, jerarquizado las áreas que originalmente contenían sub-particiones y denominado la región. Para distinguir estas mejoras las hemos marcado con el símbolo asterisco (). 8

AreaMedica AreaAdministracion EvaluacionMedica Examenes Admision Contabilidad HacerPruebasPreAdmision() EvaluacionExamenesPaciente() RellenarFichaClinica() RellenarInformePaciente() RellenarDatosContables() RealizarExamenes() RellenarFichaClinica() CapturarInformacionSeguros() VerificarFichaClinica() EnviarFichaClinica() CrearFichaCLinica() RellenarInformacionSeguros() AlmacenarDatos() AdmisionContabilidad Paciente RellenarSolicitud() RecibirEvaluacionMedica() FichaClinica CapturarInformacionSeguros() VerificarFichaClinica() EnviarFichaClinica() CrearFichaClinica() RellenarInformacionCostos() AlmacenarDatos() Solicitud Admision DatosContables EvaluacionMedica Figura 5: Diagrama de Clases obtenido desde el proceso de negocio Admisión de Pacientes Admisión Pacientes () Relllenar Solicitud Hacer Pruebas Pre-Admisión Area Medica () Recibir Evaluacion Medica Evaluación datos Paciente Paciente Actor Principal () Rellenar Ficha Clínica Rellenar Datos Contables Rellenar Informe Paciente Evaluación Medica Area Administración () Realizar Examenes Examenes Rellenar Ficha Clinica Capturar Información de Seguros Verificar Ficha Clínica Admisión Enviar Ficha Clínica Crear Ficha Clínica Fill out Cost Information Contabilidad Store Data AdmisiónContabilidad () Figura 6: Caso de Uso obtenido desde el proceso de negocio Admisión de Pacientes Tanto las clases de análisis como los casos de uso complementan el proceso unificado en las etapas de Requisitos y Análisis & Diseño. Estos artefactos constituyen un subconjunto del total de artefactos que finalmente serán necesarios para la construcción del software. 5 Conclusiones La mejora que presenta el lenguaje UML 2.0 y la aparición de la notación BPMN en relación con la representación de procesos de negocio, permite considerar dichas especificaciones como una fuente de requisitos para ser utilizados como entrada en un proceso de desarrollo de software. En este artículo hemos presentado un conjunto de transformaciones desde CIM hacia CIM y desde CIM hacia PIM que permiten obtener, a partir de un proceso de negocio construido por un analista de negocio, clases de análisis y casos de uso que pueden ser utilizados en un proceso sistemático y ordenado de desarrollo de software. El trabajo futuro está orientado a enriquecer las transformaciones de manera que sea posible obtener modelos de clases de análisis y casos de uso más completos. Junto con ello, optimizar la herramienta que hemos creado para hacer las especificaciones y las transformaciones con el propósito de mejorar la documentación y reuso de las especificaciones. 9

Agradecimientos Esta investigación es parte de los proyectos DIMENSIONS (PBC-05-012-1) y MISTICO (PBC06-0082), ambos parcialmente financiado por el FEDER y por la Consejería de Educación y Ciencia de la Junta de Comunidades de Castilla-La Mancha, España; COMPETISOFT (506AC287) concedido por CYTED y ESFINGE (TIN2006-15175-C05-05/) otorgado por la Dirección General de Investigación del Ministerio de Ciencia y Tecnología, España. Referencias [1] Aguilar-Savén, R. S. Business process modelling: Review and framework, International Journal of Production Economics, Vol. 90 (2), (2004), pp. 129-149. [2] Barros, J. P. y Gomes, L. From Activity Diagrams to Class Diagrams, Workshop Dynamic Behaviour in UML Models: Semantic Questions. Junto con Third International Conference on UML, York, UK, (2000). [3] Bézivin, J., Breton, E., Dupé, G., y Valduriez, P. The ATL Transformation-based Model Management Framework, IRIN-Université de Nantes, Nº 03.08, (2003) 17 p. [4] Bock, C. UML 2 Activity and Action Models, Part 2: Actions, Journal of Object Technology, Vol. 2 (5), September-October, (2003), pp. 41-56. [5] BPMN. Business Process Modeling Notation (BPMN), in Copyright 2004, BPMI.org. All Rights Reserved, Version 1.0 May 3, Ed., 2004. [6] BPMN. Business Process Modeling Notation Specification: OMG Final Adopted Specification, dtc/06-02-01, 2006. [7] Dijkman, R. M. y Joosten, S. M. M. An Algorithm to Derive Use Cases from Business Processes, 6th International Conference on Software Engineering and Applications (SEA), Boston, USA,. (2002), pp. 679-684. [8] Fuggetta, A. Software process: a roadmap, ICSE 2000, 22nd International Conference on Software Engineering, Future of Software Engineering, Limerick Ireland., (2000), pp. 25-34. [9] Giaglis, G. M. A Taxonomy of Business Process Modelling and Information Systems Modelling Techniques, International Journal of Flexible Manufacturing Systems, Vol. 13 (2). (2001), pp. 209-228. [10] Harmon, P. The OMG's Model Driven Architecture and BPM, 2005:.Business Process Trends, Vol. 2 (5), 2004. [11] Jacobson, I., Booch, G., y Rumbaugh, J. The Unified Software Development Process, (1999) 463 p. [12] Kalnins, A., Barzdins, J., y Celms, E. UML Business Modeling Profile, Thirteenth International Conference on Information Systems Development, Advances in Theory, Practice and Education, Vilnius, Lithuania, (2004), pp. 182-194. [13] Liew, P., Kontogiannis, P., y Tong, T. A Framework for Business Model Driven Development, 12 International Workshop on Software Technology and Engineering Practice (STEP), (2004), pp. 47-56. [14] Lonjon, A. Business Process Modeling and Standardization, BPTrends, In http://www.bptrends.com/, (2004). [15] Mega. Business Process Modeling and Standardization, 2004. [16] Object Management Group. MDA Guide Version 1.0.1, 2003. [17] Object Management Group. Unified Modeling Language: Superstructure: version 2.0, formal/05-07- 04, 2005. [18] Owen, M. y Raj, J. BPMN and Business Process Management; Introduction to the New Business Process Modeling Standard, A Popkin Software, W. P., Ed., 2003. [19] Podeswa, H. B.O.O.M.: Business Object-Oriented Modeling for Business Analysts, (2005) 401 p. [20] QVT. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, (2005) 204 p. [21] Rungworawut, W. y Senivongse, T. A Guideline to Mapping Business Processes to UML Class Diagrams, WSEAS Trans. on Computers, Vol. 4 (11), (2005), pp. 1526-1533. [22] Rungworawut, W. y Senivongse, T. Using Ontology Search in the Design of Class Diagram from Business Process Model, Enformatika, Transactions on Engineering, Computing and Technology, Vol. 12, (2006), pp. 165-170. [23] Štolfa, S. y Vondrák, I. A Description of Business Process Modeling as a Tool for Definition of Requirements Specification, Systems Integration 12th Annual International Conference, Prague, Czech Republic, (2004), pp. 463-469. [24] White, S. A. Process Modeling Notations and Workflow Patterns: BPTrends March, 2004. 10