Capítulo 4: Vistas empresariales

Visión de conjunto

Modelar un negocio complejo requiere el uso de múltiples vistas. Cada vista se centra en un
aspecto particular del negocio y se describe a través de una serie de diagramas, a veces
complementados con un documento textual. Los enlaces a la información en las vistas permiten
navegar de una vista a otra, proporcionando así una imagen más completa de la empresa.

Diseñar un modelo es muy parecido a armar un rompecabezas: al principio hay numerosas piezas
aisladas. Empiezas juntando piezas, generalmente examinando las piezas y su estructura, forma y
apariencia. Lentamente, una imagen evoluciona hasta que todas las piezas se unen en una imagen
completa. El mismo proceso se lleva a cabo en el modelado de negocios: las vistas no se modelan
de forma aislada, una a una, sino de manera gradual a medida que se recopila y se comprende la
información sobre la empresa. La información se modela en diferentes diagramas, y cada diagrama
se asigna a la vista que mejor captura ese aspecto particular del negocio. Aquí es donde termina la
metáfora, sin embargo, porque a diferencia de un rompecabezas, un modelo de negocio rara vez
muestra la imagen completa del negocio, y

rara vez encajan perfectamente todas las piezas de información. Por el contrario, el modelo de
negocio es una imagen de un aspecto particular del negocio.

Como base para definir una arquitectura de negocios con estos puntos de vista, es preferible tener:
§ Un conocimiento del negocio, recopilado de la experiencia e información de aquellos que
trabajan en este tipo de negocios.

§ Modelos previos del negocio.

§ Modelos de referencia para este tipo de dominio; es decir, estilos arquitectónicos genéricos o
patrones para este tipo de negocio.

Con frecuencia es el caso, sin embargo, que los modelos anteriores no existen, que hay muy pocas,
si alguna, descripciones textuales de los procesos, y que las personas en el negocio admiten
abiertamente que los procesos actuales no son eficientes. En consecuencia, el modelado debe
comenzar con reuniones grupales o entrevistas con los empleados y gerentes de la empresa. Los
diagramas ásperos se esbozan en base a la información recopilada en esta etapa inicial. A medida
que avanza el proceso de modelado, se agregan detalles y evolucionan los bocetos. Generalmente
hay una persona, el arquitecto de negocios, que es responsable de supervisar el proceso de
modelado y visualizar la arquitectura completa.

Una pregunta común que se formula al definir un modelo es ¿qué nivel de detalle debe incluirse en
la definición? No es una pregunta fácil de responder. Si el modelo presenta una descripción general
de alto nivel del negocio, la descripción será demasiado general y solo expresará lo obvio. Por otro
lado, si el modelo intenta capturar todo con gran detalle, será un modelo muy complejo que es
difícil de usar, evolucionar o navegar.

La solución ideal está en algún lugar entre estos dos extremos. El nivel de detalle incluido en el
modelo depende del propósito del modelo. Si el modelo se utilizará para construir sistemas de
información, se debe enfatizar la definición de la información utilizada y el formato de esa
información. Si el modelo se utilizará para mejorar o innovar el negocio, se deben enfatizar las
interacciones en los procesos, y se deben identificar los posibles cambios que podrían mejorar el
rendimiento general. Conocer el uso previsto del modelo de negocio es esencial para poder decidir
el nivel de detalle apropiado necesario para cada vista o diagrama.

Usar una herramienta como la ingeniería de software asistida por computadora (CASE) o la
herramienta de ingeniería de negocios asistida por computadora (CABE) para dibujar estos
diagramas hace que sea más fácil navegar de un diagrama en una vista a un diagrama en otra. La
herramienta almacena toda la información en su base de datos interna y proporciona enlaces a un
concepto específico que aparece en varios diagramas. Esto hace que sea más fácil encontrar todas
las instancias donde se define o usa ese concepto. Estas herramientas también hacen que la
administración de modelos más grandes sea más fácil de lo que sería posible si aparecieran solo en
papel (los modelos más pequeños, sin embargo, pueden manejarse solo en papel). El uso de una
herramienta permite al modelador o al lector del modelo centrarse en un aspecto del negocio a la
vez, para comprender gradualmente el negocio y su arquitectura. Esto no quiere decir que las
herramientas CASE se deben tratar como las herramientas milagrosas que a veces se
comercializan; lo que pueden hacer es proporcionar ayuda administrativa y simplificar el desarrollo
de modelos complicados. Este capítulo define cuatro vistas empresariales utilizando diagramas
UML estándar y las extensiones empresariales Eriksson-Penker introducidas en el Capítulo 3,
"Modelado de la arquitectura empresarial". Recuerde que estas extensiones se crean utilizando la
gramática UML y los mecanismos de extensibilidad estándar de UML que incluyen estereotipos,
valores etiquetados, y restricciones Las vistas y los diagramas se ilustran con un ejemplo continuo
de un modelo de negocios para la empresa ficticia Sample Business, Inc., una empresa que
comercializa y vende servicios financieros a través de Internet.

Cuatro vistas comerciales comunes

Las extensiones comerciales de Eriksson-Penker utilizan cuatro vistas diferentes de un negocio.

Elegimos las cuatro vistas como base para las descripciones de este libro porque son aspectos
comunes a las empresas en general y se combinan bien con las capacidades de UML. Su
incorporación como se da aquí no es obligatoria; otras vistas se pueden definir y usar en diferentes
procesos de modelado, como los efectos económicos y la vista de resultados, o una vista de
aspectos humanos que destaca el papel humano y los objetivos humanos en el negocio.

Las cuatro vistas utilizadas en este libro son: Business Vision. La visión general del negocio. Esta
vista describe una estructura de objetivos para la empresa e ilustra los problemas que deben
resolverse para alcanzar esos objetivos. Procesos de negocio. La vista que representa las
actividades y el valor creado en el negocio e ilustra la interacción entre los procesos y los recursos
para alcanzar el objetivo de cada proceso. La vista también demuestra la interacción entre
diferentes procesos. Estructura de negocio. Las estructuras entre los recursos en el negocio, como
la organización del negocio o la estructura de los productos creados. Comportamiento empresarial.
El comportamiento individual de cada recurso y proceso importante en el modelo comercial. Las
vistas no son modelos separados; son diferentes perspectivas sobre uno o más aspectos
específicos del negocio. Combinados, las vistas crean un modelo completo del negocio (Figura 4.1).

Figura 4.1: Una arquitectura de negocios se describe con cuatro vistas: visión de negocios,
procesos de negocio, estructura de negocios y comportamiento comercial. Las siguientes secciones
analizan cada una de estas vistas a su vez, su propósito general, el esfuerzo de modelado requerido
para definir la vista, los diferentes diagramas dentro de la vista y las técnicas para capturar y definir
esos diagramas usando UML. Recuerde en el Capítulo 2 que la mayoría de los diagramas UML son
aplicables para el modelado de negocios, pero hay tres que no se utilizan en absoluto: caso de uso,
componente y despliegue. Estos tres se utilizan para analizar y diseñar sistemas de información, y
tienen un papel menos importante en el modelado de negocios. El diagrama de casos de uso
identifica los requisitos en el sistema de información y vincula los modelos comerciales a los
modelos del sistema de información. Los diagramas de componentes y despliegue se usan para
modelar arquitecturas de software. (Tenga en cuenta que existen otras opiniones sobre casos de
uso y modelos comerciales, algunas de las cuales abogan por incluir casos de uso para modelos
comerciales. Nuestra experiencia es, sin embargo, que la función más importante de los casos de
uso es especificar los requisitos en los sistemas, mientras que el modelado empresarial requiere un
enfoque más orientado al proceso.) Las cuatro vistas se presentan aquí en el orden en que se
definen con mayor frecuencia; nuevamente este no es un proceso secuencial y el orden variará. El
Capítulo 5, "Reglas comerciales", explica cómo se pueden aplicar las reglas comerciales en todas
las vistas. Capítulos 6

a través de 9 patrones de negocio actuales que utilizan estas vistas, y brindan ejemplos adicionales
de cómo se pueden usar y organizar en el modelado de diferentes situaciones de negocios.

Vista de visión empresarial

La vista Business Visión representa los objetivos de la empresa. Es una imagen de hacia dónde se
dirige la empresa. Esta vista establece la estrategia general para el negocio, define los objetivos del
negocio y actúa como una guía para modelar los otros puntos de vista. Muchos de los objetivos en
esta vista no serán visibles en las otras vistas o en los sistemas de información, a pesar de que
afectan indirectamente la funcionalidad de los sistemas de información. Esto se debe a que los
objetivos se han dividido en objetivos más detallados, o porque el sistema de información en
realidad no almacena información sobre los objetivos (el sistema es parte de un proceso comercial
más amplio que se esfuerza por lograr el objetivo). La vista guía el proceso de modelado, actuando
como un punto de referencia para las decisiones de diseño al construir los sistemas de
información. La vista Business Vision también se usa como una herramienta motivacional. Se debe
compartir con los empleados del negocio y proporcionar la información y los recursos, así como
asignar la responsabilidad, para lograr esas visiones.

Tenga en cuenta que la vista Business Vision no contiene una descripción detallada de los objetivos
que se deben alcanzar. Más bien, es una estrategia básica para seguir adelante. La visión a menudo
se enfoca en mantener y fortalecer los aspectos fuertes del negocio y eliminar o mejorar los
débiles.

Hay algunos factores importantes a considerar al crear la vista Business Vision, de acuerdo con
Geoffrey Darnton [Darnton 97] [1]: Misión de la empresa. El objetivo general de la empresa.
Objetivos. Objetivos más específicos, mensurables a lo largo de un período de tiempo. Fortalezas
Los aspectos específicos en los que sobresale la empresa. Debilidades. Los aspectos específicos del
negocio que requieren mejoras. Oportunidades Áreas de crecimiento potencial para el futuro del
negocio. Amenazas Condiciones externas que pueden afectar negativamente al negocio (por
ejemplo, competidores, cambios en la tecnología, etc.). Factores críticos. Elementos que se
requieren para que la empresa tenga éxito o crezca (por ejemplo, un tiempo de comercialización
rápido, una buena adaptación a la nueva tecnología, etc.). Estrategias. Planes de acción que, si se
aplican, lograrán los objetivos. Competencias principales. Áreas del negocio que son de mayor
importancia. Roles Las funciones específicas de las personas que trabajan en el negocio. Unidades
de organización. Grupos en los que se divide el negocio. Procesos clave Los pasos clave para
alcanzar los objetivos.

También es importante observar atentamente a los clientes, las empresas competidoras y lo que
está sucediendo en el mundo para identificar los cambios y tendencias futuras en la industria entre
los competidores, en el segmento del mercado, en la tecnología o en reglamentos o políticas. Estos
cambios pueden imponer amenazas o crear oportunidades para el negocio, y deben cumplirse con
los cambios en el rendimiento del negocio. Las medidas económicas como la rentabilidad, la
solidez y el flujo de efectivo también deben estudiarse y compararse con compañías similares
dentro del mismo dominio comercial.

El resultado final de la vista Business Vision es una definición del estado futuro deseado de la
empresa y cómo se puede llegar a ese estado. El resultado primario se expresa en una declaración
de visión y uno o más modelos de meta / problema. Una declaración de visión es un documento de
texto breve que describe la visión de la compañía algunos años en el futuro. El modelo de
objetivo / problema es un diagrama formal que descompone los principales objetivos del negocio
en subobjetivos e indica los problemas que deben resolverse para alcanzar esos objetivos. Por lo
tanto, la declaración de visión es la forma legible de la visión y el modelo de meta / problema
muestra la definición de metas y objetivos secundarios más concretos que pueden vincularse a los
procesos de negocio.

Un miembro de la alta gerencia, como un CEO, presidente o miembro de la junta directiva, es

responsable de crear la declaración de visión y definir el nivel superior

metas. Esta persona debe ser capaz de comunicar la visión a todos los miembros de la compañía y
actuar como líder y mentor para el proyecto. Desglosar los objetivos y modelar los procesos es
responsabilidad de un arquitecto de negocios o modelador de procesos, pero el miembro de la
gerencia superior actúa como un defensor de los esfuerzos de modelado, enfatizando
continuamente su importancia para los empleados.

Hay tres técnicas utilizadas en la vista Visión empresarial: definición de estrategia. Posición de la
empresa con respecto al mundo actual y futuro, y los objetivos estratégicos o cambios necesarios
en el negocio. Modelado conceptual. Las definiciones de los conceptos importantes utilizados en el
negocio, junto con sus relaciones entre sí. Modelo de objetivo / problema. Definición de los
objetivos de la empresa, incluido el desglose de objetivos en objetivos secundarios, y la definición
de los problemas que dificultan el logro de los objetivos.

Los resultados de estas técnicas también se utilizan en otros puntos de vista, ya que definen los
objetivos del negocio, los conceptos utilizados al describir el negocio y las estrategias que
describen los cambios necesarios en los negocios.

Definición de estrategia

Definir una estrategia global para el futuro significa que el negocio debe ser visto en el contexto de
su mundo circundante con el fin de identificar las amenazas y oportunidades que requerirán que el
negocio cambie. Esto también implica decisiones sobre la dirección futura de la empresa,
planteando esta pregunta: ¿La gerencia o el propietario desea expandir o mantener su posición en
el mercado? Una expansión normalmente implica un mayor riesgo y, en última instancia, son los
propietarios quienes deciden si están dispuestos a correr ese riesgo.

La estrategia normalmente se basa en conclusiones que resultan de la evaluación de los procesos

centrales del negocio o mediante la creación de nuevos procesos que extienden el negocio a
nuevas áreas o nuevas formas de trabajo. Los procesos de soporte o procesos administrativos
normalmente no se consideran en esta etapa, ni son detalles de cómo los procesos centrales
deberían diseñarse o reorientarse. La estrategia muestra la dirección en que se dirige el negocio;
los procesos comerciales, así como la organización, deben adaptarse en consecuencia. La
estrategia indica cambios requeridos y presenta ideas estratégicas para la transición. La estrategia
también analiza fallas previas (como ofertas perdidas o fallas de productos) y define planes que
evitarían tales fallas en el futuro.

Las siguientes son consideraciones y preguntas típicas para la planificación estratégica: Cliente.
¿Quién es el cliente y qué características tiene él o ella? ¿Cómo está cambiando la interacción del
cliente con el negocio? Competidores. ¿Quiénes son los competidores y qué están haciendo? ¿De
qué manera están cambiando su modelo de negocio? Tamaño y posición en la industria. ¿Cómo se
posiciona el negocio en la industria? ¿Necesita expandirse para aumentar la cuota de mercado?
¿Cómo está cambiando la industria? Rentabilidad y crecimiento ¿Cómo se comparan la
rentabilidad y el crecimiento del negocio con otros negocios en el mismo dominio (benchmarking)?
El mundo circundante. ¿Qué cambios (específicamente políticos o tecnológicos) están teniendo
lugar? Percepción pública. ¿Cómo percibe el público a la compañía? ¿De qué maneras es deseable
cambiar esa percepción? ¿La empresa necesita una nueva imagen pública? Nivel de servicio. ¿Cuál
es el nivel de servicio al cliente? ¿Se podría mejorar o ampliar el servicio?

Hay dos técnicas utilizadas para definir la estrategia: una matriz TOWS y una declaración de visión.

Matriz TOWS

Una técnica utilizada para resumir la situación del negocio es evaluar amenazas, oportunidades,
debilidades y fortalezas. Las amenazas y las oportunidades son atributos externos del negocio, y las
debilidades y fortalezas son atributos internos del negocio. Estos atributos se enumeran en una
matriz de Amenazas, Oportunidades, Debilidades y Fortalezas (TOWS). [Weirich 82] [2] Los
atributos internos se muestran a lo largo del eje vertical y los atributos externos a lo largo del eje
horizontal. La matriz está llena de estrategias para manejar cada intersección entre un atributo
interno y un atributo externo (por ejemplo, una parte de la matriz muestra cómo aprovechar las
fortalezas internas y las oportunidades externas, y otra cómo manejar las debilidades internas que
se cruzan con las externas oportunidades). Las estrategias sugeridas en la matriz son la base de
una estrategia más formal. Las estrategias que se repiten en varias partes de la matriz se vuelven
especialmente importantes porque la repetición sugiere que esas estrategias tendrán un impacto
significativo en el negocio. La matriz TOWS a menudo se usa como base para redactar la
declaración de visión, el documento textual que describe el futuro del negocio. La matriz TOWS no
usa UML, lo que demuestra nuestra visión pragmática de que las técnicas que no usan UML
también se pueden usar cuando no hay un diagrama UML adecuado disponible. La Figura 4.2 es
una matriz TOWS para Sample Business, Inc. Recuerde, esta es una compañía que vende servicios
financieros a través de Internet. Sample Business, Inc. utiliza Internet como su principal medio de
comunicación con sus clientes. Los clientes usan un tablero de anuncios disponible en el sitio web
de la compañía para discutir libremente diferentes acciones y leer artículos sobre el mercado de
valores. El sitio también muestra los precios actuales del mercado de valores, ofrece perfiles de
compañías y ofrece otros servicios de interés para un inversor financiero privado. La compañía
también actuará como agente de bolsa en línea, lo que permitirá a los clientes mantener carteras
de acciones y comprar y vender acciones en los mercados a través de Internet. Los servicios de
intermediación, junto con servicios más avanzados, están disponibles solo para clientes
suscriptores que pagan una tarifa mensual. Otros servicios, como el tablón de anuncios, están
disponibles sin costo para los visitantes. Sample Business, Inc., que espera convertirse en un sitio
popular, también obtiene beneficios adicionales al vender espacio publicitario en la página de
Internet. Los anunciantes pagan una tarifa basada en el número de visitantes a sus páginas de
Internet.
Figura 4.2: Ejemplo de matriz TOWS. Las estrategias importantes se identifican mediante el análisis
de la matriz TOWS para Sample Business, Inc. en la Figura 4.2. De nuevo, aquellos que se repiten o
son similares son la clave. Tres partes importantes de una estrategia comercial que se pueden ver
en esta figura son: § Enfatizar que es un proveedor completo de servicios financieros en línea (la
estrategia para enfatizar que se trata de un servicio completo se menciona en varios lugares de la
matriz).

§ Dirigirse a clientes internacionales que desean invertir en el mercado estadounidense (el

mercado internacional se menciona como una oportunidad externa).

§ Obtener accionistas institucionales para asegurar el financiamiento inicial (se debe abordar la
debilidad de no tener suficiente financiamiento).

Aunque estas tres estrategias son las más dominantes, muchas otras estrategias mencionadas en la
matriz pueden y deben usarse en la declaración de visión. Estas estrategias se establecen como
objetivos estratégicos para Sample Business, Inc. Se deben determinar los medios para lograr estos
objetivos. La matriz TOWS es una técnica de apoyo que se usa a menudo antes de redactar la
declaración de visión.
Declaración de la visión

La estrategia se resume en una declaración de visión, un documento textual que describe el futuro
del negocio. Contiene descripciones del contexto comercial actual (lo que está cambiando, lo que
es importante), los requisitos del negocio, los problemas que se pueden visualizar y los posibles
escenarios de lo que podría suceder. La declaración de la visión es una descripción de cómo se
convertirá la empresa, cómo va a operar y qué tipo de resultados se esperan. La declaración de
visión debe contener objetivos de alto nivel claramente definidos que luego se dividirán en
objetivos operativos. Estos objetivos operativos se pueden vincular a objetivos para procesos
individuales. La declaración de visión también presenta sistemas o formas de medir si se logran los
objetivos de alto nivel.

Una declaración de visión también a menudo contiene un plan del esfuerzo del proceso a seguir, es
decir, una descripción de cómo organizar los modelos comerciales que respaldan la visión. La
declaración de la visión no es solo la visión de la administración del negocio, sino que también
tiene la intención de motivar a toda la compañía para que participe y contribuya al trabajo de
modelado y, más tarde, a la implementación de los procesos comerciales. Para evocar el cambio, la
organización debe estar convencida de la necesidad del cambio. Con demasiada frecuencia, los
empleados no están convencidos de que el plan propuesto funcionará o no lo respalda. Tales
situaciones naturalmente disminuyen las posibilidades de cambio. Por lo tanto, la declaración de
visión debe ser respaldada por gerentes que comuniquen las ideas y motiven a los empleados.

Modelado Conceptual

Un modelo conceptual define los conceptos importantes utilizados en el negocio. Este modelo
establece un vocabulario común para todos los conceptos y demuestra la relación entre diferentes
conceptos. Las definiciones claras de los conceptos básicos son fundamentales para entender el
negocio o modelar el negocio con más detalle. Sin un vocabulario común, las personas pueden
tener diferentes interpretaciones e interpretaciones de los conceptos.

Es importante darse cuenta de que hay una diferencia entre los términos utilizados para referirse a
un objeto, el concepto que describe el objeto y el objeto en el mundo real (esta teoría se llama
triángulo de Ogden). Por ejemplo, el término "automóvil" se usa para referirse a un automóvil. El
concepto de un automóvil podría definirse como un vehículo con motor, chasis y cuatro ruedas; y
un ejemplo de objeto de un automóvil en el mundo real podría ser un Toyota Celica 94. Mezclar
estos diferentes puntos de vista en discusiones o modelos puede dar lugar a malentendidos o
ambigüedad. Si se usan varios términos para referirse al mismo concepto, las referencias claras
deben estar presentes en un modelo conceptual para validar todos estos términos. Si es posible, el
modelo conceptual debe definir un término que se usará de manera consistente en todos los
modelos.

El modelo conceptual es un modelo de alto nivel de los conceptos que no tiene nada que ver con
un diseño de base de datos o con diseño de clase en un sistema de información, aunque se usa un
diagrama de clases para crear el modelo conceptual y los conceptos se modelan como clases.
Diagrama de clase para modelado conceptual

Un modelo conceptual se presenta con un diagrama de clase UML estándar. Los nombres de las
clases y asociaciones utilizadas en el modelo son importantes, ya que son los conceptos que se
definen. En UML, las flechas de los nombres de asociación se usan para especificar cómo leer una
relación y crear un modelo claro y comprensible. Las clases pueden tener atributos significativos
adjuntos para describir mejor los conceptos, así como una explicación textual definida en la
propiedad UML estándar, llamada Documentación (este texto no es visible en el diagrama UML
pero se puede recuperar con la ayuda de una herramienta ) Dichas descripciones textuales crean
un catálogo de términos en el que cada concepto se define en pocas oraciones. El nombre elegido
para cada concepto se usa luego en otros modelos y documentos que describen el negocio.

Tenga en cuenta que este diagrama de clases no es un diagrama final que describe todos los
conceptos posibles y todas sus relaciones. Es un primer intento de definir los conceptos clave
utilizados para describir este negocio. Se pueden introducir nuevos conceptos y relaciones en este
diagrama a medida que el modelado continúa. También en esta etapa, los atributos y las
operaciones de las clases no son tan importantes como lo serían en un diagrama de clase que
representa las clases de software. Más importante es capturar los conceptos como tales y sus
relaciones. Si agregar atributos y operaciones ayuda a caracterizar los conceptos, también se
pueden definir. La Figura 4.3 es un modelo conceptual de Sample Business, Inc. Los conceptos
importantes se modelan como clases, y las relaciones se expresan a través de las relaciones UML
conocidas como asociación, agregación y generalización. Leer el diagrama proporciona mucha
información sobre los conceptos principales en el negocio. Los clientes se dividen en tres tipos: §
Cliente ordinario, que es anónimo y solo visita el sitio de Internet.

§ Cliente registrado, que se ha registrado con nombre y dirección de correo electrónico.

§ Cliente suscriptor, que también paga una tarifa mensual para usar algunos de los servicios más
avanzados
Figura 4.3: El modelo conceptual de los conceptos más importantes en Sample Business, Inc.

El modelo muestra que un cliente suscriptor posee una o más carteras en las que se almacenan
valores y órdenes para comprar o vender valores. Poseer un valor se modela como una tenencia de
seguridad, donde una tenencia de seguridad representa una fecha de compra, un precio de
compra y el número de acciones que posee. La clase de seguridad representa un valor individual
en el mercado y se clasifica en Stock y Stock Option (naturalmente, también se puede modelar en
otros valores). Todos los valores están asociados con la información de precios del mercado y
tienen una clasificación con una recomendación de seguridad (por ejemplo, comprar, vender,
mantener). Un valor se asocia con la empresa que lo emitió y que incluye un perfil de la empresa
con una descripción detallada de la empresa (de acuerdo con las normativas) y noticias que
conciernen a la empresa. Finalmente, todos los clientes pueden leer y escribir mensajes en un
tablero de anuncios, que se divide en diferentes hilos de discusión

sugerido por los clientes. El tablero de fotos también contiene artículos sobre acciones y muestra
anuncios pagados. Cada una de las clases en el modelo también debe almacenar unas pocas
oraciones descriptivas en la propiedad de documentación de UML para la clase. Los atributos se
han suprimido en la figura 4.3, pero también se deben hacer y están relacionados.

Meta / problema de modelado

Un modelo de objetivos describe los objetivos del negocio y los problemas que se interponen en el
camino hacia el logro de los objetivos. Las metas controlan el comportamiento de la empresa y
muestran los estados deseados de algunos recursos en la empresa, como unidades producidas por
mes, ingresos por un producto específico o márgenes de ganancia. El modelo de objetivos
establece por qué existe el negocio, qué está tratando de lograr el negocio y cuáles son las
estrategias comerciales para lograr estos objetivos. Lo hace a través de una definición repetitiva de
subobjetivos, en el que cada objetivo se divide en sus subobjetivos, cada uno de los cuales a su vez
se divide en sus subobjetivos. Un modelo de objetivos también indica formas de mejorar el
negocio o resolver conflictos entre los objetivos. Algunos de los objetivos en un modelo de
objetivos pueden ser partes heredadas del negocio, mientras que otros objetivos pueden mostrar
áreas de mejora o oportunidades comerciales completamente nuevas.

Los objetivos se logran mediante los procesos comerciales y los recursos que participan en el
proceso. Por lo general, las subobjetivas más detalladas en un modelo de objetivos se asignan a
procesos individuales en el negocio. Si el objetivo es nuevo, es posible que sea necesario diseñar e
implementar un proceso completamente nuevo en el negocio.

Los objetivos y problemas se modelan en un diagrama de objetivos / problemas, que se basa en un

diagrama de objetos UML y algunos estereotipos en las extensiones comerciales de Eriksson-
Penker.

Meta / diagrama de problemas

Un diagrama de objetivo / problema es un diagrama de objeto UML de objetos y sus relaciones. El

modelo de objetivo completo es en realidad un número de diagramas de objetos, en el que cada
diagrama muestra un objetivo específico de alto nivel desglosado en subobjetivos. Los objetivos se
describen como objetos de clases que tienen el estereotipo «objetivo». Tales objetos se usan en
este diagrama para mostrar los objetivos, las dependencias entre las metas y las relaciones entre
las metas y los problemas que resuelven.

Hay dos clases de objetivos predefinidas en las Extensiones Empresariales de Eriksson-Penker,

aunque nada impide que el modelador defina otras clases de objetivos más especializadas. Las
clases de objetivo predefinidas son Objetivo cuantitativo y Objetivo cualitativo. Un objetivo
cuantitativo se puede medir fácilmente a través de algún valor que se logrará. Una meta cualitativa
es difícil de describir en términos mensurables, y por lo tanto, determinar si se ha logrado es más
compleja que las metas cuantitativas e implica un juicio humano. Ambos tipos de objetivos tienen
una descripción de objetivo como atributo. Un objetivo cuantitativo también tiene un valor de
objetivo, un valor actual y una unidad de medida.

Se requiere modelar objetivos como clases para definir una jerarquía de objetivos como un
conjunto de objetos, y al hacerlo también se muestra la posible implementación de estas clases en
un sistema de información. A menudo, el objetivo de un proceso no está representado en el
sistema de información, aunque el sistema de información brinda una excelente oportunidad para
medir cómo se está logrando el objetivo. Esto se debe a que el sistema de información tiene toda
la información necesaria para calcular los resultados del negocio (que puede ser en términos de
productividad, economía, calidad, etc.) y compararlos con los objetivos. Al implementar un
objetivo como clase, es posible tener operaciones que deciden si se cumple el objetivo y en qué
medida, así como realizar simulaciones de procesos en un sistema de información.

Un objetivo específico en el negocio se describe como un objeto de una clase de objetivo. Las
relaciones entre los objetivos son dependencias y asociaciones. Una dependencia entre dos
objetivos muestra que uno de los objetivos es un subgrupo o un dependiente de otro objetivo.
Las asociaciones se utilizan para mostrar enlaces entre dos objetivos, como las contradicciones
entre los objetivos.

Una dependencia está representada por una línea discontinua desde la súper-meta hasta la sub-
meta, terminando con una flecha abierta. El súper-objetivo depende entonces del sub-objetivo,
que debe interpretarse de modo que el cumplimiento de un sub-objetivo contribuya al
cumplimiento del súper-objetivo. Si un objetivo se puede dividir por completo en subobjetivos, se
dibuja una línea discontinua entre las dependencias y se escribe una restricción al lado de la línea,
en esta forma: {completa}. Si el objetivo no se puede dividir por completo en subobjetivos, se
escribe {incompleto} (este también es el predeterminado si no se escribe nada). Un objetivo que se
ha dividido por completo en subobjetivos (es decir, se especifica la restricción {completa}), indica
que el objetivo se completará automáticamente si se cumplen todos los objetivos intermedios.
Esto es lo que podría verse como una condición AND lógica entre los objetivos secundarios.
Actualmente no existe una condición OR lógica correspondiente en las extensiones, pero el
estereotipo contradictorio, explicado más adelante, se usa para indicar objetivos mutuamente
excluyentes. Si un objetivo no está completamente desglosado, otros eventos o resultados pueden
ser necesarios para cumplir el objetivo, incluso si se logran todos los objetivos intermedios.

El otro concepto clave que se muestra en un diagrama de objetivo / problema es un problema. Un

problema es un obstáculo que dificulta el logro de un objetivo. ¡Identificar los problemas es tan
importante como encontrar los objetivos! Al encontrar el problema, se descubren nuevas metas o
subobjetivos que intentan eliminar el problema. Por lo tanto, un problema siempre está
relacionado con un objetivo. Similar a los objetivos, los problemas también se pueden dividir en
subproblemas. Debido a que los problemas están vinculados a los objetivos, esta estructura
normalmente solo se muestra indirectamente en una jerarquía de objetivos, con los problemas
asociados a su objetivo respectivo. En las Extensiones Empresariales de Eriksson-Penker, un
problema se especifica más informalmente en una nota con el «problema» de estereotipo adjunto
a su objetivo. Un problema puede ser un problema temporal que puede resolverse de una vez por
todas, o puede ser un problema continuo que requiere una acción continua para evitar que el
problema vuelva a ocurrir. Los problemas se eliminan, se resuelven mediante acciones.

Un plan de acción se puede formular a partir del modelo de objetivos, donde los problemas
temporales se resuelven lo antes posible y los objetivos vinculados con los problemas continuos se
asignan a los procesos del negocio (es decir, logran el objetivo mediante actividades continuas). El
plan de acción contiene una lista de los problemas, la causa de cada problema, la acción adecuada
para cada problema, los requisitos previos para cada acción y, finalmente, el recurso o proceso
responsable de resolverlo. Esto también se puede mostrar visualmente en el diagrama objetivo /
problema mediante el uso de notas estereotipadas. Los estereotipos «problema», «causa»,
«acción» y «prerrequisito» especifican el propósito de la nota. Todos estos conceptos opcionales
se definen mediante el uso de notas informales, ya que normalmente se describen en texto simple
y no se pueden definir formalmente. Los procesos, diseñados más adelante, que implementan las
acciones y proporcionan los requisitos previos están formalmente definidos. La nota del problema
se adjunta a la meta, la nota de causa a la nota del problema, y así sucesivamente.

Una técnica para identificar objetivos es hacer estas preguntas: ¿Por qué deberíamos lograr este
objetivo? y "¿Cómo deberíamos lograr este objetivo?" Las respuestas a la pregunta ¿por qué?
identificarán metas más altas (metas para las cuales el objetivo actual es un sub-objetivo), y las
respuestas a la pregunta de cómo identificarán los objetivos secundarios. Responder a estas dos
preguntas hace posible identificar nuevas metas a partir de las existentes y revelar objetivos
adicionales que podrían no haber sido descubiertos por las personas en la empresa. La figura 4.4
es un diagrama genérico de objetivo / problema. Muestra las clases Objetivo cuantitativo y
Objetivo cualitativo, que son estereotipadas para «objetivo», y una serie de objetivos de estas
clases con sus dependencias. El objetivo X está completamente dividido en tres sub-objetivos (de
los cuales dos son cuantitativos y uno es cualitativo). Hay un problema relacionado con el subgrupo
X1; y los objetivos secundarios a X1 (uno o ambos) típicamente contribuyen a eliminar ese
problema. Los objetivos secundarios a X1 se consideran incompletos, lo que significa que pueden
tener que ocurrir otros eventos o resultados para cumplir el objetivo X1. El problema relacionado
con un objetivo se puede usar para buscar nuevos objetivos secundarios de ese objetivo.

Figura 4.4: Un objetivo genérico / diagrama de problemas.

Los Subgrupos X3-A y X3-B tienen un vínculo de asociación entre ellos estereotipado a
"contradictorio", lo que indica que los objetivos son contradictorios entre sí de alguna manera.
Ejemplos típicos de objetivos contradictorios son alta calidad y bajo costo. Intentar alcanzar estos
dos objetivos conducirá a contradicciones o conflictos. Por ejemplo, una decisión para lograr la alta
calidad conducirá a un aumento en el costo, lo cual está en conflicto con el objetivo de bajo costo.
Los objetivos contradictorios normalmente no pueden eliminarse, pero deben tenerse en cuenta al
tomar decisiones o al diseñar los procesos para evitar pasos innecesarios o incorrectos para lograr
los objetivos. La Figura 4.5 es un diagrama de objetivo / problema más concreto de Sample
Business, Inc. El objetivo general de este diagrama es tener muchos clientes. El valor del objetivo
se ha establecido en 500,000 clientes que son conocidos por la empresa; es decir, donde se han
registrado los nombres y las direcciones de los clientes (una empresa de Internet también puede
tener clientes anónimos). Este objetivo se ha dividido en tres subobjetivos que también describen
las categorías de los clientes: § Visitantes de Internet cuyos nombres se desconocen.
§ Clientes registrados, que han registrado sus nombres y direcciones de correo electrónico.

§ Suscriptores de clientes, que pagan una tarifa mensual para usar todos los servicios
proporcionados por la empresa.

Figura 4.5: Un ejemplo de un diagrama objetivo / problema.

Todas estas categorías se consideran clientes, y el concepto de negocio es proporcionar servicios

de calidad que atraerán a tantos nuevos clientes suscritos como sea posible. Los problemas en la
Figura 4.5 están relacionados con cada uno de los tres objetivos secundarios. Por ejemplo, el
problema asociado a la atracción de más visitantes de Internet es que los usuarios de Internet no
conocen el sitio. Este problema podría manejarse generando enlaces al sitio desde otros sitios
dentro de la comunidad financiera; asegurándose de que el sitio sea visible a través de los motores
de búsqueda más comunes; o mencionando el nombre del sitio en otros medios. Todo

estas acciones se han modelado como subobjetivos. Una vez más, estos objetivos secundarios
también tienen problemas relacionados con ellos que, a su vez, se utilizan para encontrar otros
objetivos secundarios.

El subgrupo "Enlaces desde otros sitios" también se define con la secuencia opcional de un
problema, causa, acción y definición de prerrequisito mediante el uso de notas. De nuevo, estos
son opcionales; no tienen que definirse para todos los problemas, o a veces no se deben definir
todas estas notas (por ejemplo, a menudo un problema y una nota de acción son suficientes). Sin
embargo, son útiles para visualizar lo que se necesita hacer para alcanzar los objetivos y cuáles son
los requisitos previos para una acción. Esta información luego se usa cuando se diseñan o cambian
los procesos de negocios. El diagrama del objetivo / problema en la Figura 4.5 muestra solo uno de
los objetivos principales de este negocio. Otros objetivos tienen sus propios diagramas. Todos los
objetivos principales del negocio se pueden resumir en un diagrama propio, donde se muestran los
conflictos entre los objetivos (objetivos contradictorios). Cada uno de los objetivos principales
puede describirse en un diagrama propio, con sus correspondientes objetivos secundarios. Por
ejemplo, el objetivo de atraer a muchos clientes puede ser contradictorio con la obtención de altos
ingresos de publicidad ya que los visitantes de Internet evitarán los sitios con demasiado contenido
publicitario. Esta contradicción podría ilustrarse en el modelo de objetivos utilizando una
asociación entre estos objetivos estereotipados a «contradictorios» (en la figura 4.4 se muestra un
ejemplo del uso de este estereotipo).

Es importante darse cuenta de que el diagrama objetivo / problema no debe estar excesivamente
formalizado o descrito en términos demasiado computacionales. El objetivo del diagrama
objetivo / problema es identificar y estructurar los diferentes objetivos del negocio y desglosar las
descripciones de los objetivos a un nivel en el que estos objetivos puedan asignarse a procesos
individuales.

Vista de proceso empresarial

La vista del proceso empresarial está en el centro del modelado de negocios. Los procesos
muestran las actividades que deben llevarse a cabo para lograr un objetivo explícito, junto con sus
relaciones con los recursos que participan en el proceso. Los recursos incluyen personas, material,
energía, información y tecnología; estos recursos se pueden consumir, refinar, crear o usar (es
decir, actuar como un catalizador) durante el proceso. Existen relaciones entre un proceso y sus
recursos y entre diferentes procesos que interactúan, y existe un acoplamiento de procesos a
objetivos. Los procesos tienen un propósito y un objetivo específico, y todos los procesos
colectivamente intentan alcanzar los objetivos generales del negocio. Las definiciones de proceso
se usan para comprender el negocio, para ver las amenazas u oportunidades en el negocio, para
mejorar o innovar, y para actuar como base para otros modelos (como los modelos de sistemas de
información).

Los objetivos de la empresa, tal como se establece en la vista Business Vision, son la base para los
procesos de modelado. Las descripciones de procesos existentes sirven como base para crear los
modelos, pero es importante tener en cuenta que estos deben revisarse con un ojo crítico. Los
procesos comerciales se modelan mediante entrevistas, debates con las personas en el negocio,
los resultados de sesiones de lluvia de ideas compuestas por grupos de personas cuidadosamente
seleccionadas y estudios prácticos sobre cómo funciona el negocio. Al realizar estas actividades, el
modelador intenta comprender y capturar cómo funciona el negocio y cómo se manejan los
recursos en la empresa. El resultado es la creación de una serie de diagramas de procesos que
describen al menos los procesos centrales de la empresa. Un proceso central es aquel que tiene
interacciones con el mundo externo o es crítico para la entrega de bienes y servicios ofrecidos por
la compañía. Los procesos centrales normalmente están orientados al cliente y son horizontales a
la organización tradicional de la empresa.

Una descripción del proceso debe ser una descripción genérica, mientras que una ejecución real
de un proceso ejecuta una ruta específica en el proceso. Esto significa que la descripción de un
proceso debe contener todas las alternativas de ejecución (es decir, incluidas las excepciones y las
condiciones de error que pueden ocurrir). Una instancia de proceso es un ejemplo de una
ejecución, una forma específica a través de la descripción general.
El arquitecto de negocios crea los modelos de procesos de negocio, posiblemente con el apoyo de
un equipo de modeladores de procesos. La vista del proceso empresarial se describe con un
diagrama de actividad UML. Para usar el diagrama de actividad como un diagrama de proceso, las
Extensiones Empresariales Eriksson-Penker establecieron un conjunto de estereotipos que definen
un proceso y varios recursos. Además, se utiliza una variante de un diagrama de proceso, llamado
diagrama de línea de ensamblaje, para representar de forma más clara cómo interactúa el proceso
con los recursos durante su ejecución. En el diagrama de la línea de montaje, los recursos son a
menudo recursos de información (es decir, objetos de información) en un sistema de información.

Es esencial definir lo siguiente al modelar negocios para identificar y especificar los procesos de
negocios: § ¿Qué actividades son necesarias? Estos se especifican como procesos o actividades en
un diagrama de proceso. § ¿Cuándo se realizan las actividades y en qué orden? Esto se especifica a
través del flujo de control en un diagrama de proceso. § ¿Por qué se realizan las actividades? ¿Cuál
es el objetivo del proceso? Esto se especifica en un diagrama de proceso a través del objeto de
objetivo adjunto y un diagrama de objetivo que coloca el objetivo en un contexto con otros
objetivos. § ¿Cómo se realizan las actividades? Esto se especifica en un diagrama de proceso, a
menudo dividiendo los procesos en subprocesos que definen las actividades con más detalle. §
¿Quién o qué está involucrado en la realización de las actividades? Esto se refiere a los recursos
que participan en el proceso. § ¿Qué se está consumiendo o produciendo? Esto se refiere a los
recursos consumidos o producidos en el proceso. § ¿Cómo se deben realizar las actividades? Esto
se define a través del flujo de control en un diagrama de proceso o mediante reglas comerciales. §
¿Quién controla el proceso? Esto se refiere al propietario del proceso que ejecuta el proceso o es
responsable de su éxito. § ¿Cómo se relaciona el proceso con la organización del negocio? Esto
puede mostrarse mediante el uso de swimlanes en un diagrama de proceso. § ¿Cómo se relaciona
el proceso con otros procesos? Esto se muestra a través del modelado de interacción, que se
analiza en la sección Vista de comportamiento más adelante en el capítulo.

A medida que su comprensión del negocio aumenta, las respuestas a todas estas preguntas se
hacen evidentes, lo que le permite modelar con precisión los procesos en el negocio.

Modelado de procesos

Existen varias técnicas utilizadas para modelar procesos, la mayoría de los cuales están orientados
al cliente y requieren la evaluación de los productos o servicios producidos en el negocio. Al
descubrir las interfaces para el cliente, es posible identificar los eventos comerciales que se
generan y luego analizarlos para indicar la acción apropiada que la empresa debe tomar para cada
evento. Al trabajar hacia atrás desde la definición del producto o servicio, descubre las actividades
necesarias 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 (por ejemplo, recursos) se captura y
se describe en un modelo de proceso, en el que cada paso del proceso agrega valor a los recursos
creados o refinados en el proceso.

Los procesos se modelan primero concentrándose y modelando por completo los procesos
centrales del negocio y luego pasando a los procesos de soporte. Una empresa generalmente no
tiene más de cinco o diez procesos principales, pero puede tener muchos más procesos de
soporte. Idealmente, todos los procesos se modelan e integran entre sí, pero si eso no es práctico,
el objetivo debería ser concentrarse en los procesos centrales. Los procesos centrales tienen
interfaces con los clientes y son los procesos que utilizan los clientes para evaluar el negocio.
También es importante determinar si los procesos de soporte indirecto de alguna manera limitan
los procesos de valor directo y central. Eso debería, por supuesto, evitarse.

El modelado de procesos crea una documentación precisa de la forma en que se realiza el trabajo,
quizás para desarrollar mejores sistemas de información. También se utiliza para mejorar o innovar
procesos para hacer que el negocio funcione de manera más eficiente. El modelado de procesos
también identifica nuevas oportunidades en el negocio y crea y diseña nuevos procesos que
aprovechan los recursos y el conocimiento presentes en la organización. Clarificar el propósito
antes de comenzar a modelar más finamente apunta al enfoque en lo que es importante en el
modelo. Puede determinar mejor si está en el camino correcto mientras modela, porque un
objetivo claro le proporciona al modelador un objetivo al que trabajar. Conocer el uso futuro del
resultado hace que sea más fácil decidir qué es importante y qué no.

La gestión de procesos es un área adicional de preocupación relacionada con el modelado de

procesos. Dado que los procesos no se asignan estrictamente a una sola unidad organizativa, sino
que abarcan varias unidades, se designa a un propietario de proceso específico dentro de la
organización como responsable de ese proceso. El propietario del proceso recibe autoridad sobre
este proceso en toda la organización. Esto es importante para garantizar que el resultado de un
proceso se distribuya equitativamente, por ejemplo, evitando que una unidad organizativa se
beneficie si un proceso funciona bien mientras que otra unidad organizacional observa una pérdida
por el mismo proceso. Idealmente, la forma vertical de construir unidades de resultados se elimina
y se reemplaza con una organización de procesos completa.

Se han escrito muchos libros sobre modelado de procesos, por lo que definitivamente hay más que
decir sobre este tema. Con ese fin, la lista de referencias al final del libro sugiere títulos para leer
sobre el trabajo más importante en esta área.

Diagrama de proceso

Un diagrama de proceso es un diagrama de actividad UML con un conjunto de estereotipos que

describen las actividades realizadas dentro de los procesos y cómo interactúan; los objetos de
entrada y salida; los recursos de suministro y control que participan en el proceso; y el objetivo del
proceso. La figura 4.6 muestra un diagrama de proceso genérico.
Figura 4.6: Un diagrama de proceso genérico. Un proceso es una actividad estereotipada para
«procesar». Este estereotipo tiene el icono de proceso tradicional que se muestra en la Figura 4.6.
Un proceso puede contener otros procesos, o subprocesos, que describen los pasos internos
tomados dentro del proceso general. Se usa un símbolo de actividad (un rectángulo con esquinas
redondeadas) para mostrar que un proceso no puede desglosarse más o que hacerlo no sería
significativo; es decir, una actividad es atómica. Un proceso atómico debe entenderse
intuitivamente según lo especificado por el texto dentro del símbolo de actividad, de modo que los
recursos que son responsables de realizarlo no puedan malinterpretarlo.

Los objetos de recursos y objetos de objetivo que están involucrados en el proceso se colocan
alrededor del proceso. Estos objetos son: Objetos de objetivo. Objeto de objetivo de un diagrama
de objetivo / problema que se ha asignado a un proceso. Un objeto objetivo se dibuja sobre el
diagrama de proceso y se adjunta con un

dependencia que es estereotipada para "lograr" desde el proceso hasta el objeto objetivo
(mostrando que el proceso intenta alcanzar el objetivo). Objetos de entrada. Objetos que se
consumen o refinan en el proceso. Los objetos de entrada son recursos y, como tales, pueden ser
estereotipados para «físico», «abstracto», «personas» o «información». Están conectados con
líneas discontinuas desde los objetos hasta el proceso (es decir, la notación del diagrama de
actividad para un objeto de entrada). Los objetos de entrada normalmente se colocan a la
izquierda del proceso. Objetos de salida. Objetos que son producidos por el proceso o que son el
resultado del refinamiento de uno o más objetos de entrada. Los objetos de salida también son
recursos y están conectados con una línea discontinua desde el proceso hasta el objeto de salida
(es decir, la notación del diagrama de actividad para un objeto de salida). Los objetos de salida se
colocan a la derecha del proceso. Suministro de objetos. Recursos que participan en el proceso
pero que no son refinados ni consumidos. Estos objetos se dibujan debajo del proceso con una
dependencia (una línea discontinua) desde el objeto hasta el proceso. La dependencia es
estereotipada para «suministrar». Controlando objetos. Recursos que controlan o ejecutan el
proceso. Dichos objetos normalmente se dibujan sobre el proceso, con una línea punteada desde
el objeto hasta el proceso. El estereotipo de la dependencia es «control».

Los refinamientos por un proceso a los objetos de entrada pueden cambiar la ubicación del objeto,
la apariencia del objeto o el contenido o la información en el objeto. Es difícil separar un objeto de
entrada de un objeto de suministro porque un objeto de suministro también puede cambiar su
estado durante el proceso. Un objeto de entrada representa un objeto clave que se refina o se
consume para producir el objeto de salida. Un suministro

objeto es aquel que el proceso requiere (participa en el proceso) para poder realizar ese
refinamiento o consumo. Por ejemplo, en un proceso de fabricación, un objeto de entrada podría
ser materia prima, y un objeto de suministro podría ser una máquina utilizada en el proceso. En
muchos casos, el objeto de salida es de la misma clase que un objeto de entrada, pero con un valor
adicional como resultado del proceso.

Tenga en cuenta que no se muestra multiplicidad en el diagrama de proceso. La multiplicidad no se

muestra en las dependencias donde solo se requiere un objeto de entrada de una clase específica
o un objeto de salida. En cambio, el proceso es una operación continua que procede a consumir
objetos de entrada y producir objetos de salida. Si se requiere el número de objetos de salida,
debe especificarse como un objetivo para el proceso (por ejemplo, el número de productos por día
o por mes), no a través de la multiplicidad como se usa para especificar las relaciones en UML. La
Figura 4.7 es un ejemplo de un diagrama de proceso que muestra el proceso de venta de
publicidad para vender espacio publicitario en páginas web. Tiene un objetivo cuantitativo
específico que incluye una suma de ventas, un costo y un presupuesto anual (tenga en cuenta que
esta clase de objetivo es una clase especial diseñada para este caso). A la izquierda están los
objetos de entrada: recursos de información sospechosos y prospectos. Un sospechoso es
información sobre una compañía que puede estar dispuesta a publicitar. Un prospecto es
información sobre una compañía que ha expresado interés en la publicidad. El resultado del
proceso de venta es Pedidos. El pedido es un recurso abstracto porque es un acuerdo entre un
cliente y Sample Business, Inc. Participando en el proceso están el vendedor y los recursos de
material de ventas. El proceso es controlado por un gerente de ventas y por las directivas de ventas
corporativas, generalmente un libro de instrucciones sobre cómo realizar ventas dentro de esta
compañía.

Figura 4.7: Un ejemplo de un diagrama de proceso.

Este proceso, Ventas publicitarias, debe integrarse con otros procesos comerciales. Podría haber,
por ejemplo, un proceso para encontrar a los sospechosos y prospectos, y un proceso de manejo
de pedidos para manejar el pedido una vez que se haya creado. Otros posibles procesos incluyen
un proceso de materiales de ventas para producir materiales y directivas de ventas, y un proceso
de reclutamiento para reclutar personal de ventas. La figura 4.8 es un diagrama de proceso en el
que se han agregado los carriles. Recuerde que un carril es una técnica utilizada para insertar
información donde pertenece un proceso o actividad específica. Normalmente, los carriles se
utilizan para describir dónde se realiza la actividad en términos de la organización del negocio (por
ejemplo, en qué división o departamento de la empresa). Un carril de navegación también puede
mostrar objetos distintos de la organización para ilustrar qué objeto es responsable de una
actividad o proceso específico. Podría, por ejemplo, mostrar qué máquina o persona es
responsable de realizar una actividad específica (sin tener en cuenta la organización a la que
pertenece la máquina o la persona).

Figura 4.8: Ejemplo de diagrama de proceso con carriles. Un carril de navegación está indicado por
dos líneas verticales. Todos los procesos que se colocan entre esas dos líneas pertenecen a la
unidad organizativa a la que se llama el carril. Por ejemplo, en la Figura 4.8, el departamento de
ventas realiza el proceso de ventas de publicidad. Los procesos que se extienden a más de un carril
flotante abarcan más de una unidad organizativa y se realizan dentro de más de una unidad. UML
especifica que las líneas de carril deben ser verticales, pero cuando se dibujan diagramas de
proceso más grandes, es más práctico dibujarlas horizontalmente. Swimlanes permite mostrar la
integración de procesos o cómo los procesos abarcan varias organizaciones. Mostrar la entrada y
los objetos de un proceso, como se ilustró anteriormente, hace que sea posible demostrar cómo
los objetos de salida de un proceso podrían convertirse en objetos de entrada o funcionar como
suministro de objetos a otros procesos. Un diagrama de proceso con carriles puede mostrar para
cada actividad los objetos de entrada y de salida de la actividad, así como

qué objeto está realizando la actividad (que se muestra colocando la actividad en un carril
específico). En la figura 4.8, el objeto pedido del proceso de ventas es un objeto de entrada al
proceso de diseño web, donde también se requiere como entrada un perfil de la empresa que
desea publicitar y un representante de esa empresa. El proceso de diseño web, que involucra a un
webmaster y un redactor publicitario, crea el anuncio real y un plan publicitario que describe con
qué frecuencia y en qué páginas debe mostrarse el anuncio. Esto se convierte en una entrada para
el proceso de implementación del sitio web, el proceso clave en la sección de entrega de la
empresa. La sección de entrega, con el proceso de implementación del sitio web, administra y
mantiene el sitio web, actualiza el material y se asegura de que el sitio esté disponible para los
clientes. El proceso de implementación usa el anuncio y el plan publicitario para actualizar el sitio
web actual en consecuencia. Otra técnica que se puede usar en los diagramas de proceso es
mostrar los eventos de negocios que el proceso recibe o genera. La Figura 4.9 muestra el proceso
de inicio de sesión del cliente. Después de iniciar sesión, el proceso espera un evento de selección
de servicio del cliente. Estos eventos comerciales también son objetos y se definen en un diagrama
de clases, como se muestra en la Figura 4.10. Según los eventos de negocios que el cliente genere,
el proceso continúa ejecutando uno de un conjunto de diferentes procesos alternativos. Este es un
ejemplo de polimorfismo orientado a objetos, una técnica en la que el tipo de un objeto decide
qué sucederá a continuación. Cada proceso maneja un tipo de solicitud; y al observar cada uno de
estos procesos, se detalla el manejo para cada tipo de solicitud. La figura también ilustra el símbolo
UML para generar un evento. El servicio comercial genera un evento de orden de stock, que se
envía a otro proceso (no se muestra aquí). Esta es toda la notación UML estándar para enviar y
recibir objetos de evento.
Figura 4.9: diagrama de proceso que muestra los eventos comerciales recibidos y generados.

Figura 4.10: Una jerarquía de clases de los eventos comerciales utilizados en la Figura 4.9. El
ejemplo del tablero de anuncios en la Figura 4.9 demuestra otro estereotipo, "no causal", que
cuando se interpreta puede hacer que el proceso produzca el objeto. El proceso de tablón de
anuncios tiene una dependencia no causal al objeto de mensaje de boletín, lo que significa que
dicho objeto podría ser el resultado del proceso (pero no siempre). Las relaciones y las
dependencias suelen ser causales, lo que significa que el objeto vinculado siempre se usa o se crea
como parte del proceso. En una dependencia no causal, que define un flujo de objeto o un flujo de
control, la conexión puede no existir y no existen condiciones bien definidas para cuando existe.
Esto se usa cuando hay un flujo de objeto no causal desde un proceso a un objeto, y el objeto
puede convertirse en un resultado del proceso (es imposible definir una condición clara para si el
proceso producirá o no este objeto). El estereotipo no causal también se puede aplicar a las líneas
de flujo de control entre procesos para indicar que un proceso puede conducir a la ejecución de
otro proceso. Si esto es resultado de una condición de regla bien definida, una regla comercial
debe definirse y especificarse entre corchetes para indicar que cuando se cumpla la condición, el
proceso siempre se ejecutará y no se aplicará ningún estereotipo. Sin embargo, a menudo no se
puede definir una regla estricta y, por lo tanto, se usa el estereotipo no causal. Recuerda eso

aquí intentamos describir un negocio complejo que a menudo es muy impredecible, no un

software que, cuando se escribe correctamente, es muy predecible. Si un modelo contiene muchos
procesos, los procesos se pueden asignar a paquetes para organizar el modelo, como se muestra
en la Figura 4.11. Recuerde que en UML, un paquete es una agrupación genérica de elementos.
Depende del modelador determinar qué paquetes son necesarios y qué representan. Los paquetes
pueden mapearse para representar la organización de la empresa, los diferentes tipos de procesos
o una serie de abstracciones por encima del nivel de proceso.
Figura 4.11: Paquetes de procesos. Diagrama de línea de ensamblaje

El diagrama de línea de ensamblaje es un diagrama único en las Extensiones de negocios de

Eriksson-Penker. Al igual que con el diagrama de proceso, se basa en gran medida en el diagrama
de actividad de UML. El diagrama de línea de ensamblaje (introducido en el método Astrakan) se
ha utilizado con éxito para modelar procesos, particularmente cuando el propósito del modelado
es la producción de sistemas de información que respaldan los procesos. Se denomina línea de
ensamblaje debido a la forma en que se ve: procesos que escriben y leen objetos colocados en una
línea de ensamblaje. En la parte superior del diagrama de la línea de montaje hay un diagrama de
proceso. Debajo del diagrama de proceso hay varios paquetes horizontales que se llaman paquetes
de línea de ensamblaje, cada uno representa un grupo de objetos (los objetos en el paquete
pueden ser de una clase específica o de diferentes clases, esa decisión depende del modelador).
Un paquete de línea de ensamblaje es un paquete UML que se estereotipa a "línea de ensamblaje"
y se dibuja como un rectángulo horizontal largo, como se muestra en la Figura 4.12. El propósito de
este diagrama es demostrar cómo los procesos en la parte superior del diagrama escriben y leen
objetos en la línea de ensamblaje. Una referencia de un proceso a un paquete de línea de
ensamblaje se indica con una línea discontinua (flujo de objeto) entre el proceso y un objeto
dentro del paquete de línea de ensamblaje. El tipo de operación realizada en el objeto se escribe a
lo largo de la línea (como el nombre del flujo del objeto). El diagrama se lee de izquierda a derecha
en la secuencia de referencias a los paquetes de la línea de ensamblaje.
Figura 4.12: Diagrama de línea de ensamblaje genérico.

Debido a que los objetos en el paquete de la línea de montaje a menudo son objetos de
información en un sistema de información, el diagrama de la línea de ensamblaje muestra a qué
información se accede a través del sistema y cómo los procesos usan esa información. Los objetos
también pueden ser otros recursos, y le corresponde al modelador determinar qué incluyen los
paquetes de la línea de ensamblaje. La descripción de lo que representa cada paquete de línea de
ensamblaje aparece en el valor etiquetado "Documentación" de cada paquete, ya que todos los
paquetes están estereotipados a "línea de ensamblaje". Un paquete podría, por ejemplo,
representar un todo

sistema de información, un subsistema en un sistema de información, una categoría especial de

clases en un sistema de información, o un tipo específico o grupo de recursos.

El diagrama de línea de ensamblaje se puede ver para que las actividades principales se muestren
en el diagrama de proceso. Las referencias al paquete de la línea de montaje son realmente
actividades de soporte completadas para hacer posible la ejecución de las actividades principales.
Debido a que se utiliza el mecanismo de paquete UML, un paquete de línea de ensamblaje es solo
un mecanismo de agrupamiento. El diagrama de línea de ensamblaje es una excelente manera de
mostrar cómo se leen o modifican los recursos como parte del proceso, y cómo un objeto
modificado (o creado) por un proceso en una etapa posterior es leído por otro proceso. La
interacción entre procesos a través de objetos de recursos comunes se muestra en el diagrama de
línea de ensamblaje. La Figura 4.13 es un ejemplo de un diagrama de línea de ensamblaje que
muestra los procesos Stock Handling Handling y Trade Handling y su interacción con una cantidad
de recursos en la línea de montaje. Los primeros tres paquetes de la línea de ensamblaje en este
caso corresponden a las clases de Portafolio, Orden y Mantenimiento de seguridad,
respectivamente; los paquetes de línea de montaje Mercado y Administración se utilizan más
como mecanismos de agrupación general para una serie de clases que representan un mercado y
una unidad administrativa dentro de la organización. Por ejemplo, el proceso Trade Handling crea
una Nota de contrato en el paquete de Administración como su última referencia a una línea de
ensamblaje, donde una Nota de contrato (un documento que se envía al comprador o vendedor
como verificación de una operación) es un objeto administrativo. es decir, un objeto en el paquete
de administración.

Figura 4.13: Ejemplo específico de diagrama de línea de ensamblaje. Diagrama de línea de

ensamblaje y casos de uso La Figura 4.14 muestra otro diagrama de línea de ensamblaje en el que
todos los paquetes de línea de ensamblaje son objetos en un sistema de información. El diagrama
muestra cómo el proceso interactúa con el sistema de información. Las referencias a los paquetes
de la línea de ensamblaje comprenden el flujo de información hacia y desde el sistema de
información y muestran la interfaz entre el proceso de negocios y el sistema de información. Esta
interfaz se describe a través de casos de uso en modelado orientado a objetos; y un conjunto de
referencias en un diagrama de línea de ensamblaje típicamente se convierte en un caso de uso que
el sistema de información debe proporcionar. Esto es muy importante porque mapea el proceso
comercial para usar casos que describen los requisitos funcionales de un sistema de información;
también identifica los actores adecuados de los casos de uso (los roles desempeñados por el
proceso que usa las líneas de ensamblaje). Los diagramas de línea de ensamblaje proporcionan la
conexión entre el modelado de negocios y el modelado de requisitos del sistema de software con
casos de uso. Una pregunta común cuando se modelan casos de uso en un sistema de software es
¿Cómo puedo saber si he definido los casos de uso correctos en términos del negocio? El diagrama
de línea de montaje es una buena técnica para responder a esto.

Figura 4.14: Las referencias a los paquetes de la línea de ensamblaje en un diagrama de línea de
ensamblaje se pueden mapear para usar casos que definen los requisitos de un sistema de
información.

Este análisis debe comenzar con los paquetes de la línea de ensamblaje en un nivel muy alto, como
el nivel del sistema o subsistema. Una vez que se identifican las referencias iniciales del proceso al
sistema de información, se pueden identificar las clases en el sistema, y el mismo análisis se puede
repetir con los paquetes ahora definidos en otro nivel más detallado. En este nivel más detallado,
las referencias del proceso también se vuelven más detalladas. Una sola referencia en el diagrama
inicial puede dividirse en varias referencias. También es importante que cada "conjunto de
referencias" que se convierte en un caso de uso no se elija de manera ad hoc, sino que se
seleccione de acuerdo con las reglas de identificación de casos de uso (por ejemplo, un caso de uso
es un servicio que aporta un valor específico a un actor externo). El caso de uso debe tener una
iniciación clara, una secuencia de comunicación entre el actor y un sistema, y un final bien definido
que aporte valor al actor. Si las referencias del proceso a los paquetes de la línea de montaje se
agrupan aleatoriamente en casos de uso, el resultado será casos de uso parcial mal formados.

Los requisitos no funcionales de los sistemas de información (como el rendimiento, la

disponibilidad, la usabilidad, etc.) pueden determinarse mediante el estudio de las descripciones
de los procesos. Factores como los plazos de entrega del proceso afectarán los sistemas de
soporte, como los sistemas de información, porque definen los requisitos del sistema de
información. Las características deseadas del proceso afectan directamente tanto a los requisitos
funcionales (¿qué debe hacer el sistema?) Como a los requisitos no funcionales (por ejemplo, qué
tan rápido y qué tan confiable debe ser el sistema). También hay factores que no se describen
directamente en el proceso que podrían afectar los sistemas de información, como un cambio en
el gobierno o una nueva ley. Al derivar todos los requisitos de los sistemas de soporte de los
procesos, con la línea de montaje y las propiedades del proceso, también es posible verificarlos.
Además, los procesos mismos son el resultado del modelado de objetivos, lo que significa que los
requisitos del sistema se pueden validar frente a los objetivos comerciales generales. La validación
se trata de hacer las cosas correctas (que logra los objetivos comerciales) y la verificación se trata
de hacer las cosas bien (para que los objetivos realmente se logren). Esto significa que al trabajar
con objetivos, procesos y el diagrama de línea de ensamblaje, es posible verificar y validar los
requisitos del sistema tanto funcionales como no funcionales. Es importante señalar que el
diagrama de la línea de montaje no está limitado al uso con sistemas de información; también se
ha utilizado con éxito para modelar sistemas logísticos y sistemas de recursos humanos.

Vista de estructura empresarial

La vista Estructura de negocio muestra las estructuras de los recursos, los productos o los servicios,
y la información en el negocio, incluida la organización tradicional de la empresa (divisiones,
departamentos, secciones, unidades de negocio, etc.). No muestra la estructura de los procesos ni
el desglose de los procesos en subprocesos; eso se muestra en la vista de proceso empresarial. La
vista Estructura de negocio se considera

complementario a la vista Proceso, que representa información que no se puede mostrar en el

diagrama de proceso pero que es vital para el funcionamiento de la empresa. También es
modelado por el arquitecto de negocios, nuevamente posiblemente respaldado por un equipo de
modeladores de procesos.

Los organigramas y las descripciones organizativas tradicionales, y las descripciones de los

productos y servicios que ofrece la empresa, son la base de la vista Estructura empresarial. La
información de la vista de Proceso también se utiliza, ya que muestra qué recursos se utilizan.
Tenga en cuenta que, por lo general, estas dos vistas se modelan en paralelo, ya que contribuyen
entre sí y deben ser coherentes. Es difícil modelar una de las vistas por completo y luego pasar a la
otra, ya que su desarrollo interactúa. Durante sus discusiones y entrevistas, encontrará que las
personas en el negocio intercambiarán información que pertenece a cualquiera de las vistas.

Los diagramas UML utilizados para documentar esta vista son diagramas de clases y objetos. Los
diagramas de clase muestran la estructura principal; los diagramas de objetos muestran una
configuración real del diagrama de clases (por ejemplo, cómo una organización mira un punto
específico en el tiempo). Debido a que los recursos se modelan como clases, tienen operaciones y
atributos. Las operaciones de un recurso se usan en un diagrama de línea de proceso o de
ensamblaje; es decir, los procesos usan las operaciones para activar el recurso para realizar un
servicio o acción específico. Recuerde que también se utilizó un diagrama de clases en la vista
Business Vision para crear un modelo conceptual de los conceptos básicos en el negocio. Los
diagramas de clase modelados en la vista Estructura muestran los recursos, la información y la
organización con más detalle, además de más reglas de negocios que rigen la estructura. El modelo
conceptual en la vista Visión proporciona una descripción general de alto nivel que define una
terminología común. Las interacciones entre varios recursos se pueden indicar en una secuencia
UML o diagrama de colaboración. Los diagramas de secuencia y colaboración muestran la
interacción entre varios objetos, en los que se puede mostrar tanto el orden en el tiempo como las
operaciones realizadas por los diferentes objetos. (Esto se ilustra y discute con más detalle en la
sección "Vista de comportamiento comercial" más adelante en este capítulo). Cuanto más
dinámica y flexible sea la estructura principal de los recursos, más se podrá cambiar la estructura
real en el futuro.

Modelado de recursos

Los modelos de recursos muestran la estructura de diferentes recursos. El modelo genérico se

representa en un diagrama de clases, mientras que una configuración real de una estructura se
muestra en un diagrama de objetos. La estructura interna de los recursos, que generalmente son
productos o servicios ofrecidos por la empresa, se puede presentar en un modelo de recursos. La
diferencia entre un modelo de recursos y un modelo conceptual (como se muestra en la vista
Business Vision) es que el modelo de recursos se concentra en estructuras más concretas de
recursos, como productos o servicios, mientras que el modelo conceptual se concentra en definir
el significado y las relaciones de conceptos importantes utilizados al definir el negocio. La Figura
4.15 muestra un diagrama de clases de la estructura de recursos del tablero de anuncios para
Sample Business, Inc. El tablero de anuncios consta de diferentes páginas web que contienen
mensajes, artículos o instrucciones. Todos los mensajes están organizados en hilos de discusión.
Una página web puede tener hasta cuatro anuncios adjuntos. Esto se modela con técnicas
tradicionales orientadas a objetos utilizando diagramas de clase.

Figura 4.15: Ejemplo de diagrama de clases de recursos. Modelado de información

El modelado de información crea modelos de información estratégicamente importante en el

negocio. Aunque la información también es un recurso en el negocio, vale la pena modelarla por
separado usando las técnicas de diagramas de clases y objetos. La información es lo que entra en
los sistemas de información que respaldan el negocio; tiene un valor muy estratégico para el
negocio. El modelado de la información es un primer paso para definir la información almacenada
en un sistema de información, aunque los detalles como los problemas de la base de datos (por
ejemplo, claves, etc.) no deberían formar parte del modelo comercial. Tales detalles se definen
durante el modelado del sistema de información de software.

Los requisitos de la información se rigen por el negocio, pero a veces la información disponible
también rige el negocio. Por ejemplo, la información que tiene la empresa puede crear nuevas
oportunidades para la empresa; Cuanta más información puede capturar una empresa sobre su
cliente, más posibilidades tiene de adaptar y configurar sus productos y servicios. Un ejemplo muy
obvio de esto es un negocio en Internet, donde numerosos sitios de comercio intentan aprender lo
más posible acerca de sus visitantes y clientes para personalizar sus páginas web. También hay
muchos ejemplos de empresas que tienen información que no se utiliza o explora por completo
con el fin de mejorar las relaciones comerciales o con los clientes. La Figura 4.16 es un diagrama de
clases que contiene clases para los recursos de información más importantes en Sample Business,
Inc. Tenga en cuenta que un modelo de negocio puede tener clases para información del cliente y
del cliente. La clase Cliente representa el cliente real, el recurso físico y cómo los objetos de esa
clase se comportan e interactúan en los procesos comerciales. La clase Información del cliente
representa la información sobre el cliente, que la empresa almacena en un sistema de información
(aunque también es plausible un simple archivo de tarjeta). Las clases de información del cliente y
del cliente son dos entidades separadas y deben modelarse como tales. Un error muy común en el
análisis y diseño de sistemas de información es que una clase en el modelo de análisis intenta ser
tanto el Cliente real (generalmente un actor en un caso de uso) como la Información del Cliente.

Figura 4.16: Ejemplo de un diagrama de clase de información.

Modelado de organización

El modelado de organización es otro caso especial de modelado de recursos, en el que los recursos
se asignan a unidades organizativas que están relacionadas entre sí de acuerdo con reglas
específicas. Los recursos asignados en una organización incluyen empleados, máquinas y
ubicaciones. Los procesos también se pueden asignar en una organización, o los recursos de una
organización se pueden asignar a un proceso. Recuerde que un proceso a menudo abarca los
límites de varias unidades organizativas. Esto no significa que la organización no sea importante. A
menudo, la responsabilidad de ejecutar un proceso se asigna a un propietario del proceso que está
vinculado a una unidad organizativa. Este propietario gestiona el proceso incluso cuando abarca
unidades organizativas. La organización debe esforzarse por hacer un uso óptimo de los recursos
dentro del negocio e intentar evitar la suboptimización interna, que, desafortunadamente, es
común en muchas organizaciones. Las funciones básicas de un modelo de organización son
mostrar la asignación de recursos, los métodos de informe, las asignaciones de tareas y la forma en
que se gestiona la empresa. La organización puede incluir varias dimensiones, como las unidades
de organización, la ubicación geográfica y la asignación de procesos.

La estructura general de una organización se expresa a través de diagramas de clases y objetos. Un

diagrama de clases especifica la estructura básica y las reglas para la organización, y un diagrama
de objetos muestra la organización actual actualmente en uso. Cuanto más flexible y bien diseñado
sea el diagrama de clases, más fácil será realizar cambios organizacionales sin afectar el modelo
comercial o sus sistemas de información de respaldo. Los recursos se suelen asignar a través de un
diagrama de objetos en el que los objetos de recursos están vinculados a objetos de la
organización. Los procesos están vinculados en una organización a través de carriles en un
diagrama de proceso, como se discutió anteriormente en este capítulo.

La tendencia en el modelado organizacional es evitar las estructuras jerárquicas clásicas a favor de

alineamientos más flexibles y dinámicos. Estas organizaciones pueden basarse en proyectos o
misiones en los que los recursos se asignan temporalmente a un proceso específico y pueden
basarse en una organización tradicional de la que se solicitan recursos o no tienen organización (es
decir, todo el trabajo se realiza en forma de proyecto). y los recursos se trasladan a otros proyectos
tan pronto como se completa un proyecto). La ventaja de la organización dinámica es que se crean
grupos de trabajo óptimos para cada tarea. La desventaja es que las personas con dichos recursos
pueden sentirse desorientadas como resultado de no pertenecer a una unidad organizativa
tradicional. Incluso en organizaciones jerárquicas muy estrictas, las estructuras informales y los
métodos de comunicación no están previstos (aunque en la práctica pueden tener lugar).

La tecnología de la información en muchas situaciones puede ser un habilitador de organizaciones

más flexibles, siempre que los sistemas de información no estén diseñados para una organización
específica y puedan adaptarse a los cambios. En el peor de los casos, si es imposible o muy costoso
adaptar los sistemas de información, su construcción obstaculiza los cambios en la organización o
el negocio. En el Capítulo 7, "Patrones de recursos y reglas", se describen algunos patrones
organizativos avanzados y pautas para crear organizaciones flexibles. El diagrama de clases
describe los nombres de las unidades organizativas y las reglas comerciales para organizarlos y
vincularlos entre sí. La Figura 4.17 muestra un diagrama de clases para una empresa con un equipo
de administración organizado en divisiones. Las divisiones a su vez están organizadas en secciones.
Esta figura muestra una estructura bastante estática que no permite mucha flexibilidad. Una mejor
solución es usar el concepto de powertypes, presentado en el Capítulo 2, "UML Primer" y
explicado con más detalle en el Capítulo 7, "Patrones de recursos y reglas".
Figura 4.17: Modelo de organización como diagrama de clase. La Figura 4.18 muestra un diagrama
de objetos que se adhiere al diagrama de clases en la Figura 4.17. Muestra instancias reales de las
clases y proporciona una vista de la organización actual. Un modelo o sistema basado en el
diagrama de clases en esta figura permitiría agregar o eliminar nuevas divisiones o secciones en el
futuro; pero no permitiría ningún cambio en la estructura real (por ejemplo, para que una sección
tenga subsecciones dentro de ella o para agregar nuevos conceptos de organización).

Figura 4.18: La organización real se muestra como un diagrama de objetos.

Vista de comportamiento empresarial

La vista Comportamiento empresarial ilustra tanto el comportamiento individual de los recursos y
procesos en el negocio como la interacción entre varios recursos y procesos diferentes. El
comportamiento de los objetos de recursos se rige por la vista de Proceso empresarial, que
muestra el flujo de control principal general del trabajo realizado. La vista Comportamiento
empresarial examina con más detalle cada uno de los objetos implicados: su estado, su
comportamiento en cada estado y las posibles transiciones de estado. La vista Comportamiento
también muestra la interacción entre diferentes procesos, como la forma en que están
sincronizados. Utilizado de esta manera, la vista de comportamiento se convierte en una
herramienta importante para asignar la responsabilidad precisa de las diversas actividades y para
definir el comportamiento exacto de cada recurso que participa en cada proceso.

Los estados combinados de los procesos y los objetos definen la condición actual del sistema. Los
estados se modifican mediante el funcionamiento del sistema, es decir, a través de los procesos.
Recuerde que en realidad son los recursos los que realizan el trabajo del negocio; el proceso solo
impulsa o coordina el trabajo de muchos recursos. Cuando se altera el estado de un proceso, se
generan eventos para notificar a otros procesos sobre el cambio de estado. Un estado también
decide qué puede suceder, qué acciones ocurrirán si un estado cambia y cómo se puede hacer que
un objeto entre en un estado específico (es decir, qué eventos se deben generar para modificar
deliberadamente el estado de un objeto). El estado es, por lo tanto, una parte importante de la
vista de Comportamiento, al igual que las acciones y los eventos. La vista Comportamiento está
definida por los diagramas dinámicos UML: diagrama de estado, secuencia, colaboración, proceso
y diagramas de línea de ensamblaje.

¿Cuál es la diferencia entre la vista Comportamiento empresarial y la vista Proceso empresarial?

Este último ilustra las actividades del sistema, las transformaciones y la funcionalidad, mientras se
concentra en las interacciones entre los recursos, los objetivos y las reglas en el negocio. La vista
Comportamiento ilustra el comportamiento dinámico de cada uno de los objetos involucrados en
estas actividades. Algunas actividades se describen en un nivel más detallado, y se definen
interacciones y responsabilidades que no son visibles en la vista Proceso. Naturalmente, debe
haber coherencia entre estos dos puntos de vista.

La vista Comportamiento empresarial es bastante detallada y normalmente la crean los

modeladores del proceso, con el apoyo de un arquitecto comercial que garantiza que estos
modelos sean consistentes con los diagramas del proceso empresarial.

Modelado de estado

El modelado de estados muestra el comportamiento de un recurso individual mediante la

identificación de los posibles estados de un recurso y el comportamiento del objeto de recurso en
cada estado. El comportamiento de un recurso se representa utilizando diagramas de diagrama de
estado UML con los siguientes conceptos clave: Estados. Los diferentes estados que el objeto
puede tener, incluidos sus estados de inicio y fin. Eventos. La causa de una transición de estado, en
la que el estado del objeto cambia a otro estado. Los eventos que se pueden enviar a un recurso se
muestran como operaciones en la clase de recurso. Comportamiento. Las actividades realizadas en
un estado específico o cuando se pasa de un estado a otro. Las acciones realizadas se modelan
como las acciones tomadas dentro de una operación en la clase de recursos.
Normalmente, los estados de los recursos, no los procesos, se muestran al modelar estados. Los
diferentes estados de un proceso son las actividades (es decir, subprocesos) en el proceso. Un
diagrama de estado para un proceso es muy similar a un diagrama de proceso y no agrega ninguna
información significativa. Diagrama de Diagrama de estado La Figura 4.19 muestra un diagrama de
estado para el recurso Orden de stock, que representa una orden de stock que se crea cuando se
recibe una orden del cliente. En algún momento, una comunicación con un mercado pondrá este
orden en el mercado. El mercado intentará hacer coincidir esta orden con otras órdenes en el
mercado, es decir, hacer coincidir una orden de compra con una orden de venta. Cuando se
informa una coincidencia desde el mercado, la orden se marca como concluida y una acción crea
una retención de seguridad que representa las acciones compradas. Una orden también puede
cancelarse y retirarse del mercado; o el día de negociación puede terminar sin hacer una
coincidencia. De acuerdo con el diagrama de estado, debe haber una decisión explícita de volver a
poner el pedido en el mercado para el día siguiente. Si no se vuelve a poner en el mercado, se
marcará como una orden cancelada.

Figura 4.19: Diagrama de estado del recurso Stock Order.

Modelado de Interacción

El comportamiento de un sistema de negocios también se compone de la interacción entre los

procesos y la interacción entre los recursos. Estas interacciones se pueden mostrar en los
diagramas dinámicos de UML, como la secuencia o el diagrama de colaboración; esto es

llamado modelado de interacción. El diagrama de estado modela el comportamiento individual de

un recurso específico, mientras que los diagramas de secuencia o colaboración muestran el
comportamiento, la interacción, que ocurre entre varios recursos diferentes.

Para complicar las cosas, la interacción entre recursos también es parte de un proceso y se puede
ilustrar en un proceso o en un diagrama de línea de ensamblaje. Los diagramas de secuencia o
colaboración deben usarse para mostrar solo los detalles de un proceso, por ejemplo, cómo se
realiza un cálculo específico o cómo se ve una interacción detallada entre recursos específicos. Las
actividades e interacciones primarias permanecen en el diagrama del proceso. Diagramas de
Secuencia y Colaboración

La técnica tradicional para representar interacciones entre objetos en UML es dibujar diagramas de
secuencia y colaboración. Ambos tipos de diagramas muestran cómo un conjunto de objetos
interactúa a través de llamadas de operación en un escenario específico. Los diagramas de
secuencia y colaboración se pueden usar para mostrar la cooperación detallada de varios objetos
de recursos. Esta cooperación también forma parte de un proceso general, pero se considera
demasiado detallada como para incluirla en un proceso o en un diagrama de línea de ensamblaje.

La interacción representada en un diagrama de secuencia y colaboración se desencadena por una

referencia de un proceso a un objeto en un diagrama de línea de ensamblaje. Los diagramas de
secuencia y colaboración muestran la interacción detallada entre los objetos colocados en
diferentes paquetes. Una referencia de un proceso a un paquete de línea de ensamblaje en un
diagrama de línea de ensamblaje desencadena la interacción entre una cantidad de recursos en el
diagrama de línea de ensamblaje. La interacción se modela al permitir que los recursos llamen
operaciones entre sí. La Figura 4.20 es un diagrama de secuencia que ilustra cómo se actualiza un
precio de seguridad. Esta interacción se desencadena por la negociación real de valores, un
proceso fuera del negocio. Este diagrama de secuencia muestra cómo se distribuye el precio a los
recursos dentro de este negocio. Los objetos que contiene pueden estar en un sistema de
información, pero también pueden ser recursos que interactúan como parte de un proceso. El
diagrama de secuencia, que se lee de arriba a abajo, resalta el orden de una interacción específica.

Figura 4.20: Diagrama de secuencia que muestra cómo se distribuye una actualización de precios
de un valor a otros recursos. La Figura 4.21 es un diagrama de colaboración que muestra cómo se
calcula el valor de una cartera. Nuevamente, esta es una descripción detallada similar a la
descripción de un algoritmo; los objetos son parte de un sistema de información. Esta interacción
se puede desencadenar a partir de todos los procesos que necesitan conocer el valor de la cartera
de un cliente, como un proceso que asigna crédito a un cliente o uno que produce información de
tenencia a un cliente.

Figura 4.21: Diagrama de colaboración que muestra cómo se calcula el valor total de una cartera.

Los diagramas de secuencia y colaboración muestran una interacción, y el modelador puede elegir
cuál usar. En general, un diagrama de secuencia enfatiza la secuencia en el tiempo, mientras que el
diagrama de colaboración enfatiza las relaciones entre los objetos (ya que es un diagrama de
objetos en el que se han agregado llamadas de operación entre objetos). También es posible
utilizar solo uno de estos diagramas de manera consistente a lo largo de un proyecto, para
simplificar el aprendizaje de la sintaxis UML y evitar el uso de demasiados tipos de diagramas
diferentes. Diagrama de proceso

La interacción entre procesos se puede mostrar en un diagrama de proceso, que recordará es un

diagrama de actividad UML con estereotipos de las extensiones. Los objetos de salida de un
proceso son los objetos de entrada a otro proceso. Este es el caso cuando se muestran los
subprocesos de un proceso, así como cuando se muestran dos procesos independientes en el
mismo diagrama. Tenga en cuenta que un proceso no se modela como una clase única como un
recurso; en realidad es una abstracción de la interacción y las actividades realizadas por una
cantidad de recursos. Para complicar las cosas, un proceso puede tener una clase de Soporte de
Procesos en un sistema de información, pero raramente maneja todo el proceso; el proceso no se
realiza completamente dentro del sistema de información. La Figura 4.22 ilustra cómo se colocan
dos procesos diferentes, A y B, en el mismo diagrama de proceso. Swimlanes indica la organización
del negocio. Tenga en cuenta que los objetos creados por el subproceso A3b son objetos de
entrada para el subproceso B2. También tenga en cuenta el ejemplo de cómo los procesos se
ejecutan en paralelo: el subproceso A3a y A3b se ejecutan en paralelo, y los objetos creados por
A3a se utilizan continuamente como objetos de entrada por A3b. Las líneas continuas entre los
procesos muestran el flujo de control de los procesos y las líneas discontinuas muestran el flujo de
objetos entre los procesos.

Figura 4.22 .: Diagrama de proceso que muestra dos procesos y su interacción. El diagrama de la
línea de montaje también ilustra la interacción entre los procesos a través de su interacción con
cualquier recurso común. Un proceso puede crear un objeto que se coloca en un paquete de línea
de montaje particular y luego es leído o usado por otro

proceso. Esta interacción se vuelve claramente visible mediante el uso del diagrama de línea de
ensamblaje. La Figura 4.23 muestra un ejemplo en el que la interacción entre los procesos Order
Handling y Conclusion of Order se realiza a través de objetos en los paquetes de la línea de
montaje. La referencia de un proceso a un paquete de línea de ensamblaje en el diagrama de línea
de ensamblaje también es lo que causa una interacción interna entre recursos, que, por ejemplo,
están presentes en un sistema de información. Esa interacción interna se puede representar
utilizando una secuencia o un diagrama de colaboración, como se discutió previamente en este
capítulo.

Figura 4.23: un diagrama de línea de ensamblaje que muestra la interacción entre procesos a
través de recursos comunes en los paquetes de la línea de ensamblaje.

[1] [Darnton 97] Darnton, Geoffrey y Moksha Darnton. Análisis de procesos comerciales.
Cambridge, U.K .: Thomson Business Press, 1997.

[2] [Weirich 82] Weirich, H. The TOWS Matrix: Una herramienta para el análisis situacional.
Planificación a largo plazo, 1982.

Resumen

La vista de Business Vision muestra la estrategia futura para el negocio y se crea en colaboración
con la gerencia superior o los dueños de negocios. La empresa se ve en contexto con sus clientes,
competidores y los cambios tecnológicos y políticos previstos para formular la estrategia, una
visión de hacia dónde se dirige el negocio. La estrategia se expresa en un documento textual,
llamado declaración de visión, que se comunica a todos los empleados del negocio y se usa como
entrada para modelar las vistas.

La declaración de visión se complementa con un modelo conceptual y diagramas de objetivos /

problemas. El modelo conceptual muestra todos los conceptos importantes en el negocio y sus
relaciones entre sí. El conjunto de diagramas de objetivos / problemas muestra los objetivos de
alto nivel en la declaración de visión divididos en subobjetivos, analizados en relación entre sí;
también señala los problemas que obstaculizan el logro de los objetivos.

Un modelo de objetivo / problema se expresa en clase UML y diagramas de objetos. Conduce a un

plan de acción, en el que los problemas temporales se pueden resolver de inmediato, pero los
problemas constantes se asignan a procesos continuos en el negocio.
La vista del proceso empresarial

está en el centro del modelado de negocios. Describe los procesos en el negocio junto con sus
objetivos, recursos y actividades. Los recursos que se consumen, producen, utilizan o refinan
durante un proceso incluyen personas, materiales, energía, información y tecnologías. Un proceso
se describe en un diagrama de proceso,

que es un diagrama de actividad UML con estereotipos adecuados para vincular recursos y
objetivos a los procesos.

El diagrama de proceso

muestra el proceso y el flujo de control de cómo los subprocesos están vinculados entre sí (un
subproceso se denomina actividad cuando no se puede desglosar más); también muestra flujos de
objetos estereotipados a los recursos, que son de entrada, salida o utilizados en el proceso. Un
proceso también puede tener una dependencia a un objetivo del modelo objetivo / problema. Los
objetos de recursos que toman parte en el proceso pueden suministrar objetos que alimentan el
proceso o controlar objetos que ejecutan el proceso. La organización del negocio se puede mostrar
en contexto con el proceso a través del uso de carriles, por lo que los procesos se colocan en un
carril para una organización específica o abarcan varias unidades organizativas. Un diagrama de
proceso también contiene símbolos para recibir o enviar eventos comerciales, donde un evento
comercial es un medio para comunicarse entre procesos. Un proceso se desencadena al recibir un
evento; genera un evento cuando termina su tarea. Un diagrama de línea de ensamblaje es un
diagrama de proceso extendido en el que se agregaron varios paquetes de línea de ensamblaje
debajo del diagrama de proceso. Estos paquetes, representados como paquetes de objetos UML,
se pueden usar para contener un tipo de objeto de información en un sistema de información. El
diagrama de línea de ensamblaje puede entonces ilustrar las referencias del proceso al sistema de
información, es decir, cómo se usan, escriben o leen los objetos en el sistema de información
durante el proceso y la secuencia de esas referencias. Este diagrama se puede usar más adelante
para definir los casos de uso que representan los requisitos funcionales del sistema de
información. El diagrama de línea de ensamblaje se usa para vincular los modelos comerciales a los
casos de uso en los modelos de software, creando así la oportunidad de rastrear los requisitos de
un sistema de software hasta los procesos que admite el sistema. (También se usa para validar los
requisitos. Esta conexión se trata en el Capítulo 10, "De una arquitectura empresarial a una
arquitectura de sistema de software").

La vista Estructura de negocio

muestra diferentes estructuras de los recursos en el negocio. Puede ser la estructura de un
producto o servicio (que muestra cómo se ensambla el producto o servicio de varios recursos), de
la información en el negocio o de la organización en la empresa. Los diagramas de clases y
diagramas de objetos definen la estructura en cada uno de estos casos. Un diagrama de clases
define las relaciones entre los conceptos y las reglas de cómo se pueden ensamblar. El diagrama de
objetos muestra una configuración real en un punto específico en el tiempo (es decir, un diagrama
de objetos puede mostrar la organización tal como está ahora).

La vista Comportamiento empresarial

describe el comportamiento de recursos individuales o la interacción entre recursos o procesos. Un

recurso se modela con un diagrama de diagrama de estado UML a través de sus estados, los
eventos que lo afectan y las acciones que realiza en un estado específico o cuando recibe un
evento específico. Las interacciones se muestran con cualquiera de los diagramas dinámicos de
UML: secuencia o colaboración. Estos diagramas muestran cómo interactúan varios recursos en
una situación específica. Estas interacciones se pueden ver como "mini-procesos", aquellos que no
están modelados en un diagrama de proceso sino que son activados por un proceso en un
diagrama de proceso. A menudo, la interacción tiene lugar dentro de un sistema de información y,
por lo tanto, no se muestra en el diagrama de proceso. Las interacciones entre procesos se pueden
modelar en un diagrama de proceso en el que se representa más de un proceso. Entonces es
posible mostrar el intercambio de recursos o la sincronización requerida entre los procesos. La
interacción entre procesos también se puede ilustrar en el diagrama de línea de ensamblaje en el
que un proceso escribe objetos en un paquete de línea de ensamblaje y otro proceso utiliza el
mismo objeto más adelante. El siguiente capítulo aborda las reglas comerciales. Las reglas
empresariales se utilizan en todas las vistas y diagramas presentados en este capítulo como una
forma de detallar y especificar aún más la información en ellos. Como se mencionó, UML tiene un
lenguaje recomendado, Object Constraint Language (OCL), para definir reglas comerciales, y el
Capítulo 5 muestra cómo se usa OCL para definir diferentes categorías de reglas comerciales.