1. Modelando Patrones de Organización
Francisco Luis Gutiérrez1
, José Luis Isla2
, Miguel Gea1
1
Departamento de Lenguajes y Sistemas Informáticos
E.T.S. de Ingeniería Informática, Periodista Daniel Sucedo Aranda s/n,
Universidad de Granada, 18071, Granada, España
{fgutierr,mgea}@ugr.es
2
Departamento de Lenguajes y Sistemas Informáticos
E.S. Ingeniería, c/ Chile, 1
Universidad de Cádiz , 1002 España
Joseluis.isla@uca.es
Resumen. Hoy en día, los sistemas de información operan dentro de un
contexto muy dinámico, en el que se produce una constante evolución del
sistema. Uno de los aspectos que mas cambios sufre es la estructura
organizativa de los usuarios que interactúan con él. Debido a esto, es necesario
desarrollar metodologías que favorezcan el análisis y la representación de este
dinamismo.
En este trabajo se propone ver un sistema de información como una estructura
social donde la organización de los usuarios es un elemento clave para el
análisis y el modelado del comportamiento del sistema. Se presenta un modelo
conceptual de los distintos elementos que aparecen en una estructura
organizativa y cómo se puede usar la metodología AMENITIES para
representar no sólo estructuras organizativas de sistemas particulares sino su
generalización usando patrones conceptuales.
Palabras clave: Sistemas de Información, metodologías de desarrollo de software,
modelado de organizaciones, patrones conceptuales.
1 Introducción
Actualmente los sistemas de información son cada vez más complejos, debido sobre
todo a los cambios tecnológicos que actúan sobre ellos. Desafortunadamente las
arquitecturas propuestas y las metodologías utilizadas en su desarrollo no soportan, en
gran medida, esta evolución constante a la que se ven sometidos. Una buena forma de
analizar y modelar un sistema consiste en partir de la idea de que un sistema de
información es una estructura social [1] que evoluciona de forma dinámica. Los
miembros de dicha estructura se encargan de realizar una serie de actividades
productivas para el negocio del sistema .
Las metodologías de desarrollo tradicionales tienden a modelar los sistemas
realizando un clara separación entre, por un lado, los usuarios y las actividades que
realizan en el sistema y por otro, el contexto en el que los usuarios se desenvuelven y

2. realizan dichas actividades. En la mayor parte de los casos esta situación no provoca
muchos problemas. Cuando nos proponemos modelar sistemas complejos, como
pueden ser sistemas en los que múltiples usuarios colaboran para la realización de
actividades comunes (sistemas colaborativos [2]), esta separación no está nada clara,
ya que al realizarla no podemos representar aspectos tan importantes (para estos
sistemas) como las responsabilidades que tiene cada uno de los usuarios o las
relaciones y dependencias que aparecen entre cada uno de ellos.
Vemos que es necesario introducir el concepto de estructura social como una
colección de actores y un conjunto de dependencias sociales entre ellos. Esto nos va a
permitir describir de una forma más precisa las responsabilidades a asignar a cada uno
de los miembros del sistema.
En la literatura aparecen distintas aportaciones relacionadas con la modelización de
estructuras sociales, siendo la mayor parte de ellas utilizadas para la representación de
sistemas MAS (Multi-Agent Systems) [3,4,5]. En estos modelos se presta una mayor
atención a la arquitectura del sistema viendo a los agentes como elementos sociales
dentro de una organización compleja. Sin embargo, para la representación de
organizaciones sociales en sistemas de información también es muy importante poder
reflejar la naturaleza cambiante de la organización.
En la siguiente sección se presenta un modelo conceptual con los principales
elementos que aparecen en una estructura organizativa, En la sección 3 se expone
cómo podemos utilizar la metodología AMENITIES para modelar organizaciones. En
las siguientes secciones presentamos la forma en la que podemos realizar
descripciones de patrones de organización y cómo nos facilitan la utilización de la
metodología. Finalmente, presentamos las principales conclusiones y trabajos futuros.
2 Modelo conceptual de organización
Para modelar la estructura social subyacente a un sistema de información es
importante incluir el concepto de “Rol”. Un “Rol” es una abstracción de las
actividades, una o más, que una agrupación de usuarios del sistema puede realizar en
un instante determinado.
Podemos abordar el problema de la modelización de la estructura social de un
sistema desde dos puntos de vista. Por un lado, agrupamos los posibles usuarios del
sistema en suborganizaciones dependiendo de las actividades que pueden realizar y
fijándonos en aspectos como las restricciones en cuanto al número de miembros de
cada una de estas suborganizaciones. En este caso estamos modelando la parte
estática de la organización. Por ejemplo, en el caso de un departamento de la
Universidad podemos detectar la existencia de distintos subgrupos de los profesores:
el del director, el del secretario y el de un conjunto de comisiones encargadas de
realizar actividades relacionadas con la gestión (comisión de investigación,
económica, ...).

3. Desde otro punto de vista necesitamos modelar cómo un usuario puede llegar a
formar parte de cada una de dichas suborganizaciones y cómo sus miembros pueden ir
evolucionando a lo largo del tiempo (¿puede un profesor llegar a director?, ¿cómo se
alcanza el rango de secretario?, si no está el director, ¿puede alguien de la
organización llevar a cabo sus funciones?, ...). En este caso nos fijamos en los
aspectos dinámicos de la organización, en su posible evolución a lo largo de la vida
del sistema.
El modelo conceptual que proponemos para la descripción de una organización es el
que describimos en la figura 1 usando un diagrama de clases de UML. Este diagrama
es similar a los que se han utilizado tradicionalmente en el modelado de sistemas
colaborativos [6,7,8].
Fig. 1 Modelo organizativo
En el anterior diagrama podemos observar cómo se refleja que una organización está
formada por un conjunto de actores, dentro del concepto “Actor” se engloban tanto
usuarios individuales del sistema como subunidades organizativas de rango inferior a
la organización.
Como ejemplo de suborganizaciones podemos introducir el concepto de grupo (tipo
de UnidadOrganizativa). Un grupo se define como un conjunto de usuarios que, de
forma esporádica, se unen para la realización de una o más actividades. Otro ejemplo
nos lo da el concepto de departamento, definido como una división estructural de la
organización. Si analizamos los ejemplos anteriores, observamos que existen dos
tipos de suborganizaciones: las estáticas, que describen la estructura general de la
organización y las dinámicas, que modelan agrupaciones de usuarios que se crean
para la realización de una tarea concreta.
Cada actor, ya sea un usuario o uno de los elementos de la unidad organizativa,
desempeña un rol determinado en el sistema en cada instante. El desempeño de un rol
implica la posibilidad o capacidad de poder realizar un conjunto de actividades
asociadas al mismo.
Por último, podemos observar cómo entre roles (refiriéndonos al conjunto de los
actores que están desempeñando el rol en un instante de tiempo) y unidades
Organización
Actor
Usuario
Actividad
desempeña
desempeña
Rol
dependenciaOrganizativ a
UnidadOrganizativa
dependenciaOrganizativ a

4. organizativas se refleja una o más relaciones denominadas dependencias
organizativas. Con estas asignaciones se modelan las relaciones del tipo: posibilidad
de pasar de un rol a otro, una suborganización puede ser parte de otra suborganización
mas general, etc. En resumen, estas dependencias describen las restricciones entre los
conjuntos de posibles usuarios del sistema.
3 Metodología AMENITIES. Vista de grupo
AMENITIES [9,10,11] (acrónimo de A Methodology for aNalysis and DesIgn of
CooperaTIve systEmS) es una metodología basada en modelos de comportamiento y
tareas para el análisis, diseño y desarrollo de sistemas cooperativos.
A nivel conceptual, la metodología AMENITIES incorpora un conjunto de elementos
orientados a la descripción de la estructura del sistema en base a la organización del
mismo. Dentro de ellos, los mas relevantes son: el grupo, el rol, los actores, la
organización y el contexto entendido como la situación de la organización ubicada en
una dimensión espacial y temporal.
AMENITIES, para modelar los elementos dinámicos de la estructura organizativa de
un sistema, introduce dos tipos de restricciones:
• Ley: Una ley es una restricción impuesta por el sistema a la propia
organización. Las leyes vienen impuestas por el propio entorno (como
normas) o por organizaciones de orden superior.
• Capacidad: Es una habilidad que un actor o grupo puede llegar a lograr
dentro del sistema. Esta capacidad puede estar ligada a aspectos cognitivos
(aprendizaje), destrezas (ser experto en...) o cualidades (propiedades o
atributos).
Ambas restricciones facilitan la modelización de sistemas dinámicos, ya que es
habitual que tanto la estructura del grupo como su comportamiento se modifique en el
tiempo. Los participantes pueden adquirir nuevas capacidades, variar el número de
miembros que conforman un grupo de trabajo, aplicar nuevas estrategias de trabajo,
etc., pero siempre cumpliendo con las leyes que establecen las normas que rigen el
comportamiento general del sistema.
Todos estos elementos se ven reflejados en una de las cuatro vistas [11]
proporcionadas por AMENITIES de un sistema. Estamos hablando de la vista
organizacional, en la que usando un diagrama basado en los diagramas de estado de
UML, se representa la forma en la que se organizan los distintos actores en base a los
roles en los que pueden participar y cómo las leyes que impone la organización
permiten la evolución de los actores o de las organizaciones mediante cambios de rol.
En la siguiente sección podemos observar la utilización de estos diagramas para
modelar patrones de organización.

5. En los diagramas de organización se reflejan los usuarios y las suborganizaciones
mediante el rol que pueden desempeñar y las dependencias organizativas se ven
reflejadas por medio de las leyes y las capacidades. El conjunto de las actividades
asociadas a un rol se describirán en la vista cognitiva [11] mediante los diagramas de
roles.
4 Patrones. Estructuras organizativas
Desde su introducción a mediados de los 90’s en el campo de la ingeniería del
software [18,19], los patrones se han erigido como un valioso instrumento para la
descripción y reutilización del conocimiento empírico empleado durante las distintas
fases del ciclo de vida del software y en diferentes dominios de aplicación.
Teniendo en cuenta que las decisiones tomadas durante las etapas de análisis de
requerimientos y modelado conceptual del sistema influyen decisivamente en las
características del producto final y en las restantes etapas del ciclo de vida del
software, la aplicación de patrones (denominados de análisis o conceptuales [20,21])
durante estas etapas sería de una gran utilidad. Su uso facilita la toma de decisiones,
acelera la creación de la especificación y la hace más comprensible y fácil de
mantener.
El modelado de la estructura y comportamiento social de los actores que intervienen
en un sistema también puede beneficiarse de la utilización sistemática de patrones
conceptuales específicos dentro de una metodología de desarrollo. A continuación
mostramos cómo se podría modelar un patrón de organización concreto con
AMENITIES y cómo se aplicaría a un caso determinado.
5 Ejemplo de Aplicación
A partir de estudios teóricos existentes sobre organizaciones y alianzas estratégicas,
hay autores que han convertido estructuras organizativas comunes en patrones útiles
que facilitan el modelado y la comprensión del contexto organizativo de un sistema
[13,22], este es el caso del patrón Joint Venture.
El patrón Joint Venture refleja la alianza estratégica que se establece entre dos o más
socios, normalmente empresas especializadas en tareas concretas, que se unen para
alcanzar un objetivo común y obtener una serie de ventajas colectivamente (inversión
parcial, costes de mantenimiento más bajos, mayores beneficios, etc.). Este patrón
organizativo cuenta además con una unidad administrativa que por un lado dirige la
estrategia de la alianza y por otro coordina las tareas que realizan los distintos socios.
Basándonos en los diagramas de organización usados en AMENITIES para describir
la vista de grupo, podemos modelar este patrón mediante los diagramas de la figura 2.

6. Fig. 2 Patrón de organización Joint Venture
Como se puede observar, cada uno de los roles está representado por un estado en el
que un actor (usuario o unidad organizativa) puede entrar, esto es, puede desempeñar
dicho rol, en base a las capacidades que posee. En este caso, un actor que posea la
capacidad para poder realizar una de las actividades necesarias para conseguir el
objetivo común, por ejemplo fabricar una de las piezas de un avión cuando el objetivo
es construir un avión, podrá desempeñar el papel de socio (obsérvese que el cardinal
del rol indica que debería haber al menos un par de socios). Dentro de este estado un
socio puede desempeñar además otros roles cuando realiza tareas determinadas. En el
diagrama hemos destacado el rol de representante para indicar que este rol es
imprescindible dentro del patrón, ya que una tarea clave dentro de esta organización
va a ser la realización de reuniones entre los representantes y el coordinador de los
socios.
Cuando un actor tiene la capacidad necesaria para poder administrar el Joint Venture
podrá participar como administrador (obsérvese que solamente puede haber uno o dos
actores que actúen como tales). En ese estado, un actor que tenga la capacidad para
coordinar los socios podrá desempeñar el rol de coordinador (éste podrá
desempeñarlo un único actor) y si tiene capacidad para dirigir la estrategia de la
alianza podrá desempeñar el rol de director (obsérvese que podrá ser desempeñado
también por un único actor). En este mismo diagrama se describe, mediante una
transición aditiva, bajo qué ley un actor que desempeña el rol de coordinador podrá
además asumir el rol de director. Tal y como se puede advertir, esto podrá suceder
cuando el coordinador tenga capacidad de dirección o la unidad de dirección no esté
disponible
role Socio
2..n
organization Joint Venture
role Administrador
1..2
[RealizaActividad?]
[AdministraOrganización?]
role Representante
1
organization Socio
[Elegido]
role Coordinador
1
organization Administrador
role Director
1
[CoordinaciónSocios?]
[Dirección?]
[Dirección? or NoDisponibleDirector]

7. La aplicación de este patrón consistirá básicamente en ligar sus parámetros a
elementos concretos dentro de un contexto determinado. Aquellos elementos que
pueden variar de una instancia a otra del patrón son los candidatos para formar parte
de sus parámetros. En la figura 3 se presenta una utilización concreta del patrón.
Fig. 3 Aplicación del patrón Joint Venture
Es importante subrayar cómo el patrón Joint Venture, utilizado habitualmente en el
contexto de las alianzas estratégicas entre empresas, es aplicado en un contexto
diferente y a distinto nivel de abstracción. En la figura 3 se muestra sucintamente
cómo puede ser usado este patrón para modelar la organización de un aula
cooperativa en la que diferentes alumnos de un grupo, cada uno especializado en la
realización de una parte concreta, se encargan de elaborar un trabajo común. Como
puede apreciarse, existen diferentes roles que pueden ser adoptados por los alumnos
del grupo, pudiendo existir cambios de rol en virtud del cumplimiento de ciertas
restricciones (véase, por ejemplo, bajo qué condiciones el rol escribano puede
desempeñar el rol de líder).
6 Conclusiones y trabajos futuros
En este trabajo se ha propuesto una ontología que permite analizar un sistema de
información como una estructura social bajo una organización dinámica. Se ha
role GrupoAlumnos
2..n
organization Aula Colaborativa
role Profesor
1..2
[RealizaActividad?]
[AdministraAula?]
role Líder
1
organization GrupoAlumnos
[Elegido]
role CoordinadorGrupos
1
organization Profesor
role DirectorCurso
1
[Coordinación?]
[Dirección?]
[Dirección? or NoDisponibleDirector]
Joint
Venture
Pattern
Socio
Administrador
Coordinador
Director
Representante
Representante
Socio
Administrador
Coordinador
Director
role Escribano
1
role Miembro
2..n
[Líder? or AusenteLíder]
[Elegido]

8. analizado cómo se ve reflejada esta ontología en la propuesta de la metodología
AMENITIES y en concreto en sus diagramas de organización.
Hemos aplicado los diagramas de organización para la descripción de patrones de
organización que pueden ser una base muy importante para la utilización de la
metodología.
Una aproximación cercana a la nuestra es la realizada por Kolp y otros [12,13] en la
que, utilizando la metodología propuesta por Yu i* [14], se realiza una descripción de
un conjunto de patrones de organización clásicos y propone una forma de guiar el
análisis de requisitos en base a la estructura organizativa del sistema. El mayor
problema de esta aproximación es que la representación del sistema se realiza bajo un
único nivel de abstracción en el que se mezclan elementos organizativos como los
grupos y los roles con elementos funcionales como las actividades, objetivos y
recursos usados.
El estudio de organizaciones se ha utilizado tradicionalmente en el diseño de
arquitecturas para sistemas basados en agentes [15], en estos casos se realizan
modelos arquitectónicos de sistemas siguiendo las teorías clásicas de organización de
negocios. Nuestra propuesta es de una gran utilidad para la descripción de estas
arquitecturas ya que los elementos de modelado son los mismos aunque el ámbito de
aplicación y la abstracción realizada sea distinta.
Podemos encontrar otras aproximaciones basadas en el análisis de requisitos guiado
por los objetivos [16,17], en las que la modelización del sistema se realiza en base a
conceptos similares a los utilizados por nosotros. Sin embargo no centran el análisis
en la organización del sistema y las relaciones sociales entre usuarios sino en los
objetivos que los usuarios tienen con el sistema y cómo realizan las actividades
pertinentes para alcanzarlos.
En la actualidad estamos trabajando en la extensión de los patrones a las distintas
fases de la modelización del sistema bajo la metodología AMENITIES.
Referencias
1 Bubenko J.A. : Next Generation Information Systems: an Organizational
Perpective, Intl. Workshop on Development of Intelligenent Information
Systems, Niagara-on-the-Lake, Canada, April 21-23, (1991)
2 Ellis C.A.: WorkFlow Technology. Computer Supported Co-operative Work.
John Wiley & Sons, (1999)
3 Ferber J. and Gutknecht O.: A Meta-Model for the Analysis and Design of
Organization in MAS. Proc of Int. Conf. In Multi-Agent Systems, (1998)
4 Norbert G. and Philippe M.: The Reorganization of Societies of Autonomous
Agents”, Multi-Agent Rationality, Proc. of MAAMAW’97, Springer (1997)
5 Wooldridge M., Jennings N., Kinny D.: The Gaia Methodology for Agent-
Oriented Analysis and Design, Autonomous Agents and Multi-Agent Systems,
V3, Kluwer Academic Publishers, (2000)

9. 6 C.R. Guareis, L. Ferreira, M. van Sinderen: “A conceptual model for the
development of CSCW systems”. Foundation for Human-Computer Interaction
Research”. ACM Transactions on Computer-Human Interaction, (7),2, (2000)
7 Gea M., Gutierrez F.L., Garrido J.L., Cañas J.J.: “Teorias y Modelos
Conceptuales para un diseño basado en grupos”, IV Congreso Internacional de
Interacción Persona-Ordenador. Vigo, España (2003)
8 M. Van Welie, G.C. van der Veer: “An Ontology for Task World Models”. In
Design, Specification and Verification of Interactive System’98. (1998)
9 Garrido, J.L., Gea, M.: Modelling Dynamic Group Behaviours. In: Interactive
System - Design Specification and Verification. LNCS 2220, Springer, 2001
10 Garrido, J.L., Gea, M., Padilla, N., Gutiérrez, F.L., Cañas, J.J., Waern, Y.
AMENITIES: Modelado de Entornos Cooperativos. III Congreso Internacional
de Interacción Persona-Ordenador. Madrid, España (2002): pp. 97-104.
11 Garrido, J.L.: AMENITIES: Una metodología para el desarrollo de sistemas
cooperativos basada en modelos de comportamiento y tareas, Tesis doctoral,
Universidad de Granada.(2003)
12 Kolp M., Giorgini P., MyloupoulosJ. : Information systems development
through Social Structures” In proceedings of the 14th
international Conference
on Software Engineering and Knoeledge Engineering, Italy. (2002)
13 Kolp M., Giorgini P. and Mylopoulos J.. Organizational Patterns for Early
Requirements Analysis, In Proceedings of the 15th International Conference on
Advanced Information Systems Engineering (CAiSE'03), Austria, June (2003)
14 E. Yu.: Modeling Strategic Relationships for Process Reengi-neering, PhD
thesis, University of Toronto, Department of Computer Science, Canada, 1995.
15 T. T. Do, M. Kolp and A. Pirotte.: Social Patterns for Designing Multi-Agent
Systems, In Proceedings of the 15th
International Conference on Software
Engineering and Knowledge Engineering, San Francisco, USA, July (2003)
16 Anton A.I.: Goal-Based Requirements Analysis, Proceedings of the 2nd
Int.
Conf. On Requirements Analysis, ICRE (1996)
17 Dardenne A., Lamsweerde, A. Van, Fickas S.: Goal-directed requirements
acquision, Science of computer programming (1993)
18 Gamma, E., Helm, R. Johnson, R.; Vlissides, J.: Design Patterns: Elements of
Reusable Object-Oriented Software, Reading, MA: Addison Wesley
Professional Computing Series (1995)
19 Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-
Oriented Software Architecture: A System of Patterns, Chichester, UK: John
Wiley and Sons Ltd (1996)
20 Fowler, M.: Analysis Patterns: Reusable Object Models, Booch, G., Jacobson, I.
and Rumbaugh, J. (eds.), Object Technology Series, Reading, MA: Addison-
Wesley Publishing Company, (1997)
21 Riehle, D., Züllighoven, H.: “Understanding and Using Patterns in Software
Development”, Theory and Practice of Object Systems, 2(1): 3-13, (1996)
22 Fuxman, A., Giorgini, P., Kolp, M. and Mylopoulos J.: “Information systems as
social estructures”, In Proceedings of the 2nd
International Conference on Formal
Ontologies for Information Systems, FOIS’01, Ogunquit, USA, October, (2001)