Este trabajo muestra el modelo genérico del modelo de negocio [BDMN04], representado gráficamente en términos de UML a través de un diagrama de clases, producto del análisis de los artefactos del Proceso Unificado que componen el modelo de negocio y sus relaciones. Además, se definen un conjunto de reglas que el modelo debe verificar.
Esta demostrado que el modelado gráfico es muy útil para visualizar, especificar, construir y documentar los artefactos de un sistema, brindando un lenguaje común, fácil de entender y aplicar. Sin embargo, no posee una semántica precisa, y por lo tanto, se presentan ambigüedades que originan problemas de interpretaciones erróneas o diferentes. En este sentido, se traduce el modelo genérico del modelo de negocio con un Diagrama de Clases UML a un lenguaje de especificación formal. Esta definición, realizada en Object-Z, permite expresar sin ambigüedad modelos de negocio concretos en dominios particulares, y facilita el análisis de las propiedades del sistema, mostrando posibles inconsistencias, ambigüedades o incompletitudes.Eje: Ingeniería en SoftwareRed de Universidades con Carreras en Informática (RedUNCI

Baum, Gabriel Alfredo

Daniele, Marcela

Martellotto, Paola

SEDICI - Repositorio de la UNLP

Traducción del Modelo Genérico del Modelo de Negocio a Object-Z 
 
Marcela Daniele,  Paola Martellotto, Gabriel Baum 
Universidad Nacional de Río Cuarto 
Facultad de Ciencias Exactas, Fco-Qcas y Naturales - Dpto. de Computación 
{marcela,paola}@dc.exa.unrc.edu.ar, gbaum@info.unlp.edu.ar 
 
Resumen 
Este trabajo muestra el modelo genérico del modelo de negocio [BDMN04], representado gráficamente en términos de 
UML a través de un diagrama de clases, producto del análisis de los artefactos del Proceso Unificado que componen el 
modelo de negocio y sus relaciones. Además, se definen un conjunto de reglas que el modelo debe verificar. 
Esta demostrado que el modelado gráfico es muy útil para visualizar, especificar, construir y documentar los artefactos 
de un sistema, brindando un lenguaje común, fácil de entender y aplicar. Sin embargo, no posee una semántica precisa, 
y por lo tanto, se presentan ambigüedades que originan problemas de interpretaciones erróneas o diferentes. En este 
sentido, se traduce el modelo genérico del modelo de negocio con un Diagrama de Clases UML a un lenguaje de 
especificación formal. Esta definición, realizada en Object-Z, permite expresar sin ambigüedad modelos de negocio 
concretos en dominios particulares, y facilita el análisis de las propiedades del sistema, mostrando posibles 
inconsistencias, ambigüedades o incompletitudes.  
 
1. Introducción 
El desarrollo de un sistema software es pensado para solucionar problemas a través de programas 
que deben presentar variadas características tales como: eficiencia, robustez, seguridad en los datos, 
dinamismo, interactividad, portabilidad, etc.. Solo es posible construir dicho sistema, estudiando 
primero el problema y luego proponiendo las posibles soluciones.  
El Proceso Unificado de desarrollo de software [RUP] [JBR99] es una metodología que define 
quién está haciendo qué, cuándo, y cómo para construir o mejorar un producto de software. Este 
método utiliza UML (Unified Modeling Language) [UML03] [BRJ99], como medio de expresión 
de los diferentes modelos que se crean durante las etapas del desarrollo. El primer artefacto 
propuesto es el Modelo de Negocio, el cual permite establecer una abstracción de la organización. 
Básicamente, la propuesta de [RUP] se basa en lograr un buen entendimiento del negocio para la 
construcción de un sistema correcto, a través del desarrollo de un conjunto de artefactos que 
permiten modelar integramente el negocio. 
Los trabajos existentes acerca del Modelado de Negocio y que hacen referencia específicamente 
a la metodología del Proceso Unificado, utilizan la definición de los artefactos, tal como la 
presentan sus autores, sin mayor análisis. En este plano cabe mencionar algunos trabajos como el 
libro escrito por Eriksson y Penker [EP00] que define una extensión a UML para describir procesos 
de negocio y presentan conceptos claves del modelado de negocio, incluyen una descripción para 
definir reglas de negocio en Object Constraint Language (OCL) y como usar modelos de negocio 
como casos de uso. [OMMN01] propone un método sistemático para obtener el modelo de 
requisitos a partir del modelo de negocio. [Salm03] utiliza las extensiones a UML para el Modelado 
de Negocio propuestas por la OMG. [SVC01] proponen una extensión a UML con la definición de 
un Profile para el modelo de negocio.  
Este trabajo muestra el análisis de los artefactos que componen el modelo de negocio, según 
[RUP]. Y resulta en un modelo genérico del modelo de negocio, representado gráficamente en 
términos de UML a través de un diagrama de clases (Figura 1), el cual establece las bases para 
especificar un modelo concreto. Con la aplicación de las reglas definidas para cada artefacto y sus 
relaciones, ayuda a construir el modelo de negocio para el conocimiento que se requiere del 
contexto. Por otro lado, el modelo genérico puede ser también usado para verificar un modelo de 
negocio concreto previamente construido. 
Esta demostrado que el modelado gráfico es muy útil para visualizar, especificar, construir y 
documentar los artefactos de un sistema, brindando un lenguaje común, fácil de entender y aplicar. 
Sin embargo, no posee una semántica precisa, y por lo tanto, se presentan ambigüedades que 
originan problemas de interpretaciones erróneas o diferentes. En este sentido, necesitamos traducir 
nuestro modelo genérico del modelo de negocio propuesto con un diagrama de clases UML a un 
lenguaje de especificación formal, tal como Object-Z, que permite expresar sin ambigüedad 
modelos de negocio concretos en dominios particulares, y aún cuando la aplicación de métodos 
formales no garantiza la corrección a priori de un sistema, facilita considerablemente el análisis de 
las propiedades del sistema, mostrando posibles inconsistencias, ambigüedades o incompletitudes.  
 
2. Modelo Genérico del Modelo de Negocio 
Tal como lo postulan los creadores del proceso [JBR99], con las particularidades introducidas 
por [RUP], el  modelo de negocio está soportado por dos artefactos principales, el modelo de casos 
de uso del negocio y el modelo de análisis del negocio. El modelo de casos de uso de negocio 
describe los procesos de negocio de una empresa en términos de casos de uso del negocio y actores 
del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. 
Presenta un sistema desde la perspectiva de su uso, y esquematiza como proporciona valor a sus 
usuarios. Por otro lado, el modelo de análisis del negocio, es un modelo interno a un negocio, que 
describe cómo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores que 
utilizan entidades del negocio y unidades de trabajo. El conjunto completo de artefactos del modelo 
de negocio captura y presenta el contexto del sistema y sirven como entrada y referencia para la 
definición de los requerimientos del sistema.  
Para la construcción del modelo genérico, partimos por definir a cada artefacto del modelo de 
negocio como una clase. En el cuadro 1 se encuentra la referencia a la sigla usada para cada 
artefacto y son agrupados según sus características que lo definen en el modelo.  
MODELOS 
MCUN Modelo de Casos de Uso de Negocio 
MAN  Modelo de Análisis de Negocio 
DOCUMENTOS ELEMENTOS DE MODELOS 
GN  Glosario de Negocio CUN Caso de Uso de Negocio 
VFO  Valoración del Fin de la Organización AN Actor  de Negocio 
VN  Visión del Negocio RCUN Realización de Caso de Uso de Negocio 
DAN  Documento Arquitectura del Negocio SN Sistema de Negocio 
ESN  Especificación Suplementaria del Negocio EN Entidad de Negocio 
RN  Reglas del Negocio WN Worker de Negocio 
ON  Objetivo del Negocio EvN Evento de Negocio 
Cuadro 1. Siglas que identifican los Artefactos del Modelo de Negocio 
 
El diagrama de clases de la Figura 1, muestra la representación gráfica del modelo genérico 
propuesto para el modelo de negocio. Permite visualizar con claridad los artefactos que componen 
el modelo completo de negocio, destacando los modelos con el estereotipo <<model>>, los 
elementos de modelos con el estereotipo <<element>> y expresados con relaciones de composición, 
y los documentos con el estereotipo <<document>>, que representan las definiciones 
suplementarias para los dos modelos fundamentales representados por MAN y MCUN. 
El MCUN es el modelo más importante a construir en el modelado de negocio. Si se analiza en 
detalle el MCUN y su relación con los demás artefactos, el diagrama de clases propuesto especifica 
de manera precisa que para cada MCUN debe existir un GN, un RN y un ON asociado. Se deduce 
que para crear el MCUN será necesario haber materializado las estrategias de negocio en ON, y una 
vez definido éstos el MCUN dirige su propósito hacia ellos. Observando el diagrama la relación 
entre MCUN y ON es una asociación simple con dirección hacia el ON con multiplicidad igual a 1 
y con 0..1 en MCUN, que además del significado que representa la relación propiamente dicha, ésta 
pretende expresar que se requiere la definición de los objetivos del negocio, al menos de manera 
parcial, antes de comenzar la descripción del Modelo de Casos de Uso del Negocio. Lo mismo 
ocurre con la relación expresada entre el MCUN y los artefactos GN y RN. Se sabe que cada uno de 
estos artefactos evolucionarán paulatinamente con la construcción del modelo general. 
 
include, 
extend  
generaliza 
disparan y reciben 
CUNAbstracto CUNNoAbstracto 1..* 0..* 
AN 
<<element>> 
1..* 
1..* 
+presta servicio 
<<interaccion>
1 
0..* 
+especializa 
ON 
<<document>> 
EvN 
<<element>> 
SN 
<<element>> 
WN 
<<element>> 
1 
0..* 
+colabora 
RCUN 
<<element>> 
1..* 
0..* 
0..* 1..* 
EN 
<<element>> 
1 
0..* 1..* 1..* <<interaccion>> 
1..* 
0..* 
RN 
<<document>> 
GN 
<<document>> 
1 
1 
MAN 
<<model>> 
1 0..1 
1 
0..1 
1..* 
DAN 
<<document>> 
0..1 
1 
VN 
<<document>> 
0..1 
1 
ESN 
<<document>> 
MCUN 
<<model>> 
1..* 
1 
0..1 
0..1 1 
1 
0..1 
0..1 
1 
0..1 
1 
0..1 
1 
VFO 
<<document>> 
0..1 
1 
CUN 
<<element>> 
1..* 
1 
0..* 
+relaciona 
  1 
 
Figura 1. Modelo Genérico del Modelo de Negocio 
 
3. Definición de Reglas 
Las reglas acompañan al modelo genérico presentado en la figura 1 para verificar que un modelo 
de negocio concreto se construye correctamente a partir de dicho modelo genérico, o determinar si 
un modelo de negocio previamente construido cumple estas reglas y por lo tanto es correcto. En la 
sección 4 se muestra su formalización en el lenguaje de especificación formal Object-Z. 
Las reglas definidas se agrupan en reglas generales para el modelo de negocio, reglas que están 
asociadas al Modelo de Casos de Uso del Negocio, y por último reglas que corresponden al Modelo 
de Análisis del Negocio, identificadas unívocamente con la sigla MN, MCUN y MAN, seguida de 
un número correlativo. 
Como ejemplo, el Cuadro 2 muestra algunas reglas generales del modelo de negocio que 
imponen principalmente relaciones y condiciones entre los artefactos, sin considerar todas las 
condiciones a tener en cuenta en la construcción interna de cada artefacto propiamente dicho. 
MN.1)  MN: {artefacto} Indica que el Modelo de Negocio está compuesto por un conjunto de artefactos. 
MN.2) artefacto = (model | modelElement | document) Cada artefacto corresponde a un tipo específico. 
MN.3) model = ( MCUN | MAN ). Un Model es un MAN o un MCUN. 
MN.4) modelElement = ( CUN | AN | SN | EN | WN | RCUN | EvN ) 
MN.5) document = ( GN | RN | ON | ESN | DAN | VN | VFO ) 
MN.6) Dado un mn : MN, mn representa una instancia del MN genérico. 
MN.7) Cada artefacto tiene una única instancia para un mn:MN particular. 
MN.8) Todo mn: MN debe contener un GN, un ON, un RN y un MCUN. 
MN.9) Todo artefacto identificado con <<document>>, está asociado al MCUN y es usado por este. 
MN.10) La creación y actualización de los elementos del MAN depende de los elementos del MCUN. 
MN.11) Cuando se crea una instancia del MCUN, deben existir las instancias de GN, RN y ON asociados. 
MN.12) Cuando se crea una instancia del MAN, deben existir las instancias del GN y RN asociados a él. 
MN.13) Cada regla de negocio definida en RN se traslada o asocia a algún elemento del MCUN o del MAN. 
MN.14) Todos los artefactos del MN respetan la definición única dada por los términos descriptos en el GN.  
MN.15) Cada término del GN debe estar incluido en la descripción de por lo menos un CUN. 
MN.16) Un término definido en GN que representa una EN, se corresponde con una clase del modelo de dominio. 
Cuadro 2. Reglas generales del Modelo de Negocio 
 
4. Traducción del diagrama de clases UML y las reglas a Object-Z 
Para la traducción del diagrama de clases UML a expresiones Object-Z se tienen en cuenta las 
definiciones expuestas en [RBR03], [BP03], [KC99] y [KC00],  y se define el siguiente mecanismo: 
a. En primer lugar, se ve al MN como un paquete que agrupa a todas las clases del diagrama. 
b. Por cada clase del diagrama se crea un esquema de clase en Object-Z, con el mismo nombre de 
la clase y se le antepone el nombre del paquete MN. 
c. Las asociaciones entre clases se expresan como atributos en la clase creada en Object-Z. En 
cada extremo de la asociación que sea navegable, se incluye en la clase el nombre de la clase 
opuesta como atributo y su tipo depende de la multiplicidad. Para las relaciones con 
multiplicidad 0..1 el tipo es el de la clase opuesta, y para más de uno, el tipo se representa como 
un conjunto de elementos del tipo de la clase opuesta. Si ambos extremos son navegables se 
agrega una restricción que lo indica.  
d. Para la composición, en la clase del “todo” se agrega el símbolo © a cada atributo que sea una 
“parte”. Además se agrega una restricción que indica que todo elemento de la parte esta 
contenida en el todo.  
e. Para la clase asociación, se representa como un esquema de clase con un atributo por cada clase 
asociada y una restricción que indica que solo existe una instancia de la clase asociación que 
pertenece a una instancia de las clases asociadas. 
f. En la generalización, se agrega el nombre de la clase padre en el esquema de clase del hijo, al 
comienzo. 
Si se observa el diagrama de clases de la Figura 1 y se sigue paso a paso el mecanismo de 
traducción expuesto se obtienen expresiones en Object-Z, como la que se muestra a continuación, 
correspondiente al artefacto GN. El esquema de clase que traduce a dicho artefacto tiene un atributo 
que indica el estereotipo con que se lo asocia. 
 estereotipo: Document  
mcun: MCUN 
man: MAN 
# man ≤ 1 
# mcun = 1 
∀ m: mcun  • self ∈ m.gn 
∀ a: man  • self ∈ a.gn 
MN.GN 
El GN presenta una relación de asociación con navegabilidad en ambos extremos con el MAN y 
el MCUN, por lo tanto contiene dos atributos, una restricción para indicar la multiplicidad y una 
restricción que indica la navegabilidad, ambas por cada atributo. 
 
5. Conclusiones 
Esta formalización del modelo genérico es una reconstrucción bien formada del modelo original 
presentado por [RUP] que, además de permitir visualizar y especificar de manera completa y 
organizada los artefactos que componen el modelo de negocio y la relaciones existentes entre los 
mismos, expresa formalmente y de manera precisa las restricciones asociadas a dichos artefactos, 
que surgen del propio diagrama de clases del modelo genérico como así también de las reglas 
generales del modelo. Además, provee una asociación precisa, completa y consistente entre el 
modelo genérico (expresado a través de un Diagrama de Clases UML), las reglas asociadas al 
mismo (expresadas en lenguaje natural), y la correspondiente traducción de ambos a Object-Z. 
 
Referencias Bibliográficas 
[BDMN04] G. Baum,  M. Daniele,  P. Martellotto, M. Novaira. “Un Modelo Genérico para el Modelo de Negocio”. X 
Congreso Argentino de Ciencias de la Computación, CACIC'2004: U.N. de La Matanza. 
[BP03]  Becker, Pons C. “Definición Formal de la Semántica de UML-OCL a través de su traducción a Object-Z”. 
CACIC 2003. 
[BRJ99]  G. Booch, James Rumbaugh, Ivar Jacobson. “The Unified Modeling Language”. Addison Wesley 1999. 
[EP00]  Eriksson, H.E., Penker, M.: Business Modeling with UML. Business Patterns at Work. John Wiley & 
Sons, Inc. 2000. ISBN:0-471-29551-5. 
[JBR99]  I. Jacobson, G. Booch, J. Rumbaugh. The Unified Software Development Process. Addison Wesley 1999.  
[KC99]  S.-K. Kim amd D. Carrington. Formalising the UML class diagram using Object-Z. In 2nd International 
Conference on Unified Modelling Language (UML'99), volume 1732 of Lecture Notes in Computer 
Science. Springer-Verlag, 1999.  
[KC00]  S-K. Kim and D. Carrington. A Formal Mapping between UML Models and Object-Z Specifications. In 
ZB2000: International Conference of B and Z Users, v 1878 of Lecture Notes in Computer Science, 2000.  
[OMG]  OMG Object Management Group. Unified Modeling Language Specification. http://www.omg.org . 
[OMMN01]  M. Ortín, J. García Molina, B. Moros, J. Nicolás, “El Modelo del Negocio como base del Modelo de 
Requisitos”. 2001. http://www.lsi.us.es/~amador/JIRA/Ponencias/JIRA_Ortin.pdf. 
[RBR03]  D. Roe, K. Broda, A. Russo. Mapping UML Models incorporating OCL Constraints into Object-Z. 
Technical Report 2003/9, Imperial college London.  
[RUP]  Rational Unified Process. http://www.rational.com/rup/ 
[Salm03]   José Francisco Salm Junior : “Extensões Da Uml Para Descrever Processos De Negócio”.  2003. 
[SVC01]  Pedro Sinogas, André Vasconcelos, Artur Caetano, João Neves, Ricardo Mendes, José Tribolet. Business 
Processes Extensions to UML Profile for Business Modeling. 2001. Http://www.inesc-
id.pt/pt/indicadores/Ficheiros/894.pdf 
[UML03]  (UML 2.0) Object Management Group, 2003, OMG Adopted Specification, ptc/03-09-15. 


Spanish

Traducción del modelo genérico del modelo de negocio a Object-Z

Servicio de Difusión de la Creación Intelectual

Traducción del Modelo Genérico del Modelo de Negocio a Object-Z  Marcela Daniele,  Paola Martellotto, Gabriel Baum Universidad Nacional de Río Cuarto Facultad de Ciencias Exactas, Fco-Qcas y Naturales - Dpto. de Computación {marcela,paola}@dc.exa.unrc.edu.ar, gbaum@info.unlp.edu.ar  Resumen Este trabajo muestra el modelo genérico del modelo de negocio [BDMN04], representado gráficamente en términos de UML a través de un diagrama de clases, producto del análisis de los artefactos del Proceso Unificado que componen el modelo de negocio y sus relaciones. Además, se definen un conjunto de reglas que el modelo debe verificar. Esta demostrado que el modelado gráfico es muy útil para visualizar, especificar, construir y documentar los artefactos de un sistema, brindando un lenguaje común, fácil de entender y aplicar. Sin embargo, no posee una semántica precisa, y por lo tanto, se presentan ambigüedades que originan problemas de interpretaciones erróneas o diferentes. En este sentido, se traduce el modelo genérico del modelo de negocio con un Diagrama de Clases UML a un lenguaje de especificación formal. Esta definición, realizada en Object-Z, permite expresar sin ambigüedad modelos de negocio concretos en dominios particulares, y facilita el análisis de las propiedades del sistema, mostrando posibles inconsistencias, ambigüedades o incompletitudes.   1. Introducción El desarrollo de un sistema software es pensado para solucionar problemas a través de programas que deben presentar variadas características tales como: eficiencia, robustez, seguridad en los datos, dinamismo, interactividad, portabilidad, etc.. Solo es posible construir dicho sistema, estudiando primero el problema y luego proponiendo las posibles soluciones.  El Proceso Unificado de desarrollo de software [RUP] [JBR99] es una metodología que define quién está haciendo qué, cuándo, y cómo para construir o mejorar un producto de software. Este método utiliza UML (Unified Modeling Language) [UML03] [BRJ99], como medio de expresión de los diferentes modelos que se crean durante las etapas del desarrollo. El primer artefacto propuesto es el Modelo de Negocio, el cual permite establecer una abstracción de la organización. Básicamente, la propuesta de [RUP] se basa en lograr un buen entendimiento del negocio para la construcción de un sistema correcto, a través del desarrollo de un conjunto de artefactos que permiten modelar integramente el negocio. Los trabajos existentes acerca del Modelado de Negocio y que hacen referencia específicamente a la metodología del Proceso Unificado, utilizan la definición de los artefactos, tal como la presentan sus autores, sin mayor análisis. En este plano cabe mencionar algunos trabajos como el libro escrito por Eriksson y Penker [EP00] que define una extensión a UML para describir procesos de negocio y presentan conceptos claves del modelado de negocio, incluyen una descripción para definir reglas de negocio en Object Constraint Language (OCL) y como usar modelos de negocio como casos de uso. [OMMN01] propone un método sistemático para obtener el modelo de requisitos a partir del modelo de negocio. [Salm03] utiliza las extensiones a UML para el Modelado de Negocio propuestas por la OMG. [SVC01] proponen una extensión a UML con la definición de un Profile para el modelo de negocio.  Este trabajo muestra el análisis de los artefactos que componen el modelo de negocio, según [RUP]. Y resulta en un modelo genérico del modelo de negocio, representado gráficamente en términos de UML a través de un diagrama de clases (Figura 1), el cual establece las bases para especificar un modelo concreto. Con la aplicación de las reglas definidas para cada artefacto y sus relaciones, ayuda a construir el modelo de negocio para el conocimiento que se requiere del contexto. Por otro lado, el modelo genérico puede ser también usado para verificar un modelo de negocio concreto previamente construido. Esta demostrado que el modelado gráfico es muy útil para visualizar, especificar, construir y documentar los artefactos de un sistema, brindando un lenguaje común, fácil de entender y aplicar. Sin embargo, no posee una semántica precisa, y por lo tanto, se presentan ambigüedades que originan problemas de interpretaciones erróneas o diferentes. En este sentido, necesitamos traducir nuestro modelo genérico del modelo de negocio propuesto con un diagrama de clases UML a un lenguaje de especificación formal, tal como Object-Z, que permite expresar sin ambigüedad modelos de negocio concretos en dominios particulares, y aún cuando la aplicación de métodos formales no garantiza la corrección a priori de un sistema, facilita considerablemente el análisis de las propiedades del sistema, mostrando posibles inconsistencias, ambigüedades o incompletitudes.   2. Modelo Genérico del Modelo de Negocio Tal como lo postulan los creadores del proceso [JBR99], con las particularidades introducidas por [RUP], el  modelo de negocio está soportado por dos artefactos principales, el modelo de casos de uso del negocio y el modelo de análisis del negocio. El modelo de casos de uso de negocio describe los procesos de negocio de una empresa en términos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. Presenta un sistema desde la perspectiva de su uso, y esquematiza como proporciona valor a sus usuarios. Por otro lado, el modelo de análisis del negocio, es un modelo interno a un negocio, que describe cómo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores que utilizan entidades del negocio y unidades de trabajo. El conjunto completo de artefactos del modelo de negocio captura y presenta el contexto del sistema y sirven como entrada y referencia para la definición de los requerimientos del sistema.  Para la construcción del modelo genérico, partimos por definir a cada artefacto del modelo de negocio como una clase. En el cuadro 1 se encuentra la referencia a la sigla usada para cada artefacto y son agrupados según sus características que lo definen en el modelo.  MODELOS MCUN Modelo de Casos de Uso de Negocio MAN  Modelo de Análisis de Negocio DOCUMENTOS ELEMENTOS DE MODELOS GN  Glosario de Negocio CUN Caso de Uso de Negocio VFO  Valoración del Fin de la Organización AN Actor  de Negocio VN  Visión del Negocio RCUN Realización de Caso de Uso de Negocio DAN  Documento Arquitectura del Negocio SN Sistema de Negocio ESN  Especificación Suplementaria del Negocio EN Entidad de Negocio RN  Reglas del Negocio WN Worker de Negocio ON  Objetivo del Negocio EvN Evento de Negocio Cuadro 1. Siglas que identifican los Artefactos del Modelo de Negocio  El diagrama de clases de la Figura 1, muestra la representación gráfica del modelo genérico propuesto para el modelo de negocio. Permite visualizar con claridad los artefactos que componen el modelo completo de negocio, destacando los modelos con el estereotipo <<model>>, los elementos de modelos con el estereotipo <<element>> y expresados con relaciones de composición, y los documentos con el estereotipo <<document>>, que representan las definiciones suplementarias para los dos modelos fundamentales representados por MAN y MCUN. El MCUN es el modelo más importante a construir en el modelado de negocio. Si se analiza en detalle el MCUN y su relación con los demás artefactos, el diagrama de clases propuesto especifica de manera precisa que para cada MCUN debe existir un GN, un RN y un ON asociado. Se deduce que para crear el MCUN será necesario haber materializado las estrategias de negocio en ON, y una vez definido éstos el MCUN dirige su propósito hacia ellos. Observando el diagrama la relación entre MCUN y ON es una asociación simple con dirección hacia el ON con multiplicidad igual a 1 y con 0..1 en MCUN, que además del significado que representa la relación propiamente dicha, ésta pretende expresar que se requiere la definición de los objetivos del negocio, al menos de manera parcial, antes de comenzar la descripción del Modelo de Casos de Uso del Negocio. Lo mismo ocurre con la relación expresada entre el MCUN y los artefactos GN y RN. Se sabe que cada uno de estos artefactos evolucionarán paulatinamente con la construcción del modelo general.  include, extend  generaliza disparan y reciben CUNAbstracto CUNNoAbstracto 1..* 0..* AN <<element>> 1..* 1..* +presta servicio <<interaccion>1 0..* +especializa ON <<document>> EvN <<element>> SN <<element>> WN <<element>> 1 0..* +colabora RCUN <<element>> 1..* 0..* 0..* 1..* EN <<element>> 1 0..* 1..* 1..* <<interaccion>> 1..* 0..* RN <<document>> GN <<document>> 1 1 MAN <<model>> 1 0..1 1 0..1 1..* DAN <<document>> 0..1 1 VN <<document>> 0..1 1 ESN <<document>> MCUN <<model>> 1..* 1 0..1 0..1 1 1 0..1 0..1 1 0..1 1 0..1 1 VFO <<document>> 0..1 1 CUN <<element>> 1..* 1 0..* +relaciona   1  Figura 1. Modelo Genérico del Modelo de Negocio  3. Definición de Reglas Las reglas acompañan al modelo genérico presentado en la figura 1 para verificar que un modelo de negocio concreto se construye correctamente a partir de dicho modelo genérico, o determinar si un modelo de negocio previamente construido cumple estas reglas y por lo tanto es correcto. En la sección 4 se muestra su formalización en el lenguaje de especificación formal Object-Z. Las reglas definidas se agrupan en reglas generales para el modelo de negocio, reglas que están asociadas al Modelo de Casos de Uso del Negocio, y por último reglas que corresponden al Modelo de Análisis del Negocio, identificadas unívocamente con la sigla MN, MCUN y MAN, seguida de un número correlativo. Como ejemplo, el Cuadro 2 muestra algunas reglas generales del modelo de negocio que imponen principalmente relaciones y condiciones entre los artefactos, sin considerar todas las condiciones a tener en cuenta en la construcción interna de cada artefacto propiamente dicho. MN.1)  MN: {artefacto} Indica que el Modelo de Negocio está compuesto por un conjunto de artefactos. MN.2) artefacto = (model | modelElement | document) Cada artefacto corresponde a un tipo específico. MN.3) model = ( MCUN | MAN ). Un Model es un MAN o un MCUN. MN.4) modelElement = ( CUN | AN | SN | EN | WN | RCUN | EvN ) MN.5) document = ( GN | RN | ON | ESN | DAN | VN | VFO ) MN.6) Dado un mn : MN, mn representa una instancia del MN genérico. MN.7) Cada artefacto tiene una única instancia para un mn:MN particular. MN.8) Todo mn: MN debe contener un GN, un ON, un RN y un MCUN. MN.9) Todo artefacto identificado con <<document>>, está asociado al MCUN y es usado por este. MN.10) La creación y actualización de los elementos del MAN depende de los elementos del MCUN. MN.11) Cuando se crea una instancia del MCUN, deben existir las instancias de GN, RN y ON asociados. MN.12) Cuando se crea una instancia del MAN, deben existir las instancias del GN y RN asociados a él. MN.13) Cada regla de negocio definida en RN se traslada o asocia a algún elemento del MCUN o del MAN. MN.14) Todos los artefactos del MN respetan la definición única dada por los términos descriptos en el GN.  MN.15) Cada término del GN debe estar incluido en la descripción de por lo menos un CUN. MN.16) Un término definido en GN que representa una EN, se corresponde con una clase del modelo de dominio. Cuadro 2. Reglas generales del Modelo de Negocio  4. Traducción del diagrama de clases UML y las reglas a Object-Z Para la traducción del diagrama de clases UML a expresiones Object-Z se tienen en cuenta las definiciones expuestas en [RBR03], [BP03], [KC99] y [KC00],  y se define el siguiente mecanismo: a. En primer lugar, se ve al MN como un paquete que agrupa a todas las clases del diagrama. b. Por cada clase del diagrama se crea un esquema de clase en Object-Z, con el mismo nombre de la clase y se le antepone el nombre del paquete MN. c. Las asociaciones entre clases se expresan como atributos en la clase creada en Object-Z. En cada extremo de la asociación que sea navegable, se incluye en la clase el nombre de la clase opuesta como atributo y su tipo depende de la multiplicidad. Para las relaciones con multiplicidad 0..1 el tipo es el de la clase opuesta, y para más de uno, el tipo se representa como un conjunto de elementos del tipo de la clase opuesta. Si ambos extremos son navegables se agrega una restricción que lo indica.  d. Para la composición, en la clase del “todo” se agrega el símbolo © a cada atributo que sea una “parte”. Además se agrega una restricción que indica que todo elemento de la parte esta contenida en el todo.  e. Para la clase asociación, se representa como un esquema de clase con un atributo por cada clase asociada y una restricción que indica que solo existe una instancia de la clase asociación que pertenece a una instancia de las clases asociadas. f. En la generalización, se agrega el nombre de la clase padre en el esquema de clase del hijo, al comienzo. Si se observa el diagrama de clases de la Figura 1 y se sigue paso a paso el mecanismo de traducción expuesto se obtienen expresiones en Object-Z, como la que se muestra a continuación, correspondiente al artefacto GN. El esquema de clase que traduce a dicho artefacto tiene un atributo que indica el estereotipo con que se lo asocia.  estereotipo: Document  mcun: MCUN man: MAN # man ≤ 1 # mcun = 1 ∀ m: mcun  • self ∈ m.gn ∀ a: man  • self ∈ a.gn MN.GN El GN presenta una relación de asociación con navegabilidad en ambos extremos con el MAN y el MCUN, por lo tanto contiene dos atributos, una restricción para indicar la multiplicidad y una restricción que indica la navegabilidad, ambas por cada atributo.  5. Conclusiones Esta formalización del modelo genérico es una reconstrucción bien formada del modelo original presentado por [RUP] que, además de permitir visualizar y especificar de manera completa y organizada los artefactos que componen el modelo de negocio y la relaciones existentes entre los mismos, expresa formalmente y de manera precisa las restricciones asociadas a dichos artefactos, que surgen del propio diagrama de clases del modelo genérico como así también de las reglas generales del modelo. Además, provee una asociación precisa, completa y consistente entre el modelo genérico (expresado a través de un Diagrama de Clases UML), las reglas asociadas al mismo (expresadas en lenguaje natural), y la correspondiente traducción de ambos a Object-Z.  Referencias Bibliográficas [BDMN04] G. Baum,  M. Daniele,  P. Martellotto, M. Novaira. “Un Modelo Genérico para el Modelo de Negocio”. X Congreso Argentino de Ciencias de la Computación, CACIC'2004: U.N. de La Matanza. [BP03]  Becker, Pons C. “Definición Formal de la Semántica de UML-OCL a través de su traducción a Object-Z”. CACIC 2003. [BRJ99]  G. Booch, James Rumbaugh, Ivar Jacobson. “The Unified Modeling Language”. Addison Wesley 1999. [EP00]  Eriksson, H.E., Penker, M.: Business Modeling with UML. Business Patterns at Work. John Wiley & Sons, Inc. 2000. ISBN:0-471-29551-5. [JBR99]  I. Jacobson, G. Booch, J. Rumbaugh. The Unified Software Development Process. Addison Wesley 1999.  [KC99]  S.-K. Kim amd D. Carrington. Formalising the UML class diagram using Object-Z. In 2nd International Conference on Unified Modelling Language (UML'99), volume 1732 of Lecture Notes in Computer Science. Springer-Verlag, 1999.  [KC00]  S-K. Kim and D. Carrington. A Formal Mapping between UML Models and Object-Z Specifications. In ZB2000: International Conference of B and Z Users, v 1878 of Lecture Notes in Computer Science, 2000.  [OMG]  OMG Object Management Group. Unified Modeling Language Specification. http://www.omg.org . [OMMN01]  M. Ortín, J. García Molina, B. Moros, J. Nicolás, “El Modelo del Negocio como base del Modelo de Requisitos”. 2001. http://www.lsi.us.es/~amador/JIRA/Ponencias/JIRA_Ortin.pdf. [RBR03]  D. Roe, K. Broda, A. Russo. Mapping UML Models incorporating OCL Constraints into Object-Z. Technical Report 2003/9, Imperial college London.  [RUP]  Rational Unified Process. http://www.rational.com/rup/ [Salm03]   José Francisco Salm Junior : “Extensões Da Uml Para Descrever Processos De Negócio”.  2003. [SVC01]  Pedro Sinogas, André Vasconcelos, Artur Caetano, João Neves, Ricardo Mendes, José Tribolet. Business Processes Extensions to UML Profile for Business Modeling. 2001. Http://www.inesc-id.pt/pt/indicadores/Ficheiros/894.pdf [UML03]  (UML 2.0) Object Management Group, 2003, OMG Adopted Specification, ptc/03-09-15. 

http://sedici.unlp.edu.ar/bitstream/handle/10915/21126/Documento_completo.pdf?sequence=1

Traducción del modelo genérico del modelo de negocio a Object-Z

Abstract

Similar works

Full text

Available Versions

SEDICI - Repositorio de la UNLP

Servicio de Difusión de la Creación Intelectual