剧本协同创作系统的设计与实现

廖娟平， 冯朝胜， 罗王平， 刘 霞， 蒋红春

(四川师范大学 计算机科学学院， 四川 成都 610101)

剧本协同创作系统的设计与实现

廖娟平， 冯朝胜*， 罗王平， 刘 霞， 蒋红春

(四川师范大学 计算机科学学院， 四川 成都 610101)

针对已有的协同创作模式协同粒度过细、不适合剧本创作的问题，根据剧本创作的特点，提出一种面向剧本的责任制粗粒度协同创作模式.该模式采用代理技术和cookie解决了Web跨域访问问题；利用分层插件式框架解决了系统可扩展难题；通过对通用模块的工具化，提高了系统的易用性.基于所提出的协同创作模式和关键问题的解决方案，设计和实现了一个基于网络协同的剧本创作系统.实际应用表明，该系统能满足剧本协同创作的需要.

协同创作; 计算机辅助协同工作; Web跨域; 插件式系统

Web2.0的到来造就了一种新的创作模式——基于网络的协同创作.该模式允许每一个用户成为作品的创造者，从而极大地提高了工作效率，因此基于网络的协同创作受到广泛关注，成为学术界和产业界研究应用的热点.

文献[1]率先提出了计算机辅助协同工作的概念CSCW(计算机支持协同工作).学术界主要致力于研究协同工作的本质和特征，而产业界则让群件成为CSCW的具体技术实现，并产生了偏向应用的群件系统[2].1995年，沃德·坎宁安发布了第一个Wiki 网站[3]，进一步丰富了群件系统，该网站采用node和link的工作模式创造了百科知识库，开创了网络式协同写作的先河.薛扬等[4]开发的协同写作系统采用多种交流方式解决了用户通信问题，在用户协作方面采用加锁机制保持了数据的一致性，但用户进行写作必须向主编提出加锁和解锁的申请，影响系统的实用性.赵剑颖等[5]为每个任务多个用户在服务器端开辟一个共享空间，传递协作对象的副本并动态构建用户光标位置等协作文档信息，这种协作机制适用于电子白板之类的应用，却由于针对性强，在应用范围上存在局限性.陈岭等[6]通过操作转换算法处理不同用户在同一文档中产生的冲突，解决了数据不一致的问题，但是该算法的运算量偏大，且存在文档格式兼容问题.蔡维纬等[7]提出一种意图保持的算法，提高了操作转换算法的计算效率，但这种算法不支持复杂对象的实时协同.

已有的协同创作模式几乎都是细粒度的，其中的典型代表是维基百科.维基百科以词条为创作的基本单位，词条与词条之间没有联系，一个词条的内容创作可以由多个用户随意修改，但容易导致文本冲突,因此，协同对象的冲突是细粒度的协同创作模式面临的一大难题.然而，剧本是以文档形式为主的文学作品，此类内容联系比较紧密的作品需要主创团队明确的分工，划分的协作对象粒度不宜过细，已有的细粒度协同创作模式并不适用于剧本创作，需要研究并构建适用于剧本创作的协同创作模式.

1 协同创作的难题及对策

实现面向剧本的协同创作系统需要解决好协作机制、跨域访问和工具化3大问题，下面分别进行说明.

1.1 协作机制 网络百科[8]是一个成功的CSCW系统，其互动机制主要包括协作、交流、冲突和共享等4种机制，协作往往是以社群的形式来实现，每一个参与词条创作的用户可以同时编辑一个段落，甚至一个句子，属于一种细粒度协作模式.这种细粒度协作机制采用扁平化和去中心的网络结构，致力于解决内容冲突问题，对粗粒度和联系紧密的内容存在应用限制.P.Hennessy[9]对联系紧密的内容提出一种信息域的共享机制，同一信息域的成员可以自由访问本信息域的资源，不能访问其他信息域的资源；但是这样的共享机制与所有用户都可以访问已完成作品的需求不符.剧本的创作不同于网络百科和基于网络百科编辑系统模式的应用[10]，更不同于超媒体系统[11]，由于涉及到作品内容分配、作品内容整合、作品归属和作品发布等问题，其需要一种新的协作机制来支持这类文学作品的创作；因此，提出一种适用于剧本创作的责任制粗粒度协同创作工作机制.

责任制粗粒度协同创作工作机制适用于多人合作完成一部作品.作品包括创作中和完成后2种工作状态，在作品创作中，以任务分配的方式确定不同内容的创作者，以信息域的方式共享作品；在作品完成后，以发布作品的方式共享作品.

1.2 跨域访问 现在所有的浏览器都使用同源策略[12]，这种策略使得基于B/S模式的不同应用系统集成后，都存在跨域问题.也就是说，运行在各大浏览器的应用系统在默认情况下不能跨域通信.为了打破Web站点之间相互访问的壁垒，已经出现了多种用来实现浏览器跨域通信的技术.

豆瓣、Youtube GData、Digg等一些著名网站采用JSONP协议绕过浏览器同源策略从而实现Web应用程序跨域访问[13]，其动态创建脚本方案的实质属于脚本注入行为，只接受以get方式提交的请求，要求服务器可信.使用URL段标识符交换信息是常见的跨域通信方案[14]，这种方案通过监听URL的变化来接收消息，鉴于URL的长度限制，每次传输的数据大小也受到相应的限制，而且一些浏览器会自动删除段标识符.浏览器端出于安全考虑禁止跨域，但服务器并不禁止跨域，因此，另一种解决跨域问题的思路是使用服务器端代理方案[15].使用服务器端代理实现浏览器跨域访问的主要做法是：所有的跨域访问请求都被提交到本网站所指定的某一个页面上去，由指定的页面完成跨域交互.服务器端代理跨域通信方案能够解决现阶段多数的跨域访问问题，但是增加了本网站服务器的工作，而且无法代用户保存session状态.

虽然服务器端代理方案能解决大部分跨域问题，但它存在2个主要缺陷.为了解决服务器端代理方案的2个主要缺陷，提出一种服务器端代理跨域通信方案.此方案使用缓存技术解决增加服务器代理负担的问题，使用cookie分割技术解决代理服务器无法代用户保存session状态的问题.

1.3 工具化 由Swift文档翻译事件[16]可以看出，互联网各大网站或各大系统有借助用户的力量共同完成一件事情的巨大需求，也就是说，很多平台需要将协同创作系统作为一个方便使用的工具免费提供给用户.工具必须具有独立性、扩展性和可用性.在独立性方面，要考虑协同创作系统如何与其他系统快速融合与分离；在扩展性方面，要考虑如何快速便捷地增加或减少系统的功能；在可用性方面，要考虑如何与其他系统紧密结合在一起共同工作.

若让某个基于B/S模式的应用系统工具化，可将系统部署在独立的服务器上保证系统的独立性；可选择具有高聚合和低耦合特性的分层插件式框架保证系统的扩展性；可通过调用外部系统的函数实现达到稳定对接的运行效果，从而保证系统的可用性.

2 协同创作系统设计

2.1 责任制粗粒度协同创作机制 文学作品协同创作的内容一般是文档形式，在协同工作的过程中需要将作品按一定的粒度分割.剧本负责人将剧本分割成多幕并指定场幕撰写者(剧本有很多种分法，一般来说，话剧剧本称幕、电影剧本称场、电视剧本称集、本文一律称为场幕；在实际开发的应用系统中分法和名称由剧本负责人确定).剧本采用同步模式，同一时间但不同地点进行同一任务的合作方式；场幕采取个人负责模式，场幕之间相互独立又有一定的联系.参与作品创作的用户在协同创作的过程中组成一个信息域.作品负责人在作品完成后，以发布作品的方式让系统中的所有用户看到作品内容.

责任制粗粒度的协同工作机制将用户分为注册用户、作品负责人和作品内容撰写者，用户之间存在泛化关系，即作品内容撰写者可以是作品负责人，而注册用户可以是作品负责人和作品内容撰写者.一部剧本可以有多个负责人，剧本的负责人指定场幕撰写者，并编写场幕要求.场幕一人编写多人讨论，这种粗粒度的任务分配避免了同一文档多人编写所产生的冲突.场幕撰写者在剧本创作的过程中可以形成一个信息域，使用Web实时交流工具和论坛进行通信.作品负责人在作品完成后使用发布作品的形式，让所有的注册用户看到作品.

图 1 协同创作模型示意图

Fig. 1 Model diagram of collaborative creation

2.2 协同创作模型对比 协同创作的内容包含图形图像、音乐、文档等各种形式，以文档为创作内容的协同创作模型大致可分为3种：群体决策模型[17]、维基百科模型[9]和责任制粗粒度模型.通过表1对这3种模式的对比，可知责任制粗粒度模型更加适合有一定联系规律可循的文本创作.

表 1 协同创作模型对比

2.3 代理跨域访问 假设集成协同创作系统的平台为A站，协同创作系统为B站.传统服务器端代理方案有2个主要的缺陷：增加A站服务器负担、在B站中无法保存用户的session状态.针对这2个缺陷，提出一种基于cookie和代理的跨域访问方案.

从代理跨域访问示意图(如图2所示)可知，A站浏览器只能看到服务器A，不关心服务器B是否存在.如果浏览器A请求B站的内容，会将请求发送到GetHtml.ashx文件中，通过这个代理文件在后台产生一个HttpWebRequest实例对象Request2，然后改变Request2的Referer、Accept、CookieContainer等属性值.session是基于cookie产生的，传统服务器端代理方案由于没有对cookie进行处理，B站服务器无法收到request请求中的cookie信息，就无法产生session保存用户的信息.为了在B站服务器产生session，编写MyCookieContainer和MyCookie 类对原Request1中的cookie按一定的规则进行分割、保存和读取，然后将处理后的cookie放入Request2中发送至B站服务器，B站服务器根据Request2中的cookie产生session，从而解决了传统服务器端代理方案的无法保存用户session的缺陷.

图 2 代理跨越访问示意图

Fig. 2 Access diagram of agent cross-domain

基于cookie和代理的跨域访问方案依然会增加A站服务器的负担，但是在方案里增加缓存机制，有效地减轻了A站服务器的负担.浏览器第一次请求B站服务器的html、css和js等静态文件时，缓存机制会把静态文件从B站服务器缓存到A站服务器，接下来的20 min再有同样的请求，浏览器直接从A站服务器读取数据.这个方案的实质是一种浏览器欺骗，在A站和B站之间对浏览器的请求和响应做一些处理形成一个虚拟浏览器，让A站的浏览器认为所有的资源来自A站服务器.

2.4 系统框架结构设计 网络式协同创作系统的创作内容通常是多样化的，可以多人协同创作剧本、翻译作品、创作图片集、创作音频库等，也就是说，网络协同创作系统能够根据用户对创作内容的具体需求进行扩展.插件式系统架构能够将独立开发的程序自由地插入到系统中或从系统中删除，使得扩展功能与框架在保持接口不变的情况下独立变化和发布，是一种非常灵活的组件式系统架构.由于插件式系统架构满足协同创作系统创作内容的多样化、需求的不确定性等要求，因此选用插件式系统架构做协同创作系统的框架最为合适.协同创作系统框架结构设计图如图3所示.

图 3 系统框架结构设计图

2.5 系统数据存储设计 剧本协同创作系统的核心功能围绕着剧本创作展开，因此给出有关剧本创作的几个数据表结构设计的E-R图.由图4可知，本系统的数据库表结构不采用复合型主键，而是让每张表的主键为单一型数值主键，且数值自动增长.这种做法简化了表之间的关系，易于查询，在进行URL跳转时使用数字识别，不存在编码问题.剧本创作的数据基础由4张数据表掌控，它们分别是：作品表、场幕表、场幕内容表和讨论表.每一个作品由多个场幕组成，一个场幕的内容编写有多个版本，一个场幕可组织多场讨论.作品表和场幕表都有创建人和负责人字段，创建人默认拥有负责人的所有权限，创建人还有删除作品和管理作品基本信息等高级权限.场幕表的创建人和负责人由作品创建人或负责人分配，且场幕要求仅由作品创建人或作品负责人编写，这种设计将管理作品与作品具体内容的创作分离，便于创作团队明确分工.场幕进度的控制由系统根据场幕的最小字数要求自动更新变化，而作品进度的控制取决于场幕的进度控制，进度的设计是作品负责人对作品控制管理的一个参考标准，具体完成情况由作品负责人和其他剧幕内容主编共同控制.种类表则用于分类剧本，如：话剧剧本、电影剧本和电视剧本等.

2.6 系统功能结构设计 系统按创作作品、管理作品、浏览作品、讨论作品、下载发布作品5大功能模块指导编程实现，系统实现部分主要是在插件式框架里面写入相应的逻辑.剧本创作存在3类用户：注册用户、作品负责人和作品内容撰写者.如果注册用户创建了一个作品Works1或者被指定负责某部作品Works1，则该注册用户是作品Works1的作品负责人.如果注册用户被指定负责Works1的某个场幕Act1，则该注册用户是剧幕Act1的撰写者.3类用户在系统中有着不同的功能，他们各自拥有的主要功能如图5所示.

图 5 系统用例图

3 协同创作系统实现

基于所提出的协同机制，实现了一个面向剧本的协同创作系统.协同创作系统利用 “影视戏曲特色文化产业公共服务平台”所提供的接口，实现了与平台的无缝对接(该平台为国家科技支撑计划支持的课题，网址：http://www.qunyh.cn).下面从系统外部接口和工作主流程说明.

3.1 系统外部接口 系统运行在“影视戏曲特色文化产业公共服务平台”上，使用了以下3个外部接口.

1) 用户接口.用户接口提供了用户的一些基本信息，如：用户的ID号、用户的名称等.协同系统主要使用了平台用户接口的用户的ID号和名称.

2) 通讯接口.通讯接口用于实现用户之间的即时交流.协同创作某一部作品的用户以好友关系组成内部信息域，并通过web即时通讯软件进行交流.

3) 发布接口.发布接口用于发布用户作品.在线展示作品的内容或者导出作品的内容后，作品负责人可使用发布接口对作品进行发布.发布主要有2种方式：图文发布方式和下载发布方式.图文发布方式是直接在网页上展示作品内容，凡是登录到系统的用户都可以看到作品的内容；下载发布方式，是将导出的作品内容上传到网站上，允许用户获取作品内容到本地计算机上.

3.2 系统工作流程 系统的剧本创作工作流程如图6所示.1) 注册用户A创建一个作品Work1；2) 用户A选择自己的好友用户B担当作品Work1的负责人，如果用户A没有好友，则A运用Web实时交流工具添加好友；3) 作品Work1的创建人A或作品Work1的负责人B在作品中创建场幕，并将场幕分配给好友C和D；4) 场幕撰写者C和D创作场幕的内容，并将已经完成的场幕内容提交至协同创作系统中，作品Work1的进度达到100%后表示作品完成；5) 作品Work1的创建人A和作品Work1的负责人B对作品内容进行导出、存储和发布.

图 6 系统实现主流程图

Fig. 6 The main flow diagram of system realization

4 结束语

网络协同创作避开地域性限制，向人们提供了一种全新的工作方式，但协同创作系统创作内容的多样化导致不同的协作机制.针对已有的协同创作机制不能很好地适用于剧本创作的特点，研究并提出了适合剧本等文学作品共同创作的粗粒度责任制协作机制.除此之外，还使用cookie和代理相结合的方法解决了Web跨域访问问题；利用插件式系统框架解决了系统的工具化问题.基于所提出的协同机制和相关方法，使用软件工程化方法实现了一个面向真实应用场景的协同创作系统.实际使用表明，所开发的协同创作系统能满足剧本创作的主要需要.

[1] GRUDIN J. CSCW:history and focus[J]. Commun ACM,1994,37(1):92-105．

[2] 杜兴,谢立,孙钟秀. 计算机辅助协同工作[J]. 计算机科学,1994,21(1):12-16

[3] 王丹丹. 维基百科自组织模式下的质量控制方式研究[J]. 图书馆理论与实践,2009,39(8):21-24.

[4] 薛扬,张湘辉,王卫,等. 远程协同写作系统的研究与实现[J]. 计算机工程与应用,1998,34(12):44-46.

[5] 赵剑颖,赵正德,王正茂. 实时协同编辑系统共享工作空间的研究[J]. 计算机工程,2001,27(1):41-43.

[6] 陈岭,陈根才,陈挺. 基于Web的实时协同编辑系统[J]. 通信学报,2002,23(2):122-127.

[7] 蔡维纬,何发智,吕晓. 一种高效率的实时协同编辑中的意图保持操作转换算法[J]. 计算机学报,2015,38(10):2041-2053.

[8] 江雨燕. 应用于CSCW协同控制机制的分析与设计[J]. 计算机工程与设计,2007,28(1):162-163.

[9] HENNESSY P. Information domains in CSCW[J]. Studies in Computer Supported Cooperative Work,1991,22(5):299-311.

[10] 赵飞,周涛,张良,等. 维基百科研究综述[J]. 电子科技大学学报(自然科学版),2010,39(3):321-334.

[11] 王智慧,黄宜华,张福炎. www环境下超媒体协同创作系统的设计[J]. 计算机科学,2000,27(2):48-51

[12] 何良,方勇,方昉,等. 浏览器跨域通信安全技术研究[J]. 信息安全与通信保密,2013,35(4):59-61.

[13] 周晓黎. Ajax跨域访问Web Services[J]. 电脑编程技巧与维护,2014,21(8):93-96.

[14] THORPE B D. Secure cross-domain communication in the browser[J]. Architecture J,2007,12(6):14-18.

[15] 孙建华,刘志容,陈浩. Web聚合应用的安全跨域通信机制[J]. 通信学报,2012,33(6):19-29.

[16] 岳芳,顾新建,郭剑锋,等. 概念知识地图协同创作过程中的群体决策模型[J]. 科研管理,2015,36(1):127-134.

(编辑 郑月蓉)

Design and Implementation of Collaborative Writing for Scripts

LIAO Juanping, FENG Chaosheng, LUO Wangping, LIU Xia, JIANG Hongchun

(SchoolofComputerScience,SichuanNormalUniversity,Chengdu610101,Sichuan)

In view of the fine-grained and the unsuitable for writing scripts of the collaborative mode, a new web-based collaborative mode for scripts, which is coarse-grained and accountable, is proposed in this paper. In this mode, we solve the problem of the web’s cross-domain access by the agent technology and cookie. Further, we solve the extensible problem of the system with layered plug-in framework, and improve the convenience of this system by making the general module into a tool. Based on the proposed collaborative mode for scripts, we design and implement a web-based cooperative writing system. Finally, a practical application shows that this system can meet the demand of collaborative writing scripts.

collaborative writing; computer support cooperative work; web cross-domain; plug-in system

2016-07-08

国家自然科学基金(61373163)、国家科技支撑计划课题(2014BAH11F01和014BAH11F02)、可视化计算与虚拟现实四川 省重点实验室课题(PJ2012002)和四川省教育厅自然科学重点基金(15ZB0042)

TP311

A

1001-8395(2017)03-0419-08

10.3969/j.issn.1001-8395.2017.03.024

*通信作者简介：冯朝胜(1971—)，男，教授，主要从事云计算、隐私保护和数据安全的研究,E-mail:csfenggy@126.com