I

S.E.P I

S.E.I.T. D.G.I.T.

I CENTRO NACIONAL DE INVESTIGACI~N

I Y DESARROLLO TECNOLÓGICO

i I ' cenidet 1 I'

I DEPENDENCIAS ESTRATÉGICO 1 I I T E S I S

I I '1

1 , CARACTERIZACIÓN FORMAL BASADA EN EL LENGUAJE OASIS DEL MODELADO DE

I QUE PARA OBTENER EL GRADO DE: MAESTRO EN CIENCIAS EN

CIENCIAS COMPUTACIONALES

P R E S E N T A : I I ' I I'

I

ERIKAMYRIAMNiETOARIZA

DIRECTOR DE TESIS: DR. JAVIER ORTIZ HERNÁNDEZ CODIRECTOR DE TESIS: M.C. HUGO ESTRADA ESQUIVEL

1 ,

MAYO DEL 2001 I " CUERNAVACA MORELOS

I I 'I

,

Centro Nacional de Investigación y Desarrollo Tecnológico 'I

FORMA C3 REVISION DE TESIS

Cuernavaca, Morelos a 6 de abril del 2001

Di. Raul Pinto Elías Presidente de la Academia de Ciencias Computacionales Presente I

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Caracterización Formal Basada en el Lenguaje OASIS del Modelado de Dependencias Estratégico, realizada por la C. Erika Myriam Nieto Ariza, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

.I

Sin otro particular, quedamos de usted.

Atentamente

La comisión de revisión de tesis

11

n

M.C. Reynaldo Alanís Cantú /

Ortiz Hernández

C.C.P. Dr. Javier Ortiz Hernández/Jefe del Departamento de Ciencias Computacionales INTERIOR INTiERNADO PALMIRA SIN. CUERNAVACA. M O R . MÉXICO APARTADO POSTAL 5-164 C P 62050. CUERNAVACA, TELS. (73112 2314.12 7613.18 7741. FAX (73) 12 2434

EMAIL ortiz@cenidet.edu.mx cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C4

AUTORlZACfON DE IMPRESIdN DE TESIS

Cuernavaca, Morelos a 24 de Abril del 2001

C. Erika Myriam Nieto Ariza Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: Caracterización Formal Basada en el Lenguaje OASIS del Modelado de Dependencias Estratégico, me es grato comunicarle, que conforme a los linearnientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Computacionaies

U

NTERIOR INTERNADO PAUAIRA SIN. CUERNAVACA, MOR. M&XiCO APARTADO POSTAL 5 1 6 4 CP 6x)5D. CUERNAVACA. TELS. (73112 2314.12 7613.18 ii41. FAX 175) 12 2434 cenidet

!'

A Dios

A mi mamá Alicia

A m i s hermanos Norma, Argelia y Valdemar

A Nayeli, Erendira, Liliana, Diana, Eduardo y Keyla

A m i s tías Delfma' y Rocio Ariza

. .

Agradecimientos

A Dios por ser a cada instante mi fuerza y dirección.

A mi mamá por ser mi ejemplo a seguir en todo momento y de quien me siento muy orgullosa.

A mi familia por su estimulo, apoyo y comprensión, gracias.

!I Al Centro Nacional de Invesagación y Desarrollo Tecnológico por la oportunidad de realizar m i s estudios de maestría.

A la SEP por su apoyo.

A mi director de tesis Dr. Javier Ortiz Hemández y a mi codirector de tesis M.C. Hugo Estrada Esquive1 por su confunza, respaldo y ayuda en la elaboración de esta tesis.

Al comité de revisores por sus valiosos comentanos M.C. Reynaldo Alanís y , Cantú, M.C. René Santaolaya Salgado y al M.C. Antonio Zárate Marceleño

A todos m i s maestros por su labor en esta institución y un reconocimiento a su labor, dedicación, esfuerzo y sabiduría.

il

/I

I A m i s compañeros de generación Claudia, Andrea, Rosy, Ana, Wfiam, Octavio, Juan Carlos y Bematdino gracias.por su amistad.

A mis amigos Alicia, Vicky, Leo, Horacio, Ernesto, Hugo, Mano, Arely, Hna. Juanita.y Delfma, gracias por todo.

A Carlos Alberto por su apoyo incondicional, cariño y confianza, gracias ,

TABLA DE CONTENIDO

1. ANTECEDENTES 1.1 Ingeniería de Requerimientos

18 1.1.1 Ingeniería de Requerimientos del Sistema 1.1.2 ' Ingeniería de Requerimientos del Software

1.2 IRIS 1.2.1 1.2.2 Etapas del Proyecto 1.2.3 Ubicación de esta tesis

Objetivos Generales del Proyecto IRIS

:. 1.3 Descripción del problema 1.4 Objetivo 1.5 Beneficios

i 2. ARCO T E ~ R I C O

2.1 Métodos Formales 2.1.1 DeíiniciÓn 2.1.2 Características

2.1.2.1 Utilidad 2.1.3 Lenguajes de Especificación

2.1.3.1 TroU 2.1.3.2 Larch 2.1.3.3 Z 2.1.3.4 Telos 2.1.3.5 Disco :I

2.2 Técnicas de Especificación Semiformal 2.2.1 Diagramas Entidad-Relaaón

'I 2.2.2 Diagramas de Flujo de Datos 2.2.3 IDEF0

3. ,iMODELO DE DEPENDENCIAS ESTRATEGIW 3.1 Framework i*

3.2 Modelo de Dependencias Estratégicas 3.1.1 Modelo Racional Estratégico

3.2.1 Elementos del modelo 3.2.2 Ventajas

3.3.1 3.3.2 Análisis de sistemas 3.3.3 Ingeniería de Requisitos 3.3.4 Análisis de Impactos organizacionales

:I

3.3 Campos de aplicación Reingeniería de procesos de negocios

4. LENGUAJE DE ESPECIFICACION FORMAL OASIS 4.1 Descripción ' 4.1.1 00-Method 4.2 Características del Lenguaje OASIS 4.3 Semánticas de OASIS 4.4 Especificación de clase

Pág.

2 2 3 3 3 3 5; 6 6 6

8 8 8 9 10 10 11 11 11 11 12 12 12 12

14 15 15 16 19 19 19 20 20 21

23 23 24 24 25

4.5 Metaclase 4.6 OASIS como Lenguaje

4.6.1 Especificación 4.6.2 Tipos de datos 4.6.3 Especificación de una clase 4.6.4 Clase compleja

4.6.4.1 Agregación 4.6.4.2 Herencia

4.6.5 Interfaces 4.6.6 Estructura General del Lenguaje

5. METODOLOGIA DE DESARROLLO 5.1 Introducción 5.2 Primera Fase

5.2.1 Modelo de Contexto 5.2.1.1 Descripción del Modelo 5.2.1.2 Interpretación del Modelo de Contexto

5.3 Segunda Fase 5.3.1 Plantilla de Intenciones 5.3.2 5.3.3

Descripción de la Plantilla de intenciones Descripción del Formato del Archivo de Intenciones

5.4 Definición de los elementos utilizados del lenguaje OASIS 5.5 Reglas de Transformación 5.6 Integración de las intenciones al modelo de contexto 5.7 Descripción General de la Herramienta

6. CASO DE ESTUDIO

CONCLUSIONES Y TRABAJOS FUTUROS ANEXO 1 REFERENCIAS

21 28

’ 28 29 29 30 30 30 31 31

34 35 35 35 36 38 39 40 43 45 47 50 52

55

85 89 94 , *

Fii.

1 2 3 4 5 6 7

9 10 11 12 13' 14 15 16 17 18 19 20

8'

INDICE DE FIGURAS Y TABLA

Etapas del proyecto IRIS Esquema Conceptual Elementos del Modelo de Dependencias Estratégicas Representación gráfica de la doble visión de una instancia de la metaclase Esquema de Trabajo Análisis del modelo de contexto Modelo de Contexto Generación del Modelo de Dependencias Estratégicas Plantiila de Intenciones Formato del archivo de Intenciones Generación del código en OASIS del MDE Estructuras utilizadas para el manejo de la información Diagrama de Clase de la Hwramienta Diagrama del Modelo de Contexto Pantalla inicial Pantalla de Captura de la herramienta Pantalla de captura del Modelo de Contexto Generación e Integración Especificación Generada Diagrama del Modelo de Dependencias Estratégicas

Tabla

1 Aplicación de las Reglas de Transformación

Pág.

4 6

16 28 34 35 36 39 40 44 52 53 54 56 57 57 76 78 78 78

Pág.

48

li

J! ill

i! Cabítalo I Antecedentes I.

!! En este capítulo, presentamos conceptos generales acerca de la Ingeniería

de Requerimientos, así como del papel de este trabajo de investigación dentro de del proyecto Ingeniería de Requerimientos de Software, IRIS.

Ji :!I

Anfecedentes capírwlo 1

1.1 Ingenieria de Requerimientos

para el éxito en el desarrollo del software es esencial tener una comprensión completa de 10s requisitos que debe satisfacer este software. La definición de requerimientos es una evaluación cuidadosa de las necesidades que un sistema debe cubrir. Se trata generalmente de un documento que debe decir por qué un sistema es necesario dado las condiciones actuales y anticipadas [Greenspan94]. Durante la crisis del software, a mediados de los 70s se conhmió el rurnor de que “el problema de los requerimientos” era una realidad. Los datos dieron a conocer que los errores en los requerimientos fueron los más numerosos y por lo tanto significativos, además de que fueron los más costosos y consumían tiempo para corregirlo. El reconocimiento de la naturaleza crítica de los requerimientos estableció la Ingeniería de Requerimientos como un subcampo de la Ingeniería de Software. En respuesta a este reconocimiento se creo una ola de conceptos alrededor del tema requerimientos, además de lenguajes, herramientas y metodologías. En el núcleo de los intereses básicos de representación y razonamiento acerca del conocimiento acumulado durante la fase de adquisición de requerimientos surge el Modelado de Requerimientos [Greenspan94].

Actualmente el análisis de requisitos es uno de los mayores retos para los ingenieros e investigadores en desarrollo de software. La bibliografía en esta área es sumamente rica en modelos, técnicas y herramientas. Sin embargo, no son numerosos los trabajos que abordan la problemática real que acontece en proyectos contractuales. Los clientes generalmente redactan documentos de requisitos que frecuentemente contienen ambigüedades, inexactitudes y huecos que el analista de sistemas debe evaluar cuidadosamente, refinando y formalizando incrementalmente en la medida de lo posible hasta producir una especificación funcional. A menudo los resultados al final de este proceso quedan muy lejos de las expectativas o w a l e s de los usuarios. C o n mucha frecuencia, la problemática de especificar requisitos se plantea como un proceso en el cual se conjugan diversos puntos de vista y diversos intereses en las diversas etapas involucradas.

La ingeniería de requerimientos está determinada principalmente por: la dificultad para caracterizar la organización y su medio inmediato; la dificultad para modelar las restricciones de la organización que inhiben o contxolan su función; la diversidad de recursos tecnológicos y humanos disponibles para un determinado contexto; y la flexibilidad, robustez, mantenibilidad y calidad requeridas

1.1.1 Ingeniería de Requerimientos del Sistema

El campo de la ingeniería de requerimientos y emerge como una sub-área de la ingeniería de software, ayudando a que la fase de requerimientos de desarrollo de sistemas de software sea más sistemática y disciplinada Iyu95aI. La fase de requerimientos debe interesarse en las relaciones entre los sistemas y sus ambientes en lugar de colocar los requerimientos solamente en términos de los sistemas de software plu95a], y por esta razón es necesario establecer la ingeniería de requerimientos del sistema.

La Ingqiería de Requerimientos del Sistema es la ciencia y disciplina para analizar y documentar al sistema. Esto involucra transformar una necesidad operacional a una

2

.. .. AntecedenteJ capítulo 1 1

descripción del sistema (análisis) y en esta descripción se deben de incluir datos acerca del desempeño de este (sistema). Esto es iogrado mediante el uso de un proceso iterativo de análisis, diseño y prototificación Payeer97 .

11.2. Ingenieria de Requetimientos del Software

La Ingeniería de Requerimientos de Software es una disciplina que tiene por objetivo analizar y documentar los requerimientos de software. Esto involucra crear particiones de los rdperimientos del sistema en subsistemas y tareas para permi,& mapearlos 4 1 al software..En este proceso también se realiza la transforma&n de re4uerimientos de1,sistema a desuipciones de requerimientos de software. A.través del.análisis; diseño y prototificación se van a conocer que datos deben ser automatizados'o no Fayeer97 .

8

I

122 IRIS I/

.. . i" I'

Hoy' en .día contamos con una gran diversidad de modelos que nos permiten representar todo tipo de aspecto's de la vida real. Así, para resolver,adecuadamente nuestros problemas necesitamos además poseer modelos que reflejen de fo&a siginificativa la realidad con objeto de poder analizar, estudiar y evaluar las diversas alternativas de.solución que se presentan. Lo cual no deja de representar ciertos riesgos, costos y complicaciones. .,I;

I . , . . .

i I [ :: 1 , .El desarrollo de esta tesis forma parte de un proyecto emprendido recientemente en el

gkpo'he'&vestigación en Ingeniería de Software del cenidet. Este grupo trabaja en el campo de la Ingeniería de Requisitos y ha generado una propuesta que permitirá unir las investigaciones realizadas en esta institución con las investigadones desarrollas en el proyecto IDEAS (proyecto de 'Ingeniería DE Ambientes de Software), el cual tiene'como hñalidad integrar esfuerzos de cooperación en el campo de la ingeniería de requisitos y de ambientes de desarrollo de software. Una de las metas de IDEAS es el desarrollo de métodos'y herramientas capaces de soportar diversas problemáticas relacionadas con el proceso de 'especificación de requisitos. , 'lb 1

I - 1.2.1 Objetivos Generales del Proyecto IRIS . . '

I. '. < .. ..

. I 1; :

.El objetivo del proyecto INS es desarro.llar métodosy herramientas para la obtención semi-automatizada de requisitos de software y la generación de prototipos de sistemas de &formacion para la pequeña y mediana empresa naciqndes, a través del: - Desarrollo de modelos, métodos y herramientas para recopilar, sistematizar, organizar,

modelar y administrar requisitos de software, así como el - Desarrollo de un prototipo generador ?e especificaaones de software para formalizar las

, necesidades de sistematización de información.

, '

, -

, . /i

. - 1.2.2 Etapas del Proyecto 4

. . Las etapas del proyecto IRIS se encuentran representadas en la figura 1, las etapas son:

1. Análisis y desarrollo de técnicas para modelar una organización. 2. Uso del modelo de discurso para obtener información de los usuarios (intenciones). 3: Traducción del modelo de contexto a una especificación en el Lenguaje OASIS.

3

4. Definición de los tipos de dependencias e integración de estas al modelo de contexto. 5. Generación de nuevas alternativas de trabajo. 6. Especificación de eventos. 7. Edición de regias de negocio. 8. Identificación y medición de la calidad en las especificaciones de requerimientos. 9. Animación de modelos conceptuales.

a 2 II

Fig. 1 Etapas del proyecto IRIS

A

1.2.3 Ubicación de la Tesis 1 .

./

Es la cuarta etapa de desarrollo de este proyecto; consiste en obtener la especificación del modelo de dependencias estratégicas; a través de enriquecer la caracterización de la empresa con información relativa a las expectativas de los usuarios con respecto al futuro sistema. A estas expectativas que pueden ser explícita o implícitamente expresadas por los usparios al tiempo de las primeras etapas en el desarrollo de un sistema de software les denominamos intenciones. Este trabajo satisface las siguientes necesidades del proyecto IRIS: - Contar con una especificación formal de un proceso de negocios que contenga

información útil para realizar reingeniena, y Poder utilizar esta +sma especificación para la generación de prototipos rápidos -

~i Se consideró el. desarrollo de una herramienta de software que permita especificar relaciones intencionales en una organización, en particular aquellas relacionadas con los procesos de negocio. Cabe mencionar que actualmente se encuentran desarrollada la etapa 6 “Especificación de eventos en procesos de Negocios” a través de esta herramienta es posible observar aunque de manera rústica el cumplimiento del objetivo de esta tesis. La especificación formal generada en esta tesis, será base para posteriormente ..generar automáticamente prototipos. I/

1.3 Descripción del problema .?” .,. >

, En Un nivel técnico la ingeniería de software inicia con’una sene de tareas de modelado que llevan a una especificación completa. de los requiiitos y a una representación del diseño general del software a construir. Las técnicas de especkcación actuales permiten describir una vaciedad de necesidades, por -ejemplo, mejorar-el entendimiento y la comunicación, apoyar procesos y algunas veces automatizarlos; muchas de estas técnicas ayuaan a expresar los pasos de un proceso y como ellos son desarrollados.

Una tendencia actual en el uso de técnicas de especificación es la de poder realizar rkingeniería de procesos. La importancia de la reingeniería reside en que, si ésta es aplicada correctamente en una organización, es posible alcanzar mejoras espectaculares mediante cambios radicales en su estructura. La técnica de modelado de dependencias estratégicas pu96], permite saber quien depende de quien, <por qué? y <para qué? Describiendo de forma clara la relación intencional que existe entre los .actores (participantes o integrantes) en una c;(ganización y permitiendo ayudar a poner en claro que objetivos o propósitos son más factibles de realizar para un correcto y eficiente desarrollo de las tareas y de los procesos. Analizar estas dependencias estratégicas en un nivel de detaile revela el papel de estas dependencias en procesos de negocios, los cuales a menudo tienen suposiciones implícitas, además de que permiten detemiinar si las actividades que se realizan en la organización son tareas hndamentales o por el contrario son tareas que obligan a replantear la forma en que a‘ttualmente se realiza el trabajo [yu94]. I:

Se tiene la necesidad de contar con la representación de un modelo que permita realizar un’proceso de reingeniería, así como utilizar el resultado para poder generar posteriormente un prototipo.

5

Para propósitos de esta tesis se ha adoptado el uso del modelo de dependencias estratégicas propuesto por Eric Yu y J. Mylopoulos [yu94],Iyu96] por encontrar que ofrece un mejor entendimiento de las relaciones organizacionales. Además, este modelo por su simplicidad ofrece la posibilidad de obtener una especificación formal para la generación de prototipos rápidos. Así como el uso del lenguaje de especificación OASIS.

1.4 Objetivo

Enriquecer un modelo de contexto con los razonamientos que prevalecen en procesos de negocio, y formalizarlo con un lenguaje de especificación con el propósito de integrarlo en un ambiente de desarrollo.

A partir de una caracterización de la organización (modelo de contexto) y de un archivo de texto que contiene razonamientos de los participantes de procesos de negocio acerca de sus inrtedependencias, se obtiene un modelo de dependecias estratégicas, como se muestra en la figura 2. Este modelo es formalizado con el lenguaje de especificación OASIS (Open andAc& Spea$atwn ofIt$omatzon .5jutetns). La formalización esta basada en un análisis a las características del modelo de dependencias y de la estructura y propiedades del lenguaje OASIS.

- Fig. 2 Esquema Conceptual

1.5 . Beneficios

El modelo de dependencias estratégicas permite expresar los requetGnientos funcionales y los no funcionales; a su vez el lenguaje OASIS permite especificar los requerimientos a nivel funcional del sistema. La utilización de la técnica de modelado de dependencias estratégicas y el uso del Lenguaje de especificación formal OASIS, permitirá tener como beneficios: - Una especificación enriquecida, proporcionando un entendimiento adecuado de los

objetivos y de las relaciones. organizacionales, lo cual permitirá eventualmente realizar reingeniería. Es deck, poder encontlar respuestas a preguntas como: ?De qué otra manera la organización puede lograr sus metas?. Se dispondrá de una especificación formal que permitirá en trabajos posteriores la generación automática de prototipos y la validación también automática de los requerimientos. Se dispondrá de una base formal para el desarrollo posterior de sistemas de información

-

-

6

li :i(

'!

CaDítdo 2 Marco Teórico

En este capítulo, se presenta el contexto que involucra la resolución del problema planteado en esta tesis.

CqifWh 2 Mam Tcórim

2.1 Métodos Formales

Con el paso del tiempo se ha visto la necesidad de asegurar que los sistemas sean confiables, de disminuir los costos de desarrollo y mantenimiento del software (se tienen altos costos debido a la imprecisión en el desarrollo del software, a la ambigüedad que existe en la fase de análisis, etc.) se ha promovido el uso de los métodos formales. El hacer uso de los métodos formales no solo provee una confianza adicional sino que además permite reducir costos. El estado que precede al diseño del software ha sido llamado especificación, este termino es usado casi siempre como una abreviación de “especificación funcional” -una prescripción de la funcionalidad deseada de un sistema a ser constniido. Este alcance limitado para los requerimientos es evidente en el uso del término “lenguajes de especificación”, aplicado al desarrollo de formalismos matemáticos como 2, VDM, Larch, OBJ. [Greenspan94].

2.1.1 Definición

El término métodos formales es utilizado para referirse al método que tiene una base matemática bien deímida, la cual es proporcionada normalmente por un lenguaje de especificación formal. De esta manera los métodos formales permiten que la funcionalidad de un sistema se especifique de una manera precisa y que pueda determinarse el comportamiento de un sistema sin la necesidad de ejecutarlo. Su uso permite revelax ambigüedad, falta de integndad e inconsistencia de un sistema. Aunado a esto un método formal puede ser utilizado en cualquier fase del proceso de desarrollo del sistema P u 9 7 , Ping901.

2.1.2 Características

Una característica importante de un método formal es que este posee un conjunto de normas, las cuales le dicen al usuario bajo que circunstancias el método puede y debe ser aplicado, así como la manera en que el método formal puede ser aplicado de una manera más efectiva Wing901. Una clasificación de como pueden ser aplicados los métodos formales es la siguiente F.971:

a) Para la producción de especificaciones que puedan servir como base para el desarrollo de sistemas convencionales. En este caso las especificaciones son usadas como medio de documentación precisa la cual tiene como ventaja la manipulación, abstracción y lo conciso. Las pruebas de consistencia y la generación automática de prototipos pueden ser desarrolladas en este estado con la ayuda de una herramienta de soporte. I

b) La producción de una especificación f o F a l que pueda ser utilizada posteriormente para verificar que un sistema sea correcto o como una base para derivar los sistemas verificados a través de las reglas de rehamiento.

El uso de los métodos formales permite además piu97l: 1) Especificar formalmente y verificar los sistemas existentes, en particular aquellos que

2) Introducir nuevas funcionalidades y/o operan en aplicaciones de segundad critica

8

Mano TeDnm . . C@’tWb 2

. . ~ . i . 3),, Tomar ventaja de las mejoras en las técnicas de diseño de sistemas, por ejemplo el remo, el

uso repetido del conocimiento amortiza el costo de desarrollo debido a su descripción formal. Debido a sus semánticas no ambiguas es posible determinar exactamente si el conocimiento que puede usarse nuevamente cae dentro de otro contexto.

Un método formal consiste de algunos componentes e sendes P u 9 q : - Un modelo semántico - . Un lenguaje de especificación (notación) - - Normas de desarrollo y

Una verificación del sistema/calculo de refinamiento

- Herramientas de soporte 8t

Modelo semántic0.- es una estructura lógica/matemáticamente dentro de la cual todos 18) términos, formulas y reglas usadas tienen un significado preciso. El modelo semántico debe reflejar el modelo computacional subrayado de la aplicación proyectada.

Lenguaje de especificación.- es un conjunto de notaciones las cuales son usadas para describir el comportamiento proyectado del sistema. Este lenguaje debe tener una semántica apropiada dentro del modelo semántico.

Sistema de verificación/calculo de refinamiento: son reglas que permiten la verificación de las propiedades y/o el refmamiento-entre especificaciones.

Normas de desarrollo: son los pasos que muestran el uso del método

Herramientas de soporte.- incluye un ayudante de pruebas, probador de tipo y sintaxis, dil. a p a d o r y un desarrrollador, de prototipos.

2.1.2.1 Utilidad

Una de las principales utilidades del uso del un método formal, es que este puede ser aplicado en cualquier fase del proceso de desarrollo del sistema. Algunos de sus usos se encuentran en Fing90]:

- . Análisis de Requerimientos.. Ayuda a poner en claro las ideas del cliente, revelando ambigüedades, contradicciones e inconsistencia en los requerimientos. Diseño del Sistema: El diseóo del sistema puede ser dividido en módulos y en cada uno de ellos pueden escribirse especificaciones que puedan captar las interfaces precisas entre los

Verificación del Sistema.. A través de la verificación se prueba que el sistema satisfaga su especificación. Aún cuando el sistema puede no ser verificado de manera completa, pueden verificarse módulos críticos. Validación del Sistema.. el uso de métodos formaies es de ayuda para realizar las prueba y la eliminación de errores en el sistema.

-

di módulos y posteriormente refinarlas. -

- 11

,¡I

I!#

9

C+ítukJ 2 M5m Teórico

- Documentación del Sistema.- El uso de métodos formales permite establecer la comunicación entre la persona que realiza la especificación y la persona que impiementara el sistema. Análisis y Evaluación del Sistema: Con el objetivo de aprender de la experiencia de construir un sistema las personas que desarrollan el sistema deben hacer una análisis de su funcionalidad y desarrollo una vez que este ha sido consmido y probado. Si se utilizaron métodos formales en su desarrollo, estos pueden ayudar a las personas que desarrollaron el sistema a responder preguntas como ?Esto es lo que cliente quería?

-

2.1.3 Lenguajes de Especificación

La especificación formal es el producto obtenido de aplicar un método formal. Por lo tanto se requiere conocer ?Qué es un Lenguaje de Especificación?

Un Lenguaje de Especificación formal wing901 es aquel que tiene una base matemática formal y se encuentra integrado por:

- Un dominio sintáctico: notación - -

Un dominio semántico.. un universo de objetos y Relaciones de satisfacción.- reglas precisas las cuales definen como cada objeto Satisface cada especificación.

Dominio sintáctico Se define en términos de un conjunto de shbolos y un conjunto de reglas gramaticales

.

para combinar los simbolos en oraciones bien formadas.

Dominio Semántico Esto difiere de acuerdo al dominio de aplicación por ejemplo en los lenguajes de

especificación de tipo de datos abstractos, lenguajes de especificación de sistemas distribuidos y concurrentes, etc. De acuerdo a un dominio semántico una función de abstracción semántica es un homomorfismo que mapea elementos del dominio semántico dentro de clases equivalentes. Las funciones de abstracción semántica hacen posible describir diversos puntos de vista de las mismas clases equivalentes del sistema.

Relaciones de Satisfacción Mediante estas reglas gramaticales se busca especificar diferentes aspectos de una

especificación, por ejemplo: el comportamiento funcional de un conjunto de módulos de un programa, la relación estructural entre módulos, etc.

Con el objetivo de conocer .las características ofrecidas por los lenguajes de especificación, se realizó una investigación de los mismos. Algunos aspectos relevantes de dichos lenguajes se presentan a continuación.

2.1.3.1 Troll

El lenguaje TROLL (Textual Representation of an Object Logic Language) de acuerdo a los autores Denker y Ehrich es considerado de ayuda en el modelado y especificación de sistemas de información en un nivel de abstracción alto. El énfasis esta en combinar el

10

Mano Teónm capítulo 2

modelado conceptual y las técnicas de especificación formal con las técnicas para modelar distribución y concurrencia. TROLL es orientado a objetos, una de sus características principales es que la sintaxis y la semántica de TROLL están definidas formalmente Penker99hl. TROLL es un lenguaje para ser utilizado en fases tempranas del diseño de sistemas de información además de tener una notación textual para la espeuficación de sistemas distribuidos complejos. La notación textual es usada para describir propiedades locales y para detallar descripciones de relaciones globales y limitaciones, incorpora todos los conceptos del lenguaje Penker99aI. - 2.1.3.2 Larch

Pertenece a una familia de lenguajes de espedcación algebraica, fue desarrollado para ayudar en el uso productivo de especificaciones formales en programación. Una de sus principales ventajas es que soporta una gran variedad de programación diferente, incluyendo lenguajes imperativos. El lenguaje Larch esta compuesto de dos componentes: el lenguaje de interfaces el cual es especifico a el lenguaje de programación particular bajo consideración y el lenguaje compartido el cual es común a todos los lenguajes de programación @u97].

2.1.3.3 2

Hace énfasis en la especificación del comportamiento de sistemas secuenciales. Los estados son descritos en términos de estructuras matemáticas tales como conjuntos, relaciones y ' funciones, las eansiciones de estado 'son dadas en términos de pre y post condiciones [Clarke96]. :,

2.1.3.4 . Telos

Fue desarrollado para proporcionar una base en el desarrollo de sistemas de información. Los principios de diseño para el lenguaje se basan en la premisa de que el desarrollo de los sistemas de información requiere de un conocimiento intensivo y que la principal responsabilidad de cualquier lenguaje es el ser capaz de representar el conocimiento relevante de manera formal. Telos tiene como base los conceptos de representación del &nocimiento. Su utilidad se centra en representar el conocimiento acerca de una variedad de

'11 mundos relacionados a un sistema de información particular: el mundo del sujeto (dominio de '11 la aplicación), el mundo de uso (modelos de usuarios, ambientes), el mundo del sistema (lequerimientos de software, diseño) y el mundo de desarrollo (grupos, metodológias) pfyl0p0ul0s90].

2.1.3.5 Disco

Ha sido diseñado para especificar sistemas reactivos, haciendo énfasis en sistemas distribuidos. Describe un sistema junto con su ambiente en un alto nivel de abstracción. El mundo descrito por una especificación Disco consiste de objetos, acciones y relaciones. Los objetos se describen por definiciones de clase, acciones por definición de acción y relaciones por deíiniciones de relación. Una acción especifica los participantes de la acción por medio de un conjunto de roles. El lenguaje permite múltiple herencia, la cual tiene una interpretación natural en un lenguaje de especificación. Una de las desventajas de este lenguaje es que en el

I:

0 1 - 0 1 1 9 11

C ~ ~ ~ I O 2 Mam Teókn

modelo de ejecución no distingue entre objetos activos y objetos pasivos, ya que ellos sólo están interesados en que la información sea intercambiada entre los participantes [Pertti98].

2.2 Técnicas de Especificación semiformal

Algunas técnicas semiformales que fueron revisadas para determinar las ventajas que ofrece el modelo de dependencias estratégicas sobre estas son las siguientes:

2.2.1 Diagramas Entidad - Relación

Los componentes principales son: objetos de datos, atributos, relaciones e indicadores de tipo. El propósito principal es representar objetos de datos y sus relaciones. Los objetos de datos se representan por un rectángulo'etiquetado. Las relaciones se indican mediante una Enea etiquetada conectando un objeto. Las conexiones entre objetos de datos y relaciones se establecen mediante una variedad de símbolos especiales que indican cardinalidad y modalidad [Pressman98].

2.2.2 Diagramas de Flujo de Datos

Es una técnica que representa el flujo de información de las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida, es conocido también como gafo de flujo de datos o como diagrama de burbujas. Puede utilizarse para representar un sistema o software a cualquier nivel de abstracción. Pueden ser divididos en niveles que representen un mayor flujo de información y un mayor detalle funcional. Proporciona mecanismos para modelar la funcionalidad y para modelar el flujo de información. El objetivo fündamentai de este método es la descomposición de un problema complejo en otros más s e n d o y manejables, facilitando la modulandad y aprovechando la comunicabilidad que ofrecen los modelos gráficos pressman98].

2.2.3 IDEF0

El ' Lenguaje de Dehnición de Manufactura Asistido por computadora, parte O (IDEF0, . . , . .~ . ,. Integrated Computer . , . . Aided Manufacturing DEFinition Language, pard) Es una metodologia de diseño estxucturado para el modelado de proceso, que inclu$ 'iin procedimiento y un lenguaje para la construcción de decisiones, acciones y actividades de una organización o un sistema. Es una metodología de diseño estructurado para el modelado de proceso, que incluye un procedimiento y un lenguaje para la construcción de un modelo de decisiones, acciones y actividades de una organización o un sistema. Propone capturar la estructura del sistema funcional necesaria para comprender su operación. Es un lenguaje gráfico del cual el formalismo básico es una caja ICOM (Input, Control, Output, Mechanisms) representando la acción a ser realizada (etiquetada con un verbo) y sus entradas, controles, salidas y mecanismos (etiquetadas con frases de sustantivos) plUiz991.

12

cabíido 3 Modelo de De6endenia.r E3tratépica.r En este capítulo se describe la técnica a uálizar paca la especificación de

requisitos, I/ el modelo de dependencias estratégicas del Framework i*. II I

'II 11.

C+?Uh 3 M d h a2 Dpen&n& Eslrntégiuu

3.1 Framework i*

En los procesos de negocio existe un entendimiento que se encuentra oculto como suposiciones implícitas, estas suposiciones son casi siempre ignoradas debido a que se utilizan técnicas de modelado tradicionales. Los procesos de negocio incluyen varios participantes, los cuales tienen relaciones complejas entre ellos. Estas relaciones son consideradas como estratégicar en el sentido de que cada participante se interesa en sus oportunidades y de la vulnerabilidad que este tiene, además de que busca proteger sus intereses [yu96]. Tradicionalmente las técnicas de modelado análisis estructurado, diagramas de flujo de datos y los diagramas entidad relación- describen lo que un proceso de negocios hace, pero no expresan el porque de este proceso, - las motivaciones, intenciones y lo que se piensa al realizar las actividades- lo cual es una desventaja [yu96].

Por el contrario, los modelos intencionales retratan explícitamente tipos de libertades de diseño que cada unidad arquitectural tiene, como se ejercen estas libertades durante el diseño para reunir las demandas competitivas y como las libertades que esta choca con la libertad de otras unidades. Las alternativas de diseño pueden ser analizadas en términos de las libertades. La representación explícita de estas metas de diseño permitirán realizar un análisis de las relaciones que existan y de la exploración de alternativas.

El framework i*', fue desarrollado para modelar y rediseñar relaciones intencionales entre actores estratégicos y para ser utilizado en la fase temprana de la ingeniería de requerimientos. El concepto central es el de actor estratégico [yu97a]. En i* las organizaciones son vistas como consistentes de actores sociales los cuales tienen libertad de acción, pero dependen de otro para lograr sus metas, desarrollar tareas y para obtener sus recursos [yu97b].

El framework i* introduce al actor intencional como una abstracción de modelado en un nivel intencional. Los actores son intencionales en el sentido de que tienen metas, creencias, habilidades, compromisos, etc., y se encuentran relacionados con otros en términos de esas propiedades intencionales. Entre los actores existen dependencias debido a que tiene que relacionarse con otros actores para lograr sus metas, desarrollar sus tareas y obtener sus recursos. Sin embargo cada actor tiene la libertad de buscar lograr sus intereses de manera autónoma, considerando siempre las consecuencias que tendrán las decisiones que toma y de las acciones que realiza con las relaciones que este tiene con otros actores [yu95].

El framework i* fue desarrollado originalmente para modelat principalmente los problemas organizacionales humanos (por ejemplo, cuando surgen en el modelado de procesos de negocios o modelado de la empresa), sin embargo actualmente esta siendo extendido para modelar la arquitechira de sistemas técnicos. El nivel intencional de modelado ofrece un framework común adecuado para entender y analizar las relaciones existentes entre los problemas organizacionales humanos y los problemas de diseño técnico. Su enfoque consiste en analizar las implicaciones estratégicas desde el punto de vista de cada actor y permitir la exploración e identificación de procesos operacionales alternativos (soluciones) los cuales permitan lograr de una mejor forma los intereses estratégicos del actor [yu97a].

' i* se dice intencionalidad distribuida

14

La premisa principal de este framework es la obtención de un entendimiento profundo del proceso el cual puede obtenerse considerando una vista estratégica intencional y la unidad central a modelar es el actor estratégico. intencional. Un actor estratégico no solamente realiza actividades y produce entidades, sino que tiene motivaciones, intenciones y razones detrás de SUS

acciones. L o s aspectos intencionales de un actor pueden ser caracterizados por propiedades como son: metas, creencias, habilidad y compromisos. Un actor es considerado estratégico cuando este no solo se interesa en lograr sus metas inmediatas, sino que se interesa también acerca de las implicaciones de sus relaciones con otros actores (las oportunidades y la vulnerabilidad que están presentes en una configuración de relaciones). El proceso de repigenieria incluye la exploración de nuevas configuraciones de relaciones, y los actores se interesan en las implicaciones estratégicas de estas nuevas configuraciones. Una vista estratégica también implica que el framework permite un alto grado de no completes, de manera que los

. detalles no son pertinentes para la evaluación de procesos alternativos [yu95a].

El framework i* incluye dos modelos [yu94], [yu96]: el Modelo de Dependencias Estratégicas y el Modelo Racional Estratégico.

311.1 Modelo Racional Estratégico ’.

Este modelo representa una red de relaciones las cuales permiten conocer las razones que existen en los procesos de configuración, estas pueden ser descritas expliciiamente en términos de elementos de procesos y relaciones entre estos. Los principales tipos de relaciones son las ligas medio-fin y ligas de descomposición. Las hgas medio-& parecen ser aplicaciones de reglas genéricas en contextos particulares. Los elementos del proceso incluyen submetas, subtareas, recursos y metas suaves. El modelo es estratégico ya que los elementos son considerados importantes para afectar al logro de alguna meta. Los agentes pueden ser capaces de cumplir algo por ellos mismos o depender de otros agentes. Un conjunto interconectado de elementos de procesos que sirven para algún propósito del agente es llamado una rutina y un agente casi siempre tiene mas de una rutina para lograr algo. La reingeniería de procesos incluye modelar rutinas existentes (haciendo preguntas “por qué” y “como”) y descubriendo nuevas y mejores rutinas.

.I! Además de las consultas básicas acerca de los nodos y de las ligas, el modelo Racional o~frece cuatro niveles de análisis en un nivel mas agregado. Un actor tiene la habilidad de lograr qgo si este tiene una rutina para este (“saber como”). Uno puede también revisar si es posible trabajar una rutina, por ejemplo, si esta puede reducirse a elementos que puedan trabajarse, a través de ligas de descomposición de tarea o medios-fin, o de dependencias que puedan trabajarse. Finalmente puede revisat si las suposiciones incluidas en el razonamiento acerca de la rutina son creíbles, por ejemplo, si son lo suficientemente justificadas.

31.2 Modelo de Dependencias Estratégicas 111

” En este modelo los actores tienen propiedades intencionales comb son: meta, creencia, gabilidades y obligación; los actores dependen entre ellos con la finalidad de lograr sus objetivos y/o desarrollar sus tareas. Un proceso en el modelo de dependencias estratégicas cs visto como una red de relaciones de dependencia entre varios actores, esta red representa las motivaciones y

15

Modeh de Dependencias Estraie&cas

el “ por qué” de las actividades que se desarrollan [yu96]. Permite además expresar los requerimientos organizacionales y los no funcionales.

3.2.1 Elementos del modelo

El modelo de dependencia estratégica se compone de los siguientes elementos, figura 3 Iyu961:

Modelo de Dependencias Estratégicas

depender actor dependee objeto dependum

dependencia de meta

posición Tipo de actor

, Fig. 3 Elementos del Modelo de Dependencias Estratégicas I

Un actor puede ser un depender (quien depende) o un @endee (de quien se depende) El objeto alrededor del cual se centra la dependencia se le llama dependurn

Cada dependencia está compuestas por [yu95]: - - -

Una dirección de la dependencia, quien es el depender y quien es el dependee El tipo de la dependencia El objeto del dependum, de acuerdo con el tipo de dependencias y el tipo de dependum se distinguen tres categorías ontológicas: a) Entidades, para modelar los objetos en el mundo (físicos o de información) Lo cual

sena una dependencia de recurso. b) Actividades, producen cambios en el mundo. Lo cual sena una dependencia de tarea c) Aserciones, expresa estados y condiciones acerca del mundo. Lo cual sena una

El nivel de vulnerabilidad de la dependencia.

Se distinguen cuatro tipos de dependencias asociadas a la noción de requerimientos

dependencia de meta. -

funcionales y de requerimientos no funcionales pu941, pu961: ‘, a) Dependencia de meta.. es una intención. Un actor depende de ORO para llegar a una

condición deseada y no se preocupa de como el dependee provea el dependum. Con una dependencias de meta, el depender obtiene la habilidad para asumir que la condición o estado del mundo podtia lograr, pero se vuelve vulnerable ya que el dependee puede failar para llegar a alguna condición. El actor del cual se depende tiene la libertad de elegir como proveer la condición deseada. Es un reque&ento funcional.

16

Modeh de Dependen& E~-tr@i@m Capítulo 3

Cuando un paciente depende de un medico-para curarse de alguna enfermedad, el medico es

': apropiado modelarlo como una dependencia de meta. Cuando' un medico depende de la unidad de enfermería para mantener la presión del paciente, esto puede ser una dependencia

, de meta. La unidad de enfermería esta ejercitada para dar los tipos de inyecciones apropiadas para mantener la presión arterial normal. Dejar e¡ carro en un taller mecánico es decir "repararlo" es otro ejemplo de una dependencia de meta. En este tipo de dependencia el

decide como tratar al paciente. El paciente solo esta interesado en el resultado. Y es

ti. actor solo esta interesado en el resultado.

b) Dependencia de tarea, el actor informa'al otro que debe hacer y como hacerlo. Un actor depende de otro para realizar una actividad. Especifica una manera particular de hacer las

., cosas (o de lograr una meta), pero no el por qué. Es utilizada rigurosamente cuando un producto deseado no esta disponible o cuando un producto no tangible esta incluido. El depender es vulnerable ya que el dependee puede fallar para desarrollar la tarea. Es un requerimiento funcional.

Si el medico dice a su paciente que tome los medicamentos (por ejemplo cuatro veces al dia, dos horas después de los aiimentos), el medico depende en el paciente para desarrollar una tarea. Si el paciente no toma los medicamentos (de la fo&a especificada), la habilidad del medico para curar al paciente puede verse afectada. Un medico depende de un laboratorio para desarrollar una prueba clínica, el especificar las instrucciones modelarse como una

, dependencia de, tarea. Un ejemplo, podría ser el que un pasajero le diga al conductor que camino tomar (sin indicar el destino). Las especificaciones de tarea deben ser vistas como resuicciones en lugar de conocer como desarrollar la tarea. Esta es "a razón de por que un dependee puede fallar al desarrollar la tarea. Otra razón puede ser que el dependee decida no 1

1/11 desarrollar la tarea, siempre y cuando tenga la capacidad de hacerlo, por ejemplo, si este decide que existen cosas más importantes. que hacer (lo cual puede deberse a otros compromisos que este tenga).

/I c) Dependencia de recurso, un actor (el depender) depende de otro (el dependee) por la ,I! disponibilidad de una entidad (fisica o de información). Estableciendo esta dependencia, el

depender tiene la habilidad de usar -esta entidad como un recurso. Al mismo tiempo que el depender se vuelve vulnerable si la entidad no se encuentra disponible. El actor del cual se depende tiene la libertad.de elegir como proveer ese recurso. No existe ningún problema de decisión por lo cual este tipo de dependencia tiene una fuerza abierta. Es un requerimiento ,

. . . . , , . I' funcional. ' 1 1 4

Algunos ejemplos serían, la dependencia de un carpintero por la herramienta en una tienda, la dependencia de un conductor por la gasolina de una estación de gasolina. Una dependencia de recurso es diferente de la noción usual de un "flujo" en que este último no indica la presencia o ausencia de intencionalidad en el flujo. Un flujo de recurso no ' necesariamente implica &a dependencia de recurso. Por ejemplo, si a un cajero, no le afecta "' en nada contar con la información del crédito de un cliente, entonces la información es un 11. simple flujo, no una dependencia de recurso.

,

d) Dependencia de meta suave, es similar a la dependencia de meta, sin embargo 'el criterio de satisfacción no es claro, es decir la condición no esta deíinida al inicio del proceso. Es una caractedstica del producto. Es un requerimiento no funcional. Un depender depende en el

17

cqbf2u.6 3 M d . 6 úe Dptnáenakr Edraf&ica

dependee para desarrollar alguna tarea que reúna una meta suave. El significado de la meta suave esta especificado en términos de los métodos que son elegidos en el curso a seguir de la meta. Como en una dependencia de meta, un depender tiene la habilidad de tener la condición de meta, pero se vuelve vulnerable en caso de que el dependee falle para encontrarse en una condición determinada. La diferencia aquí es que las condiciones a ser logradas son elaboradas como se desarrolla una tarea.

Cuando una sección de enfermería requiere que las enfermeras de guardia respondan a los pacientes rápidamente, el significado de "rápidamente" no es claro. Un recién ílegado tiene que encontrar términos de clasificar los tipos de tareas que deben tomar prioridad.

El modelo distingue tres niveles de intensidad de dependencia - abierta, obligación y critica d e acuerdo a la vulnerabilidad [yu94], [yu96]:

ubierta. El no obtener el dependum puede afectar al dependiente, pero no afecta de manera seria al actor. Si parte de una rutina falla, una de las soluciones a esto sena el hacer cumplir el compromiso. Un depender debe tener el dependum, si falla al obtener el dependum se afectarían algunas metas pero no gravemente. Del lado del dependee, una dependencia abierta es una demanda por el dependee que es capaz de lograr el dependum por medio de algún otro depender.

obúgu&ín. El no obtener el dependum pude causar algún error en alguna acción que el dependiente ha planeado para lograr una meta. Una rutina completa puede fallar, una solución es garantizar el éxito. Debido a la vulnerabilidad un depender debe estar interesado acerca de la viabilidad de la dependencia. Del lado del dependee, ma dependencia comprometida significa que el dependee tratara de la mejor forma de liberar el dependum.

i

mlzca. El no obtener del dependum puede causar que todas las acciones fallen y que el dependiente no logre alguna meta. Todas las rutinas para un propósito fallan si el dependum no es logrado. En este caso, el depender debe estar interesado no solo acerca de la viabilidad de su dependencia inmediata, sino también acerca de la viabilidad de las dependencias del dependee

Un actor es una entidad activa que lleva a cabo acciones para lograr metas a través de su conocimiento. Los actores en contextos sociales realistas tienen muchas dependencias con otros actores, así como dependencias de otros actores. Un actor es deíinido en tres tipos de subunidades -agente, role y posición- cada una de las cuales es un actor en un sentido más espe+ado Iyu941.

a) Role, es un actor abstracto. Las dependencias son asociadas con un role cuando estas dependencias se aplican a pesar. de quien juega el role. Sus caractensticas son fácilmente transferibles a otros actores sociales. Las dependencias son asociadas con un role cuando estas hependencias se aplican sin hacer caso de quien juega el role. Los roles típicamente tienen dependencias' que se relacionan a la tarea o función que un agente puede asociar o desasociar.

. . C@'&lo 3 .~ Modelo de Dependencias E.rtrategi..r !I

b) Agente, ocupación, actor con manifestaciones físicas concretas, tal como un individuo humano. Un agente tiene dependencias. que aplican prescindiendo de que roles espera aplicar. El agente puede ser usado para referirse a humanos u objetos artifides pardware O

'11 software). El desarrollo .:medible, son caractensticas tipicas de un agente concreto. El ( respaldo de instrucción.; educación pertenecen a un agente, ya que ellos acompañan al b agente cuando este se mueve a otras posiciones,(ejemplo, el grado medico de doctor). Las

características del agente no son fáciles de transferir. a otros; ejemplo, sus habilidades y experiencia y sus limitaciones fisicas.

c) Posición, envoltura, abstracción intermedia entre un rol y un agente. Esto es un conjunto de role asignados juntamente a un agente. Un agente ocupa una posición y F a posición cubre un role. Los requerimientos de calificación (ejemplo, la posición de un jefe cirujano).

, I

' Las dependencias pueden @se a través de los roles que los agentes desempeñan y de las posiciones que estos ocupan.

3!2.2 Ventajas I!. j?

La selección de la .técnica de especificación se baso también en la característica de que esta permite hacer reingeniería, lo cual permitirá mejorar procesos en un futuro. El argumento central en la reingeniería de procesos de negocios es que si no se entiende "el por qué" las cosas se hacen de una manera determinada, se automatizara el proceso de una manera anticuada, p'krdiendo la oportunidad de innovar el proceso por el mismo. De esta forma la reingeniería de procesos debe pemiihr analizar las relaciones que existen en el proceso y argumentar acerca de las soluciones de las perspectivas estratégicas Iyu961.

'11 Resumiendo algunas I de las ventajas del modelo de dependencia estratégica son Iyu94, Yu96 1: ll - I Este tipo de análisis revela aspectos importantes del proceso que tradicionalmente los

'. modelos de proceso pueden perder. - Alienta a un entendimiento profundo de un proceso de negocio para enfocarse en las

dependencias intencionales entre los actores, mas allá del entendimiento usual basado en las actividades y en el flujo de entidades. Esto ayuda a identificar los intereses y los impactos si las dependencias failan.

- I 'Permite modelar las relaciones intencionales entre los actores y sus razones, lo cual ofrece un alto nivel de descripción de las arquitecturas distribuidas complejas. Permite entender las razones de tomar una decisión determinada

f

8 %

-

3.3 Campos de aplicación

3.3.1 Reingenieda de ptocesos de negocios

El modelado de procesos de negocios es considerado un paso esencial en la reingeniería de procesos de negocios. Los modelos de procesos son utilizados para describir procesos existentes, entender sus deficiencias y proponer nuevas configuraciones de los procesos. La reingeniería incluye el desarroilo de un buen entendimiento del proceso actual, la generación de

19

Cqbi?ldO 3 Mwklo de Dependen& Estraf&icm

nuevas alternativas y la evaluación de estas. De esta forma el uso especificamente del modelo de dependencia estratégicas, permitirá tener un entendimiento de los procesos actuales pu941.

En años recientes, la comunidad de negocios se ha concientizado más en que la tecnología de información no debe ser usada solamente para automatizar procesos de negocios existentes, sino también debe ser usada como base para dar forma nuevamente a esos procesos y reunir objetivos de negocio amplios. Muchos sistemas de información intentan mejorar la eficiencia organizacional de alguna forma. La reingeniería enfatiza la necesidad de examinar el contexto de negocios.

El concepto central de reingeniería es la necesidad de hacer preguntas "por qué". Ya que si no se tiene un entendimiento claro de las razones detrás de las estructuras y practicas existentes, uno no puede fácilmente decidir que cambios podrán ser realizados a los procesos de negocios. Descubrir las razones fundamentales de un proceso, permitirán identificar rápidamente practicas fuera de tiempo y reemplazar estas con tecnologías de sistemas de información y arreglos de trabajo que reflejen nuevas realidades. Es generalmente reconocido que la practica de la reingeniería es más un arte que una ciencia, y que los resultados casi siempre son impredecibles. Los tipos predominantes de modelos utilizados son variaciones similares de modelos de flujo de trabajo o actividades; un modelo rico que capture explícitamente motivaciones y razones debe proveer un framework mas sistemático para esfuerzos de reingeniería, con mejores i p s ai desarrollo del sistema.

Con el objetivo de entender los procesos actuales, el modelo de dependencias estratégicas asegura un entendimiento profundo de los procesos de negocios enfocándose en las dependencias intencionales entre los actores. El modelo de dependencias ayuda a identificar lo que es importante, para quien, y que impactos tendrá si la dependencia fallara. Facilita la identificación de los participantes e interesados, de esta manera determina el alcance apropiado para el esfuerzo de reingeniería. Esto permitirá tener un entendimiento adecuado para la búsqueda de nuevas e innovadoras alternativas para los procesos de negocios existentes, lo cual a su vez será reflejado en el rápido incremento, reducción de costos y la mejora de la calidad y servicio [Yu94].

3.3.2 Análisis de Sistemas

Puede ser utilizado para analizar las organizaciones y el impacto de los sistemas

el enfoque basado en conocimiento fundamental puede ser utilizado para orgdnizar y relacionar la gran cantidad de conocimiento que pueden encontrarse involucrada en el entendimiento organizacional. La esbhcturación del conocimiento servirá para proveer una estructura, de acuerdo a los diferentes niveles de granularidad que se tengan. permite mostrar las diferencias entre las relaciones de trabajo, a) antes de que el sistema sea introducido, b) en el ambiente de uso organizacional que se busca, y c) en el uso actual que surgió eventualmente.

computaaonales, considerando el enfoque como se menciona a continuación Iyu95aI: -

-

3.3.3 Ingeniería de Requisitos

En.la ingeniería de software es bien conocido que capturar los requerimientos que . verdaderamente reflejan las necesidades de los usuarios es crucial para el éxito en el desarrollo

. , . '

'

20

capitulo 3 Mode/~ dc Dependenciar E~-trat@a~ 1 I/

del sistema. Uno de los obstáculos mayores para obtener los requerimientos correctos es la dificultad de obtener un entendimiento profundo acerca del dominio de la aplicación. Las decisiones en el desarrollo de sistemas técnicos necesitan ser relacionados sistemáticm,ente a este entendimiento Iyu95aI.

Durante las etapas tempranas de la ingeniería de requerimientos casi siempre es necesario ayudar a los usuarios a identificar las diferentes formas en la cual las soluciones técnicas del sistema pueden servir a sus necesidades. Los modelos de requerimientos actuales describen un ambiente organizacional solo'en términos de entidades y actividades, no capturan muchos de los intereses que los usuarios tienen acerca de las impiicaciones de adoptar una solución contra otra. Un modelo rico del ambiente organizacional facilita el esfuerzo de los ingenieros en requerimientos; con las razones y las motivaciones explícitamente capturadas en un modelo de requerimientos, se podría fácilmente incluir un sistema que reúna los cambios necesarios, reduciendo el problema de los sistemas heredados. Contar con mejores requerimientos permitirá generar un mejor diseño de manera más rápida e implementar de una mejor manera el sistema de software Fu95aI.

3i3.4 Análisis de Impactos Organizacionales

El éxito de un sistema computacional depende en un mayor parte de muchos factores que están mas ailá del sistema técnico, pero que interactuan con el ambiente organizacional ckcunvccino (humano). Los interesados en un sistema de información puede tener un conjunto de restncciones acerca de un sistema de información y como este puede alterar el ambiente de trabajo, por ejemplo, la introducción de un nuevo sistema de información, puede haber cambios en los roles de trabajo y en los niveles de habilidades y oportunidades para avanzar: los trabajos pueden ser enriquecidos o sobrecargados, puede haber cambios en la fuerza de la estructura (cuando existe competencia por recursos, quien es mas probable que gane o pierda); puede haber incremento de presión social y disciplina, o de conflicto potencial, la libertad individual o privacidad puede ser reducida Fu95a].

Los modelos convencionales utilizados en el desarrollo de sistemas ban sido diseñados p,Mcipalmente para describir sistemas técnicos, y no proveen una descripción.suficiente de las organizaciones sociales humanas. Un modelo de procesos el cual tome en cuenta algunas de (i estos problemas organizacionales facilitara que se preste una mayor atención a estos problemas

durante los esfuerzos de desarrollo del sistema y podrá potencialmente permitirá re&= el análisis organizacional que mejor se integre en el proceso de desarrollo del sistema. 'I

21

.

r

CapítzkZo 4 Leagzkdje de EqenJZcacion Formal OASIS

En este capítulo se describe el lenguaje de especificación formal OASIS, así como los elementos principales que lo integran.

Capiiulo 4 ‘I l i

. . ., . . . . . . . 4.1 Descripción

La ingeniería de requisitos es un campo de reconocida importancia en el ámbito teórico y práctico de la ingeniería del software. Las mayores deficiencias en el proceso de desarrollo de software se encuentran en sus primeras fases. La distancia entre el espacio del problema @niverso de Discurso) y el ekpacio de la solución (producto de software) hace necesario que la especificación de requisitos del sistema, resultante del. proceso de modelado conceptual, tenga dos impokantes propiedades: debe ser abstracta y declarativa Ptelier981.

OASIS (Open and.Active Specification of Information Systems) es un enfoque formal para la especificación de modelos conceptuales siguiendo el paradigma orientado a objetos. OASIS da soporte a 00-Method la cual es una metodologia de producción de software que incluye todo el ciclo de vida de producción del software (análisis, diseño e implementación); esta metodología ha sido desarroliada en un entorno completamente orientado a objetos, tomando a OASIS como modelo de referencia Ptelier981.

4A.1 00-Method !I

00-Method es una metodologia de producción de software orientada a objetos. 00- Method cubre las fases de análisis, diseño e implementación de un sistema de información desde li perspectiva del paradigma de la programación automática, es decir, haciendo énfasis en la animación automática de la especificación, prototipación automática y generación parcial del pkoducto hal. Esta metodología se encuentra integrada por pastor97J:

a) Un modelo conceptual el cual define al sistema de forma precisa b) Un modelo de ejecución$l cual fija las características del producto final de software, de todas

las propiedades dependientes de implementación. . . . ,I;

’ El análisis genera tres modelos: el modelo Objeto, el modelo Dinámico y elmodelo Funcional, analizar estos modelos’ permite obtener una especificación formal O 0 y una especificación en OASIS de una forma automatizada. De acuerdo al modelo de ejecución, se constniye de forma automatizada un prototipo que es funcionalmente equivalente a la dSpecificación pastor971. N I1 !I.

La contribución máS’ interesante de este ambiente CASE’ es su habilidad para generar código en ambientes de desarrollo desde la especificación del sistema, recolectar la información, generar una especificación formal Orientada a Objetos del sistema y un prototipo completo de software. Esta metodología usa un lenguaje de especificación formal Orientada a Objetos (ÓASIS) como un almacén del cual se pueden obtener prototipos ejecutables de la aplicación y S k provee una herramienta CASE para prototipos rápidos [Pastor97].

ICASE se denomina a la ingeniería de soibare asistida por computadora. Una CASE p m i t e automatizar akividades manuales y de mejor& la visión general de la ingeniería [F’ressman98]

23

Cqitub 4 bngqqe úe Espej?aiÓn FomaJ OASIS

4.2 Características del Lenguaje OASIS . .

En OASIS un objeto es un proceso observable cuya vida está caracterizada por la ocurrencia de acciones. Un objeto puede actuar como cliente o como servidor, Una acción es una tupla formada por el cliente, el servidor y el servicio solicitado.

Los servicios que un objeto proporciona a nivel “atómico” se denominan eventos. Cada objeto tiene un evento de creación (que inicia su vida) y opcionalmente uno de destrucción. Los eventos pueden ser estructurados como procesos en un nivel “molecular”. Se cuenta además con una semántica para distingui~ entre procesos de obligación y procesos de prohibición. Un proceso de obligación es un servicio de mayor nivel ofreado por el objeto. Un caso particuiar de proceso de obligación es cuando se asume que el proceso actúa como “todo o nada” Un proceso de prohibición impide la ejecución de determinadas secuencias de acciones en la vida del objeto definiendo las secuencias que están permitidas Ptelier981.

En OASIS, un sistema de información es una sociedad de objetos autónomos y concurrentes que interactúan entre ellos mediante acciones. Cada objeto puede solicitar sólo los servicios que le son accesibles de otros objetos. Las interfaces son un mecanismo que permite establecer relaciones de accesibilidad entre objetos, defuiendo la visión que tiene cada objeto respecto de la sociedad de objetos ptelier98J.

Cada objeto encapsula su estado y las reglas que rigen su comportamiento, los objetos pueden ser vistos desde dos perspectivas distintas: estática y dinámica. Desde el punto de vista estático, iiamaremos atributos al conjunto de propiedades que describen estructuralmente al objeto. Los valores asociados a cada propiedad estructural del objeto caracterizan el estado del objeto en un instante dado. La evolución de los objetos (perspectiva dinámica) viene caracterizada por la noción de cambio de estado: la ocurrencia de una acción puede generar cambios (definidos por evaluaciones y derivaciones) en los valores de los atributos. La actividad de un objeto está determinada por un conjunto de reglas: precondiciones, restricciones de integridad, disparos, protocolos y operaciones. La vida de un objeto puede representarse como una secuencia de pasos; cada paso está formado por un conjunto de acciones que ocurren en un instante de la vida del objeto Petelier981.

. . Cada objeto tiene un identificador único (oid) proporcionado implícitamente por el

sistema. Sin embargo, el objeto es referenciado mediante mecanismos de identificación pertenecientes al espacio del problema. Una función de identificación establece correspondencia entre los mecanismos de identificación y el oid del objeto petelier981.

El tipo es la plantilla que describe la estructura y el ‘comportamiento de un objeto. Una clase se compone de un nombre de clase, una o más funciones de identificación y un tipo. Una clase compleja es aquella definida utilizando otras clases. Las relaciones entre clases disponibles en OASIS son agregación y herencia ptelier981.

4.3 Semántica de OASIS

La semántica de OASIS es dada en términos de una estructura de Kripke (JV, 7, p). W es el conjunto de todos los mundos posibles que un objeto puede alcanzar. Sea F el conjunto de Fórmulas bien formadas (Fbf) evaluadas sobre el estado (mundo asociado) en el cual se

24

1 I encuenqa el objeto, A el conjunto de acciones de la signatura del objeto y 2A, el conjunto de pasos pdsibles. Las funciones t y p se definen como:

t : F + 2W p:2A+(W+W)

fia función z asigna a una fórmula en la lógica de estado Gg ica de Predicados de Primer Orden) el conjunto de mundos en los cuales se satisface. La función p asigna a cada paso una relación binaria entte mundos, la cual es la semántica declarativa del lenguaje. Siendo p E un paso y M ~ , w' E W, el significado buscado es: (d) E p(p) si y sólo si la ocurrencia de p conduce al objeto desde el mundo w al mundo ur'.

1' I 'I

C l

1.

2.

3.

I OASIS esta basado en Lógica Deóntica, la lógica de las obiigaciones, prohibiciones y pe@.soS [Aqvist84]. Para describir las fórmulas consideraremos 0, 0' y y como Fbf en la lógica de Predicados de Primer Orden usada con aEA. Siendo A el conjunto de acciones con aEA. Lal interpretae de las diferentes fórmulas en Lógica Dinámica, usadas en la planalla de

I

e OASIS es la siguiente petelier981:

Fórmulas del tipo ty + [a]0; en particular [a]0, cuando ty es tme'(cualquier estado del objeto). Siendo w E ~(y ) el mundo actual, si a ocurre entonces el mundo alcakzado es Iv' E t(0). Así las evaluaciones 'establecen las propiedades que deben satisfacerse en el mundo alcanzado como efecto atómico de la ejecución de una acción.

Fórmulas de prohibición 10 + [a@h Siendo M' E ~ ( 0 ) el mundo actual, si a ocurre entonces no existe por definición una transición válida. Es decir, una fórmula de prohibición impide que una acción ocurra estando el objeto ésta en determinados estados.

I!

Fódulas de obligadón 0 + [layahe Siendo w E ~(0) el mundo actual, si la 1'acción a no ocurre entonces no existe por dehnición un mundo válido alcanzable. !Ill 1 :I¡

4.4 Especificación de clase !

Una especificación OASIS es un conjunto estructurado de definiciones de clase. Para una clase simple todas las propiedades quedan establecidas en su plantilla. Para una clase compleja, además de las propiedades establecidas por su plantilla, existirán propiedades adicionales deterninadas por las relaciones que la defuien Letelier98J.

. .

'1 a) I' ?Atributos I 4,

1 Son propiedades estructurales de las instandas de una dase y poseen un tipo asociado; existe tres tipos de atributos: constantes, variables y derivados. Para cada atributo definido exiktirán funciones y operaciones asociadas, disponibles para ser usadas en !a especificación de la plantilla y que son útiles para manipular atributos cuya cardinalidad es mayor que uno.

b) R e s t h o n e s de Integridad Son fórmulas basadas en el estado del objeto y que deben ser satisfechas cada vez que se

ejecuta $a acción independiente o cuando se ejecuta la acción que finaliza una transacción. Se pueden +siúcar en estáticas o dinámicas, dependiendo de si se refieren sólo a un estado o

I

25

relacionan diferentes estados, respectivamente. Para especificar restricciones de integridad dinámicamente se utilizan los operadores temporales tradicionales.

c) Eventos

un objeto. -

Es la abstracción de un cambio de estado atómico e instantáneo que le puede acontecer a

new y destroy son respectivamente eventos de creación y destrucción de instancias. Ambos eventos son Únicos para cada clase. El evento new tiene como parámetros los valores para los atributos constantes y variables del objeto.

Se distinguen también eventos privados, eventos implicados y eventos compartidos. Los primeros son servicios ofrecidos o requeridos por un objeto y cuya ocurrencia depende sólo del comportamiento del objeto en sí mismo. Los eventos implicados y los compartidos corresponden a servicios provistos por un objeto agregado, coordinados con servicios en sus objetos componentes.

-

d) Evaluaciones Son fórmulas en lógica dinámica que establecen como las acciones afectan el estado del

objeto. Los atributos variables modifican sus valores según lo establecido en las evaluaciones. Estas fórmulas dinámicas para evaluaciones son del tipo v -+ [a]0, y se interpretan como: “si en un determinado estado del objeto se satisface v y ocurre la acción a en el estado inmediatamente posterior del objeto, se satisface 0 ”. Es decir, la condición de evaluación se evalúa y se satisface en el estado en el que ocurre la acción y 0 se satisface en el instante inmediatamente posterior a la ocurrencia de a.

e) Precondiciones En algunas ocasiones no es suficiente la iniciativa de un cliente para que una acción

ocurra en el servidor sino que además ciertas condiciones deben ser satisfechas en dicho servidor. Si la precondición asociada a una acción a no se satisface en el servidor la acción a le acontece la acción l a (es decir, cualquier otra acción, incluso ninguna). En el contexto de lógica dinámica, las precondiciones tienen la forma 70 + [aJfiuLre, donde 0 es una Fbf interpretada como una condición para la ocurrencia de la acción indicada- el significado es “si 0 no se cumple, la ocurrencia de la acción no lleva al objeto a un siguiente estado”.

r) Disparos Un disparo modela la siguiente situación: si un objeto está en un estado que satisface una

condición de disparo entonces debe generarse la obligación asociada. Si el objeto en el cual se establece la obligación es precisamente el cliente de dicha acción, dicha acción ocurre como una solicitud de servicio desde dicho objeto. Si el objeto en el cual existe la obligación sólo es el servidor de dicha acción, deberá esperar hasta que el cliente de la acción solicite el servido de la acción. Para caracterizar la actividad de los disparos se utiliza la formula dinámica 0 -+ [iaJfiuLre, cuyo significado es: “si 0 se satisface y no se ejecuta la acción indicada, entonces el objeto no alcanza un estado válido. En otras palabras, si se cumple 0, la acción debe ocurrir para que el objeto alcance un estado siguiente”

26

g) Opemciones y Protocolos Existen tres semánticas posibles que pueden ser asociadas en la especificación de un

proceso en OASIS la semántica de¡ lenguaje utilizado para su especificación, la semántica de permisos, es decir, una especificación de proceso establece secuencias de acciones que pueakn ocurrir y la semántica de obligaciones, es decir, una especificación de proceso establece secuencias de acciones que akben ocurrir

11: h) Clases i complejas ES aquelia clase que utiliza en su definición otras clases (simples o complejas). Las

relaciones para la dehnición de clases complejas son agregación y herencia.

AgrLgación, modela la noción de relaciones estructurales entre objetos. Un caso particular cuando la agregación representa la noción parte-de. Una asociación (clase cuyas instancias son grupos de objetos) se representa mediante agregación multivaluada definida con un solo componente.

la herencia se puede especializar (o generalizar) propiedades definidas en las clases. Las particiones estáticas son utilizadas en aquellas especializaciones que son fijas des& la creación del objeto. Se utilizan particiones dinámicas para expresar que la partición a la q?e pertenezca el objeto no es fija y que dependen de la ocurrencia de acciones especificas o de los valores de los atributos en un determinado instante.

Intehces IEs una clase virtual,”esto es, una vista de una clase dehnida por una proyección de la

plantilla de una clase. Esta nueva plantilla establece las propiedades de los objetos de la clase oqnd (servidores) que pueden ser usadas por determinados objetos clientes. Así, una interfaz también establece una relación de acceso o visibilidad entre clientes y servidores. Las interfaces Permit& al diseñador proteger a una clase de usos no deseados, establecer visibilidad ajustada a las necesidades de cada objeto cliente, y establecer relaciones de acceso con el entorno del sistema

4.5 I , Metaclase

,Para formalizar la funcionalidad de las clases se introduce la noción de metaclase. La metaclase es una clase cuyas instancias’ son ,objetos “especiales” que a su vez son clases de objetoJ. Todos los objetos son instancias de alguna clase y las clases son a su vez instancias de la metaclase. De esta manera, las clases son objetos de primera categoría y pueden ser tratadas de la misma.manera que los objetos. Las instancias de la metaclase poseen una doble visión que puede ser obs’ervada en la figura 4:

- Por un lado, son clases de objetos en-las que se d e h e n las propiedades estructurales que comparten todas sus instancias (la plantilla), son la factoría y el almacén de sus instancias.

- Pol otro, son objetos c m un estado (representado por los atributos que poseen), y una duiámica (expresada por los eventos que son capaces de ofrecer al resto de la sociedad de objetos).

I

I

’ tambib llamados meta-objetos

27

C@'tUlO 4 hngffge dc Espeaica&n Formal OASIS

Lihc

(objao) PopUlati*&l. ... ) tmilQim

-%a:&

( S b C )

N e M d - h k ) Irrt-evs add-att-cl,

&_cr lut-amver li<,~eil~ofc

Fig. 4 Representación gráfica de la doble vision de una instancia de la metaclase.

En las clases está deíinida la plandla'de los objetos que comparten sus instancias. Por lo tanto, la metaclase, al tener como instancias las clases que recogen las características del modelo de objetos, refleja en su deíinición todas las características del modelo de objetos de OASIS. La metaclase recoge las características de ds clases complejas especializando el comportamiento de las clases elementales añadiendo propiedades y eventos y refinando los heredados.

4.6 OASIS como Lenguaje ,

En OASIS el modelo conceptual corresponde a un conjunto de elementos de especificación, incluyendo dominios, clases simples, clases complejas e interfaces.

4.6.1 Especificación

Para precisar la sintaxis del lenguaje, junto a la descripción de cada item se presentará la parte BNF asociada. La notación utilizada es:

a) Símbolos terminales - símbolo terminal o si se trata de caracteres entre

b) Símbolos no terminales - <símbolo no-terminal> - símbolos opcionales, entre 0 - símbolos alternativos, están separados por 1

Para exponer la sintaxis de un determinado elemento del lenguaje se usarán las siguientes simplificaciones: x es un elemento en particular, para describir un bloque de elementos x usaremos <bloquex>; para una lista de elementos x se usará <lista-x>. Los significados asociados a cada uno de eilos se establecen a continuación.

ebloque-x>, - ebloque-x> ex> I ex> <lista-x> . .. .- - <licta_x> ',' ex> I ex> ecec x> .. - e s x> <x> ';'I ex> 1;'

28

C&&h 4 I a2 EspenJkadn Formal OASIS

8 / 1 1 continuación se explican algunos.súnbolos no’terminales utilizados: - El n’o terminal <fórmula> hace referencia a’ una fórmula bien formada en lógica de

predicados de primer orden, basada en valores constantes, atributos y/o parhetros de acciohes i i

El do terminal <expresión> es una expresión booleana o aritmética basada en valores

El no terminal <valor> es un elemento de alguna especie de los dominios permitidos

- , constantes, atributos y10 parámetros de acciones.

- ,I !I’ 1. ,!*

El modelo conceptual de un sistema de información corresponden en OASIS con la especificación de un esquema conceptual. Sintaxis

conceptual schema <id-querna> [<bioque-def-dorninio>] [<bloque-def-dase>] [<bio4ue-def-dase-wrnpieja>]

’ <bloque-def-interfaz> end conceptual schema

11 i !I - <deí-querna-mnceptual> ..

1,. . ’ I

4j6.2 bipos de Datos ,

i

pon utilizados como dominios para los valores de variables y atributos, y constituyen el nivel de especiúcación de datos básicos sobre el cual se dehnirán las clases del sistema (simples y complejas). En OASIS hay varios tipos de’datos estándar predefinido: nat rnatural”), int (‘!entero”), real, boo4 char, string, date, time y blob (“binary large objects”)

4.6.3 IEspecificación de una clase

.Una clase en su dehnición consta de un nombre de clase y una plan&. La plan& de 1 . . . clase esla dividida en secciones o párrafos. Su sintaxis es la siguiente.

<dd-dase> .. - class cid-clase>

I : I

bu .i l

!!. , ~mecanismos-identificaaón> <atributm-wnstanteu [<atributos-variable] [<atributos-derivados>] [<derivaciones>] [crestrincciones-integridad>] <eventou [<operacioneu] [<disparou]

‘li [<evaluaciones>] [<precondiciones>] [<protocolos>] end class

I ’ -

A continuación se dan unas breves observaciones que deben considerarse en cada una de las secciones que componen la especificación de la clase:

- ’.

1k.J 1 Mecanismo ak Iaén#$cadn, deúne los mecanismos de identificación utilizados para referirse a los‘objetos. Un mecanismo de identificación es una función que establece correspondencias

‘I

entre valores de atributos de un objeto y su oid De esta forma, un mecanismo de identificación es una clave para hacer referencia a objetos en el espacio del problema. At~bwtos, el estado de los objetos se observa mediante los valores de sus atributos. Los atributos son propiedades estructurales de las instancias de una clase y poseen un tipo asociado. Se distinguen tres tipos de atributos: constantes, variables y derivados. ReJ-trcciones de Intep.&ad, como ya se menciono son fórmulas basadas en el estado del objeto y que deben ser satisfechas cada vez que se ejecuta una acción independiente o cuando se ejecuta la acción que haliza una transacción. Si al ser verificadas las restricciones de integridad alguna de d a s no se satisface, el siguiente estado del objeto es el último en el que se cumplieron las restricciones de integridad. Eventos, pueden distinguirse en: eventos privados, eventos implicados y eventos compartidos. Evdwmones, aquí; la condición de evaluación se evalúa y se satisface en el estado anterior al de ocurrencia de la acción y se satisface en el instante inmediatamente posterior a la ocurrencia de la acción. Prrmndinones, asegurara que si no se cumple algo, ocurrencia de la acción no ilevara al objeto a un siguiente estado. Dipams, los disparos por representar a una obligación, deben ser consistentes con los permisos definidos mediante precondiciones y protocolos. Operaionesy Pmtocoh, un proceso puede ser defuiido como una obligación, es decir, son secuencias de acciones que deben ocurrir; esto se especifica en la sección operations. Pero también puede ser definido como un permiso, es decir, son secuencias de acciones que pueden ocurrir; esto se especifica en la sección Intetfates son conjuntos de atributos observables y/o eventos que' el objeto ofrece a la sociedad.

4.6.4 Clase compleja

Una clase compleja utiliza en su definición otras clases (simples o complejas). Los operadores para construcción de clases complejas son agregación y herencia. Sintaxis

<def-dace-cornpleja> ::= <def-agregación> I <def herencia>

4.6.4.1 Agregación

Una agregación modela las relaciones estructurales entre objetos. Un caso particular es cuando la agregación representa la nociónpafte-aé. Una asociación (clase cuyas instancias son un grupo de objetos) se representa mediante una agregación multivaluada definida con un solo componente.

4.6.4.2 Herencia

Mediante la herencia podremos especializar o generaliza propiedades definidas en las clases. Son uíilizadas las particiones estáticas en aquellas especializaciones que son fijas desde la creación del objeto. Por otro lado, se defmen particiones dinámicas para expresar que la partición a la que pertenezca el objeto no es fija y que dependen de la ocurrencia de eventos específicos o de los valores de los atributos en un determinado instante. Se u&a también la

30

capituo 4 ! Lngude de EpajimCanón Fomai OASIS

dase rol niando un objeto pueda desempeñar temporalmente el comportamiento especificado en la clase de rol.

/I1 La especificación de una clase se hace separadamente de las relaciones de herencia

existentes. Con esto tanto las clases simples como las clases complejas tienen la misma plantilla de clase. Una clase será compleja si participa (como clase compleja) en alguna relación estableci,& entre dases utiiizando un operador de clases complejas. AsL la relación de especialipión .(o generalización) por herencia queda especificada independientemente de la plantilla 'de la clase.

4.6.5 Interfaces

1,

:Ir i !, Una interfaz es una vista de una clase dehida por una proyección de la plantiUa de una

&se. Ehta nueva plantilla establece las propiedades de los objetos de la clase original que pueden ser usadas por determinados objetos clientes. Sintaxis.

I <def-intetfaz> interface <ref-diente> with <refseNidOr>

[attributes '(' <atributos-ofrecidos ' )'>I end interface SeWiCeS '(' <seN¡C¡W-OfieC¡dW ' )'>

<ref-diente> <ref-objeto> <ref-diente> <ref-objetw <ainbutos-ofrecidos> ::= all I none I -4ista-id-atnbutow <servicios ofrecidos> ::= all I none I <lista-id servicio>

Algunas observaciones a considerar son las siguientes: - Cuando no se'define attributes se asume que no se ofrecen atributos, excepto en el caso

cuando <ref-servidor> es self, en el cual se asume que se ofrecen todos los atributos. -' Si $ara un cliente puede' aplicarse más de una interfaz respecto de un determinado objeto

servidor, prevalecen las definiciones de la interfaz más especitica (más cercana a los objetos cliente y servidor involucrados) Toda solicitud de servicio desde un cliente a un determinado servidor, especificada en una plantilla de clase, debe poderse deducir desde alguna definición de interfaz.

- i

4.6.6 ' Esttuctuta General Del Lenguaje

¡La estructura general que utiliza el Lenguaje de especificación formal OASIS es la slguienFe, en el siguiente capítulo se mencionara la parte de esta estructura utilizada para la especiíjcación del modelo de dependenck estratégicas. .

Conceptual schema

domain [ import 1

I' [var] functions equations

end domain

dass ~

¡I identification

Esquema conceptual

Deitnicibn del dominio Tipos abstrados previamente definidos Variables

Fórmulas bien formadas de lógica eaiacional

Especificaabn de la dase Funciones de identificaci6n del objeto

31

c+ít#h 4 Lenguqe rle Epajicakón Formal OASIS

constant attributec [variable attributes ] [ derived attributes ] I derivations 1

Atributos que no varlan Atributos que varían Atributos que se calculan en base a otros atnbutos Esoecificaaón de la definiúón de un atributo derivado i conctrains

events I valuations 1 [ preconditions 1

[ operations ] [ prdocols ]

i triggers 1

end dass

[<def-ciase-m ultiple>]

interface with [attributes] services

end interface

end conceptual schema

ReStridones de integridad Abstracción del cambio de estado atómico e instantáneo del objeto Fórmulas en lógica dinámica Condiciones para que una acción ocurra en el servidor Modela acciones del objeto según si e5 diente o senidor Especifica secuencias de acciones que deben ocurrir Especifica secuencias de acciones que pueden ocurrir (permitidas)

Especificación de la clase compleja

Da una vista de una dase definida. mediante una proyección de la plantilla de una dace

32

...

!' I

!

CaDitzilo 5 Metodoloxia de Desariollo En este capítulo, presentamos la metodología que se siguió para lograr la

represkntación del modelo de dependencias estratégicas en el lenguaje de especificación formal OASIS. La integración del modelo de dependencias al modelo de contexto y la herramienta construida para la generación automática de estos (modelo de dependencias y la integración de los modelos).

/I

i

Cqtdtulo 5 Metodología de Duanvh

5.1 Introducción,

El objetivo general de esta tesis hie el generar una especificación en OASIS del modelo de dependencias estratégicas, y la integración de esta especificación al modelo de contexto. A partir de los datos de la plantilla de entrada para la generación de la especificación del modelo de dependencias en OASIS y de los datos de entrada del modelo de contexto e integrarlos.

En este capítulo se presenta el formato de la plantilla de intenciones, así como la explicación de cada Uno de sus campos; se muestra también el contenido del archivo que se obtendrá al llenarla y de como se encuentra representada la información de las intenciones en esté. El llenado de la plantilla contendrá la información relacionada al proceso de negocios a modelar. No requiere que el usuario o analista conozca acerca del lenguaje de especificación OASIS, ya que la plantilla contendrá solamente palabras claves, las cuales serin traducidas a elementos del lenguaje OASIS.

Se presenta los elementos del lenguaje de especificación OASIS utilizados para' la representación del modelo de dependencias estratégicas, así como las reglas de transformación correspondientes para la generación a partir del archivo obtenido de la plantilla de intenciones el modelo de dependencias estratégicas. Se presenta también un esquema que muestra la correspondencia con el modelo conceptual y la especificación OASIS, en el se observan los distintos elementos de OASIS que son necesarios para la representación.

Finalmente se mostrara la representación del archivo que contiene la especificación integrada del modelo de contexto y del modelo de dependencias estratégicas. La f ipra 5, nos muestra el esquema de trabajo de forma más detallada.

una esiruchva

Representaa(in del Modelo de

Unlr mibas Dwendenaas especificaciones Estratesicas en

el lenguaje

I.

Reglas de Transformación

en Oasis de las

Inlormadim de las Intendones

obtmidas a

planülla de Intenclones

intencimer I

Fig. 5 Esquema de trabajo

34

Metohlogia de Desamllo Clpí7dO 5

5.2. PPmera Fase

L~ p-era parte del desarrollo de esta tesis consiste en la lectura de un archivo de texto, el cual conaene la información del modelo de contexto. Esta información es leída y colocada en una esmctura I de datos, para posteriormente integrarle intenciones. La figura 6 muestra 10 anterior. 1

1: I

'I

Contexto en'¡) una estnictura OASIS coniexio de Datos

Fig. 6 Análisis del modelo de contexto

'5.2.1. ! Modelo de Contexto (Modelo de flujo de Productos de Trabajo)

Un modelo de contexto se puede definir como: un proceso de negocio, en el cual existen actores que participan en el proceso y en donde cada actor realiza actividades que generan productos, los cuales serán ualizados por otro actor. Las relaciones entre actores se definen en t e r n o s de la entrega de prbductos. Un actor se relaciona con otro, en el sentido de que le entrega im producto o que recibe de él un producto.

,:I . t 11

El modelo de contexto es la representación básica de un proceso de negocios, a partir de aqd ini@mos la producción del modelo de dependencias estratégicas. De acuerdo a la dehnición una actividad, es b paso del proceso, el c d puede tener resultados intermedios llamados productos (o artefactos). Los artefactos, es el resultado de la actividad que realiza el actor, es el objeto de la relación entre dos objetos, y un actor, son los recursos humanos que intervienen en el proceso de negocio, estos pueden aparecer de forma individual o como p p o .

5.2.1.1 I Descripción del modelo x

'.

Básicamente este modelo muestra a los distintos actores que participan en el proceso y lo's productos de trabajo que fluyen de un actor a otro implicando una relación entre ellos como se'muesfra I( en la @a 7. 4

I El significado de cada elemento es el siguiente:

un circulo es un actor, el cual puede ser una persona, un puesto, un grupo de trabajo o un departamento. el rectángulo es un artefacto el cual representa a un producto de trabajo, que fluye de un act& a otro, y una flecha, que es el flujo del artefacto, indica la dirección de un artefacto al ser enviado de un actor a otro.

I

I

35

Capituh 5 MetodohgÍa de Desamih

Fig. 7 Modelo de Contexto

El Modelo de Contexto nos dice que características tiene un proceso, es decir que tareas se realizan y que recursos (artefactos) fluyen en él, permitiendo detectar las relaciones entre actores. Este modelo nos da pauta inicial para producir el modelo de dependencias estratégicas, ya que este no expresa el “por qué” de las cosas, es decir, las motivaciones e intenciones que hay detrás de cada actor. A este modelo de contexto se le agregara información, es decit, elementos que expresen las dependencias entre actores. Esta información adicional proporciona más elementos de juicio para poder sugerir mejoras al proceso de negocio.

5.2.1.2 Interpretación del Modelo de Contexto (parser)

El modelo de contexto se encuentra almacenado en un archivo de tLxto, el cual al ser leído, la información contenida en este será almacenada en una estructura de datos.

El analizador tiene como función principal tomar secuencias de caracteres o símbolos del alfabeto del lenguaje y ubicarlas dentro de categoría [Ah088, Fischer881. La descipción de cada elemento reconocido por el parser del modelo de contexto se presenta por la BNF asociada [Ah088, Fischer88]. La notación utilizada es la siguiente:

símbolos alternativos, están separados por 1 , , . .

símbolo no terminal <> símbolo terminal o si se trata de caracteres, entre

Esta constituida por los siguientes elementos: . Vocabulario terminal finito Vt = { conceptual, schema, class, identification, string, int, variable, constant, attributes, Boolean, false, events, valuations, true, preconditions, if, end, interface, someone, with, services, new, destroy, all} Vocabulario no terminal finito Vn = {<id>, <idesquema>, <idclase>, <id-atributo>, <idevento >, <id-asignación>, <id-vdor>, <tipoatributo>, <id-acción>, <id-valuation>, <def-clase>,

36

I

Metodologio de Desarrollo capítulo 5

'il<defj.d . . #I entificatión>, <def:atributoconstante>, <def-ambuto-v&able>, <def-eventos>,

<defLvaluation>, <def-precon&tion>, <def-interfaces> } - Un símbolo de inicio S eVn

S = <def-esquema> - Conjkto finito de producciones

Nombre'del Proceso El hombre del proceso es'identificado como el esquema conceptual que sé esta modelando.

Clase La clase, es udizada para identificar las clases que integran la especificación. Las clases se - .

reconocen como actores (entidades) y como artefactos. La sintaxis aceptada es la siguiente ya sea pira un actor o un artefacto:

<defclase> ::= clase <id-clase> <def_identificacibn> <def-atributoconstantes> <defatributo-variable> <def-eventos> ' <def-valuations> <defqreconditions>

, Identificación Tiene bomo Características .le1 establecer la identidad del objeto, es independiente de la lo&alka&ón fisica del objeto, provee una completa independencia de locaiización y es independiente de las propiedades del objeto. Cada atributo que define el mecanismo de identificación es un atributo constante. La sintaxis reconocida es la siguiente:

<def_identificaci6n> ::= identification I: ' ' ' I ' <id-atributo> I <id-atributo> I , ' <id-atributo> ' I ' ';'

Atributos Constantes Son udizados para mantener algún valor determinado para la clase (actor), en este caso, el valor por el Cual se le identificara al actor. La sintaxis reconocida es la siguiente:

! <defatributo-constantes> ::=

conatant attributes <id-atributo> ' : I <tipo_atributo> s:' I <ibatributo> I : ' <tipo-atributo> I ' <id-valor>')' I ; '

Atributos Variables Son aquellos cuyo valor pueden cambiar cuando ocurre una acción relevante. Utiliza la misma sintaxden los atributos constantes, pero son agrupados en secciones distintas.

caef-atributovariable, ::- constant attribute- <id-atributo> ':' <tipo-atributo> I;'

I I <idatributo> ':' <tipo-atributo> ' I ' <id-valor>Il' 'i'

Eventos /I

Un evento es una abstracción de un cambio de estado atómico e instantáneo que le puede acontecer en un objeto. La sintaxis reconocida es la siguiente:

37

Cqz'tuh 5 Metodohgía de Desanuh

<def-eventos> ::= events <id-evento> ' ; <

I <id-evento> ' i ' <id-atributo> I : ' <id-asignación> x ; ,

I <id-evento> <id-acción> 1;

Evaluaciones Son formulas que establecen la forma en que las acciones afec. el estado del objeto. Los atributos vaiables modifican sus valores según lo establecido en las evaluaciones. La evaluación se aplica en cualquier estado del objeto. La sintaxis reconocida es la siguiente:

<def-vaiuationc> ::= nluat ions ' I ' <id-valuation> ' I ' <id-atributo> I : = ' <id_asignación> ';,

1 ' 1 ' <id-valuation> - 1 ' <id-atributo> . : = I <id-asignación> I , ,

I'['<id-vaiuation>'l'<id-atributo>~l' ~I'<id_at~ib~to>':='<id_asignaci6n> <id_atributo> ':=' <id-asignación> 'i'

. , . ',' <id-atributa> ':=' <id-asiqnación> -;'

Precondiciones Son utilizadas cuando ciertas condiciones deben ser satisfechas en el servidor. Es una formula, la cual se interpreta como una condición para la ocurrencia de la acción indicada. La sintaxis reconocida es la siguiente:

<def-preconditions> ::= preconditions <id-evento> 'if (' <id-atributo> *=' <id-asignaciún> ';'

~<id~evento>'['Cid_asiqnación>'i"ifI'<id-atributo>'='<id-asignación>';'

Interfaces Las interfaces es la vista de una clase (actor o artefacto) definida por una proyección de la plantilla de una clase. Establece una relación de acceso o visibilidad entre clientes y servidores. La sintaxis reconocida es la siguiente:

<def_interfaces> ::= interface <id-clase> (someone)

W i t h <id-clase> (somane) attributes ( a l l ] ' services , I r <id-atributo> I <id-atributo> ',' <id-atributo>" - 1 ,

end interface

<id-asignación > ::= true I false <id acción > ::= new 1 destroy <id schema> ;:= <id> <idzclase> : := <id> <id-atributo> ::= <id> <tipo_atributo> ::- <id> <id valor> ::= <id> <id evento> ::= <id> <idvaluation> : := <id> <id> ::= A . . Z I a . . z { A..Z I a..Z 1

-

-

5.3. Segunda Fase

La segunda fase o parte del desarrollo de esta tesis consiste en la lectura de un archivo de texto que contiene la infotmación arrojada después del llenado de la plantilla de intenciones. A la información de este archivo se le aplicaran ciertas reglas de transformación para la generación del modelo de dependencias estratéscas, como se muestra en la figura 8.

38

I

Mefoablo@~ de Desamlh CIpa,t#lO 5

liJ i

7 Fig. 8 Generación del Modelo de Dependencias Estratégicas

Plantilla de Intenciones

Para capturar la información de las intenciones se tuvo la necesidad de contar con una planda, a la cual llamamos Plantilla de Intenciones. De esta plantilla tomamos la información para representar las intenciones del modelo de dependencias estratégicas. Cabe mencionar que a n p a r la forma correcta de 'como se obtendrán los datos hacia la plantilla para el modelo, no corresponde al alcance de este trabajo. Los elementos que componen a esta planda son los mostrados en la figura 9; los datos que se obtengan a través de esta planda se encontrarán hacenados en un archivo de tipo texto. Para el llenado de esta plantilla, deberán ser identificados los actores que participan en el proceso de negocio y las características de cada una de las relaciones que existen entre ellos.

il 'I' /I I

Como se mencionó ,,en el capítulo 3, el modelo de dependencias estratégicas está consim'do principalmente por actores estratégicos, para lo cual la definición de la plantilla se consideraron los aspectos de inteligencia que son fundamento de éstos. Todo actor o agente en inteligencia artificial tiene un núcleo de componentes fundamentales: un estado I que proporciona la información del agente acerca del mundo, el estado estratégico S que proporciona la'linfonkación del control del agente que guía sus acciones, y el estado de evaluación V que guía las evaluaciones del agente y guía su razonamiento [O'Hare96]. Un agente tiene habilidades que pueden definirse en términos de la existencia estratégica de vanos contextos de estado. La existencia de estrategia, es decir, lo que un actor o grupo puede hacer o intentar, depende en la disponibilidad del estado de la información. De tal manera que la comunicación de la inform&jn de estado tiene; una función fundamental en la acción individual y social. Las dtenciones de un actor en su información de estado tienen vanas funciones. Primero, la información estratégica puede crear habilidades reales de las habilidades lógicas posibles a través de obtenerla o simplemente hacer que los actores conozcan su existencia. Segundo, 'una información de estrategia crea nueva habilidades coordinadas ya que un actor puede utilizar esta inform@n acerca de otros actores para planear sus acciones. Tercero, crea habilidades cooperativas. La comunicación de la información estratégica es una función fundamental en la Gformación de estados intencionales coordinados entre agentes, y por lo tanto forma las bases de cooperación [O'Hare96].

I

I

39

Cqilulo 5

Pacte A

Metodologia de D e ~ a m h

NomEsquema Contiene el nombre del proceso de negocio del cual se trata.

Pacte C

Pacte B Nombre del actor del cual se trata la descripción Determina que tipo de actor se trata, si es un agente, un role o una posición.

Descripción Permite conocer que se quiere realizar con esta relación Razón Permite conocer el por qué de tal elación

Dependencia Permite conocer de quien se depende paca lograr esto Fuerza Permite conocer la importancia de esta relación, el grado de íuerza Afecta Permite conocer a que actor afectara el cumplimiento o no de esta reiación

40

Cq!tWb 5 I

A partir de esta sección, como se muestra en la plantilla, se procederá a describir a los diferentes actores que intervienen en el, proceso de negocio mencionado. Cada una de las siguientes secciones describirá las características del actor con sus correspondientes relaciones (dependencias).

Metodología de Desando

Actor ./I , i I

En esta sección se debe colocar el nombre del actor que se va a modelar y el cual interviene en este proceso. Un actor puede ser pn humano (comúnmente), un sistema de computadora, una organización diferente a la act&, o cualquier cosa o entidad que interactue con el product,o. Un proceso de negocio tiene al m'enos dos actores. El nombre del actor debe estar compuesto por un' conjunto de letras cuya longitud no debe exceder 20 caracteres alfabéticos, y no debe contener espacios en blanco, números o caracteres especiaies. Ejemplo: TaiierMecanico.

I

En esta 'sección se indica el tipo del actor del cual sé esta haciendo la descripción. El tipo del actor solo puede ser uno de los cuatro siguientes: un agente, un role, una posición o un actor. Debe sei. un conjunto de letras cuya longitud no debe exceder 8 caracteres aifabéticos, y no contiend espacios en blanco, números o caracteres espeuales.

A partir de esta sección, como se muestra en la plantilla, se procederá a describir las diferentes relaciones (dependencias) que existen de este actor con otros actores. Cada una de las siguientes sekciones describirá una caractenstica de la relación a modelar.

I1

Esta se<ción de la plantilla describe alguna de las razones que tiene el actor para relacionarse con ob0 y fue determinada ya que en la inteligencia artificial las acciones que tiene un actor deben ser coordinadas debido a que [O'Hare96]: - Existen dependencias entre las acciones de los agentes; de estas dependencias surgen las

$ interdependencias que ocurren cuando las metas que se buscan lograr por el actor tienen un /I imphcto sobre las decisiones de otros miembros dentro del proceso, por ejemplo, cuando se

construye una casa, las decisiones acerca del tamaños y del lugar de las recamaras impactan en la plomería. Se qu ie ren conjuntar las restricciones globales, ya que estas existen cuando la solución ha sido desarrollada por un &up0 de actores, cumpliendo con ciertas condiciones y evaluándola como un éxito. Muchos de los problemas de los actores no pueden resolverse de manera individual debido a

./

- I I

'

- no poseen alguna experiencia, recurso o información especial.

dependencias existen debido a que se tiene alguna necesidad, algún deseo o alguna intención. Por tal motivo se tuvo que seleccionar un conjunto de palabras, las cuales nos permitirán identificar el motivo de una relación (tipo de dependencia) con otro actor. Las relaciones pueden ser: una ,dependencias de meta, de recurso, de tarea o de meta suave. A k i o i h a esto, esta sección nos permitirá conocer si se trata un requerimiento funcional o de Uno no !funcional.

41

Metodo&u de Desunuh

Meta. Es necesario recordar que una meta es una intención que se tiene para lograr algo, es decir, el objetivo a lograr. Las palabras seleccionadas para determinar si es m a dependencia de tipo meta son las siguientes:

a) objetivo b) lograr c) intentar.

Algunas preguntas que nos ayudaran a determinar si el motivo que se tiene en esta relación cumple con una dependencia de tipo meta son las siguientes: ?Qué es lo que se quiere lograr?, ?Se trata de un objetivo?, ?Se tiene alguna intención?

Recum. Una dependencia de recurso, se distingue por la necesidad que se tiene de contar con algo, ya sea de algún articulo o de alguna información. Las palabras seleccionadas para determinar si es una dependencia de tipo recurso son las siguientes:

a) recurso c) articulo b) necesita d) información. I

Algunas preguntas que nos ayudaran a determinar las palabras a utilizar serán las siguientes: ?Sé requiere contar con alguna información?, ?Sé requiere de alguna herramienta para poder realizar algo?

Tum. Es una acción o actividad que se requiere para poder lograr una meta u objetivo. El conjunto de palabras que nos permitirán determinar si se trata de una dependencia de tipo tarea son las siguientes:

a) acción b) modificar c) desarrollar.

Una pregunta que nos ayudará a determinar si el tipo de dependencia es un tipo tarea, son las siguientes: ,?El actor conoce la forma en que se logra algún elemento intencional (como una meta), pero sin necesariamente ser capaz de realizar esta por el mismo?

.Meta suum. Una meta suave nos indica un deseo sobre algo, es decir nos indica un requerimiento no funcional, por lo tanto este tipo de dependencia debe indicar alguna característica o cualidad especial que se desea tener. Algunas palabras que nos permitirán expresar este tipo de dependencia son:

a) desea b) característica

-c) cualidad. Una preginta que nos ayudará a determinar si las palabras de esta parte son las indicadas, son las siguientes: <Qué cualidad o característica sena agradable para lograr la meta u objetivo que se tiene con esta relación?

Razón

En esta sección se busca explicar en pocas palabras "la razón o el por qué" que existe detrás de esta relación (dependencia). Esta sección dice por qué la relación es importante y de que manera contribuye al propósito que se tiene. Añadir la razón permitirá entender esta dependencia. Debe ser un conjunto de conjunto de letrm cuya longitud no debe exceder 30 caracteres alfabéticos y

' I 2

cqbítu~o 5 ,

no debe contener espacios en blanco, números o caracteres e spedes por ejemplo: MaximizarPagoDeReparaciÓn.

Metodología dc Desawdo

ir '1 1

JI

se escribe el nombre del actor con el cual se encuentra relacionado para el logro de algo. Debe ser un conjunto de letras cuya longitud no debe exceder 20 caracteres alfabéücos y no debe contener espacios en blanco, números o caracteres especiales por ejemplo: ~ a ~ ~ ~ ~ ~ C a n i c 0 .

Las interaependencias pueden, ser clasificadas en dos dimensiones oaogonales: débiles o fuertes. Las dependencias fuertes son satisfechas cuando la dependencia de meta es exitosa y las dependencias débiles son aquellas que facilitan o restringen la solución de problemas pero no requieren ser cumplidas de manera obligatoria para que la dependencia de meta se cumpla [O'Hare96]. Esta sección de la plantilla se encuentra relacionada con el concepto de creencia en in$ellgenh artificial. Aquí debk indicarse cual será la intensidad con la que será afectado un actor de la relación en caso de que se cumpla o no la dependencia. Las palabras aceptadas en esta sección son: a) abierta

i c) critica b) comprometida

Afecta

En esta .sección se indica a quien afectara esta relación si esta no se cumple. La información cqntenida en esta sección seiuálizara en conjunto con la información obtenida en el campo fukrza. Esta sección debe contener el nombre del actor que se está describiendo, o el nombre del actor con el cual sé esta relacionado; es decir uno de los dos nombres que aparecen en el campo ACtor o en el dependencia. Es un conjunto de letras cuya longitud no debe exceder 20 caracteres alfabéticss y no debe contener espacios en blanco, números o caracteres especiales por ejemplo: TherMkcanico. I1

5.3.3. Descripción del Formato del Archivo de Intenciones i El formato del archivb que contiene las intenciones es un archivo de texto, el cual debe

ser llenado como se indico en la sección 5.1.1. figura 9. El nombre del archivo generado debe tener la extensión .inten

' El análisis del archivo se realiza considerando los identificadores, es decir, las palabras o frases uhzadas por el usuario. El patrón para un identificador en el archivo de la plantilla de intenciones es una letra seguida de letras que no exceda de 32 caracteres. La gramática reconocida por el parser para h lectura de la información del archivo de la plantilla de intenciones se presenta por la BNF asociada [AhoSS, FischerSS]. La notación utilizada es la niencionada anteriormente. 1)

Esta constituida por 10s siguientes elementos: - Vocabulario terminal f i t 0

43

Cl@&h 5 Metodohgia de D e s m h

Formato del Archivo

Vt = { NomEsquema, actor, tipo, descripción, razón, dependencia, fuerza, afecta, actor, rol, posición. agente 1

Descripción del Archivo

. Y

Vocabulario no terminal fmito Vn = {<def_proceso>, <def-actor>, <def-dependencia>, <idnombre-proceso>, <id-actor>, <id-tipo>, <id-descripción>, <id-razón>, <idbependencia>, <id fuerza>, <id-afecta>; <id>} Un símbolo de inicio S EVn S = <dcf-proceso> Conjunto finito de producciones

-

_1

descripción Lograr razón CarroSeaReparado dependencia TallerMecanico fuerza Abierta afecta PropietarioDelCarro

<def-actor> ::= actor <id-actor> tipo <id-tipo>

I <def-dependencia> 1 . .

<def-dependencia> : := descripción <id-descripción> razón <id r a z ó n > dependencia <id-dependencia> fuerza <id_fuerza> afecta <id-afecta>

<idnombreproceso> ::= <id> <id_actor> . _- <id> <id-tipo> <id-descripción> _ _ <id> <id_rarón> <id> <id-dependencia> . _- <id>

<id-afecta> <id> <id> ::= A..Z I a . . z I A..Z I a . . ~ 1

. .- : := actor I rol I posición 1 agente . .= . .- . .-

<id-fuerza> . . ._ .- abierta I comprometida I crit ica . .-

Quiere lograr algo Ese algo es la reparación de su carro Quien reparara su carro serb el Taller Mecánico Esta relación no afecta demasiado al propietario del carro

NomEsquema ProcesoDeReclamo El nombre del proceso de negocio que se esta modelando es Proceso de Reclamo.

actor tipo

descripción razón dependencia fuerza afecta

descripción r a z ó n dependencia fuería afecta

actor tipo

TallerMecanicO Actor

Necesita PagoPorReparacionas PropietarioDelCarrO Abierta TallerMecanico

Desea RepetirNegocio PropietarioDelCarro Abierta TallerMecanico

PrapietarioDelCarro ACtDr

Nombre de uno de los actores y del cual se describen sus caracieristicas, El tipo que en este caso es de tipo genérico.

Se necesita de algo para algún logro Indica el porque de la existencia de esa relación El actor TalierMecanico se relaciona con el aitor Propietario Del Cam> La relación es abierta. es decir, no es demasiado importante SI esta relación no se cumple el aitor Taller MecanlCO serb afectado

Se desea lograr algo. La relación existe porque se quiere Repetir el Negocio El TallerMecanico se relaciona también con el actor PropietarioDelCarro No es demasiado importante esta relación Quien se vera afectado sin no existe es el actor Taller Mecánico

Mro de los actores en el proceso de reclamo es el Propietario del Carro Es un actor genérico

.I

’

44

whllo 5 Metodología de Desanvllo

La figura 10 solo nos muestra una parte del código recibido en el archivo que contiene las intenciones. Este archivo es leído y se obtiene una relación de todas las entidades manejadas en el proceso. Estas entidades son guardadas en una estructura de datos en Java, y postenoTente serán traducidos a una especificación en el lenguaje OASIS, la cual permitirá representar el modelo de dependencias. Mientras se realiza la relación de las entidades manejadas, se determina que clases serán manejadas para actores y que clases se generaran para representar las dependencias.

I

5.4. definición de los elementos utilizados del lenguaje OASIS

En el modelo de dependencias no es relevante saber en que momento una dependencia es cumphda o las regias de negocio se encuentran en este proceso. Este modelo simplemente denota como se relacionan los actores y las causas o razones por la cual estos se relacionan. Por esta razón, los elementos del lenguaje utilizados se concretan simplemente a los necesarios para representar las relaciones de los actores, y las características de cada una de estas relaciones.

! Ea estructura del lenguaje de especificación OASIS utilizada para la representación del

modelo de dependencias estratégicas es la siguiente:

Conceptual schema Esquema conceptual I

Class Identification Constant attributes [ variable attributes ]

’ events ‘1 [valuations]

I preconditions ] end dass

I interfay with [ attributes 1 services

end interface

Especificación de la dase Funciones de identificación del objeto Atributos que no varían Atributos que varlan

Abstracción del cambio de estado atómim e instantáneo del objeto Fórmulas en lógica dinámica Especifica secuencias de acciones que pueden ocurrir (permitidas)

Da una vista de una dase definida. mediante una proyección de la Dlantilla de una clase

I end mnuiptuai schema

A continuación se explicará el uso de los elementos utilizados para representar el modelo de dependencias estratégicas. Los elementos que integran el modelo de dependencias a representar en el lenguaje OASIS son: actores y dependencias.

La clase actor, esta deíine las características básicas de los actores que participan en el proceso de negocio. La clase dependencia, define las características básicas de las dependencias que tienen

’. I

l o s a E s a conceptual

La especificación en OASIS de “Conceptual schema” es utilizada para establecer el nombre del proceso de negocios que sé esta modelando es considerado como el esquema conceptual de la especificaúón que sé esta generando, ya que indicará que la especificación ahí contenida pertenece a un proceso de negocios determinado. ‘I

45

Cq.hh 5 Metodohgia de Desamh

clase La palabra “Class” en OASIS permitira especificar en ella las características de un actor o de una dependencia. Actor. se deh i rá una clase para cada actor. El nombre de la clase será el nombre del actor. Dependen&. se definirá una clase para cada dependencia. El nombre de la cl&e será el nombre de la dependencia.

Identificación La palabra “Identification” en OASIS permite identificar aspectos tanto para los actores como para las dependencias. Actor. El tipo de actor que sé este modelando, será especificado a través de la identificación de objetos. Esto permitirá conocer si esa clase (actor) es un agente, un role o una posición. La representación seria así: Actor Pro i> ie ta r ioCar ro

Tipo agente

La generación de la especificación en OASIS es la siguiente: I d e n t i f i c a t i o n

agente : ¡nombre);

Depenáemia será también utilizada durante la especificación de la dependencia (caractm’sticas de esta) para decir si la dependencia es de meta, tarea, recurso o meta-suave.

Atributos Constantes Se utiliza la especificación de “Constant attributes” en la clases actor y dependencia. Actor. Los atributos de identificación se definen también como atributos constantes ya que no cambiaran durante la vida del objeto, son utilizados para mantener el nombre del actor que sé este modelando. Dependefiiu. Los atributos de identificación se definen también como atributos constantes, son utilizados para mantener el tipo de dependencia que sé este modelando.

Atributos Variables Se utiliza laespecificación de “Variable attributes” en la clases actor y dependencia. Actor. Las diversas dependencias que este actor tenga por “algo”, serán especificadas en la sección de atributos variables, se representan las dependencias que este tiene por medio de agregar una B al inicio de estas por ejemplo: El actor tiene una dependencia por el pago de las reparaciones, la declaración del atributo variable seria: BpagoPorReparaciones

Dependen& Son utilizados para representar en esta quien es el actor dependee y quien el depender. Es decir, quien depende de esta clase y quien la puede proveer, la declaración del atributo variable seria: Depender-<quien s a t i s f a c e esta dependencia>

d e p e n d e r T a l l e r M e c a n i c o

Los valores de los atributos variables se& modificados en por medio de los eventos, evaluaciones y precondiciones.

Eventos Se utiiiza la especificación de “Events” en la clases actor y dependencia. Actor. son utilizados para representar’en-la clase de tipo actor, por qué” o “qué” requiere <‘ relacionarse con otro, por ejemplo: S o l i c i t a < q u e s o l i c i t a el a c t o r >

Soiici tapagoPorReparaciones

Dependencia en las clases dependencia, los eventos son utilizados para decir a quien sirve está, se le agrega la palabra remitir por ejemplo: remitir<Nombre del p r o p i e t a r i o a q u i e n S i r v e i

remi t i rPropie ta r ioDelCarro

46

i

I C ~ ~ U i D s Metoáohgiú de Desamilo

I

Evaluaciones v Drecondiciones Se &aliza ia espeiificación de <¿Valuations y preconditions” en la clases actor y dependencia son ualizas para,cambiar el estado de los valores de los atributos variables. Sin embargo, esto no es de utilibd para la representación del modelo de dependencias, pero sí para la especificación correcta y completa dentro del lenguaje de especificación OASIS.

Interface Se ,,utiliza¡ la especificación de “Interface” para representar la comunicación o relación que existirá entre las clases, es de&, que clase act& se relaciona con determinada clase dependencia, y esta clase dependencia es provista por una clase actor:

I

Es necesario mencionar que no todos ios elementos de OASIS fueron utilizados para la representación del modelo de dependencias. Como se ha venido comentando el modelo de dependencias estratégicas tiene como objetivo el representar aspectos estáticos de un proceso de negocio. IMientras que el lengtaje OASIS permite especificar sistemas desde el punto de vista estático y dinámico, es decir, se pueden especificar las estructuras y propiedades de p sistema y las; acciones que se llevaran a ¡cabo en el sistema, junto con las resmcciones correspondientes. Por tal motivo, los elementos utilizados del lenguaje corresponden a la vista estática. Esta caractenstica del lenguaje podrá ser aprovechada en trabajos posteriores, para incluir aspectos dinámicos a la especificación del modelo de dependencias y representarlos en OASIS para la construcpión de prototipos. :,,

5.5. Reglas de Transformación

La definición de las reglas de transformación consiste en establecer una correspondencia de cada lelemento del modelo de dependencias, con un elemento o estructura de OASIS, de tal forma que semánticamente representen IO mismo. OASIS no ve a un sistema como un proceso de negokio propiamente dichb, sino como una colección de objetos autónomos y mncúrrentes que se comunican a través de las acciones. De esta forma el trabajo de transformación consiste en representar los elementos ‘¿le un proceso de negocio en una conjunto de objetos en OASIS; pero especificándolos de tal forma que no se pierda el significado de la información orifid

n!.

~ I( Estas reglas de transformación consisten en realizar un mapeo de cada. elemento del

conteniio del archivo de la plantilla de intenciones, a un elemento de OASIS. En la siguiente tabla se”muestra la correspondencia para la definiuón de las dependencias y un ejemplo del resultado obtenido después de la transformación con su interpretación correspondiente.

Plantilia de Intenciones I NomProceso <id-nombre-proceso>

Actor <id-actor> Tip0 <id-tipo>

Razón <id-razón>

I

I, Descripción <id-descripcibn>

!

Especificación en OASIS

Conceptual schema <id-nombregroceso>

Class <id-actor> Identification

Constant attributes

variable attributes

Events

Nombre : (<id-tipo>)

<Id-tipo> : stnng;

B<id-razón>: Bool (false);

Crear new; Borrar destroy;

47

Con los mismos datos se crea la clase dependencia

Descripción < i d d e s c r i p c i ó n > Razón <id-razón> Dependencia <id-dependencia> Fuerza <id-fuerza> Afecta <id-afecta>

Descripción < id_des i r ipc ión> Razón <id-razón> Dependencia <id-dependencia;

CkSS <id_razón> Identification

Constant attributes Nombre : (<id-descripci6n>)

<id-descripción> : string; fuerza : string (<id-fuerza>); Aplica-Fuerza : string (<id-afecta>); .,

Depender-<id_actor>: Boo¡ (false); Dependee<iddependencia>: Boo1 (false);

Crear new; Borrar destroy;

,Envia<id-dependencia>;

[< id-dependenc ia>]Depender-< id-~~t~=>= true

variables attributes

Events

Evaluations

, Dependee<iddependencia> = true; Preconditions Envia<id-dependencia>if<Depender-<id-actor>= false);

End class

interface <id-actor> (someone) With Dependee-<id-dependenci.> (someone) Attributes (all) Services(<iddescripción>)

End interface

Tabla 1 Aplicación de las Reglas de Transfomación

A continuación se muestra se presentan las reglas de transfomación para convertir de la información del archivo de intenciones a una especificación en lenguaje OASIS. La regla 1 es aplicada para el nombre del proceso, de la regla 2 a la 5 para datos del Actor y de la regla 6 a la 12 para las dependencias.

Reda 1 Proceso NomProceso < i d nombre proceso> I Conceptual schema < i d nombre proceso: - -~ - 1 End conceptual schema-

Reda 2 Actor Actor <id-actor> Class c id-actor> ‘I End class

Reda 3 Actor, considerando la información anterior y la encontrada en el siguiente análisis Tip0 <id- t ipo> Identification

Nombre : (<id-t ipo>) Constant attributes

48

Cqí2Ulo 5 Metodología de Desanallo I) I

1 < id - t i po> , string;

Razón <id-razón>

I

Revla 4 Ahor, considerando la información anterior y la'encontrada en el siguiente análisis Se realiza una asignación de valor para lo encontrado en el token descripción.

Descripción <id-descripción>

Variable attributes

Events B< id razón> : Boo1 (false);

Solicita<id razbn>;

Descripción <id-descripción> I I

- Valuations

preconditions [solicita<id-razón>]B<id_raz6n>= true;

SOlicita<id-rarón> if{ B<id-razón>=false };

Identification

Constant attributes Nombre : (<id- descripción>)

<id-descripción> : string;

49

Actor <id-actor> Descripci6n <id-descripción> Dependencia <id-dependencia>

5.6. Integración de las intenciones al modelo de contexto

Interface <id_actor> (someone) With Dependeecid-dependencia>.(someone)

Attributes (all) ServiCes(<id~descripci6n>)

End interface

El modelo de contexto es un modelo que contiene información muy similar a la contenida en un diagrama de flujo de datos. Muestra que actores intervienen en el proceso y los artefactos que fluyen en él. Los artefactos representan tareas o recurso que existen en ese proceso, lo cual se observa de manera implícita.

El modelo de dependencias estratégicas por el contrario muestra todas aquellas dependencias (relaciones) tanto explícitas como implícitas que existen en un proceso de negocios. Por esta razón, la información acerca de las intenciones, razones, necesidad, es obtenida de la plantilla de intenciones.

AI integrar las intenciones al modelo de contexto, a las clases que son actores se les agregará la información acerca de las dependencias que este tiene. La forma que se utilizó para identificar si se trataba de un actor o de un artefacto fue observando que: - .

Un actor solamente tenia los eventos de creación y destrucción; mientras que Un artefacto contiene además de los eventos de creación y desttucción, eventos del envío de este artefacto. Events

Enviara<nombreDelActor>

A la clase actor, le es integrada la información relacionada a las dependencias. Un ejemplo de esto se muestra a continuación.

50

Metodología & Desurn/lo Capíih 5

event3 ~

Damelllfd : new: Cancelar : d e s t r o y ;

i"d c las

La especi6cación resultante ai intercalar ambos modelos es la siguiente:

: la .JI Pag0POIRepalaCio"eS i d e n t i f i c a t i o n

cons tan t a t t r i b u t e 8 recurso : ! I~cYIQO , numero I ;

IeCYTIo : s t r i n g ;

"YmeiO : ' i n t ;

f u e r z a : 1 s t r i n g ! s b i e r t a i ; Aplica- fuerza : n r r i n 3 1 T a i i e r n e c a n i c a ) ;

: la39 Propie tor ioOelCar ro i d e n t i f i c a f i o n

Constant a t t r i b u t e s nombre : 1 actor , nuera Ji

actor : arc ing ; numero : int:

v a r i a b l e a t t i i h u t e s BCarroSeaReparado : Boaleanlfalsel;

51

Cqi?uh 5 Metodohgía de Desanvh

5.7. Descripción General de la Herramienta

La herramienta para la representación del modelo de dependencias estratégicas en OASIS, es básicamente un traductor y generador de código, es decir un programa que toma el texto escrito en un lenguaje (lenguaje fuente = especificación en OASIS y el archivo que contiene la información de la plantilla de intenciones) y lo convierte en el texto equivalente (lenguaje destino = especificación en lenguaje OASIS del modelo de dependencias estratégicas) IAh088, Fischer881. Un generador depende de varios aspectos, entre ellos: la sintaxis y la semántica de la especificación de entrada, la sintaxis y la semántica del código de salida, y las reglas de transformación entre la entrada y la salida[Calvez98]. El principio de generación se muestra en la figura 1 1 .

String nexiToken0

Fig. I 1 Generación del cddigo en OASIS del MDE

El lenguaje destino .representa el modelo de dependencias en una especificación del lenguaje OASIS y describe lo que parecen su programa (sintaxis) y lo que significa (semántica).

Para análisis de los archivos se utilizaron las instrucciones del lenguaje de programación Java ofrecidas por la Clase StreamTokenizer con sus métodos respectivos. Esta clase permite descomponer un texto en palabras token, y durante el análisis, los tokens identificados son enviados a una estructura de datos en Java.

I M * n i o s util izados I Funcionamiento I lStrino stri I Crea una instancia de StrinoTokenizer

los delimitadores(espacios, tabuladores, retornos de carro, etc.) que se deseen ignorar de la cadena str. Obtiene un token mas

52

- DefhkiÓn de la estructura de datos en la cual se contiene la especificación en memoria - Dehición del formato de los datos de entrada de la planda - Definición de como debe estar almacenado en disco los datos de la p l a n a - '!Se crearon las clases respectivas para mantener las estructuras de datos - Definición del algoritmo para la integración de los modelos. - Se diseño el procedimiento para la generación de código en OASIS

'It

4

Tara el desarrollo iie la herramienta se utilizaron las estructuras proporcionadas por Java. Seiutilizaron dos vectores, unos para contener la información de las clases, @ara actores y para dependencias de acuerdo al modelo de dependencias estratégicas) y otro vector para almacenar las interfaces que existen (relaciones entre los actores por medio de las dependencias), las estructuras son representadas en la Figura 12.

1' I Fig. 12 Estructuras utilizadas para el manejo de la información

Cada nodo del vector de Estructura de clase esta compuesto por un objeto tipo Clases. A su vez,, el objeto Clases, se ljcompone de dos variables de tipo cadena, Nombre de la Clase e Ideníificador de la clase. Y ,por cinco vectores, para el manejo de atributos constantes, para atributos variables, para eventos, para evaluaciones y para precondiciones.

11 [Cada nodo del vector de la Estructura de interfaces esta compuesto por un objeto tipo Interfaies, el objeto Interfaces, se compone de dos variables de tipo cadena, para el Nombre de la clase y otra para el nombre del actor. Y por un vector para almacenar las acciones.

'Estas estructuras tienen como propósito registrar información que se comparte durante la aplidación de las reglas 'de transformación y la integración de los modelos, permitiendo administrar los recursos asociados a las entidades que manipulara el programa. La figura 13, nos muestra en notación UML mediante un diagrama de clase, la estructura de la clase PideDatos, como se observa está clase es una agregación otras. Los atributos y operación de las clases manejadas aquí podrán ser localizadas en el anexo 1 Atributo y operaciones del Diagrama de Clase.

I

I/

53

1

C0pít.h 5 Metodohgío de Desamilo

Fig. 13 Diagrama de Clase de la Herramienta

Entre las clases sobresalientes se encuentran:

La clase EstrClases esta compuesta por una o más defmiciones de Clases. A su vez, la clase Clases esta compuesta de definiciones de una lista de Atributos, una lista de valuaciones, una lista de precondiciones y una lista de eventos. Esta clase es utilizada para almacenar información referente a los actores y a las dependencias.

Las clases LeePlantilla, LeeModelo y EscribeModelo están compuestas por una defmición de la clase EstrClases y EstrInterfaces. Adicional a estas clases la clase LeePlantilla se define también como una agregación de la clase Identifica-dependencia.

La clase Integra, permite realizar la integración del modelo de contexto con las intenciones encontradas en la plantilla, esta clase es una agregación de las clases EstlClases, EstrInterfaces y EscribeModelo.

54

I’ 1

I ! !lI

!! ] !I

ii!

lil. il

/i

cabhdo 6 Caso de Estudio

,I), En este capítulo se presenta el caso de estudio del proceso de reclamo para I

mostrar lo realizado en este trabajo de tesis.

Caso de Estudo Capíbrúl6

Es necesario recordar cual es la pregunta básica en la reingeniería “?Por qué estamos haciendo esto?”. Esto es debido a que es posible ver que muchas tareas que se realizan no tienen nada que ver con satisfacer las necesidades de los clientes. Muchas tareas se ejecutan simplemente para satisfacer exigencias internas de la propia organización de la empresa. En la actualidad las empresas ya no deben organizar su trabajo en tomo a la división del trabajo, si no que estas deben organizarse en tomo al proceso. La característica más común y básica de los procesos rediseñados es que desaparece el trabajo en sene pmunefl4].

Proceso de Negocios: Aseguradora de Autos (Proceso de Reclamo)

Descripción: La compañía aseguradora desea reducir al mínimo el desembolso a los demandantes, empleando a los ajustadores para que evalúen la cuantía de los daños y determinen cuánto deben reconocer por reparaciones. Este paso de control tiene por objeto impedir que el taller mecánico aumente excesivamente la cuenta o efectúe trabajo innecesario. Sin embargo, los ajustadores no son baratos, y sin duda, demoran el proceso con lo cual los clientes quedan molestos -y los clientes enojados, atmenudo entablan demandas. Por esta razón, cuando se trata de accidentes leves, algunas compañías de seguros prescinden del ajustador. Envían al cliente a un tailer apropiado y pagan por lo que haya que hacer. AI mismo tiempo, la compañía de seguros desea mantener a los clientes felices de modo que c o n t i n h renovando sus pólizas. Los propietarios de los coches quisieran que los daños de la reparación fueran evaluados en su mayoría y que sea posible conseguir talleres mecánicos que maximizen las estimaciones de reparación. Para poder elegir entre procesos altemativos de negocio, los analistas necesitan poder describir estos lazos, proponerlos y discutir sobre soluciones de perspectiva estratégicas. Graficamente el proceso se representaria como lo muestra la figura 14.

,/-d . .. .At e) . . . . . . . .. . . . .... . . . ~. . . . . . , . . .. . .

Fig. í 4 Diagrama del Modelo de Contexto

Para la lectura del archivo que contiene la información de las intenc(ones, la herramienta presenta la pantalla de la figura 15, cabe mencionar, que la extensión del archivo que contiene la información debe ser .interi, como lo muestra la figura 16.

56

Fig. 15 Pantalla inicial 1 1

Fig. 16 Pantalla de Captura de la herramienta

La información contenida en el archivo de la plantilla de intenciones es la siguiente:

NomEsquema

actor tipo

descripción razón i dbpendencia

afecta

descripción razón ' dependdncia f"erza afecta

actor

I

f k z a ~

tipo 1 descripción razón dependencia fuerza afecta ~

descripción razón dependencia fuerza

I

afecta1

descripción razón dependencia fuerza afecta:

descripción razón

ProcesoDeReclamO

TallerMecanico actor

necesita PagoPorReparaciones PrOpietarioDelCarrO abierta TallerMecanicO

desea RepetirNegOcio PropietarioDelCarro abierta TallerMecanico

PrOpietarioDelCarro actor il

lograr CarrOSeaReparado TallerMecanicO abierta "

PrOpietarioDelCarro

desea ReparacionestimadaMaximizada TallerMecaniCO abierta PropietarioDelCarrO

desea EvaluacionDeReparacionJusta Ajustador abierta PropietarioDelCarro

TeC"TS0

PagoDeDBmandaS

3n esta parte da a conocer el nombre del proceso que se esta modelando. El actor a modelar es el taller mecánico el cual es un actor, es decir una entidad general.

~i ~aiier mecánico necesita que se realice el pago por las reparaciones por parte del propietario del carro, si el propietario del carro no realiza el pago, esto no afectara al taller mecánico en su desempeño futuro.

El Taller mecánico desea que se repita el negocio por parte del propietario del carro, si el propietario del carro no repite el negocio, esto no afectara al taller mecánico en 5u desempeño futuro.

El actor a modela ahora es el Propietario del Carro, el cual es un actor, es decir una entidad general. El Propietario del Carro quiere lograr que el carro sea reparado por parte del taller mecánico, si el taller mecánico no repara el carro, esto no afectara al propietario del carro.

El propietario del carro desea que las reparaciones estimadas Sean maximiradas por parte del taller mecánico, si el taller mecánico no maximiza la estimación de reparación, esto no afectara al propietario del carro en su desempeao.

El propietario del carro desea también que la evaluación de la reparación sea justa por parte del ajustador, si el ajustador no evalúa de manera justa la reparación, esto no afectara al propietario del carro en su desempeao.

El propietari6 del Carro necesita un recurso el cual es el pago de las demandas por parte de la

51

Casa de Estudia C@ii%ú~ 6

dependencia fuerza afecta

descripción

dependencia' fuerza

razón

afecta

actor tipo

descripción razón dependencia fuerza afecta . descripci6n K i Z Ó "

dependencia fuerza afecta

descripción razón dependencia fuerza afecta

actor tipo

descripción raz6n dependencia fuerza afecta

CompaniaACeguradora abierta Propietari?DelCarro

intentar ReparacionSeaCubierta .'CompañiaA~eg"~adors~~. ::vi

abierta PropietarioDelCarro

CompañiaAseguradora actor

desea ClienteFeliz PropietarioDelCarro abierta CompañiaAseguradora

desarrollar EvaluarDaños Ajustador abierta CompañiaAseguradora

desea ReparacionesMinimas Ajustador abierta CompañiaAceguradora

Ajustador actor

desea Empleadoseguro CompaiiiaAseguradora abierta Ajustador

companía aseguradora. 61 la compania aseguradora no paga las demandas, esto no afectara a i propietario del carro en su desempeao.

El propietario del carro tiene la intención de que la reparación sea cubierta por parte de la compaaia aseguradora, si la compañía aseguradora no cubre l a reparaci6n. esto no afectara al propietario del carro en su desempeiio.

El actor a modela ahora es la Compañia Aseguradora, la cual es un actor, es decir una entidad general. La compañia aseguradora desea que el Cliente sea Feliz por parte del Propietario del carro, si el Propietario del carro no es feliz, esto no afectara a l a compaaia aseguradores en su desempeño.

! La compañia aseguradora desarrollara la evaluación de daños por parte del Ajustador, si el Ajustador 'no evalúa los Daños. esto no afectara a l a compañia aseguradora.

\

La compaaia aseguradora desea que las reparaciones sean mínimas por parte de l Ajustador, si el Ajustador no evalúa las reparaciones minimas esto no a f e c t a r a de manera grave a la compañia aseguradora en su desempeño.

El actor a modelar ahora es el Ajusrador. el cual es un actor.

El ajustador desea ser un empleado seguro por parte de la compania aseguradora, si el empleado no esta seguro. esto no afectara de manera grave al ajustador en su desempeño.

A la información recibida le son aplicadas las reglas de transformación p a producir una especificación en OASIS y posteriormente se coloca en una colocada en una estnictura de datos en Java. Las reglas de transformación aplicadas serian las siguientes:

Regla 1 Proceso Conceptual schema ProcasoDDeRecl- I BRd COnceOtual schema NomEsquema ProcesoDeReclamo

Regla 2 Actor Actor TallerMecanico \Conceptual schema ProcssoDeReclamo

Regla 3 Actor Tipo actor

class TallerMecanico End class

End conceptual schema

Conceptual Schema ProcesoDeReclamo

Class TallerMecanico Identification

Nombre : actor Constant attributes

Actor : strina: - End class End conceptual schema

58

Caro de Estudio capíiuíu 6

II I I/

Regla 4 y 5 Actor. Para la regla cuatro, se determina el tipo de dependenaa que se trata, en este caso, se trata de una deuendencia de mmno, y mediante la regla 5, se detemiina el atributo variable, los eventos, valuaaones y precondidones a c y Dedcripcipn necesita ~326" PagoPorReparaciones

:onceptual schema ProcesoDeReclamO

;lass TallerMecanico Identification

Constant attributes Actor : String:

Variable attributes 6pagoPorReparaciones : molean (false) :

SolicitaPagoPoeReparaciones;

Nombre : I actor ) ;

Events

Valuations

preconditions

false): end class

End conceptual schema

[aolici+a~luyo~o~~racioneslBpagoPcrReparacionea:=true;

solicitaPagoPoraeparaciones if(6pagoPorReparaoiones =

A partit de la regla 4, se inicia también la especificación de las características de la dependencia, considerando.la información recibida anteriormente y la que posteriormente se ha de encontrar.

Regla 6 Dependencia. Con la infonnaaón de la razón, se crea una nueva clase para especificar la dependenaa con sus características.

I

Raz6n PagoPOrReparacioneS

I /I

Conceptual Schema PrOCeSODeReclamo

Class TallerMeCanicO Identification

Nombre : ( actor I; Constant attributes Actor : string;

Variable attributes BpagoPorReparaciones : Boolein(fa1se);

Events SOliCitaPagOPorReparaCiones:

Valuations

preconditions

false]; end class

ciass PagoPorReparaciones end class

End conceptual schema

~solicitaPag~PorReparacioneslBpagoPorReparaciones:=true;

SOlicitaPagoPorReparaciones iftBpagoPo=Reparaciones =

Regla 7 Dependenaa. Con la información de descripción e identificándola como un tipo de dependencia, en este Caso recurso, se incorpora a la dase de la dependencia la identificación y los atributos constantes. DescripCión necesita I Conceptual schema PrOceSoDeReclamO

Class TallerMeCanicO Identification

Nombre : I actor I: Constant attributes Actor : string;

Variable attributes

59

Casa de Esfud1o C+l& 6

Actor TallerMecanico Dependencia PropietarioDelCarra

BpagoPorRepaiaciones : Booleanifalseli

S o l i c i t a P a g o P o r R e p a r a c i o n e s ; Events

Valuations

preconditions

false] ; end class

[solicitaPagoPorReparacionesiBpagoPorRep~=~=i~~=~:=t~"~;

so l ic i t aPagoPorReparac iones iflBpagoPorReparaciones ,-

Conceptual schema ProcesoDeReclamo

Class TallerMecanico Identification

Nombre : I actor 1 ; Constant attributes

Actor : string; Variable attributes

BpagoPorReparaciones : Booleanifalse); merits

class PagoPOrRepamCiOneS ldentification

recyL-so : ( recurso ) ; constant attributes

end c l a s s mNr90 : String;

I End conceptual schema Regla 8 Dependencia. Conociendo la información de la dependencia, podemos conocer de quien se depende para el pago de las reparaciones. Se considera adicional a esta información, la información del nombre del actor que sé esta modelando. Esta información se agrega a la clase que describe la dependencia. Actor TallerMecanico Dependencia PropietarioDelCarro

:onceptual schema ProcecoDeReclamo

:lass TallerMecanico Identification Nombre : 1 actor 1 ;

;onstant attributes Actor : string;

4ariable attributes BpagoPorReparaciones : Booleanifalsel;

3"e"tS SolicitaPagoPOrReparaciones;

false); end class

class PagoPorReparaciones identification

constant attributes recurso : string:

variable attributes depende-TallerMeGaniao : BOO1 (false) ; clependee-PropietaeioDelcarro : Bocl(fal8eii

recurso :, I recurso 1 ;

end class

End conceptual schema

60

Cam de Estudio C+'tuio 6

I/ I I/

SOiicitaPagoPorReparaciones; Valuations

preconditions

false); end class

class PagoPorReparacioneS identification recurso : ( recurso ) ;

constant attributes recurso : string;

variable attributes dependerTallerMecanic0 : Bool(fa1se); dependee-PropietarioDelCarro : Boollfalse) ;

remitirPropietarioD%lCarro;

[ r e m i t i r P r o p i e t a r i o l C a r r o ] &~der-TailarHe&ao :=

~ s o ~ ~ c ~ ~ a ~ a g ~ ~ ~ r ~ e p a r a c i a n e s l ~ p a g o P o r R e ~ a r a c i o n e s : = ~ ~ ~ ~ ~

soiicitaPagoPorReparaciones if{spagoPorReparaciones =

events

w d u a t i o n e

true , depn&e-PropietarioDelCarro := true ; preconditions

f d a e 1; end class

End conceptual schema

remitirPropietarioDelCarm if ( aepen&r-Tallemecani co =

Regla 10 Dependencia. Conociendo la información de la fuerza, esta se agrega a la dase dependencia como un atributo constantes.

abierta I

fuerza Conceptual Schema PrOCeSODeReClamo

Class TallerMecanico Identification Nombre : I actor 1;

Constant attributes Actor : string;

Variable attributes BpagOPorReparacioneS : Boolean(fa1se);

Events SOliCitaPagoPorReparaciones;

Valuations

preconditions

false); end class

class PagoPorReparaciones identification recurso : ( recurso ) i

constant attributes recurso : string; fuerza : etring(abierta) ;

variable attributes depender-TallerMecaniCo : Bool(fa1se); dependee-P*opietarioDelCarro : B001lfalse);

remitirPrOpieta=ioDelC~=~o:

IremitirPropietarioDelCarro] dependerTallerMecanic0 :=

~soiicitaPagoPorReparacioneslBpagoPorReparacianes:=Crue;

solicitaPagoPorReParaCiones if{BpagoPorReparaciones =

events

valuations

true , dependee-PropietarioDelCarro := true ; preconditions

remitiTPTOpietaTioDelc~==~ if ( dependerTallerMecanico =

61

esta dependencia, esta infomiación se Afec ta Ta l l e rMecan ico

Class Tal le rMecan ico I d e n t i f i c a t i o n Nombre : I a c t o r I ;

i o n s t a n t a t t r i b u t e s A c t o r : s t r i n g ;

u ' a r i ab le a t t r i b u t e s BpagoPorReparaciones : B o o l e a n l f a l s e l ;

ZYentS Sol ic i t aeagDPOrReparac iones ;

g a l u a t i o n s

a r e c o n d i t i o n s

t a i s e i ; end class

-lass PagoPorReparaciones i d e n t i f i c a t i o n recurso : i recurso 1;

:onstant a t t r i b u t e s recurso : s t r i n g ; fuerza : s t r i n g l a b i e r t a i ; Aplica-fuerza : string(TallerMecanic0);

[ s o l i c i t a P a g o P o r R e p a r a c i o n e s l B p a g o P a r R e p ~ ~ ~ ~ i ~ " ~ ~ : ~ t ~ " ~ ;

s o l i c i t a P a g o P o r R e p a r a c i a n e s iflBpag0POTRepaTaciones =

v a r i a b l e a t t r i b u t e s d e p e n d e r T a l l e r M e c a n i c o : B o o l i f a l s e i ; dependee-PropietaiioDelCarro : B o o l i f a l s e i ;

r e rn i t i rProp ie ta r ioDe1Carro ; e v e n t s

agrega a la clase dependencia como un atributo constantes. Conceptual schema PrOcesoOeReclamo

valuations [ ~ e m i t i ~ P ~ o p i e t a ~ i o D e l C a r r o l d e p e n d e r T a l l e r M e c a n i c o :=

~

t r u e , dependee-PropietarioDelCarro := t r u e ; preconditions

false I ; end c l a s s

End c o n c e p t u a l schema

r e r n i t i r P r o p i e t a r i o D e l C ~ = = ~ if 1 d e p e n d e r T a l l e i M e c a n i c o =

El campo postecior que se encuentra es 4escripción- lo cual indica que se trata de la descripción de otra dependencia, para lo cual se realizan las siguientes traducciones.

Regla 12 Creación de las interfaces para el actor Taller Mecánico y la dependencia I'agoPorRepmciones, se considera la información recibida antes.

l c o n c e p t u a l schema ProcesoDeReclarno

C l a s s Ta l l e rMecan ico ...

, e n d c l a s s

class PagoPorReparaciones

end class

interface TallerMecanico (someone)

. . .

with PagoPorReparaciones (someone)

62

Caso de Estudo C@’&h 6

precondiaones a crear en la dase actc descripci6n desea

attributes (all) services ( remitirPropietarioDelCarro )

end interface

Se considera el actor que actualmente sé esta modelando.

I End conceptual schema

razón , RepetirNegOcio

¡I

:onceptual schema ProcesoDeReclamo

:lass TallerMecanicO identification nombre : I actor I ;

ionstant attributes actor : string;

iariable attribute3 BpagoPorReparaciones : Booleanifalse); Br-tirNegoci0 : Booleanlfalse);

SolicitaPagoPOrReparaciones; Solicitar<epetirNegocio;

[sol ici taPagoPorReparaciones] BpagoPOrReparacioneS :=

[eolicitaRepetirNegociol BrepetirN-cio := trve :

SolicitaPagoPOrReparaciones if ( BpagoPorReparaciones =

eolicitaRepetirNegoci0 if { BrepetirNegocio = false 1;

Events

valuations

true ;

preconditions

false );

end class

class PagOPOrReparacioneS

end class

End conceptual schema

...

Se inicia a especificat. una nueva dependencia, considerando también la información recibida anteriormente y la que postenofmente se ha de encontrar.

Regla GI Dependencia. Con 1aIinformaciÓn de la razón, se crea una nueva clase para especificar la dkpendencia con sus caractdsticas. razdn RepetirNegOcio lconceptual Schema ProceSODeReclamO

class TallerMecanico identification

constant attributes

variable attributes

nombre : ( actor I ;

actor : string;

BPagoPorReparacianes : Boolean(false1; BRepetirNegOCio : Boalean(false1;

SOlicitaPagOPorReparaciones; SOlicitaRepetirNegocio;

~solicitaPagoPorReparacionesl BPagoPOrReparacioneS :=

[~olicitaRepetirNeg~cio] BRepetirNegOCio := true ;

salicitaPagoPorReparaCiones i f ( BPagoPorReparaciones =

Events

Valuations

true ;

preconditions

63

se incorpora a la dase de la depende1 descripci'n desea

Valuations l so l i c i t aPa4oPorReparac iones l BPagoPorReparaciones :=

a la identificación y los atributos constantes. Conceptual schema ProcesoDeReclamo

class TallerMecanico identification nombre : ( actor I ;

constant attributes actor : string;

variable attributes BPagoPorReparaciones : Booleanlfalsel; BRepetirNegocio : Booleanifalsel;

SOl i c i t aPagOPOrRepa rac iones ; SolicitaRepetirNegOcio;

Events

true ;

preconditions

false I ;

end class

class PagoPorReparacianes

end class

c l a s s RepetirNegOcio identification

constant attributes

end class

End conceptual schema

Iso l ic i taRepet i rNegocio l BRepetirNegocio := true ;

SOl i c i t aPagoPOTRepaTac iones if 1 BPagoPorReparaciones

solicitaRepetirNegocio if i BRepetirNegocio = false I ;

...

meta-suave : ( 5eta-sua.m ) ;

meta-suave : string;

descripción desea Conceptual schema PrOCeSODeReClamO

Class TallerMecanico Identification Nombre : i actor 1;

Constant attributes Actor : string;

Variable attributes BPagoPorReparacionec : BoOleanIfalsel; BRepetirNegocio : Boalean(false1;

64

Events SolicitaPagoPorReparacioneC; SOlicitaRepetirNegOCio;

[ ~ ~ l i c i t ~ P ~ g o P ~ r R ~ p a r a c i o n e S l BPagoPorReparaciones := Valuations

true ;

preconditions

false 1;

end class

[~olicitaRepetirNegociol BRepetirNegocio := true ;

SOliCitaPagOPOrRepaIaci~”=~ if ( BPagOPOeReparacioneS =

SOlicitaRepetirNegoCio if 1 BRepetirNegocio = false );

class PagoPorReparaCiOneS

end class

class RepetirNegOcio identification

constant attributes

evente

...

meta-suave : ( meta-suave I ;

meta-suave : string;

=re.- : n e w ; borrar : deatroy;

end class

I End conceptual Schema Regla 8 Dependencia. Conodendo la información de la dependencia, podemos conocer de quien se depende para el pago de las reparaciones. Se agrega en la dase dependencia quien requiere esta dkpendencia y quien la provee. Actor TallerMecanico Dependencia PropietarioDelCarro

11 I

!

Conceptual schema ProcesoDeReclamo

Class TallerMecanico Identification Nombre : ( actor ) ;

Constant attributes Actor : string;

Variable attributes BpagoPorReparaciones : Boolean(fa1se); BrepetirNegOCio : Boolean(false1;

SOliCitaPagOPOiReparaciones; SOlicitaRepetirNegOcio;

isolicitaPagoPorReparaciones1 BPagOPorReparacioneS :=

isolicitaRepetirNegocio1 BRepetirNegocio := true ;

sol ici taPagoPorReparaciones if I BPagoPorReparaciones =

SOlicitaRepetirNegocio if ( BRepetirNegOCio = false 1;

Events

Valuations

true ;

preconditions

false 1;

end class

class PagoPorReparaciones

end class

class RepetirNegocio identification

constant attributes

...

meta-suave : ( meta-suave I ;

meta-suave : ~tring;

65

Caso de Est& C@Mo 6

V a r i a b l e attributes Depender-TallerMecanico : Bool(fa1se) ; Depende-PropietarioDelCarro : Bcol(fa1se);

end c l a s s

End c o n c e p t u a l schema

fuerza a b i e r t a

Regla. 9 Dependencia. con la misma infocmación se agrega en la dase dependencia, los eventos, iúcaran esta dependencia. h n c e p t u a l schema ProcesoDeReclamo

Conceptual schema ProcesoDeReclamo

Class TallerMeCaniCO I d e n t i f i c a t i o n

Nombre : [ a c t o r I ;

- evaluaciones y precondiciones que m Actor Ta l l e rMecan ico Dependencia P r o p i e t a r i o D e l C a r r o

: lass Tal le rMecan ico [ d e n t i f i c a t i o n

Nombre : I a c t o r I ; : ons tan t a t t r i b u t e s

Ac tor : s t r i n g ; I a r i a b l e a t t r i b u t e s

BpagoPorReparaciones : Boolean(false1; Brepe t i rNeqoc io : Boolean(false1;

Solici taPagoeorReparacionec; S o l i c i t a R e p e t i r N e g o c i o ;

[ so l i c i t aPagoPorReparac ioneCl EPagoPorReparaciones :=

I ~ o l i c i t a R e p s t i r N e g o c i o l BRepet i rNegocio := t r u e ;

so l ic i taPaqoPorReparac iones i f [ BPaqoPorReparaciones =

s O l i c i t a R e p e t i r N e q O c i 0 i f 1 ERepetirNegOcio = false I ;

:ven t s

f a l u a t i o n s

:rue ;

m e c o n d i t i o n s

:alse ) ;

?nd c l a s s

,lass PagoPorReparaciones

?nd class

:lass Repe t i rNeqoc ia i d e n t i f i c a t i o n

:onstant a t t r i b u t e s

i i a r i a b l e a t t r i b u t e s

meta-suave : I meta-suave I ;

meta-suave : s t r i n g ;

Depender-TallerMecaniao : B o o l ( f a l S e 1 ; D e p e n d e e P r o p i e t a r i o D e l C a r r o : BOOl(falBe1;

crear : new; Borrar : d e s t r o y ; Rermt+rPTOpLetaTloDelCarro:

IremitirPropietarioD~lCarro] depender-Tallernecanico :=

Events

Valuations

true , depndee-PropietarroDelCarro := true ; preconditions

false ) ; end class

End conceptual schema

remitirPrOpietarloDelc~rro.if ( depender-TallerMecanrco =

66

I II

'I1 r

Regla 11 Dependencia. Conociido esta dependencia, esta información sc Afecta TallerMecanicO

'1

'!I

onstant attributes

'ariable attributes Actor : string;

BpagoporReparaciones : Booleanifalse); BRepetirNegOciO : Booleanlfalse);

SolicitaPagoPorReparaciones; SolicitaRe~etirNegOcio;

:vents

laluations rsolicitaPa~0ParReparacionesl BPagoPorReparaciones :=

:rue ;

,reconditions

false );

snd class

:lass PagoPorReparacioneS

end class

class RepetirNegocio identification

constant attributes

[solicitaRepetirNegocio] BRepetirNegOCio := true i

so l iC i t aPagOPOrRepa rac ioneS if { BPagoPOrReparaciones =

SolicitaRepetirNegOcio if ( BRepetirNegocio = false ) ;

...

meta-suave : i meta-suave I ;

meta-suave : string; fuerza : steirig(abieeta) :

Depender-TaiierMecanica : Boolifalsel; Dependee-PrOpietarioDelCarro : Boolifalseli

Crear : new: Borrar : destroy; RemitirPropietarioDelCarro;

[ r e m i t i ~ P r o p i e t a ~ i o D e l C a r r o I depender-TallerMecanico :=

Variable attributes

Events

Valuations

true , dependee_PrOpietarioDelCarro := true ; preconditions

false 1; end class

End conceptual schema

información de afecta; se conme a quien afectara si no se cumple grega a la dase dependencia como un atcibuto constantes. Conceptual schema ProCeSODeReclamo

Class TallerMecanico Identification Nombre : ( actor I ;

Constant attributes Actor : string;

Variable attributes BPagoPorReparaciones : Booleanlfalse); BRepetirNegOcio .: Booleanifalsel;

SOl i c i t aPagOPOrRepa rac iones ; SOliCitaRepetirNegOcio;

remi t i rPrOpie ta r ioDelCar rO if I depender-TalierMecanico =

Events

Valuations IsolicitaPagoPorReparacionesI BPagoPOrReparacioneS :=

[sol ic i taRepet i rNego~io] BRepetirNegOcio := true ; true ;

67

Coso de Estudo C@’&h G

preconditions Sol ic i t aPagoPorReparac iones if [ BPagoPOrReparaciones =

501icitaRepetirNeg~cio if I BRepetirNegocio = false 1; f a l s e 1;

end class

class PagoPorReparaciones

end class

d a i s RepetirNegocio identification

:onstant attributes

...

meta-suave : <.rneta-suave 1;

meta-suave : string; fuerza : stiinglabiertal; Aplica-fuerza : string(Tal1erHecanico);

depender-TallerMecanico : Boolífalsel; dependee-PropietarioDelCarro : Boollfalsel;

crear : new; borrar : destroy; r emi t i rP rOpie ta r iDDe1Car ro ;

[ ~ e m i t i r P ~ ~ p i e t a r i o D e l C a r r o l dependerTalierMecanic0 :=

iariable attributes

?Vents

mluarions

:rue , dependee-PropietarioDelCarro := true ; xecondi tions

Calse 1; .nd class

r e m i t i r P r o p i e t a r i o D e l C a r r o if i depender-TallerMecanico =

2nd conceptual schema

El campo que se encuentra posteriormente es -actor- nos indica que se iniciara a describir otro actor y las dependencias de este, aquí se aplica la regla 12.

Regla 12 Creación de la interface par I actor Taiier Mecánico y la dependencia RepeárNegocio conceptual schema ProcesoDeReclamo

-lass TallerMecanico . .< end class

class PagoPorReparaciones

end class

class RepetirNegocia

end class

interface TallerMecanico (someone)

... , .

...

with Pagoporpeparaciones [someone) ...

end interface

interface TallerMecanicO (someone) w i t h RepetirNegocio (someone) attributes (all) services ( remitirPropietarionelCar~ )

end interface

End conceptual schema

68

I Casa de Estudio

I1 La !+ente palabra identificada, es la palabra actor, lo cual señala que se inicia la descripción de un nuevo actor.

Regla 2 Actor Actor PropietarioDelCarro / .

Regla 3 Actor Tipo actor

/i I

:onceptual schema ProcesoDeReclamo

:lass TallerMecanicO

2nd class

zlass PagoPorReparaciones

end class

class RepetirNegOcio

...

...

end class

claes PropietarioDelCarro end class

interface TallerMecanicO (someone)

end interface

interface TallerMecanicO (someone)

end interface

End conceptual schema

Conceptual schema PrOceSODeReClamo

class TallerM&anico

end class

class PagOPorReparaciones

end class

class RepetirNegOcio

end class

class PropietarioDelCarrO identification

constant attributes

end class

interface TallerMecanicO (someonel

end interface

interface TallerMecanicO (someone)

end interface

End Conceptual Schema

...

...

...

...

...

nombre : ( actor ) :

*=tor : etzing:

...

...

, !

! 69

valuaciones y precondiciones a crear. descripción l o g r a r razbn CairoSeaReparado

class PagoPorReparaciones

end class

class RepetirNegocio

end Elass

class PropietarioDelCarrc identification

nombre : 1 actor 1; constant attributes

actor : string; variable attributes ,

...

...

Conceptual schema PracesoDeReclamo

Class TallerMecanico

end class

class PagoPorReparaciones

end class

class RepetirNegocio

end class

class PropietarioDelCarro identification

nombre : I actor I ; constant attributes

actor : string; variable attributes BCarroSeaReparado : Booleanifalre);

eolicitaCarmseaReparado;

(solicitaCarroseaReparadol BCarroSeaReparado := true ;

soiicitaCarroseaReparado if { BcarmSeaReparado = false);

. . .

...

. . .

events

valuations

preconditions

end class

interface TallerMecanicO isomeonel

end interface ...

interface TaiierMecanico (someone) ... 6nd interface

End conceptual schema

70

Caro de Estudto Capí2uh 6

dependencia se agrega a la dase depq Descripción lograr

41 I I¡

iencia la identificación y los atributos constantes. Conceptual schema ProceSODeReclamo

BCarroSeaReparado : Baolean(false1;

SolicitaCarroSeaReparadÓ;

[solicitaCarroSeaReparadol BCarrOSeaReparado := true i

solicitaCarroSeaReparado if [ Bcarroseaneparado = false);

'vents

ialuations

?reconditions ,

end class

class CarroseDReparado end class

interface TallerMecaniEo lsomeone)

el tipo de la

Class TallerMecanicO

end class

Class PagoPorReparacianes

end class

class RepetirNegOCio

end class

class PrOpietarioDelCarrO identification

nombre : 1 actor ) i constant attributes actor : string;

variable attributes BCarrOSeaReparado : Boolean(fa1se);

eYentS SOiiCitaCarrOSeaReparado;

valuations isolicitaCarroSeaReparadol BCarroSeaReparado := true ;

preconditions SolicitaCarrOSeaReparado if I BcarroSeaReparada = false);

end class

class CarroSeaReparado identification

meta : ( mete ) ;

conetent attributes meta : string;

end class

interface TallerMecanico (someone)

end interface

...

...

...

...

71 'I

C+*&h G Cam de Estudio

interface TallerMecanico (~omeons)

end interface

End conceptual schema

. . .

Regla 8 Dependencia. Conociendo la información de la dependencia, podemos conocer de quien se

Actor PropietarioDelCarro Dependencia TallerMecanico

depende p i que el cmo sea repara Dependencia TallerMecanico

Conceptual schema ProcesaDeReclamo

Class TallerMecanico

end class . . .

Conceptual schema ProcesoDeReclamo

Class TallerMecanicc

end class

class PagoPorReparaciones

end class

-lass RepetirNegocio

2nd class

:lass PrOpietarioDelCarrO identification nombre : i a c t o r ) ;

Eonstant attributes actor : string;

variable attributes BCarroseaReparado : üooleanifalsel;

events sol ici taCarroSeaReparado;

valuations [ so l i c i t aCar ioSeaReparado l BCarroSeaReparado := true ;

,reconditions SOl ic i t aCar rOSeaReparada if I BcarroseaReparado = false];

m d class

:lass CarroSeaReparado identification meta : ( meta 1;

constant attributes meta : string;

variable attributes depen&r-PrapietarioDelC=rro : B001(faleel; dependee~TallerMecaico : BOOlifalsel ;

...

...

...

end class

i n t e r f a c e TallerMecanico Isomeonel

end interface

interface TallerMecanicO ISOmeOneI

...

end interface

End concep tua l schema

72

Regla 10 Dependencia. Conoáendo 1 Fuerza abierta

:lass PagoPorReparaciones

?nd class

:lass RepetirNegOCio ... ?o6 class

-lass PropietarioDelCarrO identification nombre : actor ) ;

constant attributes actor : string;

variable attributes BCarroSeaReparado : Booleanlfalse);

events SolicitaCarrOSeaRepaTado;

valuations [solicitaCarroSeaReparadal BCarrOSeaReparado := true ;

preconditions SolicitaCarroSeaReparado if I BcarroSeaReparado = false);

end class

class CarroseaReparado identification meta : ( meta I ;

constant attributes meta : string:

variable attributes depender-PropietarioDelCarro : B001(falSe): depende=-TallerMecanico : Bool(false1;

creaz : new; borrar : deatroy; remitirTa11ernecMico;

tremitirTallerMecanico1 depemier-PropietarioDelcarro :=

event-

V a l U a t i O l l S

true , dependse-TallerMecanico := true : preconditions

false ); end class

interface TalleeMecanicO Isomone)

end interface

interface TallerMecanico (someone)

end interface

End conceptual schema

nfomuón dci campo fuerza, se agrega a la dase dependencia. Conceptual schema ProceSoDeReclmo

Class TallerMecanico

end class

Elass PagoPorReparaciones

end class

remitirTallerMecanic0 if i deper ider-Propietar ioDelCarro =

...

...

...

...

73

Caro de Est.uiro C@i&cllú, 6

Afec ta P r o p i e t a r i o ü e l C a r r o

c l a s s R e p e t i m e g o c i o

Conceptual schema ProcesoüeReclamo

Class Tal le rMecan ico ... end class

class PagoPorReparaciones

end class

class Repe t i iNegoc io

end c lass

. . .

...

end class

c l a s s P r o p i e t a r i o D e l C a r r o i d e n t i f i c a t i o n nombre : i actor i ;

c o n s t a n t attributes a c t o r : s t r i n g ;

v a r i a b l e a t t r i b u t e s BCarroSeaReparado : B a o l e a n i f a l s e ) ;

so l ic i t aCar roSeaReparado;

[solicitaCarroSeaReparadol BCarroSeaReparado := tme ;

solicitaCarroSeaReparado i f t BcarroSeaReparado = false]:

svents

i a l u a t i o n s

> r e c o n d i t i o n s

2nd class

:lass CarroSeaReparado i d e n t i f i c a t i o n

meta : i meta 1 ; m n s t a n t a t t r i b u t e s

meta : s t r i n g ; fuerza : string(abierta) ;

i a r i a b l e a t t r i b u t e s depender-PropietarioDelCarro : Boolifalsei; dependee-TalleTMecanico : B o o l l f a l s e i :

'vents crear : new; borrar : destroy; remi t i rTa l l e rMecan ic0 ;

[ r e m i t i r T a l l e r M e c a n i c o l depender-PropietarioDelCarro := d a l u a t i o n s

t r u e , d e p e n d e e T a l l e r M e c a n i c o := LrUe ; w e c o n d i t i o n s

Ealse I ; 2nd class '

i n t e r f a c e Ta l l e rMecan ico isomeonel

end i n t e r f a c e

i n t e r f a c e T a l l e r M e c a i i c o someo one^

r e m i t i r T a l l e r M e c a n i c o i f 1 depender~Propie tar ioDelCarr0 =

...

end i n t e r f a c e

End c o n c e p t u a l schema

74

Caso de Estudio CapWo 6

11 I1

Conceptual schema PrOCeSoDeReclamo

Class TallerMecanico

end class ...

lass PropietarioDelCarrO dentification nombre : i actor 1;

,onstant attributes actor : string;

wriable attributes BcarroseaReparado ~oolean(false1;

!vents ~ ~ 1 i c i t a C a ~ ~ ~ S e a R e p a r a d o ;

raluations [solicitacarraseaReparadol BCarroSeaReparado := true ;

>reconditions SOlicitaCarroSeaReparado if { Bcarroseaneparado = false];

?nd class

:lass CarroSeaReparado identification . ,

meta : i meta I ; >onstant attributes meta : string; fuerza : stringiabierta); Aplica-fuerza : ~ t ~ i n g ( P ~ 0 p i e t a ~ i o D e 1 C a r r o l ;

depender-PiopietarioDelCarro : Baol(fa1se); variable attributes

‘dependee-TalleTMecanico : Bool(fa1se);

crear : new; borrar : destroy; remitirTallerMecanic0;

[remitirTalierMecanicol depende=-PropietarioDelCarro :=

events

valuations

true , dependeeTallerMecanico := true ; preconditions

false I ; end class

interface TallerMeCaniCo (Someone)

end interface

interface TallerMecaniCO (someone)

end interface

End conceptual Schema

remitirTallerMeCaniC0 if ( depender-PrOpietarioDelCarro =

...

...

class PagoPorReparaciones

end class

class RepetirNegOcio

... II.

...

C@ít& 6 Caro de Estudo

I end class

class P r a p i e t a r i o D e l C a r r o

end class

class CarroSeaReparado

end class

i n t e r f a c e TallerMecanico (someone)

end interface

interface TallerMecanicO isorneane)

end interface

interface PropietarioDelCarro (someonel

. . .

...

...

...

with CarroseaRqarado (someanel attributes (all1 services ( remitirTallernecanico )

end interface

E n d conceptua l schema

La aplicación de las reglas de transformación se reaka de igual manera con los siguientes datos encontrados, hasta la generación completa de la especificación en el lenguaje OASIS. El siguiente paso consiste en la recepción del archivo de contexto. La herraínienta presenta una pantalla como la mostrada en la figura 15 para la captura del nombre del archivo, cabe mencionar, que la extensión del archivo que contiene la información debe ser .ouszs, como lo muestra la f ia ra 17.

Fig. 17 Pantalla de captura del Modelo de Contexto

Como se ha mencionado a lo largo del capítulo 5, el modelo de contexto permite conocer el flujo de los artefactos o productos de una entidad a otra en un proceso de negocio. Para este caso de estudio, elegimos el proceso de reclamo, el archivo que se recibe es la especificación en lenguaje OASIS de tal proceso.

La información recibida en el archivo del modelo de contexto nos proporciona información acerca del proceso de reclamo. Nos dice quienes son los actores que integran a este proceso (Taller Mechico, el Propietario del Carro, la Compañía Aseguradora y el Ajustador) y

16

C@ííu.h 6 cm0 de EStUdiO

I / '11

los tres artefactos (el pago por las reparaciones, el pago de las demandas y la evaluación de los daños) que fluyen entre ellos. La información recibida es la siguiente:

t 11

Class EvaluarDanOs

'I1 constant attributes fecha : date:

variable attributes YarTallerMecanrco : boo1 ItTYeli varPronierariaRuto : boo1 Ifalsel;

Identification fecha : (fecha); .!

VarRjustador : bool I fs lSe l ; varcompania : bao1 lfalsel;

Elaborar new; Cancelar destroy: EnviaraPropietarioAutO; Enviarajusiador; Enuiaracompania;

events

ValuationJ IEnuiarBPlopier~iioRYrol varTallerMeCanico :- false

IEnviaraRjustadorl varPrapietarioAut0 := false , IEnviaraConpaIIial VarAjuntador := false ,

, "drPrOpietaIiollUtO := true:

VarAjustador := frue:

varcompania := LTYei

I1 precdnditions It EnviaraPropierarioRuro if IvarTallerHecanicO = true

1; EnuiaraAjuStadoT if IvarPropieLarioAuto = true I : EnviaiaCompania if Ivarnjusrador = true 1:

end class

c d s s PagODeDemandas '' identification

""mero : 1numero1 i constant attributes

numero : int; variable attributes /' ' VarPropietaiiMuto : bool ir&i;

VarAjuisrador : boo1 lfalsej; l b varcompania : bool Ifalsel;

Elaborar new:

EnviaraAjustadori

eYe"ts

Cancelar destroy;

EnviaraCompaniai VaiYatiOnO

VarRjustador :- true;

uarcompainia := true:

IEnviaraAjustad0rl vorP~~pietarioAuto := fa l s e

wnuiarñcompaniai var*jjustadar := mse

PIecondiiions , EnviaraAjusradar if IVarPropieLariohuLo = true l ;

EnviaroCompaflia if ivarAjustador = true 1: end class

class PagoPorReparaciones identification

numero: Inmerol; constant attributes II

numero : int; variable aiiribufes

varcoinpania : bod I t r Y e l i varPrOpietarioRuto : b o d (false); VdrTallecneCardCO : bo01 IfelSeli

ElabMarCheque new; Cancelar deoiroy;

EnviaraTallerMecanico;

[EoviaraPropielarioAufOl u d m m p n i a := false ,

[E""iaraTolleTNeca"iC01 "arPrDpieiari0A"tO := false

events

EnaiaraPiOpietdTio~Yio;

UdlYatio".

"arPropiejarimufo := true;

, "arTallerHecanic0 := true:

events OarDeRlta new; Cancelar destrovi

end class

class Ajustador identification

claue:Icla"el; constant attributes

clave : inti events

DarDeAlta new: Cancelar destroy:

end Class

class Tallernecanico identificafion

"0iobre: lno~rel ; cOnStant attribute8

nanbre : Itring: events

crear new: Cancelar destroy;

end class

class CompaniaAsepuradara identification

nombre: ("onbrel: consiant attributes

nombre : string; events

crear new: Cancelar destroy;

end class

inreiface Ajustador 190meonel "ith ReparaciOoesNinimas (5me*r,eJ attributesialll ser"iCes1En"iaraCompania~;

end interface

interface conipania iriomeonei with PagoReparacion Isameonel attributeslalll serviceslEnviaraPropielariot~,ElabararCheque,

a"Celar1 end interface

interface PropietarioAuto Isomeonel with PagoReparacion (someonel aiLributesIall1 SerUiCeSIEnYiaTaTallerNecanic0)

end interface

interface TallerHecanico (3oneo"e) with SeruicioDeReParacion Isoneonel altribules(all1 SBIYICBS1E"YiaraPI~pietaiioll"RYLOi Realizar, Cancelar1

end interface id conceptu.31 schema

77

C~'Uc0 G Caro de Estudia

La información que se recibe, es colocada en la estructura de datos en Java correspondiente, posteriormente esta información será utilizada para integrarle las intenciones recibidas a través del archivo que contiene la información de la plantilla de intenciones.

Una vez seleccionados los archivos, se activa el botón Generar Modelo en la herramienta, una vez realizada la acción de generación del código figura 18, se procederá a integrar al modelo de contexto las intenciones. Después de haber realizado este proceso, se activará la opción para la lectura de la especificación generada figura 19.

Fig. 16 Generación e integración

La representación gráfica de la especificación generada se muestra en la figura 20.

-,,,,*., - asddni.rrrrulo -memm*w. , .

Fig. 20 Diagrama del Modelo de Dependencias Estratégicas

78

Caso dc Estudio Cqítuío 6

'I

A continuación se muestra la interpretación que se debe realizar a la especificación generada: Esta explicación se.da con el objetivo de que posteriormente esta pues ser utilizada para intekarle aspectos dinádbos, pero principalmente para realizar el proceso de reingeniería.

TallerHecanica i d e n t i f i c a t i o n

nombre : ( actor , nombre I : constani attribute3

actor : string; nomhre : string;

variable attributes BpagoPorReparacionea : Booleanl fa l ie i : siepeririiegocio : Boolea" iia1sei;

Events crear : nevi Cancelar : destroy; saliciraPagoPoiReparaciones; so1iciraRepefir"egocio;

I~soiicir~PagoPorReparaCiones] BPagoPorReparaciones := t i u e : isolicitaRepetirNegoCiol BRepeiirNegocio := true ;

LlolicitaP.gOPOTReparaclones if 1 BPagoPorReparaciones = f a l s e I ; g o l i c i i a R e p e t i r N e g ~ ~ i o i f I BRepetirNegocio = fali le I ;

valuations

preconditions

e"? class I . .

class PagoPoiReparaciones i d e n t i f i c a t i o n

recuran : I recur40 , numero 1:

IBC"T30 : string;

+Plica-fueira : gtIinglTal1ernecanico); numero : i n t i

constant attributes

fuerza : stringlabiert81:

variable altribufe$ depender_Talle~-Wec.niCO : Boollfalsei; dependeePropietarioDelCarro : B o o i i f a l s e i ; VarCOmpania : boo>lllrue); ,~arPropiptariaAuto : boollfalse): :arTallerHecanico : boollfalse);

Elaborarcheque : iew: Cancelar : destroy; ~emitirPiopieiarioDe1Carro; En"ia~-aPIOpiet~TioRYrO; E""iaTLTBllerHeCa"iCD;

I1 ewnts

va1varions

dependee-PropietarioDelCarra :- true ;

true ;

: - , t r u e :

lremitirPrapietario~elCarrol depende=TaiierHecanico := t m e

I E n v i a r a P r a p i e f a r i o t ~ l varCompafiie := fa l s e , varPropietario~uto :. IEnuiar.T.lle~Mecani~al YarPrOpieiarioAuto := false , varTailerHecanic<

p r ' b m d i t i o n s remitirPropietarioOelCarro if I depende-aiiernecanico = false 1;

:- true

I proceso de negaio a modelar tiene por ombre proceso de reclamo. I ador que modela es el taller mecánico el ual es un acta que se identificara tambien p a I nombre, este tiene una dependencia por el 'ago de las reparaciones y por que se repita d egOCi0.

o que se modela en este mmento es la ependencia Pago por Reparaciones, la cual es e tipo recurso y que se identificara también 01 medio de un número. Quien requiere de Sta dependencia es el Taler Mecánico y quien uede satisfacerla es el Propietario del carro, in embargo el no cumplimiento de esto no fectara al Tailer Mecánico

e modela ahora la dependencia Repetir egccio. esta dependencia es una STmdencia suave. Quien requiere de esta !pendencia es el Taller Mecánico y quien iede satisfaceria es el Propietario del carro. n embargo si esta dependencia no se cumple, ;to no aiectara al Taller Mecánico.

79

end class

:= U"*

false 1;

El actor que se modela es el Propietano del Carro el cual es un actor que se identificara también por el número, , este tiene una dependencia por que el Carro sea reparado, por que las Reparaciones estimadas sean Maximizadas. por que la Evaluación de la Reparación sea justa, por que se le Paguen las Demandas y por que la Reparación sea cubierta.

to que se modela en este momento es la iependencia Carro sea Reparado, la cual es de ipo meta Quien requiere de esta dependencia 3 el Propietario del Carro y quien puede jatisiacerla es el Taller Mecánico. sin embargo ii no se satisface esta dependencia. esto no afectara al Propietario del Carro.

to que se modela en este momento es la dependencia Reparación estimada Maximizada. la cual es de tipo meta suave. Quien requiere de esta dependencia es el Propietario del Cano y quien puede satisfacerla es el Taller Mecánico. sin embamo si no se satisface esta dependencia. esto no afectara al Propietario del Carro.

Lo que se modela en este momento es la dependencia Evaluación de Reparación Justa,

80

identification

constant attribute3 meta-suave : I netd_PYa"e I.

rneta-sume : string;

*plica_f"erza : srri"glPropietarioPelCa==ol: fuerza : siringlabiertai:

variable attributeS 1;

dependee-Ajustador : Boollfalsel; eucnti

crear : new; borrar : destroy; remitirAjusiador:

"a1"BtIo"s

dependee-Ajustador := true : preconditions

end c ia39

class PagoDeDeniandas identification

IremitirAjuitador] depender-PIopieiarioD~IC~~~~ := true ,

iemitirAhustador if I dependcoropietariaDelCarro E false 1:

TeCYrsO : I recurso , numero 1: constant ñttribuies

TeCUIBo : string; fuerza : stringlahieria); Aplica-fuerza : ~fringIsropietario0clCarrali numero : inr;

dependeTPrOpieiaIi~OelCarrO : ~oolifalsel; i,dependee_CanipaniaRieguradara : 8001/falsel: VarPropietarioAuto : boolltruel; varAjuoiador : boollfalrel; .varCOinpania : hoOlifalSel:

variable attributes

eeenta Elaborar : new:

11 : +e*tification class COmpadiaASeguradora

nombre : I .%iCtOI , nombre 1; constant attributes

actor : strino; nombre : string:

a cual es de tipo meta suave. Quien requiere le esta dependencia es el Propietario del Carro

quien puede saisfacerla es el Ajustador. sin imbargo el no cumplimiento de esta no ifedara al Prwietario del Carro.

Se modela la dependencia Pago de Demandas, la cual es de tipo recurso y la cual se identificara por un numero. Quien requiere de esta dependencia es el Propietario del Carro y quien puede saiifkerla es la Compañia Aseguradora, sin embargo si no se satisface esta dependencia esto no afectara al Prwietario del Carro.

Se modela la dependencia Reparación sea Cubierta. la cual es de tipo meta. Quien requiere de esta dependencia es el Propietario del Carro y quien puede satisfacerla es la Cmpaiiia Aseguradora. sin embargo si no se sat'iface esta dependencia esto no afedara ai Propietario del Carro.

El ador que se modela es la Cwnpañia Aseguradora. la cual es un ador que se identificara también por el nombre, este tiene una dependencia p a de que el Cliente sea Fe¡¡¡, por que sé Evalúen las DaRcs y para que las Reparaciones sean Minimas.

81

Caso de Estudo C+'tuh 6

Se modela la dependencia Cliente sea Fel i . la Cual es de tipo meta suave. Quien requiere de esta dependencia es la Compañia Aseguradora y quien puede satisfacerla es el Propietario del Carro, sin embargo si no se satisface esta dependencia esto no afectara a la Compafiia Aseguradora.

Se modela la dependencia Evaluar Daños, la cual es de tipo tarea y la cual también sera identificada por medio de una fecha. Quien requiere de esta dependencia es la Compafiia Aseguradora y quien puede Satisfacerla es el Ajustador, sin embargo si no se satisface esta dependencia esto no afectara a la Compafiia Aseguradora.

Se modela la dependencia .Reparaciones Minimas. la cual es de tipo meta suave. Quien requiere de esta dependencia es la Compañia Aseguradora y quien puede satisfacerla es el Ajustador. sin embargo si no se satisface esta dependencia esto no afectara a la Compañia Aseguradora.

82

Caro de Estudio C+" 6

. +tirRjustadOr if I depender-CompaniaAseguradora = false end class

class Rjustador identificarion nombre : i actor , clave 1:

CO"3fd"t attributes actor : string; Clave : int;

variable attributes BEmbpleadoSeguro : Boaleanifalsel:

Events Daroealta : new: Cancelar : destroy; IsolicitaElopleadoSegura;

IsolicitaEmplead~Segvrol BMpleadoSeguro := rrue i

soliciraEnipleadoSegura if i BEmpleadoSeguro = false I :

4

. YI

Yal"atio"9

pr.eCOnditionS

end class

c?ass EmpleadoSegum identification .//i

meta-suave : i meta-soave 1:

metasuave : s t r i ng ; constant aLLzibuteS

fuerza : siringlabierfal; Aplica-fuerza : StringiAjustadorl;

variable attributes 'ldepender_Ajustador : B o d (false1 : aependee_Campania*.regvradora : Booiifalilel;

event3 crear : Dew; borrar : delimy; remirirCoiapaniaAJeguradara;

"0l"atiO"s

dependee COmpaIiaRseguradOra := true ; IremifirConipa*I~egvradoial depender-Ajustador := t r Y e

interface Tallernecanica isameonel With PagoPorReparaciones isomeonel attributes l a i l l services ( remirirPropIetaiioDelCarro I

end interface

interface Tallerltecanico isomeonel with RepeiirNegocio isomeonel : attribuies la111 services I remIfirPropietarioDelCairo 1

end interface

interface PropieZarioDelCarro isomeonel with CarraSeaReparado isomeonel attribufes ( a l l 1 aervices I reniirirTallerMecanico I

end interface

interface Propiecariooelcario i5omeanel with Rep~r~ciDneStimadaM~ximilada (someonel attribYtes l a 1 1 1 services i rMlitirIalleIWecanic0 1

end interface

interrace PropietarioDelCarro Isomeonel with Ev~luaciUnDeReparaCi(inju9ta (someone) attributes ialil services i reoiltIrAj'lostador 1

end interface

&errace PTOpietarioDelCaIrO isomone) with PagoDeDemanda$ isomeonel

El ador que se modela es el Ajustador el cual ts un actor que se identificara también por una :lave, este tiene una dependencia por ser un Empleado Seguro.

Se modela la dependencia Empleado Seguro. la cual es de tipo meta suave. Quien requiere de esta dependencia es el njustadar y quien puede satisfaceria es la Compaiila Aseguradora. sin embargo si no se satisface esta dependencia esto no afectara al Ajustador.

El Taller Mecánico tiene una dependencia por el Pago de las Reparaciones, quien satisfacerá está será el Propietano d d Carro.

El Taller Mecánico tiene una dependencia por Repetir el Negocio, quien satisfacera está será el Propietario del Cano.

El Propietano del Carro tiene una dependencia por que el Carro sea Reparado, quien satisfacerá está será el Taller Mecánico.

El Propietario del Carro tiene una dependencia de que las Reparaciones Estimadas sean Maximizadas. quien satisfacerá está será el Taller Mecánico.

El Propietario del Carro tiene una dependencia por que la Evaluación del Carro sea Justa, quien satisfacerá está es el ajustador.

El Propietario del Carro tiene una dependencia p a el Pago de las Demandas, quien satisfacerá está es la compañía Aseguradora.

83

attribute, ( a l l ) services 1 r e m i t i r c o m p a a i e . a i e q ~ ~ ~ ~ ~ ~ j

end interface

interface P r o p i e r s r i o ~ e i ~ e ~ ~ ~ (aomeonei with Reparacioaseanibierra (somaone1 attributes l a l l j service* 1 reniirirCompañiaAseguradora j

end interfece

interface cumpañiaAseguratiora ,3omBo"ej with ClienteEeliz (someonej attributes (all) services ( remitirpropieteriaDe1Carro j

end interface

interface CmpañiaRseguradora ( s m e m e j With EvaluarDuio, i%"neo"e) attributes (all, reivicss I reioirirrijustador >

end interface

El Propietario del Carro tiene una dependencia por que la Reparación Sea Cubierta. quien Mtifacerá esta es la Compania Aseguradora.

La Cornpaiiia Aseguradora tiene una dependencia por que ei Cliente Sea Feliz. quien saiiiacerá está es el Propietario del Carro.

La Compania Aseguradora tiene una dependencia por que se EvalUen IOJ Dafios, quien satisfacerá está es el Ajustador.

I

La Compafiia Aseguradora tiene una dependencia porque las Reparaciones sean las Minirnas. quien satisfacerá está es el Ajustador.

El Ajustador tiene una dependencia por ser un Empleado Seguro, quien satisfacera &a es la Compañia Aseguradora.

Se termina la especificación del proceso

84

'I

ConcZztsionesy Trabajos Fzttziros

Concúmanesy Tmbaj,, Futtms

Conclusiones

Con el desarrollo de este trabajo se logra enriquecer un modelo de contexto con intenciones, logrando con esto la representación formal del modelo de dependencias estratégicas en el lenguaje OASIS.

Al contar con una especificación enriquecida con las intenciones se tendrá un conocimiento adicional acerca de los "porques" de los pasos en un proceso de negocios y de esta fotma apoyar proyectos de reingeniería. Adicionalmente, la representación en el lenguaje OASIS proporcionará la base formal requerida para las etapas posteriores del proyecto IRIS, en particular para la generación de prototipos.

Los objetivos propuestos se han logrado, ya que como se ha mencionado en el desarrollo de la tesis, el modelo de dependencias estratégicas modela solamente aspectos estáticos, pero gracias a que el lenguaje OASIS ofrece un modelado estático y dinámico es posible realizar esta transformación.

Trabajos Futuros

El trabajo desarrollado constituye una versión inicial dentro del proyecto IRIS para el desarrollo de reingeniería y para la generación de prototipos. Por lo cual quedan trabajos y mejoras por realizarse, entre ellas se encuentran:

a) Establecer un método correcto para el llenado de la plantilla de intenciones ya que en este trabajo sólo se mencionan algunos puntos a considerar durante su llenado.

b) Con respecto a la herramienta, hace falta realizar una interfaz que permita observar de manera gráfica como se presenta el modelo de dependencias estratégicas y que muestre las dependencias en donde sea más factible realizar reingeniería.

c) Conjuntar este trabajo a los trabajos desarrollados en el proyecto IRIS, de esta manera se observaran las diferentes etapas que conforman el proyecto, desde la captura de los requisitos con el usuario hasta la obtención de un prototipo.

d) Analizar los métodos actuales para aplicar Reingenieria

e) .Realizar un medio de análisis que puedan ser apoyados con esta herramienta. En pdcu la r tomando en cuenta los siguientes aspectos:

El modelo de Dependencia Estratégica provee un conjunto de conceptos para modelar procesos en téminos de dependencias intencionales entre actores. Provee un entendimiento profundo acefca de los procesos existentes.

Oportunidad y vulnerabilidad. El conjunto de nodos y ligas en el modelo forman un a red de dependencias. Siguiendo las cadenas de dependencias, uno puede explorar las posibilidades que tiene un actor para realizar algo. Un actor puede utilizar esa red dependencia para determinar como puede ser afectado advesamente por estas dependencias.

86

Concimionesy Tmbajos Futms

,l. ‘I/

Con la ayuda de los’dependees, un depender puede expandir sus oportunidades y lograr 10 que de’ otra forma no podría. Uno puede responder para este caso {Qué nuevas relaciones son posibles entre los actores? De, manera que al igualar las dependencias del depender (“deseos”) y la de los dependees (“habilidades”), puedan explorarse nuevas oportunidades que estén disponibles para esos actores. Analizando los dependums, el “lado débil” de una dependencia para un depender significa que el depender es vulnerable a la falla de la dependencia. Por tal razón el depender debe interesarse en la viabilidad de una dependencia.

11 ‘I

Mitigando la vulnerabilidad. Existen vaxios mecanismos que pueden Contribuir a fortalecer d a dependencia y a mitigar la vulnerabilidad.

I1 Un compromiso se cumple cuando existe alguna forma para que el depender logre alguna ‘meta si i l dependee falle.

Debe existir alguna evidencia de que el dependee libere el dependum además de cumplir con sus propias demandas. Por ejemplo, conocer que compromisos.tiene el dependee y asegurar que sean cumplidos. I/

,Los mecanismos de aseguramiento reducen la vulnerabilidad de un depender reduciendo el grado de dependencia hacia un dependee en particular. Un depender puede resolver la vulnerabilidad que tiene sobze un dependum si este dependum puede obtenerlo o lograrlo con .I ayuda de mas de un dependee. Por ejemplo, un paciente que quiere una segunda opinión en su condición medica y tratamientos hace uso de un mecanismo de aseguramiento. Un medico que &vía pniebas a dos laboratdios independientes.

Agentes, Roles y Posiciones. Las nociones más especializadas de los actores son agentes, roles y posiciones.

La distinción entre agente, role y posición permite identificar de manera separada las dependencias que son atribuibles a un role, como opuestas a aquellas que son directamente atribuibles a un agente concreto. Las medidas de desempeño, por ejemplo son características aplicables a un agente concreto. La educación y experiencia pertenecen a un agente, ya que corresponden al agente cuando el/ella se mueve a otra posición @or ejemplo el grado de medico lie un doctor). Los requedientos de calidad, sin embargo, pertenecen a las posiciones y a los roles (por ejemplo, la posición de jefe de planta). Los roles típicamente tienen dependencias que relacionan tareas o funcionks que un agente debe asociar o desasociar, por ejemplo hablar o moverse hacia una posición.

Cuando separamos estos “componentes” de un actor social, cada componente es una descripción parcial del actor social. Cada componente da alguna insinuación acerca de como el actor social debe portarse, o’se espera que se comporte en algún contexto estrecho especihado.

:J Cada asociación de un agente a una posición o a un role pueden ser problemático. Por ejemplo, mientras haya ciertas expectaciones en un role, cuando este role es cubierto bajo una posición, la combinación de roles puede resultar en confictos que hace que esas expectaciones sean menos probables de ser cumplidas. Igualmente, una posición puede ocasionar expectaciones que un agente concreto con habilidades, conocimientos específicos que no pueden ‘corresponder exactamente.

87

ConclUsio0ne-y Trnbqas Futums

El modelo de Dependencia Estratégica presenta una imagen de los agentes al modelar explícitamente solo sus relaciones intencionales externas con cada uno de los otros. Las semánticas de estas relaciones externas, sin embargo, son caracterizadas en términos de algunas características intencionales externas presuntas del agente. Se asume que la estructura intencional interna de un agente incluye al menos los siguientes tres componentes: un conjunto de rutinas, un conjunto de reglas medio-fm y un conjunto de “elementos trabajables primitivos”.

Rutinas. La caracterización interna de un agente se centra alrededor de las .rutinas que son dirigidas por el agente y los elementos que integran la rutina. Una rutina es el vehículo principal a través del cual un agente puede lograr lo que este quiere. Esta es una plantilla para las actividades recurrentes de los agentes. Una rutina consiste de elementos, los cuales incluye submetas, subtareas, recursos y metas suaves. Pueden existir relaciones entre elementos especificados como restricciones, d e s como precedencia temporal. Una rutina puede ser vista como el esqueleto de un plan.

Habilidad. Cuando un agente tiene una rutina que puede servir a algún propósito, e.g., lograr una meta determinada, decimos que el agente tiene habilidad para lograr la meta.

Trabajabiiidad. Para indicar que un agente cree que algunas rutmas deben trabajar, siempre y cuando no estén completamente especificada. Se juzga que una rutina es trabajable si cada uno de sus elementos mencionados son aabajables y si todas las restricciones en la rutina se espera que sean manejadas. Un elemento trabajable primitivo es aquel que es juzgado a ser trabajable sin una reducción futura. En el modelo de dependencias estratégicas el principal interés en las rutinas es la parte de delegación.

88

, . '!

Anexo

R.eX0 1

Datos

Public Sbing nombreAtributo; public String tipoAtribut0;

Diqrama de Ckases

Métodos Constructor asigna nombre del atributo asigna el tipo del atributo devuelve nombre del atributo devuelve el tipo del atributo

public interiaces(String nomAtributo, String tAtributo) public void setnombreAtributo(Stñng nombre) public void senlpoAtributo(String tipo) public String getnombreAtributo() public String gettipoAtributo0

Atributos y Operaciones del Diagrama de Clase.

Datos

public String nombreAtributo; public String BpoAtributo; public String ValorAtributo;

Métodos constructor public atributos() asigna nombre del atributo asigna el tipo del atributo asigna el valor defauii del atributo devuelve nombre del atributo devuelve el tipo del atributo devuelve el valor default del atributo

public void seinombreAtributo(Sirhg nombre) public void settipoAtributo(String tipo) public void setvalorAtributo(String valor) public String getnombreAtribuio() public String geitipoAtributo() public String getvalorAtributo0

public Stnng parametro. public Stnng tipo; ir^

I

Datos I Métodos oublic Strina nombreEvento: I constructor nublic eventos0

asigna nombre del evento puDiic void setnombreEvento(Stnng nombre) 1 asigna e, nombre del parametro que se recibió

I as'gna el tipo de pardmetro del evento public void setTipo(String tip) devuelve nombre del evento devuelve el nombre del parametro devuelve el tipo del parametro

public voia setParametro(String param)

pbblic String gelnornnreEven1oO pubic Stnng QetParametroO pub1 c String getT PO()

Datos Public String nombreEvento; puüic string parametro; public String variable; puMc Wing valor; public String variable2; public String vaioR;

Métodos Constructor public vaiuacionesO asigna nombre del evento asigna el nombre del parámetro que se recibió asigna el nombre de la variable del evento asigna el valor que tomara la variable del evento public void setValor(String Val) asigna el nombre a la segunda variable del evento public void setVariaMeD(String Var) asigna el valor que tomara la variable dos del evento public void setValorD(String Val) devuelve nombre del evento de la evaluación devuelve el nombre del paremetro devuelve el nombre de la variable devuelve el valor de la variable devuelve el nombre de la variable dos devuelve el valor de la variable

public void setnombreEvento(String nombre) public void setParametro(String param) public void setVariable(String Var)

public String getnombreEvento0 public String getparametro0 public string getvariable0 public String getValor0 public Shing getvariable20 public String getValoR(1

Datos public String nombreEvento; public String parametro; public String atributo; public String valor;

90

Métodos constructor public precondiciones0 asigna nombre del evento de la precondcion public void setnombreEvento(String nombre) asigna el nombre del parámetro que se recibió public void setParametro(String param) asigna el nombre de la variable del evento public void setAtributo(String var) asigna el valor que tomara la variabie del evento public void setValor(String val) devuelve nombre del evento de la precondicion public String getnombreEvento0 devuelve el nombre del parámetro public String getparametro0 devuelve el nombre del atributo public String getAtributo0 devuelve el valor de la variable public String getValor0

Clases M8todos

Datos vedar Listclasec; ihi paselement; Public Clases clase; String nombreílase;

I

Datos ublic String NombClase;

EStrClaSes

Constructor de la clase Esticlases inmta una clase lata de Clases

irketta segundo idenüñcador

Inserta un atributo constante en la clase !)publicvoid InsertaConstantes(String nomClase. Siring nom, String tipo. Shing valor) Inserta un atributo variable en la clase

public void ImertaVanables(String nomClase, String nwn. String tipo. String valor) Inserta un evento en la clase

public void InsertaEvento(Str1ng nodlase. siring nom, String par, String tip) lnserla un evento al inicio del vedor de la clase

public void InsertaEventolniclo(String nomClase. String nom, string par. String tip. inti) Inserta una evaluación en la clase Public void InserlaValuaciones(String nomclase. String nom, String par, String var, Strin! val, String vaR. String va12) Inserta una precondicion en la clase Eublic void lnsertaPrecondiciones(Siring nomclase. String nom. String par, String atr String val) Devuelve el nombre de la clase que encuentre en la posición i

devuelve el nombre del idetiificador de la clase que encuentre en la posición i

Mútodos public Esticlases()

public void InsertaClase(String nomClase. String Hen. String tipolden)

public void lnsertaldentificador(String nomClase, String iden)

public String getClasqint i)

' public String g&Nomlden(int i)

ublic S t n i iden; ublic String tipolden; ubilic String iden2; ubllic String tipolden2; *or AiConstantes; edor &Variables; &or Eventos; &M Vaiuaciones; '&u PrecondiUones; 'HM Disparos = new Vedo(); '&u P m t o ~ ~ o s = new Vedoro; ublic atributos ACon; ublic atributos AV- ublic eventos Even; ubliC valuaciones valu; ublic precondciones Prec;

Z-tnidM public Clases(String nomclase. String iden, String tipolde. String iden2, 5tring tipolde2)

signa nmbre de clase sidna el identiffcadw de la clase asigna el tipo del idenüñcador asigna el segundo identiicador de la clase

asigna el tipo del segundo identificada imqla los abibutos constantes de una clase

imqia Im atdbutos variables de una clase

insgia los evenios de una clase

i n s l a los eventos de ueacion de destrucciái'al inicio del vector de eventas

inserta las valuaciones de una clase puMic void setValuaciones(String nom. String par, String var, String val, String var2 Shing va12) inserta las precondiciones de una clase

devuelve nombre de la clase devuelve nombre del identiifcador de la clase deheive tipo de identificaior devuelve nombre del segundo identificador de la clase devuelve tipo del segundo Hentificador devuelve el objeto de atributo constantes en determinada posición

/\public Objed getAiConstantes(int j) devuelve el objeto del atributo variable en deirninada posición

public Objed geWariables(int j) devuelve el objeto del evento en determinada pffiici6n devuelve el objeto de la valuación en determinada posición

public Objed getValuaciones(int j) devuelve el objeto de las precondicione en determinada posición

1) public Objed getPrecondiciones(inij) devuelve el lamano del vectw de atributos constantes . devuelve el tamaño del m o r de atributos variables devuelve el tamaño del Mdor de eventos devuelve el tamaño del vedor de valuaciones devuelve el tamaño del vedor de precondiciones devuelve el tamatio del vector de disparos

public void sewombreCiase(String dase) public void setidetiicacion(String identiifidor) public void setTipolden(String tlde)

public void setldenüñcaUonDos(String identificada) public void setTpoIdenDS(StriW tlde)

public void sdAtConstantes(String nom, String tipo, String val)

bublic void setAtVariables(String nom, String tipo, String val)

public void setEventos(String nom, String par, String tip)

p u M i void setEvenic6ln~qString nom, Siring par, String tip. ¡ni i)

,public void setPrecondciones(String nom. String par, Siring atr. String val) pubiic String getNombreClasq)

public Shing getlden() public String gettipolden()

public String gettipoldenDos() public String getldenDas()

public Object getEvento(int j)

public in1 siz&Comtanies() public int sizeWVariables() public int sizeEwntos() public int sizeValuaciones() public int sizeF'recondiciones() public int sizeDisparos()

91

Diagma de Ches Anexo 1 ..

Datos public String NombClase; public String Actor; public Vector Acciones=new Vector();

devuelve el tipo del idenlifeador de la clase que encuentre en la posición i public String getTipolden(int i)

devuelve el nombre del segundo identificador de la clase que encuentre en la posición i public String getNomldenüos(int i)

devuelve el tipo del segundo identificador de la clase que encuentre en la posición i public String getTipoldenüos(int i)

devuelve el nombre del atributo constante piblic String getNomConstante(in1i. in1 j) devuelve el tipo del atributo constante public String getTipoConstante(in1 i, int j) devuelve el valor del atributo constante public String getValorConstante(int i, int j) devuelve el nombre del atributo variable public String getNomVariabie(int i, int j) devuelve el tipo del atributo variable public String getTipoVariable(int i. int j) devuelve el valor del atributo variable public String getValorVariable(int i, int j) devuelve el nombre del evento public String getNomEvento(int i, int j) devuelve el nombre del parámetro del evento public String getParEvento(1nt i, inl j) devuelve el tipo del parámetro del evento public String getTipEvento(int i, int j) devuelve el nombre del evento de la evaluación public String getNomValu(int i, int j) devuelve el parámetro del evento de la evaluación public String getParValu(in1 i. int j) devuelve la variable del evento de la evaluación public String getVarValu(int i. int j) devuelve el valor de la variable del evento de la evaluación

devuelve la segunda variable del evento de la evaluación

devuelve el segundo valor de la variable del evento de la evaluación

devuelve el nombre del evento de la precondiclon ' public String getNomPrec(int i, int j) devuelve el parámetro del evento de la precondicion public String getParPrec(ht i, inl j) devuelve el nombre del atributo del la precondicion public String getAtrPrec(int i, int j) devuelve el valor del atributo del la pecondicion public String getValPrec(int i, int j) devuelve el tamatio del vector de atributos constantes public int sizeConstantes(int i) devuelve el tamafio del vector de atributos variables public int sizeVariables(int i) devuelve el lamafio del vector de eventos public in1 sizeEventos(int i) devuelve el tamafio del vector de valuaciones public int sizeVaiuaciones(in1 i) devuelve el tamatio del vector de precondiciones public int sizePrecondiciones(int i) devuelve el tamatio de la lista de Clases public int size0 devuelve la posición del elemento que se busca, compara que exista el nombre de la ClaSf y el nombre del actor del cual se depende public void ExisteElemento(String dato)

public String getValValu(int i. int j)

public String getVarValu2(int i, int j)

public String getValValuZ(int i, in1 j)

Metodos Constructor

asigna nombre de clase public Interfaces(String nomclase, String actorüepende, String aXiOn)

public void sev\ctores(String act) public void setAccion(String accion)

public void setNombClase(String Valor) asigna nombre del actor inserta Acciones devuelve nombre del actor dependiente devuelve nombre del actor del cual se depende devuelve el nombre de la acción de determinada pOSiCi6n

devuelve el tamafio del vector de acciones

public String getNombCiase0 public String getNombActor0

public String getNombAIUon(int j) public in1 sizeAccionO

Datos vector Listinlerfaces; int poselement; public Interfaces interfaz; String nombreclase;

Métodos Constructor de la interface public EstrlnterfacesO Inserta interfaz a lisla de interfaces

Devuelve el nombre de la clase que encuentre en la posición i

devuelve el nombre del actor que se encuentre en la posición i

devuelve valores de la acción que se encuentre en dicha posición

devuelve el tamafio del vector de acciones devuelve el tamaño de la lista de Interfaces devuelve la posición del elemento que se busca, compara que exista el nombre de la clase y el nombre del actor del cual se depende

public void InsertalnteIfaz(S1ring nomc, String act, String accion)

public String getClase(int i)

public String getActor(int i)

public String getAccion(in1 i, int j) public in1 sizeAcciOn(int i) public int Size0

public void ExisteElemento(String dato, String nombre))

92

Sinng tipoDependencia

.I!:

comtructa public rdentifica-dependenciaO Idenifica, clasifica y enna el tipo de la dependenaa public Siring iden(Stnng s)

111

'I.

i;

'I

93

~~ ~~ ~

Referencias

.[Ah0881

[Aqvist84]

[Calvez981

[Clarke961

Aho, Alfred V., Ravi Sethi b] Jeffrey D. Ullman, Compilers, Principles, Techniques and Tools (Addison-Wesley, 1988).

Aqvist L. Deontic logic. in D.M. Gabbay and F. Guentfiner, editors, Handbook of Philosophical Logic 11. 1984

Calvez J.P., Heller H., Muller F. b] Pasquier O. “A programable Multi-Language Generator for CoDesign” (en: Proccedings of the Design Automation and Test in Europe (DATE’98), February, 23-26,1998, Pm’s, France).

Clarke, Edmund M. [y] Wing, Jeannette M., “Formal Methods: State of the Art and Future Directions”, (Report bv the Working G r o w on Formal Methods for the ACM Workshop on Strategic Directions in Cornputins Research. ACM Computing Surveys, vol. 28, no. 4, (December 1996))>p. 632.

penker99b] Denker G. H. ,571 Enrich D., “TROLL : Desarrollo de un lenguaje de Especificación Orientada a Objetos para el diseño de Sistemas de Información”. (Página htto://\invw.cs.tu-bs.de/idb/html e/~rofile/node6.hm7I#dieor~) Diciembre 10, 1999.

Denker G. H. b] Hartel P. , “TROLL.- An Object Oriented Formal Method for Distributed Information System Design: Syntax and Pragmatics” (Página ht tp: / /~~~~.cs .hi-bs .de/ idb/I i tml e /1~rof i le /no~e3.~i tml#~ieo~) Junio de 1999.

Denker99aI

[Fischer88] Fischer N. Charles b] LeBlanc, Jr Richard J Crafting a Compiler (The Benjamin/Cummings Publising Company, 1988).

Hammer Michael, Reengineering Work Don’t Automate, Obliterate ( Harvard bussiness Review, 1990)

Hammer Michael ,571 Champy James, Reingeniería, (Grupo editorial Norman, Traducción Jorge Cárdenas Nannetti, 1994)

Letelier P., Ramos I., Sánchez P., Pastor O., “OASIS 3.0: Un enfoque formal para el modelado conceptual Orientado a Objetos”, (Servicio de publicaciones, Universidad Politécnica de Valencia, 1998)

Liu .X., Yang H.,b] Zedan H., “Formal Methods For Re-engineering Of Computing Systems: A Comparison”, (Proceedings of the COMPSAC 97 - 21”. International (Computer and Applications Conference)l997) p. 1

plarnmer90]

[Hammer94]

Fetelier98]

Liu97

~ylopoulos90] Mylopoulos J., Borgida A,, Jarke M. ,571 Koubarakis M., “Telos: Representing Knowledge about Information Systems”, ( EN: ACM Transactions on. Information Systems Vol. 8, NO,.^ (Oct. 1990)), pp. 325-3628.

94

Refetennciar

,[Oi/are96] O‘Hare G.M.P:) N.R. Jennings and Wiiey, Foúndations of Distributes Artificial r Intelligence, 1996

[Pastor9‘T] i

Pastor O., Insfrán E., Pelechano V., Romero J., [y] Merseguer J., “00- METHOD: AnltOO Software Production EnWoment Combining Conventional and Formal Methods”, Barcelona España, (Conference on Advanced Information Systems Engineering (CASE ’97)) 1997, p. 2.

I!

pertti981 Pertti Kellomaki. “The Disco Language”. ( Página htto://www.cs.tut.fisCo/lanma&Lanwt?e.htmi) Agosto 6 de 1998

P)ressman98] Pressman Roger S. Ingeniería de Software: Un enfoque practico (cuarta edición, México, Mc Graw-Hill, 1998) pp. 205 y 206

Ruble, David A. Análisis y Diseño de sistemas Cliente - Servidor con Interfaces GIU (Prentice Hail, 1998)

Ruiz Garcia, S.Y. Or&, H. J. Núñez E. G. Sheremetov B. L. “ADAN, un Ambiente Visual para el Desarrollo del Conocimiento en Sistemas de Aprendizaje Colaborativo”, (6to. Congreso Internacional de Investigación en ciencias Computacionales (CIICC’99)) 1999

Thayeer H. Richard b] Dorfman Morlin, Software Requirements Engineering. (segunda edición, IIE, computer Society Press, Los Alamitos California, 1997).

I1

[Ruble981

[Rui$99]

Phayeer971

wing901 Wing Jeannette M. “A Specifier‘s Introduction to Formal Methods”, (EN: IEEE Computer (Septiembre de 1990), pág 8.

E. Yu and J. Mylopoulos, “From E-R to ‘A-R’ -- Modelling Strategic Actor Relationships for Business Process Reengineering,” Entity-Relationship Approach (ER’94) -- Business Modelling and Re-Engineering (Proceedings of

l 13th Int. Conf: on the Entity-Relationship Approach, Manchester, U.K., (December 1994)), Lecture Notes in Computer Science no. 881, Springer-Verlag. P. 554

Yu, E. S. K, ‘‘Modelling Strategic Relationships for Process ReEngineering”, Ph.D. Thesis. Department of Computer Science, University of Toronto, 1995.

E. Yu, “Models for supporting the Redesign of Organizational work”, (EN: l’roc. Conf. On Organizational Computing Systems (COOCS ’95), Milpitas, California, (August 1995)), pp. 225 - 236.

E. Yu, J. Mylopoulos, and Y. Lesperance, “AI Models for Business Process Reengeering”, (EN: IEEE ExDert, (August 1996)), p. 18

vu941 1

[yu95a]

[Yu95b]

vu961

95

vu97aI E. Yu, “Why Agent-Oriented Requirements Engineering”, (EN: Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ97, Barcelona, Catalonia, Spain, (June 1997)), pp. 171-183.

E. Yu and J. Mylopoulos, “Modelling Organizational Issues for Enterprise” Fu97bI

96