Towards developing software from a description of the business processes they support

组织构建软件系统来支持业务流程。因此，有理由期望软件模型以一种或另一种形式体现它应该支持的业务流程的模型。将业务建模工件映射到软件工件的想法是一个吸引人的想法，并且在过去三十年左右的时间里以不同的形式得到了追求。MIS的先驱们已经将这种关系形式化，以高级业务功能和粗粒度信息系统块之间的映射的形式（参见[CARL79]）。虽然这种映射对高级系统规划是有用的，但它在信息系统的实际开发中提供的帮助很少。业务流程管理和面向服务的体系结构的最新发展已经在很大程度上弥合了业务分析师可以开发的流程模型与其在软件中的实际实现之间的差距（参见示例[OUYA09]）……前提是各种流程任务已经作为服务实现。如果不是呢？如何首先构建这些服务呢？我们认为，从软件被设计为支持的业务流程的描述中开发软件的分析模型是可能的[MILI07]。这取决于我们处理两个挑战的能力，1)使业务分析人员能够开发详细的流程模型，而不将它们变成“BPMN程序员”，以及2)对早期系统分析决策有足够的理解，以将它们实现为模型转换。我们建议通过向业务分析人员提供流程建模辅助来解决第一个挑战，帮助他们使用通用业务流程模型目录和业务友好型流程定制/专门化操作符来指定详细的组织特定流程[mil09]。我们建议通过构建一个（过程->软件）模型映射帮助来解决第二个挑战，a)编写早期系统分析决策（软件的范围，其目的，以及过程自动化的期望级别），b)为最常见的选择提出软件模式[MILI07]。

Organizations build sofware systems to support business processes. It is thus reasonable to expect that a model of the software would incarnate, in one form or another, a model of the business process it is supposed to support. The idea of mapping business modeling artifacts to software artifacts is an appealing one, and has been pursuded, in different forms, for the past thirty or so years. MIS pioneers have formalized this relationship in the form of a mapping between high-level business functions and coarse-grained information system blocks (see e.g. [CARL79]). While such a mapping was useful for high-level system planning, it provided little help in the actual development of the information system. Recent developments in business process management and service-oriented architectures have considerably bridged the gap between a process model that a business analyst could develop, and its actual realization in software (see e.g. [OUYA09])... provided that the various process tasks are already implemented as services. What if they aren't, and how to build those services, in the first place? We argue that it is possible to develop analysis models of a software from a description of the business processes it is designed to support [MILI07]. This depends on our ability to address two challenges, 1) enable business analysts to develop detailed process models, without turning them into 'BPMN programmers', and 2) understand enough about the early system analysis decisions to implement them as model transformations. We propose to address the first challenge by providing business analysts with process modeling aids that help them specify detailed organization-specific processes using a catalog of generic business process models, and business-friendly process customization/specialization operators [MILI09]. We propose to address the second challenge by, building a (process -> software) model mapping aid that, a) codifies the early systems analysis decisions (scope of software, its purpose, and the desired level of process automation), and b) proposes software patterns for the most common choices [MILI07].