Modelando Patrones de OrganizaciónFrancisco Luis Gutiérrez1, José Luis Isla2, Miguel Gea11Departamento de Lenguajes y Sist...
realizan dichas actividades. En la mayor parte de los casos esta situación no provocamuchos problemas. Cuando nos proponem...
Desde otro punto de vista necesitamos modelar cómo un usuario puede llegar aformar parte de cada una de dichas suborganiza...
organizativas se refleja una o más relaciones denominadas dependenciasorganizativas. Con estas asignaciones se modelan las...
En los diagramas de organización se reflejan los usuarios y las suborganizacionesmediante el rol que pueden desempeñar y l...
Fig. 2 Patrón de organización Joint VentureComo se puede observar, cada uno de los roles está representado por un estado e...
La aplicación de este patrón consistirá básicamente en ligar sus parámetros aelementos concretos dentro de un contexto det...
analizado cómo se ve reflejada esta ontología en la propuesta de la metodologíaAMENITIES y en concreto en sus diagramas de...
6 C.R. Guareis, L. Ferreira, M. van Sinderen: “A conceptual model for thedevelopment of CSCW systems”. Foundation for Huma...
Upcoming SlideShare
Loading in …5
×

Gutierrez

162 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
162
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Gutierrez

  1. 1. Modelando Patrones de OrganizaciónFrancisco Luis Gutiérrez1, José Luis Isla2, Miguel Gea11Departamento de Lenguajes y Sistemas InformáticosE.T.S. de Ingeniería Informática, Periodista Daniel Sucedo Aranda s/n,Universidad de Granada, 18071, Granada, España{fgutierr,mgea}@ugr.es2Departamento de Lenguajes y Sistemas InformáticosE.S. Ingeniería, c/ Chile, 1Universidad de Cádiz , 1002 EspañaJoseluis.isla@uca.esResumen. Hoy en día, los sistemas de información operan dentro de uncontexto muy dinámico, en el que se produce una constante evolución delsistema. Uno de los aspectos que mas cambios sufre es la estructuraorganizativa de los usuarios que interactúan con él. Debido a esto, es necesariodesarrollar metodologías que favorezcan el análisis y la representación de estedinamismo.En este trabajo se propone ver un sistema de información como una estructurasocial donde la organización de los usuarios es un elemento clave para elanálisis y el modelado del comportamiento del sistema. Se presenta un modeloconceptual de los distintos elementos que aparecen en una estructuraorganizativa y cómo se puede usar la metodología AMENITIES pararepresentar no sólo estructuras organizativas de sistemas particulares sino sugeneralización usando patrones conceptuales.Palabras clave: Sistemas de Información, metodologías de desarrollo de software,modelado de organizaciones, patrones conceptuales.1 IntroducciónActualmente los sistemas de información son cada vez más complejos, debido sobretodo a los cambios tecnológicos que actúan sobre ellos. Desafortunadamente lasarquitecturas propuestas y las metodologías utilizadas en su desarrollo no soportan, engran medida, esta evolución constante a la que se ven sometidos. Una buena forma deanalizar y modelar un sistema consiste en partir de la idea de que un sistema deinformación es una estructura social [1] que evoluciona de forma dinámica. Losmiembros de dicha estructura se encargan de realizar una serie de actividadesproductivas para el negocio del sistema .Las metodologías de desarrollo tradicionales tienden a modelar los sistemasrealizando un clara separación entre, por un lado, los usuarios y las actividades querealizan en el sistema y por otro, el contexto en el que los usuarios se desenvuelven y
  2. 2. realizan dichas actividades. En la mayor parte de los casos esta situación no provocamuchos problemas. Cuando nos proponemos modelar sistemas complejos, comopueden ser sistemas en los que múltiples usuarios colaboran para la realización deactividades comunes (sistemas colaborativos [2]), esta separación no está nada clara,ya que al realizarla no podemos representar aspectos tan importantes (para estossistemas) como las responsabilidades que tiene cada uno de los usuarios o lasrelaciones y dependencias que aparecen entre cada uno de ellos.Vemos que es necesario introducir el concepto de estructura social como unacolección de actores y un conjunto de dependencias sociales entre ellos. Esto nos va apermitir describir de una forma más precisa las responsabilidades a asignar a cada unode los miembros del sistema.En la literatura aparecen distintas aportaciones relacionadas con la modelización deestructuras sociales, siendo la mayor parte de ellas utilizadas para la representación desistemas MAS (Multi-Agent Systems) [3,4,5]. En estos modelos se presta una mayoratención a la arquitectura del sistema viendo a los agentes como elementos socialesdentro de una organización compleja. Sin embargo, para la representación deorganizaciones sociales en sistemas de información también es muy importante poderreflejar la naturaleza cambiante de la organización.En la siguiente sección se presenta un modelo conceptual con los principaleselementos que aparecen en una estructura organizativa, En la sección 3 se exponecómo podemos utilizar la metodología AMENITIES para modelar organizaciones. Enlas siguientes secciones presentamos la forma en la que podemos realizardescripciones de patrones de organización y cómo nos facilitan la utilización de lametodología. Finalmente, presentamos las principales conclusiones y trabajos futuros.2 Modelo conceptual de organizaciónPara modelar la estructura social subyacente a un sistema de información esimportante incluir el concepto de “Rol”. Un “Rol” es una abstracción de lasactividades, una o más, que una agrupación de usuarios del sistema puede realizar enun instante determinado.Podemos abordar el problema de la modelización de la estructura social de unsistema desde dos puntos de vista. Por un lado, agrupamos los posibles usuarios delsistema en suborganizaciones dependiendo de las actividades que pueden realizar yfijándonos en aspectos como las restricciones en cuanto al número de miembros decada una de estas suborganizaciones. En este caso estamos modelando la parteestática de la organización. Por ejemplo, en el caso de un departamento de laUniversidad podemos detectar la existencia de distintos subgrupos de los profesores:el del director, el del secretario y el de un conjunto de comisiones encargadas derealizar actividades relacionadas con la gestión (comisión de investigación,económica, ...).
  3. 3. Desde otro punto de vista necesitamos modelar cómo un usuario puede llegar aformar parte de cada una de dichas suborganizaciones y cómo sus miembros pueden irevolucionando a lo largo del tiempo (¿puede un profesor llegar a director?, ¿cómo sealcanza el rango de secretario?, si no está el director, ¿puede alguien de laorganización llevar a cabo sus funciones?, ...). En este caso nos fijamos en losaspectos dinámicos de la organización, en su posible evolución a lo largo de la vidadel sistema.El modelo conceptual que proponemos para la descripción de una organización es elque describimos en la figura 1 usando un diagrama de clases de UML. Este diagramaes similar a los que se han utilizado tradicionalmente en el modelado de sistemascolaborativos [6,7,8].Fig. 1 Modelo organizativoEn 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 tantousuarios individuales del sistema como subunidades organizativas de rango inferior ala organización.Como ejemplo de suborganizaciones podemos introducir el concepto de grupo (tipode UnidadOrganizativa). Un grupo se define como un conjunto de usuarios que, deforma esporádica, se unen para la realización de una o más actividades. Otro ejemplonos lo da el concepto de departamento, definido como una división estructural de laorganización. Si analizamos los ejemplos anteriores, observamos que existen dostipos de suborganizaciones: las estáticas, que describen la estructura general de laorganización y las dinámicas, que modelan agrupaciones de usuarios que se creanpara 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 rolimplica la posibilidad o capacidad de poder realizar un conjunto de actividadesasociadas al mismo.Por último, podemos observar cómo entre roles (refiriéndonos al conjunto de losactores que están desempeñando el rol en un instante de tiempo) y unidadesOrganizaciónActorUsuarioActividaddesempeñadesempeñaRoldependenciaOrganizativ aUnidadOrganizativadependenciaOrganizativ a
  4. 4. organizativas se refleja una o más relaciones denominadas dependenciasorganizativas. Con estas asignaciones se modelan las relaciones del tipo: posibilidadde pasar de un rol a otro, una suborganización puede ser parte de otra suborganizaciónmas general, etc. En resumen, estas dependencias describen las restricciones entre losconjuntos de posibles usuarios del sistema.3 Metodología AMENITIES. Vista de grupoAMENITIES [9,10,11] (acrónimo de A Methodology for aNalysis and DesIgn ofCooperaTIve systEmS) es una metodología basada en modelos de comportamiento ytareas para el análisis, diseño y desarrollo de sistemas cooperativos.A nivel conceptual, la metodología AMENITIES incorpora un conjunto de elementosorientados a la descripción de la estructura del sistema en base a la organización delmismo. Dentro de ellos, los mas relevantes son: el grupo, el rol, los actores, laorganización y el contexto entendido como la situación de la organización ubicada enuna dimensión espacial y temporal.AMENITIES, para modelar los elementos dinámicos de la estructura organizativa deun sistema, introduce dos tipos de restricciones:• Ley: Una ley es una restricción impuesta por el sistema a la propiaorganización. Las leyes vienen impuestas por el propio entorno (comonormas) o por organizaciones de orden superior.• Capacidad: Es una habilidad que un actor o grupo puede llegar a logrardentro del sistema. Esta capacidad puede estar ligada a aspectos cognitivos(aprendizaje), destrezas (ser experto en...) o cualidades (propiedades oatributos).Ambas restricciones facilitan la modelización de sistemas dinámicos, ya que eshabitual que tanto la estructura del grupo como su comportamiento se modifique en eltiempo. Los participantes pueden adquirir nuevas capacidades, variar el número demiembros que conforman un grupo de trabajo, aplicar nuevas estrategias de trabajo,etc., pero siempre cumpliendo con las leyes que establecen las normas que rigen elcomportamiento 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 vistaorganizacional, en la que usando un diagrama basado en los diagramas de estado deUML, se representa la forma en la que se organizan los distintos actores en base a losroles en los que pueden participar y cómo las leyes que impone la organizaciónpermiten 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 paramodelar patrones de organización.
  5. 5. En los diagramas de organización se reflejan los usuarios y las suborganizacionesmediante el rol que pueden desempeñar y las dependencias organizativas se venreflejadas por medio de las leyes y las capacidades. El conjunto de las actividadesasociadas a un rol se describirán en la vista cognitiva [11] mediante los diagramas deroles.4 Patrones. Estructuras organizativasDesde su introducción a mediados de los 90’s en el campo de la ingeniería delsoftware [18,19], los patrones se han erigido como un valioso instrumento para ladescripción y reutilización del conocimiento empírico empleado durante las distintasfases 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 derequerimientos y modelado conceptual del sistema influyen decisivamente en lascaracterísticas del producto final y en las restantes etapas del ciclo de vida delsoftware, 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 demantener.El modelado de la estructura y comportamiento social de los actores que intervienenen un sistema también puede beneficiarse de la utilización sistemática de patronesconceptuales específicos dentro de una metodología de desarrollo. A continuaciónmostramos cómo se podría modelar un patrón de organización concreto conAMENITIES y cómo se aplicaría a un caso determinado.5 Ejemplo de AplicaciónA partir de estudios teóricos existentes sobre organizaciones y alianzas estratégicas,hay autores que han convertido estructuras organizativas comunes en patrones útilesque 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ássocios, normalmente empresas especializadas en tareas concretas, que se unen paraalcanzar un objetivo común y obtener una serie de ventajas colectivamente (inversiónparcial, costes de mantenimiento más bajos, mayores beneficios, etc.). Este patrónorganizativo cuenta además con una unidad administrativa que por un lado dirige laestrategia 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 describirla vista de grupo, podemos modelar este patrón mediante los diagramas de la figura 2.
  6. 6. Fig. 2 Patrón de organización Joint VentureComo se puede observar, cada uno de los roles está representado por un estado en elque un actor (usuario o unidad organizativa) puede entrar, esto es, puede desempeñardicho rol, en base a las capacidades que posee. En este caso, un actor que posea lacapacidad para poder realizar una de las actividades necesarias para conseguir elobjetivo común, por ejemplo fabricar una de las piezas de un avión cuando el objetivoes construir un avión, podrá desempeñar el papel de socio (obsérvese que el cardinaldel rol indica que debería haber al menos un par de socios). Dentro de este estado unsocio puede desempeñar además otros roles cuando realiza tareas determinadas. En eldiagrama hemos destacado el rol de representante para indicar que este rol esimprescindible dentro del patrón, ya que una tarea clave dentro de esta organizaciónva a ser la realización de reuniones entre los representantes y el coordinador de lossocios.Cuando un actor tiene la capacidad necesaria para poder administrar el Joint Venturepodrá participar como administrador (obsérvese que solamente puede haber uno o dosactores que actúen como tales). En ese estado, un actor que tenga la capacidad paracoordinar 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 laalianza podrá desempeñar el rol de director (obsérvese que podrá ser desempeñadotambién por un único actor). En este mismo diagrama se describe, mediante unatransició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á sucedercuando el coordinador tenga capacidad de dirección o la unidad de dirección no estédisponiblerole Socio2..norganization Joint Venturerole Administrador1..2[RealizaActividad?][AdministraOrganización?]role Representante1organization Socio[Elegido]role Coordinador1organization Administradorrole Director1[CoordinaciónSocios?][Dirección?][Dirección? or NoDisponibleDirector]
  7. 7. La aplicación de este patrón consistirá básicamente en ligar sus parámetros aelementos concretos dentro de un contexto determinado. Aquellos elementos quepueden variar de una instancia a otra del patrón son los candidatos para formar partede sus parámetros. En la figura 3 se presenta una utilización concreta del patrón.Fig. 3 Aplicación del patrón Joint VentureEs importante subrayar cómo el patrón Joint Venture, utilizado habitualmente en elcontexto de las alianzas estratégicas entre empresas, es aplicado en un contextodiferente y a distinto nivel de abstracción. En la figura 3 se muestra sucintamentecómo puede ser usado este patrón para modelar la organización de un aulacooperativa en la que diferentes alumnos de un grupo, cada uno especializado en larealización de una parte concreta, se encargan de elaborar un trabajo común. Comopuede apreciarse, existen diferentes roles que pueden ser adoptados por los alumnosdel grupo, pudiendo existir cambios de rol en virtud del cumplimiento de ciertasrestricciones (véase, por ejemplo, bajo qué condiciones el rol escribano puededesempeñar el rol de líder).6 Conclusiones y trabajos futurosEn este trabajo se ha propuesto una ontología que permite analizar un sistema deinformación como una estructura social bajo una organización dinámica. Se harole GrupoAlumnos2..norganization Aula Colaborativarole Profesor1..2[RealizaActividad?][AdministraAula?]role Líder1organization GrupoAlumnos[Elegido]role CoordinadorGrupos1organization Profesorrole DirectorCurso1[Coordinación?][Dirección?][Dirección? or NoDisponibleDirector]JointVenturePatternSocioAdministradorCoordinadorDirectorRepresentanteRepresentanteSocioAdministradorCoordinadorDirectorrole Escribano1role Miembro2..n[Líder? or AusenteLíder][Elegido]
  8. 8. analizado cómo se ve reflejada esta ontología en la propuesta de la metodologíaAMENITIES y en concreto en sus diagramas de organización.Hemos aplicado los diagramas de organización para la descripción de patrones deorganización que pueden ser una base muy importante para la utilización de lametodología.Una aproximación cercana a la nuestra es la realizada por Kolp y otros [12,13] en laque, utilizando la metodología propuesta por Yu i* [14], se realiza una descripción deun conjunto de patrones de organización clásicos y propone una forma de guiar elanálisis de requisitos en base a la estructura organizativa del sistema. El mayorproblema 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 losgrupos y los roles con elementos funcionales como las actividades, objetivos yrecursos usados.El estudio de organizaciones se ha utilizado tradicionalmente en el diseño dearquitecturas para sistemas basados en agentes [15], en estos casos se realizanmodelos arquitectónicos de sistemas siguiendo las teorías clásicas de organización denegocios. Nuestra propuesta es de una gran utilidad para la descripción de estasarquitecturas ya que los elementos de modelado son los mismos aunque el ámbito deaplicación y la abstracción realizada sea distinta.Podemos encontrar otras aproximaciones basadas en el análisis de requisitos guiadopor los objetivos [16,17], en las que la modelización del sistema se realiza en base aconceptos similares a los utilizados por nosotros. Sin embargo no centran el análisisen la organización del sistema y las relaciones sociales entre usuarios sino en losobjetivos que los usuarios tienen con el sistema y cómo realizan las actividadespertinentes para alcanzarlos.En la actualidad estamos trabajando en la extensión de los patrones a las distintasfases de la modelización del sistema bajo la metodología AMENITIES.Referencias1 Bubenko J.A. : Next Generation Information Systems: an OrganizationalPerpective, Intl. Workshop on Development of Intelligenent InformationSystems, 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 ofOrganization in MAS. Proc of Int. Conf. In Multi-Agent Systems, (1998)4 Norbert G. and Philippe M.: The Reorganization of Societies of AutonomousAgents”, 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. 9. 6 C.R. Guareis, L. Ferreira, M. van Sinderen: “A conceptual model for thedevelopment of CSCW systems”. Foundation for Human-Computer InteractionResearch”. ACM Transactions on Computer-Human Interaction, (7),2, (2000)7 Gea M., Gutierrez F.L., Garrido J.L., Cañas J.J.: “Teorias y ModelosConceptuales para un diseño basado en grupos”, IV Congreso Internacional deInteracción Persona-Ordenador. Vigo, España (2003)8 M. Van Welie, G.C. van der Veer: “An Ontology for Task World Models”. InDesign, Specification and Verification of Interactive System’98. (1998)9 Garrido, J.L., Gea, M.: Modelling Dynamic Group Behaviours. In: InteractiveSystem - Design Specification and Verification. LNCS 2220, Springer, 200110 Garrido, J.L., Gea, M., Padilla, N., Gutiérrez, F.L., Cañas, J.J., Waern, Y.AMENITIES: Modelado de Entornos Cooperativos. III Congreso Internacionalde Interacción Persona-Ordenador. Madrid, España (2002): pp. 97-104.11 Garrido, J.L.: AMENITIES: Una metodología para el desarrollo de sistemascooperativos basada en modelos de comportamiento y tareas, Tesis doctoral,Universidad de Granada.(2003)12 Kolp M., Giorgini P., MyloupoulosJ. : Information systems developmentthrough Social Structures” In proceedings of the 14thinternational Conferenceon Software Engineering and Knoeledge Engineering, Italy. (2002)13 Kolp M., Giorgini P. and Mylopoulos J.. Organizational Patterns for EarlyRequirements Analysis, In Proceedings of the 15th International Conference onAdvanced Information Systems Engineering (CAiSE03), Austria, June (2003)14 E. Yu.: Modeling Strategic Relationships for Process Reengi-neering, PhDthesis, University of Toronto, Department of Computer Science, Canada, 1995.15 T. T. Do, M. Kolp and A. Pirotte.: Social Patterns for Designing Multi-AgentSystems, In Proceedings of the 15thInternational Conference on SoftwareEngineering and Knowledge Engineering, San Francisco, USA, July (2003)16 Anton A.I.: Goal-Based Requirements Analysis, Proceedings of the 2ndInt.Conf. On Requirements Analysis, ICRE (1996)17 Dardenne A., Lamsweerde, A. Van, Fickas S.: Goal-directed requirementsacquision, Science of computer programming (1993)18 Gamma, E., Helm, R. Johnson, R.; Vlissides, J.: Design Patterns: Elements ofReusable Object-Oriented Software, Reading, MA: Addison WesleyProfessional Computing Series (1995)19 Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns, Chichester, UK: JohnWiley 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 SoftwareDevelopment”, Theory and Practice of Object Systems, 2(1): 3-13, (1996)22 Fuxman, A., Giorgini, P., Kolp, M. and Mylopoulos J.: “Information systems associal estructures”, In Proceedings of the 2ndInternational Conference on FormalOntologies for Information Systems, FOIS’01, Ogunquit, USA, October, (2001)

×