Tallerescolegasusta

8

MONOGRAFIA

NOVATICA ene./feb. 2000 nº143

La Orientación a Objetos hoy

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

Diseñar la empresa: una jerarquía de medios y fines
© Trygve Reenskaug Traducción: César Pérez-Chirinos

Introducción del traductor: este artículo es un anticipo del trabajo en curso de Trygve Reenskaug, quien ha tenido laamabilidad de responder a la invitación de Novática elaborando apresuradamente las líneas que siguen con destino expreso para este número. Para quien no le conozca, el Dr. Reenskaug es una de las personas más respetadas en el área de la Ingeniería de Software. Inventor del concepto ModeloVista-Controlador y del marco metodológico OOram, en la actualidad es revisor para el Object Management Group (OMG) dela notación UML. Mi intención original era traducir uno de los artículos publicados en su página web sobre modelización de sistemas distribuidos usando el Modelo de Referencia de ISO para Proceso Distribuido Abierto (ODP) y UML. La extensión y relativa aridez del mismo, junto con la agradable sorpresa de poder ofrecer este anticipo a los lectores de Novática me han hecho cambiar de opinión. Porfavor, léanlo sin prejuicios y nos volvemos a encontrar al final del artículo.

nos deja enlazar información entre los diferentes niveles siempre que escojamos hacerlo así.

1. Reconocimiento de la necesidad de introducir algún 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 gestión de las cuentas de gastos de viaje, ya que no nos satisface la forma en que actualmente se lleva. En un caso real, nos extenderíamos mucho más sobre qué queremos conseguir y porqué.

2. Elección del contexto/fronteras de la solución
Definición: un sistema es una parte del mundo real que escogemos contemplar como un todo, separado del resto del mundo durante algúnperiodo de consideración. Un todo que elegimos considerar como una colección 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 almismo 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 gestión de viajes y no modelamos detalles acerca de sus motivos, ni cómo el viajero recupera los desembolsos realizados. Además, no queremos cambiar elplan actual de nuestra organización. Todo está aún 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 específico? ¿Debe autorizar el formulario algún apoderado? ¿Necesita el viajero autorización previa al viaje? ¿Debe ser esta autorización verbal oformal?

Sumario y conclusión
En este artículo exploro la relación entre las necesidades y soluciones en los niveles más generales [de la empresa] y los posibles sistemas de información y sus soluciones en los niveles inferiores. Lo que encuentro es una jerarquía de fines y medios, en la que la especificación de los sistemas informáticos puede considerarse como una decisión de diseño de bastantebajo nivel. Propongo la siguiente jerarquía: - Reconocimiento de la necesidad de introducir algún cambio o mejora en la empresa. - Elección del contexto/fronteras de la solución. - Diseño de los procesos de negocio (asignación de responsabilidades, quién hace qué y cuando). - Descripción de las tareas del personal. - Selección de tecnología y arquitectura del sistema. - Diseño detallado de las...