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

点击翻译按钮获取中文摘要

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].