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

你走进你最喜欢的杂货店，当你走进门时，你会在一个主要的显示屏上看到你的名字。你走过肉区，一条短信(或平视显示器)会让你注意到一份关于羊排的特别节目，因为众所周知，你的另一半喜欢吃这些东西。你在购物车里放了一个肉类托盘，你就会对西拉葡萄酒竖起两个大拇指。奶酪要配那个吗？你挑选饼干，并得到关于钠含量的警告，因为你有高血压的病史。在购买牙膏时，你会收到4号婴儿纸尿裤的特价通知，因为你已经购买3号纸尿裤超过6个月了。 该场景是Customer Experience Management应用程序运行的一个示例，它依赖于连接的对象、关于客户的知识(事实和推断)以及对购买过程的隐含理解，以便在适当的时候触发与消费者的定制交互，以实现所需的业务结果。现在考虑一个患者监控应用程序，该应用程序依赖于连接到患者或他们的环境的传感器，并且根据对患者和他们的环境的先验知识，1)根据需要通知、操作或反应，2)记录和“消化”数据以改进未来的反应。或者是一种保险应用程序，它依靠传感器来捕捉司机的驾驶事件，以1)通知、行动或反应，以及2)记录和“消化”数据，以完善未来的反应，或许还能提高保费！这些是以下三个应用程序的示例：1)使用普适计算实现上下文感知；2)依赖精心设计的主题配置文件(包括事实数据和领域推断)来组成响应；3)具有学习组件，随时间调整应用程序的响应；以及4)实现新的业务流程以实现高级别的业务结果，例如更多的销售、更快乐的客户、更低的风险等。我将这些称为智能流程应用程序或SPA。 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.