MODELADO_DE_NEGOCIOS

Cimat©

Guía Metodológica para el Modelado de Negocio

Versión 1.0 02/05/2005

Adaptado de: Business Modeling with UML,Eriksson y Pender, Wiley

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0

Control De Versiones

Nombre del Archivo GM_Mod_Negocio

02/05/2005

Versión 1.0

Fecha 02/05/2005

Autor JFCR, APV e IJS

Comentarios Versión Inicial del Documento

2/51

Cimat ©


Índice del Documento 1 Introducción...................................................................................................... 5 1.1 Propósito......................................................................................................... 5 1.2 Alcance ........................................................................................................... 5 1.3 Acrónimos....................................................................................................... 5 1.4 Referencias..................................................................................................... 5 1.5 Definiciones .................................................................................................... 5 2 Modelado de Negocio con UML ....................................................................... 9 2.1 Modelado de Negocio ..................................................................................... 9 2.1.1 Modelado de Proceso de Negocio ............................................................... 9 2.1.2 Modelado de Negocio con UML................................................................. 14 2.2 Modelando la Arquitectura de Negocio ......................................................... 15 2.2.1 Arquitecturando un Negocio ...................................................................... 15 2.2.2 Conceptos de Negocio............................................................................... 17 2.2.3 Extensiones de Negocio de Eriksson-Penker ............................................ 20 2.3 Vistas De Negocio ........................................................................................ 31 2.3.1 Cuatro Vistas Comunes del Negocio ......................................................... 32 2.3.2 Vista De Visión De Negocio....................................................................... 33 2.3.3 Vista del Proceso de Negocio.................................................................... 40 2.3.4 Vista de Estructura de Negocio ................................................................. 44 2.3.5 Vista de Comportamiento de Negocio ....................................................... 47

Índice de Figuras Figura 2-1 Sistema de Negocio Interconectado con otro Sistema de Negocio ..... 18 Figura 2-2 Meta-Modelo Básico de Conceptos de Modelado de Negocios ........... 19 Figura 2-3 Símbolo de Proceso de Negocio.......................................................... 22 Figura 2-4 Eventos de Negocio Modelados como Clases en una Jerarquía de Clases ............................................................................................................ 24 Figura 2-5 Procesos Empaquetados ..................................................................... 25 Figura 2-6 Meta-Modelo que muestra una Jerarquía de los Tipos de Recursos ... 26 Figura 2-7 Tipos de Recursos Estereotipados ...................................................... 27 Figura 2-8 Reglas de Negocio en un Diagrama de Clases ................................... 29 Figura 2-9 Diagrama de Clases con Relaciones Estáticas.................................... 30 Figura 2-10 Notas de Referencia .......................................................................... 31 Figura 2-11 Arquitectura de Negocio: Cuatro Vistas ............................................. 33 Figura 2-12 Un Ejemplo de la Matriz TOWS ......................................................... 36 Figura 2-13 Ejemplo de un Modelo Conceptual .................................................... 38 Figura 2-14 Modelo Genérico de Meta/Problema.................................................. 39 Figura 2-15 Diagrama de Procesos Genérico ....................................................... 42 Figura 2-16 Ejemplo de un Diagrama de Procesos............................................... 44 Figura 2-17 Ejemplo de un Diagrama de Clases de Recursos.............................. 45 Figura 2-18 Ejemplo de un Diagrama de Clases de Información .......................... 46

02/05/2005

3/51

Cimat ©


Figura 2-19 Modelo de la Organización como un Diagrama de Clases ................ 47 Figura 2-20 Diagrama de Secuencia..................................................................... 49 Figura 2-21 Diagrama de Colaboración ................................................................ 50 Figura 2-22 Diagrama de Procesos....................................................................... 51

02/05/2005

4/51

Cimat ©

1


Introducción

1.1 Propósito Guiar al alumno en los procesos que se usan para hacer un modelado de negocio, proveyendo los argumentos de por qué UML es apropiado para el modelado de negocio y que elementos de UML son requeridos para dicho fin. También se describen las diferentes vistas de un modelo de negocio para capturar aspectos específicos del negocio.

1.2 Alcance Éste documento aplica a todos los proyectos generados dentro de la Licenciatura de Sistemas Computacionales plan 04 y la Licenciatura en Ingeniería en Computación plan 03 a partir de la liberación de la línea base.

1.3

Acrónimos

Acrónimo BPI BPR TOWS UML

1.4

Descripción Business Process Improvement (Mejora de Procesos de Negocio) Business Process Reengineering (Reingeniería de Procesos de Negocio) Threats, Opportunities, Weaknesses, and Strengths (Amenazas, Oportunidades, Debilidades y Fortalezas) Unified Modeling Language (Lenguaje de Modelado Unificado)

Referencias

Núm. 1

Descripción Ericsson, Hans-Erik and Magnus Pender. 2000. Business Modeling with UML: Business Patterns at Work.

1.5 Definiciones A continuación se listarán los conceptos clave del modelado de negocio y que ayudarán a entender de mejor el contenido del documento. Palabra Actor

02/05/2005

Definición El objeto externo que interactúa con el sistema. En un caso de uso, el actor es el rol jugado por un ser humano u otro sistema.

5/51

Cimat © Arquitectura Asociación Caso de Uso Comportamiento Dependencia

Diagrama de Clase

Diagrama de Colaboración Estado Estereotipo

Evento de Negocio Extensiones de Negocio de Eriksson –Penker Generalización

Lenguaje de Modelado Meta Meta-Modelo

Modelado Conceptual Modelado

02/05/2005

Guía Metodológica para el Modelado de Negocio – v. 1.0 La estructura organizacional de un sistema. La relación sistemática entre dos o más clases que especifican conexiones entre sus instancia. Una descripción de cómo puede ser usado un sistema, desde el punto de vista de un actor externo Las acciones que un objeto de negocio es capaz de llevar acabo para cumplir su propósito. Una relación entre dos elementos que de alguna manera son dependientes uno de otro. Por lo que indica que un cambio en el objeto dependiente afectara al objeto del cual depende. Usado para describir estructuras. Las estructuras están construidas de estructuras y relaciones. Las clases pueden representar y estructurar objetos como información, productos, documentos, y organizaciones. Una diagrama de UML que describe una colaboración completa entre un escenario de objetos. Los diferentes estados que el objeto puede tener, incluyendo sus estados de inicio y final. Un elemento de modelado que extiende la semántica de UML. Los estereotipos deben estar basados en los elementos que ya son definidos en UML. Los estereotipos pueden extender la semántica pero no la estructura de elementos de persistencia. Ciertos estereotipos están predeterminados en UML; otros podrían ser definidos por el usuario. Un suceso del mundo real externo que requiere cierta acción [Gale-Eldred 1996]. Extensiones para UML que hace posible hacer un modelo tanto de negocio y sus sistemas de soporte. Una relación entre un elemento general y un elemento más específico. El elemento más específico es completamente compatible con el elemento más general, y contiene la información adicional o de comportamiento. Lenguaje usado para expresar modelos. Un lenguaje de modelado está definido por sintaxis y semántica, así como por reglas pragmáticas. Propósito del negocio, o el resultado que el negocio como un todo esta tratando de lograr. Un modelo que describe otros modelos, expresado en un metalenguaje. Los Meta - modelos son usados para describir UML y muchos otros lenguajes. Definiciones de los conceptos importantes usados en el negocio, junto con sus relaciones con cada uno. Definición de las metas de la compañía incluyendo la división

6/51

Cimat © Meta/Problema Modelo

Negocio Proceso

Proceso de Negocio

Recursos

Reglas

Reglas de Negocio

Subproceso Subsistema UML Vista de Comportamiento de Negocio Vista de Estructura de Negocio Vista de Proceso de Negocio

02/05/2005

Guía Metodológica para el Modelado de Negocio – v. 1.0 de metas en submetas y la definición de los problemas que impiden que se logren las metas. Descripción abstracta de un sistema. Un modelo es expresado con diagramas y los diagramas son expresados en un lenguaje de modelado. Un modelo es una expresión de alguna cosa (un negocio, etc.) y siempre tiene objetivos. Las relaciones entre clientes y proveedores. Una descripción de un conjunto de actividades relacionadas que, cuando son llevadas a cabo correctamente, satisfacen un objetivo explícito. El proceso viene del Latín processus, que significa avance o progreso. Una descripción de un conjunto de las actividades relacionadas que, cuando se llevan a cabo correctamente, satisfacen la meta de negocio. Los objetos dentro del negocio, tales como personas, material, información y productos, que son usados o producidos en el negocio. Los recursos son ordenados en estructuras y tienen relaciones entre ellos. Los recursos son manipulados (usados, consumidos, refinados o producidos) a través de procesos. Los recursos pueden ser catalogados como físicos, abstractos e informativos. Declaraciones que definen o restringen algunos aspectos de negocio y representan el conocimiento de negocio. Las reglas controlan como el negocio debe funcionar o como los recursos deben ser estructurados y relacionados unos con otros. Las reglas pueden ser catalogadas como funcionales, de comportamiento y estructurales. Declaraciones que restringen, obtienen, y dan condiciones de existencia. Las reglas de negocio son usadas para especificar la situación admitida, incluyendo estados de objeto de negocio admitidos. El resultado de dividir un proceso en procesos adicionales. El resultado de dividir un sistema en sistemas adicionales. Un subsistema es representado como un paquete en UML. Lenguaje de modelado unificado; un estándar de OMG para el modelado orientado a objeto visual. Representa el comportamiento de cada recurso y proceso importante del negocio. Las estructuras de los recursos de negocio, como la organización de negocio o la estructura de los productos creados. Describe los procesos de negocio que representan las actividades y el valor creado en el negocio; los procesos interactúan con los recursos para lograr la meta de cada proceso y para mostrar la interacción entre los diferentes

7/51

Cimat ©

Vista de Visión de Negocio

02/05/2005

Guía Metodológica para el Modelado de Negocio – v. 1.0 procesos. La visión global del negocio describe una estructura de meta para la compañía, e ilustra los problemas que deben ser eliminados para llegar a esas metas.

8/51

Cimat ©

2 2.1


Modelado de Negocio con UML Modelado de Negocio

2.1.1 Modelado de Proceso de Negocio Un negocio es un sistema complejo, está constituido por una organización jerárquica de departamentos y sus funciones. Algunas de estas funciones, sin embargo, no son restringidas a un solo departamento; cruzan horizontalmente a través de varios departamentos. El método tradicional para documentar un negocio es dibujar un mapa de la organización, que divida el negocio en un número de departamentos o secciones (por ejemplo, investigación y desarrollo, mercadotecnia, ventas, fabricación, etc.), representado verticalmente. Este método de documentación es limitado a cómo un negocio es construido y organizado. No documenta los procesos de negocio que fluyen horizontalmente y afectan todos los departamentos verticales (por ejemplo, el desarrollo de un nuevo producto afectará todas divisiones). Otras estructuras en el negocio, como los procesos de negocio, los recursos que participan o son usados en el proceso, las reglas que controlan la ejecución del negocio, las metas, y los problemas que impiden alcanzar esas metas, no pueden ser capturadas en la vista organizativa tradicional. Un buen modelo de negocio contiene toda esta información. Capturando y documentando esta información en si mismo puede ser la base para tomar mejores decisiones en un negocio y especificar los requerimientos del sistema de información. El concepto principal usado para el modelado de procesos es el proceso de negocio, el cuál describe las actividades dentro del negocio y como se relacionan e interactúan con los recursos del negocio para lograr una meta para el proceso. Un modelo de negocio nunca puede ser totalmente exacto o completo, simplemente porque ninguno de los dos observadores de un negocio tendrá una percepción idéntica o estará de acuerdo con un modelo exacto. El modelo debe concentrarse en las tareas y mecanismos clave principales del negocio. Determinar con precisión las tareas principales de negocio y determinar qué debe plasmarse en el modelo es responsabilidad del modelador. Igualmente, un modelo de negocio de una vista futura de un negocio no puede esperarse que se realice tal como se planeó. Los cambios en el mundo real pueden afectar la base sobre la que el modelo fue creado, quedando este modelo como no completamente valido. Incluso con esas limitaciones, los siguientes argumentos para producir modelos de negocio todavía son muy fuertes:

02/05/2005

9/51

Cimat ©


•

Para comprender mejor los mecanismos clave de un negocio existente. Se debe proveer una imagen clara de sus roles y tareas en la organización global, los modelos pueden ser usados para entrenar a las personas. (Pueden ser usados en una organización jerárquica o en una organización orientada a procesos).

•

Para actuar como base para crear sistemas de información convenientes que soporten el negocio. Las descripciones de negocio son usadas para identificar el apoyo de sistemas de información. Los modelos también son usados como una base para especificar los requerimientos clave de esos sistemas.

•

Para actuar como base para mejorar la estructura actual del negocio y su operación. Los modelos identifican cambios en el negocio actual que son necesarios para implementar el modelo de negocio mejorado.

•

Para mostrar la estructura de un negocio innovado. El modelo se vuelve la base para el plan de acción.

•

Para experimentar con un nuevo concepto de negocio o para copiar o estudiar un concepto usado por una compañía competitiva. El modelo puede ser una nueva idea, inspirada por el modelado de otros negocios, o puede tomar ventaja de nuevas tecnologías, tal como la Internet.

•

Para identificar oportunidades de outsoursing. Los elementos del negocio no considerados como “parte central”, son delegados a proveedores externos. Los modelos son usados como especificación para los proveedores.

2.1.1.1 Entender el Negocio Uno de los principales motivos para desarrollar cualquier modelo es incrementar el conocimiento del negocio y facilitar la comunicación. Un modelo visual es mas fácil de comprender y discutir que una descripción textual. El modelo es una fotografía actual de cómo los modeladores ven actualmente el negocio. El modelo cambiara y evolucionará conforme los modeladores mejor entiendan el negocio o conforme el negocio cambie. Una vez que los modelados sean estables, debido a que ya dan una imagen clara de los roles y tareas a través de toda la organización, estos pueden ser usados para entrenar al personal. 2.1.1.2 Soporte del Sistema de Información Hoy, la mayoría de los negocios usan algún tipo de sistema de información. A decir verdad, puede decirse que la tecnología de información es una parte integral de la operación diaria de muchas compañías. Con la Internet como infraestructura

02/05/2005

10/51

Cimat ©


técnica para comunicación y transacciones financieras, una riqueza de nuevas oportunidades de negocios esta emergiendo. Los modelos de negocio existentes necesitan ser adaptados con las nuevas posibilidades que provee la Internet. Aun siendo tan grande esta tendencia, sin embargo, muchas compañías están insatisfechas con la calidad de sus sistemas de información, mencionando que ofrecen el soporte de negocio insuficiente o inútil, difícil de usar, no son fiables, y no están integrados con otros sistemas. En muchos casos, esto se debe al hecho de que los sistemas no están siendo desarrollados con un entendimiento correcto del negocio. La solución es crear un modelo global de negocio que puede ser usado para determinar qué sistemas de información son requeridos, como deben ser desarrollados esos sistemas de información, y qué funcionalidad deben contener los sistemas. Si la especificación de requerimientos está basada en un buen modelo de negocio, hay una gran probabilidad de que el sistema de información soportará el negocio adecuadamente. Existen varias ventajas de basar todos los sistemas de información en un mismo modelo básico de negocio: •

Los sistemas de información se vuelven una parte integral del negocio global, soportando los negocios y fortaleciendo el trabajo y los resultados.

•

Los sistemas se integran fácilmente unos con otros y pueden compartir o intercambiar información.

•

Los sistemas son más fáciles de actualizar y modificar como dicten los cambios en el modelo de negocio, como resultado del ambiente que le rodea, metas del negocio, o mejoras o innovaciones del modelo de negocio. Esto reduce el costo de mantener actualizado los sistemas de información y de actualizar continuamente los procesos del negocio.

•

La lógica de negocio puede ser re-usada en algunos sistemas.

Idealmente, los objetos presentados en los modelos de negocio traducen o mapean objetos en el sistema de información. Normalmente, esto no es un mapeo uno a uno. Un objeto o proceso en el modelo de negocio no siempre puede ser traducido a un objeto dentro del sistema de información y viceversa, hay objetos en el sistema de información que no están presentes en absoluto en el modelo del negocio. Usar modelos de negocio como base para los sistemas de información también presenta una oportunidad para el re-uso de software. Si son varios sistemas de información que soportan el mismo negocio, usualmente tendrán un conjunto de objetos que coincidan.

02/05/2005

11/51

Cimat ©


Esos objetos tienen que ser implementados solo una vez y pueden ser re-usados en otros sistemas de información. La ventaja del re-uso también es aplicable a modelos. Si el mismo modelo de negocio puede actuar como la base de varios sistemas de información, este puede ser re-usado como la entrada básica para definir los requerimientos de cada sistema. Sin un modelo de negocio común, cada equipo de desarrollo de sistema crearía su propio modelo de análisis para entender el mundo real. No solo es trabajo redundante, sino que aumenta el riesgo de que los diferentes equipos interpreten la realidad de manera diferente y por lo tanto desarrollarán sistemas incompatibles. 2.1.1.3 Mejora Un modelo de negocio puede ser usado para mejorar un negocio actual. Esta técnica, a veces llamada mejora de procesos de negocio (Business Process Improvement, BPI), es usada para identificar las posibles formas de hacer el negocio mas eficiente. El negocio actual es modelado y luego analizado para oportunidades de perfeccionamiento o mejora. La mejora de procesos de negocio sugiere que el negocio sea cambiado incrementalmente en lugar de hacerlo inmediata y radicalmente. Cuando una oportunidad de mejora es identificada, es producido un nuevo modelo de negocio para demostrar cómo el negocio debe verse después de que esos cambios sean implementados. Varias actividades deben ser completadas en orden para cambiar el negocio e implementar un nuevo modelo de negocio: •

Describir nuevas rutinas y crear soporte administrativo para esas rutinas.

•

Entrenar al personal afectado por el cambio; enseñarles los nuevos procesos y motivarlos a volverse parte del cambio.

•

Cambiar los sistemas de información que participan en el negocio para mejorar el soporte y perfeccionar la operación del negocio.

•

Negociar con subcontratistas y otros compañeros que necesitaran adaptarse a los cambios.

Dependiendo de la extensión de los cambios, mejorar el negocio puede ser trabajo simple o complicado. 2.1.1.4 Innovación La innovación de negocio involucra el análisis del negocio actual y la búsqueda del modelo para nuevas formas de hacer las cosas. El modelo de negocio y sus

02/05/2005

12/51

Cimat ©


procesos son cambiados significativamente para crear diferentes y mejorados procesos. A menudo, pueden existir rutinas en un negocio por razones históricas o porque la infraestructura demanda que se hagan de cierta manera. La innovación es un riesgo mucho más grande que la mejora, pero si la innovación tiene éxito, el resultado puede lograr grandes ganancias en eficiencia. La innovación es por consiguiente usada en compañías que requieren un cambio radical incitado por un pobre rendimiento, falta de presupuesto, y productividad ineficiente. Una forma extrema de innovación de negocio es la reingeniería de procesos de negocio (BPR). La BPR define los cambios radicales para los procesos de negocio; esto significa que todas las cosas acerca de la manera actual en que funciona el negocio son cuestionadas y a menudo substancialmente cambiadas. Conseguir tal innovación es mucho más difícil y tiene un alto riesgo de fracaso. Por consiguiente, ha habido una fuerte resistencia para la BPR. 2.1.1.5 Diseñar Nuevos Procesos El modelado de negocio puede ser usado para crear nuevos modelos. Los modelos son usados para determinar si la organización actual, los recursos y los sistemas de información pueden ser fácilmente usados en los nuevos procesos o adaptados a los nuevos procesos. Los modelos de negocio también son usados para hacer benchmarking de un negocio, esto es, para copiar o estudiar procesos de negocios usados por los competidores para medir nuestros propios procesos contra los de la competencia. A menudo, nuevos procesos son diseñados sobre la base de una visión de nuevas oportunidades. Modelando esta visión o idea se crea un “primer intento” que prueba la viabilidad del proceso. Obviamente, otras actividades tienen que ser llevadas acabo antes de implementar el proceso, incluyendo cálculos de ganancia, análisis de costo y estudio de mercado. Estas actividades pueden usar el nuevo modelo de proceso como una especificación de las metas proyectadas para el nuevo proceso y de los recursos necesarios, y para determinar cómo el nuevo proceso es implementado dentro del negocio actual. 2.1.1.6 Outsourcing Una práctica común entre los líderes de negocio es enfocarse en el centro del negocio, procesos fundamentales en que la compañía se destaca y que da ventaja de competitividad. Los procesos que no son parte del núcleo o centro del negocio son outsourcing. Las compañías contratan subcontratistas para manejar las funciones de soporte o incluso departamentos enteros, en lugar de manejarlos ellos mismos.

02/05/2005

13/51

Cimat ©


El modelado de negocio puede ser usado no solo para identificar y definir procesos centrales, sino también para definir los procesos que son candidatos para outsourcing. 2.1.2 Modelado de Negocio con UML Hay algunas ventajas de hacer un modelo de negocio usando conceptos y técnicas orientados a objetos: •

Conceptos similares: Un negocio puede ser descrito en términos de procesos que logran metas en colaboración con diferentes tipos de objetos de recursos. Las reglas definen las condiciones y las restricciones respecto a cómo podrían relacionarse los procesos y los recursos y cómo pueden actuar. Todo esto puede mapearse en objetos, relaciones entre objetos e interacciones entre objetos; por ejemplo, creando modelos estáticos y dinámicos orientados a objetos.

•

Técnicas establecidas bien-probadas: El modelado y la programación orientada a objetos han sido usadas por varios años y han probado que pueden manejar sistemas grandes y complejos. Nuevas técnicas, como patrones, han sido introducidos en el campo del modelado orientado a objetos y varios patrones están disponibles para el modelado de negocios.

•

Notación estándar: Los métodos y técnicas de modelado de negocios necesitan de una notación estándar: cada método usa su propia notación y su propia herramienta. El modelado orientado a objetos finalmente tuvo una notación estándar: UML. Esto significa que las herramientas ya están ahí, y que las mismas herramientas que son usadas para modelar los sistemas de información pueden ser adaptadas y usadas para describir modelos de negocio. También abre la posibilidad de permitir continuo rastreo de los requerimientos de negocio a toda forma de implementación de código. Hoy, la falta de esta capacidad es un defecto muy importante en la mayoría de las herramientas.

•

Curva de aprendizaje corta: Esta es la mayor ventaja cuando los mismos conceptos básicos (objetos, clases, etc.) usados para describir los sistemas de información que soportan al negocio también pueden ser usados para describir los negocios como un todo.

•

Nuevas y fáciles maneras de ver una organización o un negocio: La manera tradicional de describir y ver una organización no indica gran parte de cómo el negocio es llevado a cabo.

UML es un estándar bien definido, soportado por muchas herramientas. Es un lenguaje de modelado dominante usado para modelar sistemas de información orientados a objetos.

02/05/2005

14/51

Cimat ©


2.2 Modelando la Arquitectura de Negocio Una arquitectura bien definida hace posible entender totalmente la estructura que está siendo construida, para planear la construcción actual y para estimar costos; esto sirve de base para los planos de la estructura. Una vez que la construcción ha sido terminada, una buena arquitectura incluye documentación del proceso y el resultado, que hace posible de entender, mantener y si así se desea, para extender la estructura. Igualmente, la importancia de la arquitectura en la construcción de sistemas de información ha sido reconocida desde hace algún tiempo y es actualmente el enfoque de muchas investigaciones. Una arquitectura captura las partes vitales de una estructura en una manera organizada y es una herramienta práctica para el manejo de un sistema complejo, tal como un sistema de software o un negocio. La arquitectura define la estructura de negocio, por lo que el modelado de esta arquitectura es clave para entender el negocio y como funciona este.

2.2.1 Arquitecturando un Negocio La arquitectura de negocio es la base para describir y entender una empresa. Ésta lista las partes requeridas de un negocio, cómo las partes están estructuradas e interactúan y cómo debe evolucionar la arquitectura. Aunque es difícil definir claramente el término, una definición funcional de la arquitectura de negocio es: Un conjunto organizado de elementos con relaciones claras unas con otras, las cuales juntas forman una definición completa para su funcionalidad. Los elementos representan la estructura organizacional y de comportamiento de un sistema de negocios, y muestran abstracciones de los procesos y estructuras clave en el negocio (Vernadat, 1996). Todos los negocios tienen algún tipo de arquitectura. Pero como un mapa organizacional es usualmente la única descripción disponible del negocio, muchas de las situaciones y estructuras en éste, nunca son documentadas o visualizadas. Esto hace pensar en hacer comprender a las compañías que tienen muchos dibujos de sus edificios y/o sus productos, pero ninguno sobre como son conducidos sus negocios. Para definir y documentar como un negocio es conducido, uno puede acumular conocimiento del negocio que ya esta disponible. La arquitectura actúa como una base de conocimiento; ésta es un recurso estratégico para el negocio. Documentar el sistema de negocio hace que sean más fáciles las mejoras o las innovaciones en el negocio e identifica las nuevas oportunidades de negocio.

02/05/2005

15/51

Cimat ©


2.2.1.1 Buena Arquitectura Una buena arquitectura permite al modelador abstraer el negocio en diferentes aspectos o vistas y concentrarse en sólo un aspecto a la vez. Lograr abstracción, suprimir detalles e información irrelevante, es esencial para entender sistemas complejos y sus relaciones. Una buena arquitectura tiene las siguientes características: •

Captura el negocio tan verdadera y correctamente como sea posible. Esto define una arquitectura que es realista y viable de implementar y que logre las metas del negocio.

•

Se enfoca en los procesos y estructuras clave del negocio a un nivel de abstracción apropiado. El nivel apropiado es diferente de caso a caso y depende del propósito de la arquitectura.

•

Representa una vista de opinión entre las personas que operan en el negocio. Por ejemplo, administradores y trabajadores están de acuerdo en que la arquitectura correcta describe como opera el negocio.

•

Se adapta fácilmente al cambio y extensiones.

•

Es fácil de entender y crea comunicación entre los diferentes stakeholders del negocio. Una arquitectura es útil solo si ésta puede ser entendida por sus usuarios.

Lograr estas características no es fácil. Esto requiere varias cosas: •

Modeladores que tengan un alto conocimiento del negocio, o acceden por lo menos a las personas con tales conocimientos que pueden ser entrevistados y pueden participar en la construcción de la arquitectura.

•

Un lenguaje de modelado que puede capturar todos los conceptos importantes del negocio, al mismo tiempo que las relaciones entre éstas. Las estructuras estáticas y dinámicas deben ser capturadas. El lenguaje debe ser suficientemente simple de entender para diferentes personas, sin perder exactitud o poder. El lenguaje debe también ser escalable para que puedan ser descritas cosas a diferentes niveles.

•

Una capacidad de organizar diagramas visuales dentro de diferentes vistas de negocio, donde cada vista ilustra un aspecto especifico del negocio. La descripción completa del negocio no puede ser definida en una sola vista.

02/05/2005

16/51

Cimat ©


•

Un diseño basado en la experiencia, sobre qué trabajar y qué no. Si es posible, podrían usarse patrones de modelado bien definidos que se han probado que trabajan bien.

•

Un proceso de desarrollo que asegure la calidad y exactitud de los modelos producidos.

Obviamente, necesitamos una buena técnica o lenguaje para definir la arquitectura de negocio. Aunque existen varias arquitecturas de referencia (ISO Referente Model, CIMOSA, PERA, etc.) que usan diferentes técnicas para describir un negocio, todas estas tienen un factor común: el uso de modelos. UML (Unffied Modeling Language) ha sido establecido ya como el lenguaje de modelado estándar para modelar sistemas de información.

2.2.2 Conceptos de Negocio Un negocio, una empresa, es un sistema complejo que tiene un propósito especifico o meta. Todas las funciones del negocio interactúan para lograr esa meta. Los sistemas de negocios también pueden conectarse y ser afectados por decisiones y eventos que tienen lugar en otros sistemas, entonces no deben ser analizados en aislamiento. Debido a esto, definir los límites de negocio puede ser difícil. Los recursos dentro de una organización también pueden tener metas separadas que no siempre refleja el negocio. Muchos de los elementos importantes en un negocio, tales como clientes, proveedores, leyes y regulaciones, son externos al negocio y no son definidos dentro del negocio mismo. Así, el sistema de negocio es un sistema abierto donde sus objetos y partes son a menudo también objetos y partes de otros sistemas de negocio. Como se puede apreciar en la Figura 2-1.

02/05/2005

17/51

Cimat ©


Figura 2-1 Sistema de Negocio Interconectado con otro Sistema de Negocio

Fuente: Hans-Erik Eriksson and Magnus Penker, 2000

Los negocios individuales tienen diferentes metas y estructuras internas, pero usan conceptos similares para describir su estructura y operación. Los conceptos usados para definir los sistemas de negocio son: •

Recursos: Los objetos dentro del negocio, tales como personas, material, información y productos, que son usados o producidos en el negocio. Los recursos son ordenados en estructuras y tienen relaciones entre ellos. Los recursos son manipulados (usados, consumidos, refinados o producidos) a través de procesos. Los recursos pueden ser catalogados como físicos, abstractos e informativos.

•

Procesos: Las actividades realizadas dentro del negocio durante las cuales el estado de los recursos del negocio cambian. Los procesos describen como es hecho el trabajo dentro del negocio; estos son controlados por reglas.

•

Metas: El propósito del negocio, o el resultado que el negocio como un todo esta tratando de lograr. Las metas pueden ser divididas en submetas y destinadas a partes individuales del negocio, tal como procesos u objetos. Las metas expresan el estado deseado de los recursos y son logradas por los procesos. Las metas pueden ser expresadas como una o mas reglas.

•

Reglas: Declaraciones que definen o restringen algunos aspectos de negocio y representan el conocimiento de negocio. Las reglas controlan

02/05/2005

18/51

Cimat ©


como el negocio debe funcionar o como los recursos deben ser estructurados y relacionados unos con otros. Las reglas pueden ser afectadas desde afuera por regulaciones o leyes o pueden ser definidas dentro del negocio para lograr las metas del negocio. Las reglas pueden ser catalogadas como funcionales, de comportamiento y estructurales. Todos estos conceptos son relacionados unos con otros. Una regla puede afectar la forma en que algunos recursos son estructurados; un recurso es destinado a un proceso específico; una meta es asociada con la ejecución de un proceso específico. La meta del modelado del negocio es definir estos conceptos y mostrar las relaciones e interacciones entre ellos. Un meta-modelo es un modelo de conceptos básicos de negocio y sus relaciones. Los conceptos mostrados en este modelo son usados para crear otros modelos. Como se puede apreciar en la Figura 2-2. Figura 2-2 Meta-Modelo Básico de Conceptos de Modelado de Negocios

Fuente: Hans-Erik Eriksson and Magnus Penker, 2000 02/05/2005

19/51

Cimat ©


La Figura 2-2 es un meta-modelo que suma todos los conceptos usados en el modelado de negocio y sus relaciones unos con otros. El meta-modelo es un diagrama de clases UML en el cual cada concepto es mostrado como una clase y las relaciones entre los conceptos son una asociación o una especialización. Una meta es establecida para superar uno o más problemas y expresa el estado deseado de uno o más recursos. Las metas pueden ser expresadas como reglas que controlan el proceso. Un proceso interactúa con los recursos a través de una interface y puede causar que el estado del recurso cambie. Los recursos pueden ser físicos (como personas o computadoras), abstractos (como una factura o cuenta) o informativos, conteniendo información acerca de otros recursos (como un registro de base de datos en una sistema de información).

2.2.3 Extensiones de Negocio de Eriksson-Penker Porque UML fue diseñado inicialmente para describir aspectos de un sistema de software, tuvo que ser extendido para identificar y visualizar más claramente los conceptos importantes de procesos, metas, recursos y reglas de un sistema de negocio. Para abordar este asunto, hemos creado una serie de extensiones basadas en los elementos existentes del modelo de UML. Hemos introducido estas extensiones y se proveen símbolos para hacer un modelo de los procesos, recursos, reglas y metas de un sistema de negocios. Los mecanismos de extensión estándar en UML permiten adaptar UML para acomodar nuevos conceptos. Los mecanismos de extensión son: •

Estereotipo: Una extensión del vocabulario de UML que permite crear nuevos componentes básicos específicos a partir de los existentes [Booch, 1998]. Un estereotipo puede tener sus propios iconos.

•

Valor Etiquetado (propiedad): Una extensión de las propiedades de un elemento de UML, que permite crear nueva información en la especificación de ese elemento [Booch, 1998].

•

Restricción: Una extensión de la semántica de un elemento de UML que permite agregar nuevas reglas o modificar las existentes [Booch, 1998].

Los casos de uso son una técnica común para capturar los requerimientos funcionales de un sistema de información. Describen las funciones provistas por un sistema de caja negra. Sin embargo, ver el sistema del negocio como una caja negra no ofrece suficiente visión de la operación de los procesos existentes o futuros. Un sistema de información puede ser caracterizado por sus interacciones con el usuario o cliente, pero implementar mejoras o innovaciones en los procesos del negocio requiere ver los procesos existentes y sus operaciones, no solo las operaciones con el usuario. Definir el usuario y los limites del sistema es también

02/05/2005

20/51

Cimat ©


bastante difícil. Un sistema del negocio debería por consiguiente, ser visto como un sistema abierto. 2.2.3.1 Procesos de Negocio Los procesos de negocio son la parte activa del negocio. Estos describen las funciones del negocio e involucran recursos que son usados, transformados o producidos. Un proceso de negocio es un concepto abstracto que muestra la cooperación entre los recursos y la transformación de estos dentro del negocio. Enfatiza cómo se realiza el trabajo, más que tratar de describir los productos o servicios que son resultado del proceso. Una definición más formal de un proceso del negocio es la siguiente: Un proceso de negocio es una colección de actividades que toman una o mas clases de entrada y crean una salida que es de valor para el cliente. Un proceso de negocio es una meta y es afectada por eventos que ocurren en el mundo exterior o en otros procesos. [Hammer and Champy, 1993]. Otra definición más elaborada es: Un proceso es simplemente un conjunto estructurado de actividades diseñadas para producir una salida específica para un cliente o mercado en particular. Esto implica hacer énfasis fuerte sobre cómo es hecho el trabajo dentro de la organización en vez de enfocarse al producto. Un proceso es por lo tanto, un conjunto específico de actividades de trabajo a través del tiempo y lugar con un inicio y un final, y entradas y salidas claramente identificadas: una estructura para la acción. [Davenport, 1993]. Porter define que toda empresa esta hecha de un número de procesos de negocio, cada uno produciendo valor para el cliente. Sumando las similitudes entre las diferentes definiciones, un proceso de negocio: •

Tiene una meta: un conjunto de objetos de entrada y salida

•

Tiene una entrada específica: Recursos que son transformados o consumidos como parte de un proceso (materia prima o proceso de manufactura).

•

Tiene una salida especifica: Logro de las metas como resultado del proceso (producto terminado o listo para pasar al siguiente proceso nuevamente como recurso de entrada)

•

Usa recursos

02/05/2005

21/51

Cimat ©


•

Tiene un número de actividades que son realizadas en algún orden, dependiendo de las condiciones y eventos que ocurran durante la ejecución del proceso. Las actividades dentro del proceso pueden ser vistas como subprocesos.

•

Afecta más de una unidad organizacional. Esto es más bien horizontal que vertical en consideración a la organización tradicional del negocio.

•

Crea valor de algún tipo para el cliente. El cliente puede ser o interno o externo al negocio.

Las Extensiones de Negocio de Eriksson-Penker representan un proceso en un diagrama de clases de UML con el símbolo de proceso. Como se puede apreciar en la Figura 2-3. Figura 2-3 Símbolo de Proceso de Negocio


Los valores etiquetados de UML que se ligan a procesos en las Extensiones de Negocio de Eriksson-Penker son: Metas, propósito, documentación, propietario de proceso, actores de proceso, prioridad, riesgos, posibilidades, tiempo y costo.

02/05/2005

22/51

Cimat ©


2.2.3.1.1 Pasos del Proceso El proceso contiene un número de pasos o actividades que son llevadas a cabo como parte de un proceso. Cada una de estas actividades puede ser considerada un proceso de este mismo y como un subproceso del proceso que lo contiene. Las actividades son catalogadas como sigue: •

Directa: Una actividad directamente involucrada en la creación del producto o servicio, esto es, el valor creado por el proceso.

•

Indirecta: Una actividad que soporta las actividades directas; incluye mantenimiento, administración, actividades de planeación.

•

Aseguramiento de la Calidad: Una actividad que asegura la calidad de otras actividades; por ejemplo, inspecciones, controles o revisiones.

Los pasos de proceso son ilustrados como actividades empaquetadas del proceso. Los procesos pueden abarcar varios límites organizativos (ejemplo, departamentos o divisiones en un negocio). Por lo tanto, un proceso es descompuesto en subprocesos independientes de la organización y su estructura, y no deben ser divididos sólo porque cruza un límite organizativo. Un proceso puede requerir contener información acerca de sí mismo. Esta posesión de información se ilustra usando el estereotipo <> en uno o más objetos de recursos conectados al proceso.

2.2.3.1.2 Eventos de Negocio Un proceso es afectado por eventos que ocurren en el ambiente que le rodea o generados por otros procesos que causan que un proceso sea activado. Los eventos de negocio son disparadores que inician actividades o que controlan qué actividades son realizadas. Un evento de negocio puede ser definido como sigue: •

Un evento de negocio es un suceso del mundo real externo que requiere cierta acción [Gale-Eldred, 1996].

•

Un evento de negocio representa un registro de cambio en el negocio en un instante determinado [OMG BOCA Proposal, 1998].

Varios eventos pueden ocurrir durante la operación de un proceso al cuál el proceso debe reaccionar, como una cancelación de una orden por un cliente, una entrega de material, etc. Un proceso también puede generar eventos a otros 02/05/2005

23/51

Cimat ©


procesos dentro del negocio u otros negocios que causan que otros procesos reaccionen de una manera especial. Un evento puede: •

Iniciar la ejecución de un proceso

•

Afectar el comportamiento y ejecución del proceso

•

Concluir un proceso generando un evento

En la notación de las Extensiones de Negocio de Eriksson-Penker un evento de negocio es representado como una clase (el tipo de evento) y objetos (instancias del tipo de evento). Las clases evento son estereotipadas como un evento de negocio. Sus relaciones (ejemplo, jerarquías de generalización) pueden ser ilustradas en un diagrama de clases. Como se puede apreciar en la Figura 2-4. Figura 2-4 Eventos de Negocio Modelados como Clases en una Jerarquía de Clases


2.2.3.1.3 Modularizando el Sistema de Negocio Un sistema grande tendrá muchos procesos. Para manejar todos los procesos, estos deben ser agrupados o modularizados para que un modelador pueda concentrarse en un sólo grupo de procesos a la vez. Los procesos son modularizados usando el mecanismo de paquete de UML. Los procesos son asignados a un paquete específico, a veces referenciados como un subsistema en sistemas de información, cada uno de los cuales contiene un conjunto de procesos

02/05/2005

24/51

Cimat ©


y sus subprocesos. Un paquete puede contener otros paquetes. Como se puede apreciar en la Figura 2-5. Figura 2-5 Procesos Empaquetados


2.2.3.2 Recursos Los recursos son objetos que actúan o son usados en el negocio. Por ejemplo; materiales, energía, productos, personas, información y servicios. La mayoría de los elementos normalmente son modelados en una clase orientada a objetos. Vernadat propone una definición de recurso: Un recurso es una entidad que puede tener un rol en la realización de cierta clase de tareas [Vernadat, 1996]. Otra definición es: Un recurso es un concepto usado en el negocio y representa algo que decidimos valorar como un todo. [Darnton, 97]. Los tipos de recurso son representados como clases. Las instancias de recurso son representadas como objetos. Las Extensiones de Negocio de Eriksson-Penker definen algunos estereotipos para indicar diferentes categorías de tipos de recurso. Un meta-modelo de estos recursos se muestra en la Figura 2-6 en la cual cada clase ilustra una categoría específica de tipos de recurso. Como se puede apreciar en la Figura 2-6.

02/05/2005

25/51

Cimat ©


Figura 2-6 Meta-Modelo que muestra una Jerarquía de los Tipos de Recursos


Se definen cuatro tipos de recurso concretos [Thornton Gale y James Eldred, 1996]: •

Físicos: Una entidad con material real que ocupa un volumen en el espacio. Algo que puede ser visto y tocado. Productos primarios, materias primas, partes o productos usados en un proceso son ejemplos de recursos físicos.

•

Abstractos: Una idea o concepto, a menudo compuesto de otros objetos (por ejemplo, una orden de compra es un concepto que se relaciona con una colección de cosas). Involucran cosas y conceptos que no son físicos y no pueden ser tocados pero son importantes para el negocio. Contratos, roles, cuentas, y energía son ejemplos de recursos abstractos.

•

Objetos de información: Una representación de un concepto, cosa u otro objeto de información. Contiene información de otros recursos y trabaja como un sustituto para el recurso, por ejemplo, en un sistema de información.

•

Personas: Un ser humano que actúa en el proceso. Es una especialización de recurso físico para enfatizar e identificar a las personas en el proceso.

02/05/2005

26/51

Cimat ©


Estos cuatro tipos de recurso son también los estereotipos usados para categorizar las clases de recurso. Como se puede apreciar en la Figura 2-7. Figura 2-7 Tipos de Recursos Estereotipados


La Figura 2-7 muestra algunos ejemplos de diferentes tipos de recursos, donde las clases son estereotipadas a sus categorías respectivas. Note que el estereotipo de información tiene un tipo de icono especial. El icono es un rectángulo de clase inclinado. 2.2.3.3 Metas Una meta describe el estado deseado de uno o más recursos. Las metas son ligadas al negocio entero y a procesos de negocio individuales. Las metas motivan actividades que llevan a un cambio de estado en una dirección deseada. La medida puede ser definida en términos cuantificables como ganancia, volumen, tiempo o calidad, o puede ser definida en términos cualitativos, como, “nuestra compañía atraerá el trabajo más competente”. Poner una métrica a una meta será más fácil determinar si ha sido lograda. Las metas son estados en términos que indican la optimización, como incrementar resultados, incrementar la calidad o reducir el tiempo de producción. La suma de todos los esfuerzos de los procesos, recursos y reglas deben lograr las metas. Una meta puede ser dividida en submetas, esto es llamado modelando de metas. Las metas están estrechamente relacionadas con problemas, porque un problema es un obstáculo para una meta. Por lo tanto, es común modelar los problemas cuando se modelan metas. Representar metas y problemas en UML no es simple. La solución usada en las Extensiones de Negocio de Eriksson-Penker es representar las metas como objetos, y usar un diagrama de objetos para mostrar las dependencias entre metas y submetas. En las Extensiones de Negocio de Eriksson-Penker, existen dos clases de metas predeterminadas: meta Cualitativa y meta Cuantitativa.

02/05/2005

27/51

Cimat ©


Los problemas son mostrados como notas estereotipadas al Problema y descritos en un texto claro. 2.2.3.4 Reglas de Negocio Un modelo de negocio contiene reglas del negocio que definen restricciones, condiciones y políticas sobre como deben ser realizados los procesos del negocio. Las reglas de negocio afectan a todos los demás conceptos; estas pueden restringir la ejecución de un proceso de negocio, el comportamiento de un recurso y los medios de conseguir una meta específica. A menudo una regla trata de las relaciones entre conceptos, definiendo la manera en que los conceptos peden ser relacionados unos con otros y las condiciones que debe tener esa relación para que sea valida en determinado momento. Una definición práctica de una regla de negocio es: …una declaración que puede controlar o afectar tanto la ejecución de un proceso de negocio como la estructura de los recursos en el negocio. La declaración especifica una condición que debe ser defendida, o una condición que controla qué actividad deber seguir después. Esta puede expresar una meta de negocio, especificar la manera en que un proceso debe ejecutarse, detallar las condiciones de una relación, o restringir el comportamiento de un recurso. Hay tres tipos de reglas de negocio y son: •

Derivaciones: Reglas que definen cómo un conocimiento puede ser transformado en otro conocimiento (por ejemplo, cómo una información es derivada de otra información). Una derivación puede ser una formula para calcular un valor o una regla de inferencia. Esto significa que si cierto hecho es verdadero, entonces otro hecho de inferencia también debe ser verdadero.

•

Restricciones: Reglas que restringen la posible estructura o comportamiento de objetos o procesos; por ejemplo, la manera en que los objetos se relacionan unos con otros o la manera en que ocurre un cambio de estado de un objeto o proceso. Una operación puede ser restringida a través del uso de operaciones de precondición y postcondición. Una precondición debe ser cumplida antes de que la operación sea ejecutada. Una postcondición debe ser cumplida después de que la operación ha sido ejecutada.

•

Existencia: Reglas que definen cuando un objeto es creado o destruido.

A veces una regla puede ser especificada de diferentes maneras, usando la especificación formal para los sistemas de información o la especificación informal para las personas en el negocio. Las reglas complementan los diagramas; juntos contiene toda la información sobre cómo debe ser dirigido un negocio. 02/05/2005

28/51

Cimat ©


Las reglas pueden estar presentes en todas las vistas y en todos los diagramas. Como se puede apreciar en la Figura 2-8. Figura 2-8 Reglas de Negocio en un Diagrama de Clases


La Figura 2-8 muestra un diagrama de clases con algunas reglas del negocio incorporadas, una restricción y una regla del negocio en una nota. 2.2.3.5 Relaciones Además de las relaciones y estructuras dentro de cada categoría de recurso, también existen relaciones entre categorías de concepto diferentes. Un proceso de negocio es asociado con una o mas metas, los recursos son destinados a un proceso de negocio, los recursos pueden tener sus propias metas, y puede haber reglas que restrinjan los posibles estados de un proceso o un recurso. Las relaciones mas comúnmente usadas en UML son: •

Transición Estado/Actividad: Una relación entre actividades o estados, muestran qué actividad o estado seguirá a otro. Esto es llamado una relación temporal, que muestra el orden de las actividades.

•

Generalización: Una relación de especialización/generalización, en la cual los objetos del elemento especializado son sustituibles por objetos del elemento generalizado. La generalización puede ser usada, por ejemplo, para mostrar una jerarquía de recursos diferentes. Como se puede apreciar en la Figura 2-9.

02/05/2005

29/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-9 Diagrama de Clases con Relaciones Estáticas


Observe la Figura 2-9, donde la línea con la flecha abierta muestra cómo un elemento es una especialización de otro elemento; la flecha abierta apunta al elemento genérico. •

Asociación/Agregación: Una relación que describe un conjunto de vínculos, en la cual un vínculo es una conexión entre objetos. Por ejemplo, un objeto cliente tiene una asociación a uno o mas objetos. La agregación es un caso especial de asociación donde uno de los objetos contiene o controla al otro objeto. Por ejemplo un producto es un ensamblado de algunos componentes. Observe la Figura 2-9, donde la asociación es la línea directa entre dos clases y la agregación es mostrada con líneas terminadas en un diamante relleno apuntando a la clase a la que pertenecen.

•

Dependencia: Una relación entre dos elementos que de alguna manera son dependientes uno de otro. Por lo que indica que un cambio en el objeto dependiente afectará al objeto del cual depende. Una dependencia también puede ser usada entre una actividad y un objeto para mostrar que un objeto es consumido o producido por la actividad, o entre paquetes para indicar que paquetes son dependientes uno de otro.

•

Refinamiento: Es un relación entre dos elementos donde uno de ellos es un refinamiento del otro. Por ejemplo, el refinamiento describe el mismo concepto pero de una manera más detallada o explicita. Un refinamiento es mostrado usando una línea punteada con una flecha abierta. La flecha apunta al elemento no refinado. El elemento refinado esta en el otro extremo de la línea.

02/05/2005

30/51

Cimat ©


2.2.3.6 Mecanismos Generales Hay solamente un nuevo mecanismo general en las Extensiones de Negocio de Eriksson-Penker: la nota de referencia. Una nota de referencia es una nota estereotipada que contiene una referencia a otro diagrama o a otro documento (ver la Figura 2-10). Esta característica, que no está incluida en la especificación actual de UML, permite al modelador referirse a otro diagrama de una manera estandarizada. Como se puede apreciar en la Figura 2-10. Figura 2-10 Notas de Referencia


2.3 Vistas De Negocio Modelar un negocio complejo requiere el uso de múltiples vistas. Cada vista se enfoca en un aspecto en particular del negocio y es descrito a través de diferentes diagramas, algunas veces complementados con un documento de texto. Las ligas a la información en las vistas hacen posible navegar de una vista a otra, brindando una vista completa del sistema. Las vistas no son modeladas aisladamente unas de otras. La información es modelada en diferentes diagramas y cada diagrama es colocado en la vista que mejor captura el aspecto particular del negocio. Como base para definir una arquitectura de negocio con esas vistas, es preferible tener: •

Un conocimiento del negocio, recolectado de la experiencia e información de los trabajadores de los diferentes tipos de negocio.

•

Modelos previos del negocio.

•

Modelos de referencia para este tipo de dominio; como estilos arquitecturales genéricos o patrones para este tipo de negocio.

El nivel de detalle incluido en el modelo depende del propósito del modelo. Si el modelo será usado para construir sistemas de información, la definición de la información usada y el formato de la información deben ser enfatizados. Si el 02/05/2005

31/51

Cimat ©


modelo será usado para mejorar o innovar el negocio, las interacciones en los procesos deben ser enfatizados y posibles cambios que puedan mejorar el funcionamiento deben ser identificados. 2.3.1 Cuatro Vistas Comunes del Negocio Se usarán cuatro vistas las cuales no son las únicas, pueden ser definidas otras vistas dependiendo del modelado de procesos a utilizar. Las cuatro vistas utilizadas en este documento son: •

Visión del Negocio: La visión global del negocio. Esta vista describe la estructura de una meta de la compañía e ilustra problemas que deben ser resueltos para alcanzar estas metas.

•

Proceso del Negocio: Esta vista representa las actividades y valores creados en el negocio e ilustra la interacción entre los procesos y recursos para lograr las metas de cada proceso. Esta vista también demuestra la interacción entre los diferentes procesos.

•

Estructura del Negocio: Las estructuras entre los recursos en un negocio, tal como la organización del negocio o la estructura de los productos creados.

•

Comportamiento del Negocio: El comportamiento individual de cada recurso y proceso importante en el modelo del negocio.

Las vistas no son modelos separados; son diferentes perspectivas sobre uno o más aspectos específicos del negocio. Combinadas, las vistas crean un modelo completo del negocio como se muestra en la Figura 2-11.

02/05/2005

32/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-11 Arquitectura de Negocio: Cuatro Vistas


La mayoría de los diagramas de UML son aplicables al modelado del negocio, pero son tres los que no se aplican que son: el diagrama de casos de uso, el de componentes y el de despliegue. Estos tres son usados para analizar y diseñar sistemas de información y tienen un rol menos significativo en el modelado del negocio. El diagrama de casos de uso identifica los requerimientos en un sistema de información y liga los modelos del negocio con los modelos de sistemas de información. Los diagramas de componentes y de despliegue son usados para modelar arquitectura de software. 2.3.2 Vista De Visión De Negocio Esta vista muestra las metas de la compañía. Es una imagen hacia donde la compañía es dirigida. Esta vista establece la estrategia global para el negocio, define las metas del negocio y actúa como guía para el modelado de las otras vistas. Muchas de las metas en esta vista no serán visibles en las otras vistas o en el sistema de información, a pesar del hecho de que indirectamente afecta la funcionalidad del sistema de información. Esto es porque las metas están siendo divididas en metas mas detalladas o porque el sistema de información no almacena información actualmente acerca de las metas. La vista guía el proceso de modelado actuando como un punto de referencia para decisiones de diseño 02/05/2005

33/51

Cimat ©


cuando se construyen los sistemas de información. La vista de visión del negocio también es usada como una herramienta de motivación. Ésta debe ser compartida con los empleados del negocio que deben proveer la información y recursos, tanto como su responsabilidad lo requiera para lograr esas visiones. Note que la vista de visión de negocio no contiene una descripción detallada de las metas a lograr. Más bien, ésta es una estrategia básica de progreso. La visión es a veces enfocada a mantener y fortalecer los mejores aspectos del negocio y eliminar o mejorar los aspectos débiles. Hay algunos factores importantes a considerar cuando se crea la vista de visión de negocio, de acuerdo con Geoffrey Darnton [Darton 1997]: •

Misión de la compañía: La meta global de la compañía.

•

Objetivos: Metas más especificas, medibles en un periodo de tiempo.

•

Fortalezas: Aspectos específicos en los que sobresale el negocio.

•

Debilidades: Aspectos específicos en los que el negocio requiere mejoras.

•

Oportunidades: Áreas de crecimiento potencial para el futuro del negocio.

•

Amenazas: Condiciones externas que pueden afectar negativamente el negocio (competidores, cambios en la tecnología, etc.).

•

Factores críticos: Elementos que se requieren para que el negocio tenga éxito o crezca (Ej., buena adaptación a la nueva tecnología).

•

Estrategias: Planes de acción que, si se aplican, logren los objetivos.

•

Competencias Centrales: Áreas del negocio que son de mayor importancia.

•

Roles: Las funcione específicas de la gente que trabaja en el negocio.

•

Unidades de organización: Grupos dentro de los cuales se divide el negocio.

•

Procesos importantes: Los pasos importantes para lograr los objetivos.

El ultimo resultado de la vista de visión del negocio es la definición de un futuro estado deseado de la compañía y como puede ser alcanzado ese estado. Tenemos tres técnicas usadas en la vista de visión del negocio:

02/05/2005

34/51

Cimat ©


•

Definición de estrategias: Posición de la compañía que considera el mundo actual y futuro, y las metas estratégicas o cambios necesarios en el negocio.

•

Modelado Conceptual: Definiciones de los conceptos importantes usados en el negocio, junto con sus relaciones con cada uno.

•

Modelado Meta/Problema: Definición de las metas de la compañía incluyendo la división de metas en submetas y la definición de los problemas que impiden que se logren las metas.

Los resultados de estas técnicas son usados para otras vistas. 2.3.2.1 Definición de Estrategias Definir una estrategia global para el futuro significa que el negocio debe ser visto en el contexto de su ambiente mundial para identificar amenazas y oportunidades que requieren que el negocio cambie. Esto también involucra decisiones acerca de la dirección futura de la compañía. Surgiendo esta pregunta: ¿el administrador o dueño quiere expandir o mantener la posición en el mercado?. Una expansión normalmente involucra mayor riesgo y ultimadamente es el dueño el que decide si se mantiene así o si corre el riesgo. La estrategia es normalmente basada en conclusiones que resultan de evaluar los procesos centrales del negocio o de crear nuevos procesos que entiendan el negocio a través de nuevas áreas o nuevas maneras de trabajar. 2.3.2.2 Matriz TOWZ Una técnica usada para resumir la situación del negocio es evaluar las amenazas, oportunidades, debilidades y fortalezas. Las amenazas y oportunidades son atributos externos del negocio y las debilidades y fuerzas con atributos internos. Estos atributos son listados en una matriz TOWS (Fuerzas. Oportunidades. Debilidades y Amenazas). Los atributos internos son mostrados en los ejes verticales y los externos en los ejes horizontales. La matriz se llena con estrategias para manejar cada intersección entre un atributo interno y un externo. Las estrategias sugeridas en la matriz son la base para estrategias más formales. Las estrategias son repetidas en varias partes de la matriz lo que significa que estas son de mayor impacto para el negocio. La Figura 2-12 muestra un ejemplo de la matriz TOWS.

02/05/2005

35/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-12 Un Ejemplo de la Matriz TOWS


2.3.2.3 Statement de Visión La estrategia es resumida en un statement de visión, que es un documento textual que delinea el futuro del negocio. Este contiene descripciones del contexto actual del negocio (lo que esta cambiando, que es importante), los requerimientos en el negocio, los problemas que pueden ser visualizados y los posibles escenarios de lo que puede pasar. El statement de visión es una descripción de lo que la compañía puede llegar a ser. Debe contener metas de estado de alto nivel que se dividirán en metas operativas. Estas metas operativas pueden ser ligadas a metas

02/05/2005

36/51

Cimat ©


por procesos individuales. La declaración de visión también presenta sistemas o maneras de medir si las metas de alto nivel son logradas. 2.3.2.4 Modelado Conceptual Define los conceptos importantes usados en el negocio. Este modelo establece un vocabulario común para todos los conceptos y demuestra las relaciones entre diferentes conceptos. Definiciones claras de los conceptos básicos son importantes para entender el negocio o modelarlo con más detalle. Sin un vocabulario común, los individuos pueden tener un entendimiento e interpretaciones diferentes de los conceptos. El modelo conceptual es un modelo de alto nivel de conceptos, no es un diseño la de base de datos o un diseño de clase de un sistema de información, aunque algunas veces los diagramas de clase son usados para crear el modelo conceptual y los conceptos son modelados como clases. 2.3.2.4.1 Diagrama de Clases para el Modelado Conceptual Un modelado conceptual es representado en UML como un diagrama de clases. El nombre de las clases y asociaciones usadas en el modelo son importantes, desde que los conceptos son definidos. En UML, son usadas flechas de asociación para especificar como leer una relación y crear una modelo claro y entendible. La siguiente Figura 2-13 muestra un ejemplo del modelo conceptual con los conceptos más importantes.

02/05/2005

37/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-13 Ejemplo de un Modelo Conceptual


2.3.2.5 Modelado Meta/Problema Un modelo de metas describe las metas del negocio y los problemas que impiden lograr dichas metas. Las metas controlan el comportamiento del negocio y muestra el estado deseado de algunos recursos en el negocio, tales como unidades producidas por mes, rédito de un producto especifico o márgenes de utilidad. El modelo de metas establece por que existe el negocio, que e lo que el negocio esta tratando de lograr y que estrategias de negocios hay para lograr esas metas. 2.3.2.5.1 Diagrama Meta/Problema Un diagrama de meta/problema es un diagrama de objetos en UML, de objetos y sus relaciones. El modelo completo de las metas del negocio es actualmente varios diagramas de objetos donde cada diagrama muestra una meta específica de alto nivel dividida en submetas. Las metas son descritas como objetos de clases que tienen el estereotipo <>. Tales objetos son usados en este diagrama para mostrar metas, las dependencias entre metas y las relaciones entre metas y problemas que estas resuelven.

02/05/2005

38/51

Cimat ©


Recordemos las metas cuantitativas y las cualitativas. Para modelar metas como clases se requiere definir una jerarquía de metas como un conjunto de objetos. La Figura 2-14 es un modelo genérico de meta/problema y contiene 2 clases llamadas Metas cuantitativas y Metas cualitativas ambas estereotipadas con <> y contiene además un número de objetos de esas clases con sus dependencias. Algunas metas X son divididas en submetas X1, X2, etc. Hay un problema ligado a la submeta X1, pero las submetas de X1 contribuyen a eliminar el problema. Note que la submeta X1 esta marcada como incompleta, esto es porque algunos otros eventos o resultados pueden ocurrir para que se cumpla esta meta. El problema ligado a la meta puede ser usado para buscar nuevas submetas de esta meta. Las submetas X3a y X3b están ligadas por una asociación estereotipada como <> lo que indica que las metas son contradictorias una a la otra. Ejemplos típicos de esta contradicción podrían ser: Alta Calidad y Bajo Costo. Figura 2-14 Modelo Genérico de Meta/Problema


02/05/2005

39/51

Cimat ©


2.3.3 Vista del Proceso de Negocio La vista de procesos del negocio es el centro del modelado de negocio. Los procesos muestran las actividades que deben ser emprendidos para lograr una meta explicita, a través de sus relaciones con los recursos participantes en el proceso. Los recursos incluyen gente, material, energía, información y tecnología; esos recursos pueden ser consumidos, refinados, creados o usados durante el proceso. Hay relaciones entre un proceso y los recursos, y entre diferentes procesos que interactúan, hay un acoplamiento de los procesos a las metas. Los procesos tienen un propósito y una meta especifica y todos los procesos colectivamente se esfuerzan para lograr las metas globales del negocio. Las definiciones de los procesos son usadas para entender el negocio, para ver las amenazas y oportunidades en el negocio, para mejorar o innovar y para actuar en base a otros modelos. Los procesos de negocio son modelados utilizando entrevistas, discusiones con la gente en los negocios, los resultados de las sesiones de preguntas compuestas por un grupo de personas cuidadosamente selecto, y practicar estudios de cómo operan los negocios. Realizando estas actividades, el modelador se esfuerza en entender y capturar como opera el negocio y como son manejados los recursos en una compañía. El resultado es la creación de varios diagramas de procesos que describen hasta el menor de los procesos centrales de la compañía. Un proceso central es el que tiene interacciones con el mundo externo o es importante para entregar productos y servicios ofrecidos por la compañía. Los procesos centrales son normalmente orientados al cliente y son horizontales a la organización tradicional de la compañía. La vista del proceso del negocio es descrito con un diagrama de actividad en UML. Para usar un diagrama de actividad como un diagrama de procesos, se utilizarán una serie de estereotipos que definen un proceso y varios recursos. 2.3.3.1 Modelando Los Procesos Existen varias técnicas para modelar los procesos, la mayoría orientados al cliente y que requiere evaluación de los productos o servicios producidos en el negocio. Para descubrir las interfaces con el cliente, es posible identificar los eventos del negocio que son generados y analizarlos para indicar la acción apropiada que el negocio debería tomar para cada evento. Una vez definido el producto o servicio, se descubren las actividades requeridas para producir el producto o servicio. Una vez que el proceso ha sido identificado, se puede dividir en subprocesos. El flujo de control y de objetos es capturado y descrito en un modelo de procesos en el cual cada paso en el proceso agrega valor a los recursos creados o refinados en el proceso.

02/05/2005

40/51

Cimat ©


Los procesos son modelados primero concentrándose completamente en modelar los procesos centrales del negocio y seguir con los procesos de apoyo. Un negocio usualmente no tiene más de cinco a diez procesos centrales pero muchos tienen muchos procesos de apoyo. El modelado de procesos crea una documentación exacta de la forma en la que se realiza el trabajo, tal vez para desarrollar mejores sistemas de información. Este también es usado para mejorar o innovar procesos para hacer las funciones del negocio más eficientes. El modelado de procesos también identifica nuevas oportunidades en el negocio, crea y diseña nuevos procesos que toman ventaja de los recursos creados y del conocimiento presente en la organización. La administración de procesos es un área adicional que concierne a lo relacionado al modelado del proceso. Como los procesos no son estrictamente asociados a una unidad organizacional, pero se dividen en varias unidades, un proceso específico dueño dentro de la organización es designado como responsable para el proceso. El proceso dueño es entonces quien tiene la autoridad en este proceso a través de la organización. 2.3.3.1.1 Diagrama de Procesos Un diagrama de procesos es un diagrama de actividad en UML con un conjunto de estereotipos que describen las actividades realizadas dentro de un proceso y como interactúan, los objetos de entrada y salida; proporcionando y controlando los recursos que participan en el proceso; y la meta del proceso. La Figura 2-15 muestra un diagrama de proceso genérico.

02/05/2005

41/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-15 Diagrama de Procesos Genérico


Un proceso es una actividad estereotipada <>. Un proceso puede contener otros procesos o subprocesos que describen los pasos internos tomados dentro del proceso global. Un símbolo de actividad (un rectángulo con las esquinas redondeadas) es usado para mostrar que un proceso no puede ser dividido, o sea, que es una actividad atómica. Un proceso atómico debe ser intuitivamente entendido y especificado por el texto dentro del símbolo de actividad. Los objetos de recursos y los objetos meta que están involucrados en el proceso son colocados alrededor del proceso. Estos pueden ser: •

Objetos meta: Un objeto meta de un diagrama meta/problema que ha sido colocado en un proceso. Un objeto meta es dibujado sobre el diagrama de proceso y adjuntado con una dependencia que es estereotipada <> desde el proceso al objeto meta (mostrando que el proceso se esfuerza por lograr la meta).

•

Objeto de entrada: Objetos que son o consumidos o refinados en los procesos. Los objetos de entrada son recursos y como tales pueden ser estereotipados como <>, <>, <> o <>. Estos son conectados con líneas punteadas desde los

02/05/2005

42/51

Cimat ©


objetos hacia el proceso. Los objetos de entrada son normalmente colocados a la izquierda del proceso. •

Objetos de salida: Objetos que son producidos por el proceso y que son el resultado del refinamiento de uno o mas objetos de entrada. Los objetos de salida son también recursos y son conectados con una línea punteada desde el proceso al objeto de salida. Los objetos de salida son colocados a la derecha del proceso.

•

Objetos suministradores: Recursos que están participando en el proceso pero no son refinados ni consumidos. Estos objetos se dibujan bajo el proceso con una dependencia (una línea punteada) desde el objeto al proceso. La dependencia es estereotipada como <>.

•

Objetos controladores: Recursos que controlan el funcionamiento o proceso. Tales son dibujados normalmente antes o arriba del proceso con una línea punteada desde el objeto al proceso. El estereotipo para esta dependencia es <>.

Note que aquí no hay multiplicidad mostrada en el diagrama de procesos. La multiplicidad no se muestra en las dependencias donde solo un objeto de entrada o una clase especifica o un objeto de salida es requerido. En cambio, el proceso es una operación continua que consume objetos de entrada y produce objetos de salida. Si el número de objetos de salida es requerido, este debe ser especificado como una meta para el proceso. (Ejemplo, el numero de productos por día o por mes), no a través de multiplicidad como se usa para especificar relaciones en UML. La Figura 2-16 es un ejemplo de un diagrama de procesos que muestra el anuncio del proceso de ventas para vender un espacio de un anuncio en una página Web. Esto tiene una meta cuantitativa específica que incluye una suma de ventas, suma de costos y un presupuesto anual. A la izquierda están los objetos de entrada: los recursos de información Suspect y Prospect. Los resultados de los procesos de ventas son Orders. Una Order es un recurso abstracto porque es un acuerdo entre un cliente y un Negocio Simple. En el proceso participan recursos como materiales de venta y vendedores. Los procesos son controlados por el administrador de ventas y por los directivos de ventas de la corporación.

02/05/2005

43/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-16 Ejemplo de un Diagrama de Procesos


2.3.4 Vista de Estructura de Negocio La vista de estructura del negocio muestra la estructura de los recursos, los productos o servicios y la información en el negocio incluyendo la organización tradicional de la compañía (divisiones, departamentos, secciones, unidades del negocio, etc.). Esta no muestra la estructura de los procesos o la división de estos en subprocesos que son mostrados en la vista de procesos de negocio. La vista de estructura de negocio, es considerada como suplemento de la vista de procesos, mostrando la información que no puede ser mostrada en el diagrama de procesos pero que es vital para la operación de la compañía. También esto es modelado por la arquitectura del negocio, posiblemente apoyado por un equipo de modeladores de procesos. Los mapas tradicionales de la organización, y las descripciones de los productos y servicios que la compañía produce, son la base para la vista de estructura de negocio. La información desde la vista de procesos es usada también pues esta muestra que recursos son usados. Note que, típicamente, estas dos vistas son modeladas en paralelo, pues contribuyen una con otra y deben ser consistentes. Es difícil modelar una de las vistas completamente y pasarse a la otra, pues su desarrollo es interactivo.

02/05/2005

44/51

Cimat ©


Los diagramas UML usados para documentar esta vista son diagramas de clases y objetos. Los diagramas de clases muestran la estructura principal; los diagramas de objetos muestran una configuración actual del diagrama de clases (ejemplo, como se ve la organización en un punto especifico del tiempo). Recordemos que el diagrama de clases también fue usado en la vista de visión del negocio para crear un modelo conceptual de los conceptos básicos del negocio. El diagrama de clases modelado en la vista de estructura del negocio representa los recursos, información y la organización con mas detalle, además de las reglas del negocio que gobiernan la estructura. 2.3.4.1 Modelando los Recursos Los modelos de recursos muestran la estructura de los diferentes recursos. El modelo genérico es representado en un diagrama de clases, mientras que la actual configuración de la estructura es mostrada en un diagrama de objetos. La estructura interna de los recursos, que son usualmente productos o servicios ofrecidos por la compañía, pueden ser representados en un modelo de recursos. La diferencia entre un modelo de recursos y un modelo conceptual (como se muestra en la vista de visión del negocio) es que el modelo de recursos se concentra en estructuras de los recursos mas concretas, tales como productos o servicios, mientras que el modelo conceptual se concentra en definir el significado y relaciones de los conceptos importantes usados cuando se define el negocio. La siguiente Figura 2-17 muestra un ejemplo de un diagrama de clase de recursos. Figura 2-17 Ejemplo de un Diagrama de Clases de Recursos


02/05/2005

45/51

Cimat ©


2.3.4.2 Modelando la Información El modelar información crea modelos de información y es una importante estratégica en el negocio. Incluso aunque la información también es un recurso en el negocio, ésta es la que vale mas la pena modelar por separado usando las técnicas de los diagramas de clases y objetos. La información es la que debe ir en los sistemas de información que apoyan los negocios; esto es de valor estratégico para el negocio. Los requerimientos de información son gobernados por el negocio pero a veces la información disponible también gobierna el negocio. Por ejemplo, la información que tiene un negocio, puede crear nuevas oportunidades para el negocio; mientras mayor información se pueda capturar de un cliente, hay más posibilidad de adaptar y configurar los productos y servicios. La siguiente figura muestra un ejemplo de diagrama de clases de información. Figura 2-18 Ejemplo de un Diagrama de Clases de Información


2.3.4.3 Modelando la Organización Modelar la organización es otro caso especial del modelado de recursos, en el cual los recursos son colocados en unidades organizacionales que son relacionados una con otra de acuerdo con reglas especificas. Los recursos colocados en una organización incluyen empleados, maquinas y localizaciones. Los procesos también pueden ser ubicados en una organización, o los recursos de una organización pueden ser ubicados en un proceso. Recordemos que un proceso ofrece empalmar las fronteras de varias unidades organizacionales. Esto 02/05/2005

46/51

Cimat ©


no significa que la organización no sea importante. A menudo la responsabilidad de echar a andar un proceso es asignado a un proceso propietario quien es ligado a una unidad organizacional. Este propietario maneja el proceso incluso cuando este empalma unidades organizacionales. La organización debe hacer un uso óptimo de los recursos dentro del negocio y esforzarse en evitar la desoptimización interna, lo cual desafortunadamente es común en muchas organizaciones. Las funciones básicas del modelo organizacional son mostrar la ubicación de los recursos, los métodos de reporte, la asignación de tareas y la forma en que es manejada la compañía. La organización puede incluir varias dimensiones, tales como las unidades de organización, ubicación geográfica y la ubicación de procesos. La Figura 2-19 muestra un ejemplo de un modelado organizacional como diagrama de clases. Figura 2-19 Modelo de la Organización como un Diagrama de Clases


La estructura global de la empresa es expresada a través de diagramas de clases y objetos. Un diagrama de clases especifica la estructura básica y las reglas de la organización y un diagrama de objetos muestra la actual organización en uso. La tendencia en modelos de la organización es evitar la clásica estructura jerárquica a favor de alineaciones más flexibles y dinámicas. 2.3.5 Vista de Comportamiento de Negocio La vista de comportamiento de negocio ilustra el comportamiento individual de los recursos y procesos en el negocio así como la interacción entre varios recursos y procesos diferentes. El comportamiento del objeto de recurso es gobernado por la 02/05/2005

47/51

Cimat ©


vista del proceso del negocio, que muestra el flujo del control principal global y el trabajo realizado. La vista de comportamiento de negocio ve a cada objeto involucrado con mas detalle: su estado, su comportamiento en cada estado y sus posibles transiciones de estado. La vista de comportamiento también muestra la interacción entre diferentes procesos tales como la manera de cómo de realiza su sincronización. Usada de esa forma, la vista de comportamiento viene a ser una importante herramienta para ubicar la responsabilidad precisa de varias actividades y para definir el comportamiento exacto de cada recurso que toma parte en el proceso. La vista de comportamiento de negocio es definida por diagramas dinámicos de UML: diagramas de estado, secuencia, colaboración, procesos, etc. 2.3.5.1 Modelado de Estado El modelado de estado muestra el comportamiento de un recurso individual para identificar los posibles estados de un recurso y el comportamiento del objeto del recurso en cada estado. El comportamiento del recurso es ilustrado usando los diagramas de estado de UML, con los siguientes conceptos clave: •

Estados: Los diferentes estados que el objeto puede tener, incluyendo sus estados de inicio y final.

•

Eventos: La causa de la transición de estado en la cual el estado del objeto es cambiado a otro estado. Los eventos que pueden enviarse a un recurso son mostrados como operaciones en la clase de recurso.

•

Acciones: Las actividades realizadas en un estado especifico o cuando van de un estado a otro. Las acciones realizadas son modeladas como las acciones tomadas dentro de una operación en la clase de recurso.

Normalmente, los estados de recursos, no procesos, son mostrados cuando se modela el estado. Los diferentes estados en un proceso son las actividades en un proceso. Un diagrama de estados de un proceso es muy similar a un diagrama de procesos y no agrega ninguna información significante. 2.3.5.2 Modelando la Interacción El comportamiento de un sistema de negocio también esta compuesta por la interacción entre procesos y la interacción entre recursos. Estas interacciones pueden ser mostradas en diagramas dinámicos de UML como el diagrama de secuencia y colaboración; esto es llamado modelado de interacción. El diagrama de estados modela el comportamiento individual de cada recurso específico mientras los diagramas de secuencia o colaboración muestran el comportamiento, la interacción que ocurre entre varios recursos diferentes.

02/05/2005

48/51

Cimat ©


2.3.5.3 Diagramas de Secuencia y Colaboración La técnica tradicional para ilustrar las interacciones entre los objetos en UML es dibujar diagramas de secuencia y colaboración. Ambos tipos de diagramas muestran como interactúan un grupo de objetos a través de operaciones llamadas en un escenario específico. Los diagramas de secuencia y colaboración pueden ser usados para mostrar la cooperación detallada de un número de objetos recursos. Ambos diagramas, de secuencia y colaboración muestran una interacción y el modelador puede escoger cual usar. En general, el diagrama de secuencia enfatiza la secuencia en tiempo, mientras que el diagrama de colaboración enfatiza las relaciones entre los objetos. Las Figura 2-20 muestra un ejemplo de un diagrama de secuencia y la Figura 2-21 muestra un diagrama de colaboración. Figura 2-20 Diagrama de Secuencia


02/05/2005

49/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-21 Diagrama de Colaboración


2.3.5.4 Diagrama de Procesos La interacción entre procesos puede ser mostrada en un diagrama de procesos, el que como recordaremos es un diagrama de actividades de UML con estereotipos. Los objetos de salida desde un proceso son los objetos de entrado de otros procesos. Este es el caso cuando los subprocesos de un proceso se muestran, como dos procesos independientes mostrados en el mismo diagrama. Note que un proceso no es modelado como una sola clase como un recurso; este es actualmente una abstracción de la interacción entre actividades realizadas por varios recursos de las organizaciones. La Figura 2-22 muestra un ejemplo de un diagrama de procesos.

02/05/2005

50/51

Cimat ©

Guía Metodológica para el Modelado de Negocio – v. 1.0 Figura 2-22 Diagrama de Procesos


02/05/2005

51/51

MODELADO_DE_NEGOCIOS

Recommend Documents