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

组织构建软件系统来支持业务流程。因此，可以合理地预期，软件的模型将以某种形式体现它应该支持的业务流程的模型。将业务建模构件映射到软件构件的想法很有吸引力，在过去三十年左右的时间里，人们一直在以不同的形式追求它。管理信息系统的先驱已经以高级业务功能和粗粒度信息系统块之间的映射的形式将这种关系形式化(参见例如[CARL79])。虽然这种映射对高级别系统规划很有用，但对信息系统的实际开发几乎没有帮助。业务流程管理和面向服务的体系结构的最新发展在很大程度上弥合了业务分析师可以开发的流程模型与其在软件中的实际实现之间的差距(参见例如[OUYA09])……假设各种流程任务已经作为服务实现。如果它们不是，那么如何构建这些服务呢？我们认为，通过对软件所支持的业务流程的描述来开发软件的分析模型是可能的[MILI07]。这取决于我们解决两个挑战的能力，1)使业务分析人员能够开发详细的流程模型，而不会将他们变成“BPMN程序员”；2)对早期系统分析决策有足够的了解，以便将其实现为模型转换。我们建议通过为业务分析人员提供流程建模辅助工具来解决第一个挑战，这些辅助工具可以帮助他们使用通用业务流程模型目录和业务友好的流程定制/专门化操作符来指定特定于组织的详细流程[MILI09]。我们建议通过构建(过程-软件)模型映射辅助工具来解决第二个挑战，该辅助工具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].