8

MONOGRAFIA

NOVATICA ene./feb. 2000 n143

La Orientacin a Objetos hoy

Trygve Reenskaug
trygve.reenskaug@ifi.uio.no http://www.ifi.uio.no/~trygver

Disear la empresa: una jerarqua de medios y fines

Trygve Reenskaug Traduccin: Csar Prez-Chirinos

Introduccin del traductor: este artculo es un anticipo del trabajo en curso de Trygve Reenskaug, quien ha tenido la amabilidad de responder a la invitacin de Novtica elaborando apresuradamente las lneas que siguen con destino expreso para este nmero. Para quien no le conozca, el Dr. Reenskaug es una de las personas ms respetadas en el rea de la Ingeniera de Software. Inventor del concepto ModeloVista-Controlador y del marco metodolgico OOram, en la actualidad es revisor para el Object Management Group (OMG) de la notacin UML. Mi intencin original era traducir uno de los artculos publicados en su pgina web sobre modelizacin de sistemas distribuidos usando el Modelo de Referencia de ISO para Proceso Distribuido Abierto (ODP) y UML. La extensin y relativa aridez del mismo, junto con la agradable sorpresa de poder ofrecer este anticipo a los lectores de Novtica me han hecho cambiar de opinin. Por favor, lanlo sin prejuicios y nos volvemos a encontrar al final del artculo.

nos deja enlazar informacin entre los diferentes niveles siempre que escojamos hacerlo as.

1. Reconocimiento de la necesidad de introducir algn cambio o mejora en la empresa

Se trata de una necesidad del negocio; algo que queremos cambiar, mejorar o introducir porque nuestro negocio lo requiere. Ejemplo: necesitamos organizar la gestin de las cuentas de gastos de viaje, ya que no nos satisface la forma en que actualmente se lleva. En un caso real, nos extenderamos mucho ms sobre qu queremos conseguir y porqu.

2. Eleccin del contexto/fronteras de la solucin

Definicin: un sistema es una parte del mundo real que escogemos contemplar como un todo, separado del resto del mundo durante algn periodo de consideracin. Un todo que elegimos considerar como una coleccin de partes, cada una de las cuales est caracterizada por atributos y por acciones que pueden involucrar a ella misma y a otras partes. Para un sistema dado, el contexto es el conjunto de todos los objetos externos al sistema cuyas acciones afectan al sistema o que son afectados por l, as como aquellos objetos externos al mismo cuyos atributos cambian a causa de sus acciones. De esta forma describimos el sistema como una caja negra, identificando los objetos del contexto (actores) y los mensajes que fluyen de y hacia dichos objetos. Ejemplo: nos centramos en la gestin de viajes y no modelamos detalles acerca de sus motivos, ni cmo el viajero recupera los desembolsos realizados. Adems, no queremos cambiar el plan actual de nuestra organizacin. Todo est an muy abierto. No hemos decidido si queremos ser indulgentes o muy formalistas. Puede el viajero solicitar un anticipo al cajero? O tiene que aportar recibos? O un informe de gastos en un formulario especfico? Debe autorizar el formulario algn apoderado? Necesita el viajero autorizacin previa al viaje? Debe ser esta autorizacin verbal o formal?

Sumario y conclusin
En este artculo exploro la relacin entre las necesidades y soluciones en los niveles ms generales [de la empresa] y los posibles sistemas de informacin y sus soluciones en los niveles inferiores. Lo que encuentro es una jerarqua de fines y medios, en la que la especificacin de los sistemas informticos puede considerarse como una decisin de diseo de bastante bajo nivel. Propongo la siguiente jerarqua: - Reconocimiento de la necesidad de introducir algn cambio o mejora en la empresa. - Eleccin del contexto/fronteras de la solucin. - Diseo de los procesos de negocio (asignacin de responsabilidades, quin hace qu y cuando). - Descripcin de las tareas del personal. - Seleccin de tecnologa y arquitectura del sistema. - Diseo detallado de las herramientas. Determinacin de los casos de uso. - Especificacin de los servicios de informacin inexistentes. - Diseo e implementacin de los servicios de informacin informatizados (p.ej. como Enterprise JavaBeans). - Diseo e implementacin de las interfaces de usuario (herramientas) que soporten las operaciones de los usuarios. Me gusta este enfoque. Permite el uso de formalismos si y cuando los queremos, mientras que otras partes pueden mantenerse informales e incluso indocumentadas. Adems

NOVATICA ene./feb. 2000 n143

Y ciertamente no hemos tomado decisin alguna sobre la utilizacin de un sistema informatizado.

3. Diseo de los procesos de negocio (asignacin de responsabilidades, quin hace qu y cuando)

Ahora responderemos muchas de las cuestiones que dejamos planteadas en el nivel precedente. Diseamos un proceso de negocio que implementa una solucin a nuestra necesidad original. Y seguiremos sin hacer an suposiciones sobre ordenadores o telecomunicaciones! Hay una diferencia significativa entre un proceso de negocio y un proceso informatizado. Un proceso de negocio describe la forma bsica de hacer algo, siendo los casos reales variantes de esta forma bsica. En contraste con esto, un proceso informatizado encierra todas las ejecuciones posibles, no pudiendo haber variantes al margen de los lmites del procedimiento. Decidimos que queremos un procedimiento bastante formal en el que un Autorizador aprobar el viaje de antemano y tambin la cuenta de gastos de viaje a su conclusin. El siguiente diagrama de secuencia ilustra el procedimiento propuesto:

Todava no hemos considerado la posibilidad de usar computadoras. Esta es una decisin de diseo que se pospone hasta el nivel 5, en el que escogemos la tecnologa a emplear.

4. Descripcin de las tareas del personal

Pensamos en trminos de decisiones y productos resultantes (deliverables) sin considerar la tecnologa auxiliar. Por ejemplo, el Autorizador que recibe una solicitud DePermisoDeViaje podra realizar la tarea siguiente (que es un mtodo del objeto Autorizador):

Viajero

Autorizador
solicitudDePermisoDeViaje() <Comprobar los compromisos del viajero> <Comprobar presupuesto de viajes> <Decidir> <Enviar la respuesta>

permisoDeViaje()

Seguimos sin tomar decisiones sobre informatizacin. Pero ahora tenemos una descripcin razonablemente estructurada de lo que queremos que ocurra, que nos ayuda a decidir dnde y cmo usar computadoras.

5. Seleccin de tecnologa y arquitectura del sistema

A continuacin presentamos el diagrama de colaboracin. Una Colaboracin describe una Interaccin particular, los objetos implicados en esta Interaccin y cmo interaccionan estos objetos durante dicha Interaccin. Un rol (RolClasificador, ClassifierRole [en UML]) describe un objeto en un contexto concreto de otros objetos durante una Interaccin concreta.
/Viajero
* 1

Al fin, y tras este largo proceso, llegamos al punto en que consideramos la seleccin de tecnologa. Ante nosotros se abre un amplio abanico de posibilidades, que va desde sistemas basados exclusivamente en papel hasta una informatizacin total de las operaciones. De forma un tanto arbitraria decidimos basar todo el procedimiento en un sistema informtico. Decidimos igualmente equipar a parte de los participantes con herramientas a medida para darles el mximo apoyo en sus tareas. Una primera consecuencia de esta eleccin es que necesitamos almacenar informacin sobre los viajes en un servicio de almacenamiento que debe estar disponible en la red. Pero viendo las descripciones de las tareas, encontramos igualmente que nuestros usuarios necesitan acceder a los planes y presupuestos de la empresa. Supongamos que ya tenemos instalado un componente de servicios de Planificacin y un componente de servicios de Presupuesto. Procedemos a comprobar si estos componentes

/Autorizador

0 1

/Contable

0 1

/Tesorero

Ahora ya hemos tomado muchas decisiones. Hemos decidido quin estar implicado en gestionar un viaje, as como sus responsabilidades. Hemos determinado tambin disparadores y flujos de datos tpicos, y las tareas a realizar por cada participante. El modelo es bastante concreto. No hemos considerado clases ni diagramas de clases (UML). Ni los necesitamos, ni los queremos a este nivel.

10

NOVATICA ene./feb. 2000 n143

soportan las operaciones requeridas por las tareas. Suponiendo que esto es as, terminamos con una arquitectura del sistema. La arquitectura para la herramienta de aprobacin del Autorizador es la ilustrada en la figura:

llevar a casos de uso adicionales. Estos casos de uso especifican qu pueden hacer los usuarios con las herramientas. [Al considerar que] este uso ha de pasar por las herramientas para conseguir las operaciones de los servicios, obtenemos una primera imagen de las interfaces de los servicios. Probablemente, hace mucho tiempo que adoptamos una tecnologa comn para los servicios de informacin; p.ej. Enterprise JavaBeans. Esta decisin, que cae fuera del mbito de los proyectos individuales como el de nuestro ejemplo, matizar nuestras opiniones en cierto grado.

ServiciosDePresupuesto

HerramientaDeAutorizacin

ServiciosDePlanificacin

Autorizador

ServiciosDeGastos DeViaje

6. Diseo detallado de las herramientas. Determinacin de los casos de uso

Quiz podamos usar herramientas estndar para alguna de las operaciones. Quiz podamos usar la misma herramienta para varias operaciones. Es claro que tendremos que iterar entre el diseo detallado de las herramientas y la arquitectura, tratando de alcanzar un buen equilibrio entre costos y beneficios. Ser una buena idea desarrollar una serie de estudios, cada uno de los cuales explore una alternativa. Los estudios podran sacar provecho del prototipado de herramientas. Por ejemplo, sta es una posible herramienta para el Autorizador que est considerando aprobar una solicitud de viaje:

8. Diseo e implementacin de los servicios de informacin informatizados (por ejemplo Enterprise JavaBeans)
Usamos cualquier mtodo aplicable.

9. Diseo e implementacin de las interfaces de usuario (herramientas) que soporten las operaciones de los usuarios
Usamos cualquier mtodo aplicable.

Apostilla del traductor

Confieso la perplejidad que me caus la primera lectura de este artculo. Al principio, la achaqu a que, evidentemente, no se trata de un trabajo concluido, como nos comenta el propio Reenskaug. Sin embargo, los nueve niveles que propone estn claramente identificados. De dnde surge, pues, la desazn? Dado que este nmero debe cerrarse en fecha y no hay tiempo material para contrastar con el autor este punto, me arriesgar a dar mi punto de vista, y prometo compartir con los lectores en un prximo artculo la respuesta del Dr. Reenskaug a mi conjetura. Comenzar mi apostilla con una ancdota sobre el autor. Tuve el placer de asistir a su conferencia en las IV Jornadas de TO en Deusto en 1998 en la que, bajo el ttulo Las cuatro caras de UML, hizo una demoledora crtica sobre la trivialidad de UML 1.0 y sus insuficiencias. Sin embargo, fue tan sutil y educada que nadie se atrevi a preguntar nada. Slo un profesor (que no identificar) se atrevi a decirle tmidamente, ya en privado: No cree usted que no han entendido su charla? Ha dicho cosas tan tremendas1 que debera haberse suscitado una gran polmica.... Trygve le mir con cara de guasa y se limit a sonrer. Creo que lo inquietante de este artculo no es lo que dice, sino lo que piadosamente omite. Acabamos de asistir al derrumbe del suffl del efecto 2000 y supongo que, si alguien pidiera cuentas sobre el dinero invertido en crear el problema primero y en supuestamente? resolverlo despus, la respuesta de este gremio sera algo as como ya hemos escarmentado; de ahora en adelante trabajaremos con metodologas y haremos especificacin de requerimientos previamente. Lo que a alguien que conozca castellano y desconozca nuestra jerga le har pensar que sabemos tan

Un diagrama de mtodos ms elaborado con base en esta herramienta se muestra en la figura 1.

7. Especificacin de los servicios de informacin inexistentes

Usamos los requisitos de informacin de la forma bsica de la tarea para especificar el modelo de informacin de los gastos de viaje. Tambin consideramos la informacin que ser necesaria en variaciones de la forma bsica. En este trabajo nos sern de ayuda las entrevistas con participantes clave, tradicionales en la especificacin de bases de datos. Similarmente consideramos los casos de uso que resultan de las operaciones de la tarea, recordando de nuevo que hemos descrito slo los casos bsicos y que las variantes pueden

NOVATICA ene./feb. 2000 n143

11

Figura 1

poco sobre cmo realizar nuestro trabajo que, en lugar de seguir un mtodo de trabajo establecido y contrastado, tenemos que hacer un estudio metodolgico previo para elegir la forma de resolver su problema, y que nuestra desconfianza hacia el cliente har que todas nuestras aclaraciones terminen siguiendo la amenazadora va del requerimiento notarial. El problema que creo que asoma las orejas por detrs del artculo precedente, y crea ese desasosiego, es el de si es en absoluto posible que los sistemas de informacin respondan a las necesidades reales de las organizaciones que los pagan, dado el abismo terminolgico y las prioridades discrepantes entre gestores y tecnlogos. Teniendo en cuenta que el propio Reenskaug escribi en 1997 un artculo con el ilustrativo ttulo de Porqu los programadores no usan mtodos y qu podemos hacer al respecto, y que explcitamente relega a los dos niveles inferiores, de los nueve considerados, la utilidad prctica de los mtodos actuales, lo que creo que est haciendo es reformulando el problema en los trminos de (sta vez si) metodologas ms generales, como la SSM de Checkland, en las que se asume que hay otros factores de tipo cultural y psicolgico que son tanto o ms relevantes que el tecnolgico a la hora de disear organizaciones eficaces y eficientes. Qu opina el lector? Estamos realmente incapacitados para comunicarnos fuera del mbito de nuestros colegas inmediatos (y no slo por afn de protagonismo)? Somos ya tan imprescindibles e incomprensibles para la sociedad como los expertos en mecnica cuntica? Si es as, vienen (por fin!) tiempos exigentes: slo se van a poder vender

resultados objetivos y mensurables, respaldados por una asuncin de responsabilidades sobre vicios ocultos. Es lo que ha venido ocurriendo histricamente cuando se ha optado por convertir al cliente en mero consumidor...

Notas
1

Por ejemplo, dijo que el diagrama de clases es perfectamente irrelevante, ya que cualquier entorno de desarrollo presentable nos presentar una vista semejante para facilitarnos el acceso al cdigo.