1.文章概述
本文从软件架构的角度结合工程实践项目——金融文本挖掘进行分析，通过一组关键视图在不同视角和抽象层次来描述项目的架构模型，本文主要在分解视图、依赖视图、泛化视图、执行视图、实现视图、部署视图和工作任务分配视图来进行分析。
首先介绍一下此次的工程实践项目，通过抓取历史新闻数据，提取知识去构建知识图谱，并抓取当下的微博，基于构件好的知识图谱对新发生的事件去推理此事件可能产生的结果及影响，也提供历史的类似事件以供用户加以自己判断。每隔一段时间将近一段时间的新闻提取知识合并到知识图谱中。
2.设计方案
若要软件能够长期有效的工作，在设计之初就要考虑周全，以应对不断变化的环境，不断增加的需求等改变，选择合适的设计风格和设计模式就尤为重要。
设计模式：从不同的角度对设计模式分类的话，所得的分类结果也不相同。1.根据模式是主要用于类上还是主要用于对象上来划分的话，可分为类模式和对象模式两种类型的设计模式。2.根据设计模式可以完成的任务类型来划分的话，可以分为创建型模式、结构型模式和行为型模式 3 种类型的设计模式。常用的设计方案也很多，例如单例（Singleton）模式、原型（Prototype）模式、建造者（Builder）模式、享元（Flyweight）模式、策略（Strategy）模式、命令（Command）模式、模板方法（TemplateMethod）模式等等，虽然设计模式很多，但是都要遵循以下原则，即开闭原则（OCP）、Liskov替换原则（LSP）、依赖倒置原则（DDIP）、单一职责原则（SRP）、迪米特法则（LoD） 、合成复用原则（CRP）。
软件架构：常见的软件架构三层架构 、MVC架构、 MVVM架构等，可以说是几种设计模式的组合，也可以说是在几种设计模式的基础上发展。软件架构的设计要考虑满足数量众多的各种系统功能需求， 也需要完成诸如系统的易用性、系统的可维护性等非功能性的设计目标， 还要遵从各种行业标准和政策法规。 不过并不是每一个项目我们都需要从头开始进行完全创新性的设计，更多的是通过研究借鉴优秀的设计方案，来逐步改进我们的设计。软件架构模型是通过一组关键视图来描述的，同一个软件架构，由于选取的视角不同（Perspective）可以得到不同的视图，这样一组关键视图搭配起来可以完整地描述一个逻辑自洽的软件架构模型。一般来说，我们常用的几种视图有分解视图、依赖视图、泛化视图、执行视图、实现视图、部署视图和工作任务分配视图。
架构风格：主要包括管道-过滤器 、客户-服务 、P2P、发布-订阅 、CRUD 、层次化。
2.1设计模式
本系统采用中介者模式，所谓中介者模式即定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。在现实生活中，常常会出现好多对象之间存在复杂的交互关系，这种交互关系常常是“网状结构”，它要求每个对象都必须知道它需要交互的对象。如果把这种“网状结构”改为“星形结构”的话，将大大降低它们之间的“耦合性”，这时只要找一个“中介者”就可以了。在软件的开发过程中，这样的例子也很多，例如，在 MVC 框架中，控制器（C）就是模型（M）和视图（V）的中介者，采用“中介者模式”大大降低了对象之间的耦合性，提高系统的灵活性。
在本系统中，用户仅和contoler产生交互关系，所取数据均由contoler来完成。同时HistorySpider仅将爬取的数据存入mysql数据库，由Entity_extraction来进行实体抽取，关系抽取，实体链接等，并将产生的三元组存入neo4j，RealTimeSpider同样仅联系Entity_extraction，将数据给予Entity_extraction提取知识，存入MySQL，并隔一段时由Entity_extraction进行知识图谱的更新。
以下给出大致的UML图：
2.2架构风格
本系统采用客户-服务的设计风格，客户-服务模式的架构风格是指客户代码通过请求和应答的方式访问或者调用服务代码。这里的请求和应答可以是函数调用和返回值，也可以是TCP Socket中的send和recv，还可以是HTTP协议中的GET请求和响应。 在客户-服务模式中，客户是主动的，服务是被动的。客户知道它向哪个服务发出请求，而服务却不知道它正在为哪个客户提供服务，甚至不知道正在为多少客户提供服务。 客户-服务模式的架构风格具有典型的模块化特征，降低了系统中客户和服务构件之间耦合度，提高了服务构件的可重用性。
在本系统中，user调用Controler的函数，以获取返回值。同时，Spider调用Entity_extraction的函数，处理抓取的数据并将知识存入MySQL。
如图所示：
3.项目视图
3.1分解视图
分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模型的关键视图，一般分解视图呈现为较为明晰的分解结构（breakdown structure）特点。分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。前述分解方法中已经明确呈现出了分解视图的特征。
3.2依赖视图
依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关系。 依赖视图在项目计划中有比较典型的应用。比如它能帮助我们找到没有依赖关系的软件模块或子系统，以便独立开发和测试，同时进一步根据依赖关系确定开发和测试软件模块的先后次序。 依赖视图在项目的变更和维护中也很有价值。比如它能有效帮助我们理清一个软件模块的变更对其他软件模块带来影响范围。
本系统基本是模块的调用的依赖和数据依赖，如图所示：
3.3泛化视图
泛化视图展现了软件模块之间的一般化或具体化的关系，典型的例子就是面向对象分析和设计方法中类之间的继承关系。值得注意的是，采用对象组合替代继承关系，并不会改变类之间的泛化特征。因此泛化是指软件模块之间的一般化或具体化的关系，不能局限于继承概念的应用。 泛化视图有助于描述软件的抽象层次，从而便于软件的扩展和维护。比如通过对象组合或继承很容易形成新的软件模块与原有的软件架构兼容。
3.3执行视图
执行视图展示了系统运行时的时序结构特点，比如流程图、时序图等。执行视图中的每一个执行实体，一般称为组件（Component），都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把它们合并成一个。 执行实体可以最终分解到软件的基本元素和软件的基本结构，因而与软件代码具有比较直接的映射关系。在设计与实现过程中，我们一般将执行视图转换为伪代码之后，再进一步转换为实现代码。
3.4实现视图
实现视图是描述软件架构与源文件之间的映射关系。比如软件架构的静态结构以包图或设计类图的方式来描述，但是这些包和类都是在哪些目录的哪些源文件中具体实现的呢？一般我们通过目录和源文件的命名来对应软件架构中的包、类等静态结构单元，这样典型的实现视图就可以由软件项目的源文件目录树来呈现。
本项目目录如下：
3.5部署视图
部署视图是将执行实体和计算机资源建立映射关系。这里的执行实体的粒度要与所部署的计算机资源相匹配，比如以进程作为执行实体那么对应的计算机资源就是主机，这时应该描述进程对应主机所组成的网络拓扑结构，这样可以清晰地呈现进程间的网络通信和部署环境的网络结构特点。
3.6工作任务分配视图
工作分配视图将系统分解成可独立完成的工作任务，以便分配给各项目团队和成员。工作分配视图有利于跟踪不同项目团队和成员的工作任务的进度，也有利于在个项目团队和成员之间合理地分配和调整项目资源，甚至在项目计划阶段工作分配视图对于进度规划、项目评估和经费预算都能起到有益的作用。
4.数据库设计
新闻数据：
三元组：
neo4j：
5. 软件系统运行环境和技术选型
语言：在针对本项目的项目性质，主要有java和python两种选择，但是在测试对比后发现python在进行实体抽取等工作时准确率更高，且编写爬虫时更加高效，语言更加简洁，因此本项目选择python作为主要的开发语言。
数据库：历史新闻抓取以后，将新闻数据存入MySQL。将提取的三元组存入neo4j数据库以构建知识图谱。
支持库：LTP进行分词，词性标注，及句法依赖以便进一步进行知识抽取。Scrapy框架来搭建历史的分布式爬虫加快历史信息的抓取。
6.概念模型的核心工作机制
每个视图都是从不同的角度对软件架构进行描述和建模，比如从功能的角度、从代码结构的角度、从运行时结构的角度、从目录文件的角度，或者从项目团队组织结构的角度。 软件架构代表了软件系统的整体设计结构，它应该是所有这些视图的集合。但我们不会将不同角度的这些视图整合起来，因为不便于阅读和更新。不过我们会有意识地将不同角度的视图之间的映射关系和重叠部分了然于胸，从而深刻理解软件架构内在的一致性和完整性，这就是系统概念原型。
基于以上各视图，我们就可以总结出此项目的概念原型，以下总结本系统的工作流程：
本系统需要首先构建知识图谱，故需要历史爬虫抓取历史信息经过知识抽取后构建知识图谱。用户可以查看最近的新闻事件，进而查看系统基于知识推理做出的事件影响预测，也可以输入事件，查看历史相似事件来进行自我判断。
7.总结
本文主要在分解视图、依赖视图、泛化视图、执行视图、实现视图、部署视图和工作任务分配视图来对基于知识图谱的数据挖掘系统进行分析。通过本文增加了对设计模式，架构风格以及软件整体架构方面知识的理解，但是在一些方面仍然认识不足，文章不足之处欢迎指正。
