1 项目简介

项目简介：这是一个关于爬取豆瓣热榜250的数据，可以根据具体需求爬取相关电影条目的数据，每一个数据包括”电影详情链接”, “图片链接”, “影片中文名”, “影片外国名”, “评分”, “评价数”, “概况”, “相关信息”等。主要目的是获取数据。该项目的用户主要是想分析电影数据的相关从业人员，可以通过该分析系统查看热榜电影的数据。

这篇文章将对该项目进行软件系统的分析和设计，阐述使用的设计模式、软件架构风格与策略，并采用视图来描述软件系统的模型。

进行数据库和核心数据结构的设计分析，最终形成软件系统概念原型。

2 项目的设计方案

2.1 pipe-filter架构

该架构专门用来处理数据流，属于数据流模式(data-flow architecture)

管道-过滤器模式的体系结构是面向数据流的软件体系结构

它最典型的应用是在编译系统。一个普通的编译系统包括词法分析器,语法分析器,语义分析与中间代码生成器,优化器,目标代码生成器等一系列对源程序进行处理的过程。人们可以将编译系统看作一系列过滤器的连接体,按照管道-过滤器的体系结构进行设计

在管道-过滤器架构模式中，每个构件都有一组输入，输出，构件读取输入的数据流，经过内部处理后，产生输出数据流，该过程主要完成输入流的变换及增量计算。通常，将这里的构件称为过滤器，其中的连接器就像是数据流传输的管道，将一个过滤器的输出传送到另一过滤器的输入。管道，过滤器输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

2.2 设计模式

2.2.1 SOLID设计原则

这五条原则是在罗伯特·马丁的著作《敏捷软件开发：原则、模式与实践》中首次提出的。

SOLID是让软件设计更易于理解、更加灵活和更易于维护的五个原则的简称

1. Single Responsibility Principle - 单一职责原则：修改一个类的原因只能有一个
2. Open/closed Principle - 开闭原则：对于扩展，类应该是“开放”的； 对于修改，类则应是“封闭”的。
3. Liskov Substitution Principle - 里氏替换原则：当你扩展一个类时，记住你应该要能在不修改客户端代码的情况下将子类的对象作为父类对象进行传递
4. Interface Segregation Principle - 接口隔离原则：客户端不应被强迫依赖于其不使用的方法
5. Dependency Inversion Principle - 依赖倒置原则：高层次的类不应该依赖于低层次的类。两者都应该依赖于抽象接口。抽象接口不应依赖于具体实现。具体实现应该依赖于抽象接口。

2.2.2 设计模式概述

设计模式是软件设计中常见问题的典型解决方案。它们就像能根据需求进行调整的预制蓝图，可用于解决代码中反复出现的设计问题。

设计模式与方法或库的使用方式不同，你很难直接在自己的程序中套用某个设计模式。模式并不是一段特定的代码，而是解决特定问题的一般性概念。你可以根据模式来实现符合自己程序实际所需的解决方案。人们常常会混淆模式和算法，因为两者在概念上都是已知特定问题的典型解决方案。但算法总是明确定义达成特定目标所需的一系列步骤，而模式则是对解决方案的更高层次描述。同一模式在两个不同程序中的实现代码可能会不一样。算法更像是菜谱：提供达成目标的明确步骤。而模式更像是蓝图：你可以看到最终的结果和模式的功能，但需要自己确定实现步骤。

设计模式分类

（1）创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。

（2）结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。

（3）行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。

2.2.3 该项目所采用的的设计模式 —— 责任链模式

责任链模式是一种行为设计模式，允许你将请求沿着处理者链进行发送。

收到请求后，每个处理者均可对请求进行处理或将其传递给链上的下个处理者。

而责任链在现实生活中最贴切的例子就是你拨打技术支持电话，如下：

由此可见，责任链模式完美匹配爬虫的业务模型

其UML类图如下

3 数据库设计与核心数据结构

3.1 数据库设计

使用MongoDB作为数据库

3.2 接口设计

# 1. 爬取网页
def getData(baseurl):

# 2. 逐一解析数据  
def parseData(html):

# 3. 保存数据  
def saveData(datalist, savepath):  
  
# 4. 获取数据
def showData(): 

3.3 项目目录结构

4 项目视图——使用4+1视图描述

1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。

该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途：

逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。

开发视图：描述软件在开发环境下的静态组织。

处理视图：描述系统的并发和同步方面的设计。

物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。

4.1 user-case view

4.2 logic view

4.3 development view

4.4 process view

4.5 physical view

5 技术选型概述

from bs4 import BeautifulSoup  # 网页解析，获取数据
import re  # 正则表达式，进行文字匹配
import urllib.request, urllib.error  # 制定URL，获取网页数据
import xlwt  # 进行Excel操作
import mongoD  # 进行数据库操作