El documento describe el diseño de negocios de un sistema de operaciones. Identifica y especifica el comportamiento de un subsistema de operaciones. También describe analizar casos de uso empresariales para identificar agentes de negocios, entidades y eventos. Además, discute construir una prueba de concepto arquitectónica para comprender mejor el problema y las soluciones posibles.

1. DISEÑO DE NEGOCIOS DE LA OPERACIÓN Ahora, trabajando con la ampliación (caja blanca) de negocios en las descripciones de casos de uso, el detalle de los mensajes, las entidades intercambiaron, secuenciación, control de flujo A continuación, los pasos de trabajo de la caja blanca y las realizaciones de la Operación, el Subsistema de Operaciones se identifican y se especifica su comportamiento. el Diseñador de negocios evalúa la calidad de las colaboraciones emergentes, en busca de oportunidades para refactorizar el diseño. los pasos de trabajo de la caja blanca y las realizaciones de la Operación, el Subsistema de Operaciones se identifican y se especifica su comportamiento

2. Las operaciones también se puede recurrir por localidad o por proceso, lo que demuestra la asociación de un conjunto de Subsistema de Operaciones con cada localidad o con cada proceso En el extremo, todas las operaciones de un subsistema se puede alojar en múltiples localidades, lo que significa que, efectivamente, se replica el propio subsistema. La necesidad de determinar los casos en replicar únicamente depende también de las razones para la replicación. Para cada subsistema, usted tiene: define sus operaciones define las interfaces que esperan que el subsistema de apoyo describió cómo el subsistema colabora con otros subsistemas para realizar el uso comercial de los casos define el contexto del subsistema: sus actores, las interfaces de E / S entidades empresariales Usted está por lo tanto una buena posición para ser capaces de hand-off de este conjunto de productos de trabajo a favor o en descomposición adicional para llevar a cabo de manera recursiva

3. EMPRESAS DE CASOS DE USO ANÁLISIS identificar a un trabajador de negocio y darle una breve descripción. También puede buscar en los sistemas de software actualmente en uso. Sin embargo, debe ser consciente de que-como los sistemas de software de la gente-muchos realizan múltiples funciones dentro de la organización identificado a sus trabajadores de negocios, caminar a través de cada caso de uso empresarial y el Estado que los trabajadores de negocio son involucrados en cada paso Identificar las Entidades de Negocios Para encontrar entidades candidatos negocio, considere qué información maneja cada trabajador de negocios. La información que debe ser consultada, una liquidación, creado, o comunicarse es un buen punto de partida. Caminar a través del flujo de trabajo de cada caso de uso comercial para garantizar que ninguna entidad de negocios han sido olvidados. Además, asegúrese de que los que han identificado están participando realmente en un flujo de trabajo.

4. Identificar Eventos Empresariales Inspeccione las interacciones entre los agentes empresariales, los trabajadores de empresas, y entidades comerciales. agentes de negocios pueden iniciar un caso de uso comercial mediante el envío de un evento de negocios.

5. PRUEBA DE NEGOCIOS CONSTRUIR ARQUITECTÓNICO DE CONCEPTO Dependiendo de qué enfoque de la construcción se ha elegido, un conjunto de técnicas, herramientas y bienes serán utilizados en la construcción de la prueba de concepto. El arquitecto de negocios ha de tener en cuenta una serie de factores: Cobertura: los requisitos arquitectónicamente significativos deben ser abordados por la prueba de concepto, utilizando como fuente principal las realizaciones de casos de uso definidos. Riesgos: un subconjunto de los riesgos identificados previamente han de conducir el ámbito de aplicación de la prueba de concepto Resultados: el artefacto resultante debe ayudar a los arquitectos empresariales y otros interesados obtener una mejor comprensión del problema y los espacios de solución, y mejorar el proceso de decisión.

6. DEFINIR SISTEMA DE NEGOCIOS DE CONTEXTO Considerando que el modelo de casos de uso muestra el contexto del comportamiento del sistema, aquí se muestra un modelo lógico del sistema en su ambiente, utilizando lo siguiente: Artefacto: Negocios de casos de uso Modelo, Artefacto: Especificación complementaria. El modelo se utiliza para delinear un diagrama de contexto. Un diagrama de contexto muestra la colaboración de alto nivel entre el sistema y sus actores. El I / O entidades que fluyen entre el sistema y sus actores. Las interfaces requeridas por el sistema (que se realizará por los actores que interactúan con el sistema) para la correcta realización. Un Sistema de la operación es un servicio que puede solicitarse a un objeto a un comportamiento efecto

7. Las variables de estado y las tiendas son los atributos definidos en las interfaces realizados por el sistema. Estos son abstractas y requieren que el sistema de mantener la información que corresponda al tipo y la multiplicidad del atributo y permiso de almacenamiento, recuperación y modificación de dicha información Crear inicial Diagrama de Contexto A medida que evolucionan y añadir más detalles al Modelo de casos de uso (el descubrimiento de los agentes de negocios, o si las operaciones de los actores y tal vez ya han sido identificados, la elaboración de su interacción), puede crear la colaboración inicial e ilustrar esto con un diagrama de contexto. Filtrar las asociaciones y las interfaces A continuación, a definir las asociaciones entre los actores empresariales y del sistema, y la interfaz del sistema. Se puede empezar a razonar sobre las operaciones del sistema y el sistema de los atributos que se desprendan

8. Detalle de operaciones de negocios y otras características En este paso, empezar a construir escenarios de negocio de casos de uso (instancias de casos de uso) desde el que se describen las operaciones comerciales del sistema (siempre y es necesario). Los escenarios se puede ilustrar la interacción o diagramas de actividad. Podría ayudar a la comprensión de dividir a la interfaz del sistema en más interfaces específicas y, de hecho, no puede haber requisitos de la interfaz en el Pliego de actividad adicional que impulsan esto.