Towards a business-aware framework for the development of smart process applications

你走进你最喜欢的杂货店，当你进门时，你会在一个大的展示上看到你的名字。你走过肉类区，一条短信（或抬头显示器）让你注意到羊排特价，因为你的另一半很喜欢吃羊排。你在购物车里放了一盘肉，然后你就得到了西拉葡萄酒的两个赞。加奶酪吗？你拿起饼干，就会得到关于钠含量的警告，因为你有高血压病史。在买牙膏的时候，你会收到4号婴儿尿布的特价通知，考虑到你已经买了6个多月的3号尿布。”******该场景是运行中的客户体验管理应用程序的一个示例，该应用程序依赖于连接的对象、关于客户的知识（事实和推论）以及对购买过程的隐式理解，以便在适当的时候触发与消费者的自定义交互，以实现期望的业务结果。现在考虑一个患者监测应用程序，该应用程序依赖于附着在患者或其环境上的传感器，并且根据对患者及其环境的先前知识，1)根据需要发出通知、采取行动或作出反应，2)记录和“消化”数据以改进未来的响应。或者一个保险应用程序，它依赖于传感器来捕捉司机的驾驶事件，1)通知、行动或反应，2)记录和“消化”数据，以改进未来的反应，也许还能提高保费！以下是应用程序的三个示例：1)使用泛在计算实现上下文感知；2)依赖复杂的主题概要文件（其中包括事实数据和领域推断）来组成响应；3)有一个学习组件，随时间调整应用程序的响应；4)实现新颖的业务流程以实现高水平的业务结果，例如更多的销售、更满意的客户、更低的风险等。我将把它们称为智能流程应用程序或spa。****** spa提出的问题，从商业模式，到应用工程，到数据隐私和安全，再到法律和道德问题。我专注于应用工程。传统的业务应用程序实现易于理解的流程，例如供应链或财务，而spa实现动态的新流程，这些流程通常辅助或伴随系统范围之外的人工流程。业界解决这个问题的方法是“让我们把传感器放在任何地方，收集数据，看看我们能做些什么”。但是，没有系统的方法来指定spa的需求。我认为，我们必须首先将我们希望通过的进程编成法典，然后才能具体说明安全方案将做什么。因此，我建议为spa开发一种需求方法，该方法依赖于对底层过程的显式编纂。其次，我建议利用这些过程的编码和spa之间的相似性来通过框架开发领域功能。

You walk into your favorite grocery store, and you are greeted by name on a major display as you go through the door. You walk by the meat section, and a text message (or head-up display) brings to your attention a special on lamb chops because your significant other is known to relish those. You put a meat tray in your shopping cart, and you get two thumbs up on Syrah wine. Cheese with that? You pick crackers, and get a warning about sodium content, given a medical history of high blood pressure. While getting toothpaste, you get notified of a special on size 4 baby diapers, considering that you have been buying size 3 diapers for over 6 months".******The scenario is an example of a Customer Experience Management application in action that relies on connected objects, knowledge about the customer (facts and inferences), and an implicit understanding of the purchasing process to trigger custom interactions with the consumer at the opportune time to achieve a desired business outcome. Consider now a patient monitoring application that relies on sensors attached to patients or their environment and that, depending on prior knowledge about the patients and their surroundings, 1) notifies, acts, or reacts, if need be and 2) records and “digests” the data to refine future responses. Or an insurance application that relies on sensors to capture a driver's driving events to 1) notify, act, or react, and 2) record and “digest” the data to refine future responsesand perhaps raise the premium! These are three examples of applications that 1) use ubiquitous computing for context-awareness, 2) rely on elaborate subject profiles, which include factual data and domain inferences, to compose a response, 3) have a learning component that adapts the application's response over time, and 4) that implement novel business processes to achieve a high-level business outcome, e.g. more sales, happier customers, less risk, etc. I will refer to these as smart process applications or SPAs.******SPAs raises issues, from business models, to application engineering, to data privacy and security, to legal and ethical issues. I focus on application engineering. Whereas traditional business applications implement well-understood processes, such as supply chain or finance, SPAs implement dynamic novel processes that often instrument or accompany human processes that are outside the scope of the system. The way industry approaches this is "let us put sensors everywhere, collect the data and see what we can do with it". However, there is no systematic way of specifying requirements for SPAs. I argue that we must first codify the processes that we wish to instrument before we can specify what the SPA will do. Thus, I propose to develop a requirements methodology for SPAs that relies on an explicit codification of the underlying processes. Second, I propose to leverage the codification of such processes and similarities between SPAs to develop the domain functionality through frameworks.