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

组织构建软件系统来支持业务流程。因此，可以合理地预期软件模型将以一种或另一种形式体现它应该支持的业务流程模型。将业务建模工件映射到软件工件的想法是一个很有吸引力的想法，并且在过去三十年左右的时间里一直以不同的形式得到追求。 MIS 先驱以高级业务功能和粗粒度信息系统块之间映射的形式正式化了这种关系（参见[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].