前面我们从业务系统的客户谈到服务项目，从服务项目谈到对外服务体系，可以说，这些是"站在离业务系统比较远一点的地方"看到的业务系统比较宏观的外部景象。如果我们再"走近"一点，但仍然保持是"站在业务系统外面"的观察点来仔细观察一个业务系统，那么，我们就会"看到"业务系统的客户是如何享受每一个服务项目的服务的，我们可以描述客户的详细的体验过程，这是发现和评价服务项目的价值最直接的办法。
UML通过事件流描述的办法来记录（设计）客户在服务项目上的交互过程。此时，我们需要把业务系统看成是一个"黑箱"，要想象客户与业务系统的交互过程发生在"黑箱"的某个对外开放的"窗口"上，这个窗口就代表一个服务项目，我们只能看到客户以及业务系统在这个窗口上所发生的全部事件，窗口里面所发生的一切，我们暂时不去细究。
这个"窗口"，实际上就是客户和业务系统进行交互活动的一个"界面"。UML事件流描述的方法从界面交互的细节为切入点，能抓住业务系统为了满足客户的体验需求而必须做出的所有活动，从而为下一步在设计业务系统内部运作过程时提供了目标每一个业务系统内部的活动都必须是以满足界面上必须表现的行为为目标的，而且每一个界面上所发生的业务系统的响应事件，都必需要有内部活动来支持。在"窗口"上所作的事件流记录，集中体现了以下重要的模型价值：
对客户行为和业务系统的行为进行了耦合；
对客户提供了过程清晰，价值明确的服务向导和指南；
对客户的体验进行了直接和真实的记录，以利于和客户沟通，发现问题及时改进；
对客户的需求与业务系统的功能提供了良好的匹配；
通过"近距离"观察客户和业务系统交互的界面，业务建模的焦点从客户逐渐转移到业务系统身上来了，为接下来进入业务系统内部探究找到了可以跟踪返回的入口。
对业务系统的边界（即对外功能范围）提供了详尽的描述；
对业务系统的服务项目的服务功能和性能提供了测试的详细依据。
如何来描述一个服务项目的事件流呢？
事件流的描述，实际上就是对观察到的现实的或者设计想象的虚拟的客户体验过程进行详细的文字录像。把客户在什么样的背景条件下，启动业务系统的某个服务项目，向业务系统提出怎样的服务请求，业务系统又如何回应，要了解客户的哪些信息，要客户做出什么配合行动，要为客户做出什么行动，要交付客户什么物品，要在多长时间内完成等等，按先后顺序和逻辑过程详细地用文字一句一句地记录下来。
相信大多数读者有到食堂吃饭的经历，下面，我们就以食堂的客户的身份，来考察一下"食堂"这个业务系统的"卖饭"这个服务项目，看看它的事件流表达是怎样的。