精华内容
下载资源
问答
  • 2018-02-07 17:53:47

    一、概述

      多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。

    二、星型模式(star schema)

      星型模式的核心是一个大的中心表(事实表),一组小的附属表(维表)。星型模式示例如下所示:

     

    三、雪花模式(snowflake schema)

      雪花模式是星型模式的扩展,其中某些维表被规范化,进一步分解到附加表(维表)中。雪花模式示例如下图所示:

    从图中我们可以看到地址表被进一步细分出了城市(city)维。supplier_type表被进一步细分出来supplier维。

    四、事实星座模式(Fact Constellation)或星系模式(galaxy schema)

      数据仓库由多个主题构成,包含多个事实表,而维表是公共的,可以共享,这种模式可以看做星型模式的汇集,因而称作星系模式或者事实星座模式。本模式示例如下图所示:

    如上图所示,事实星座模式包含两个事实表:sales和shipping,二者共享维表。

    五、总结

      事实星座模式是数据仓库最长使用的数据模式,尤其是企业级数据仓库(EDW)。这也是数据仓库区别于数据集市的一个典型的特征,从根本上而言,数据仓库数据模型的模式更多是为了避免冗余和数据复用,套用现成的模式,是设计数据仓库最合理的选择。当然大数据技术体系下,数据仓库数据模型的设计,还是一个盲点,探索中。

      最近在做大数据技术体系下的数据仓库模型设计,重温数据传统数据仓库的关键技术和数据模型,有感兴趣的可以一起讨论,共同学习。QQ群: 347018601

      

    更多相关内容
  • 海豚雕塑3D模型设计

    2020-01-01 15:04:19
    海豚雕塑3D模型设计适用于展示模型设计
  • 数据仓库多维数据模型设计

    万次阅读 多人点赞 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...

    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。


    数据仓库建模方法

    大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。

    数据仓库的建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。

    目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。

    我们下面给大家详细介绍一下这些建模方法。


    范式建模法(Third Normal Form,3NF)

    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。
    目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。
    在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :
    每个属性值唯一,不具有多义性 ;
    每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;
    每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
    由于范式是基于整个关系型数据库的理论基础之上发展而来的,因此,本人在这里不多做介绍,有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
    根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。

    从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。
    这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
    数据仓库的域模型应该包含企业数据模型的域模型之间的关系,以及各主题域定义。
    数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
    在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类,以及实体的关系等。
    以笔者的观点来看,Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。
    但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。


    维度建模法

    维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。

    事实表是用来记录具体事件的,包含了每个事件的具体要素,以及具体发生的事情;维表则是对事实表中事件的要素的描述信息。

    比如一个事件会包含时间、地点、人物、事件,事实表记录了整个事件的信息,但对时间、地点和人物等要素只记录了一些关键标记,比如事件的主角叫“Michael”,那么Michael到底“长什么样”,就需要到相应的维表里面去查询“Michael”的具体描述信息了。

    基于事实表和维表就可以构建出多种多维模型,包括星形模型、雪花模型和星座模型。

    维度建模法最被人广泛知晓的名字就是星型模式(Star-schema)。

    [1345621614_4017.JPG]

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。
    通过这些预处理,能够极大的提升数据仓库的处理能力。
    特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。
    不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
    但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。
    而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。
    而在这些与处理过程中,往往会导致大量的数据冗余。
    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
    因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。
    维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。


    实体建模法

    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。
    从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。
    那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。
    即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明。
    例如我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:
    实体,主要指领域模型中特定的概念主体,指发生业务关系的对象。
    事件,主要指概念主体之间完成一次业务流程的过程,特指特定的业务过程。
    说明,主要是针对实体和事件的特殊说明。
    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。


    维度建模法数据模型的区别

    多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。


    星型模式(star schema)

    星型模式的核心是一个大的中心表(事实表),一组小的附属表(维表)。星型模式示例如下所示:

    [903014-20160324180338683-1916113766.jpg]

    [200916184066377.jpg]

    可以看出,星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:

    a. 维表只和事实表关联,维表之间没有关联;

    b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;

    c. 以事实表为核心,维表围绕核心呈星形分布;


    雪花模式(snowflake schema)

    雪花模式是星型模式的扩展,其中某些维表被规范化,进一步分解到附加表(维表)中。雪花模式示例如下图所示:

    [903014-20160324180236104-1134926519.jpg]

    [200918380319666.jpg]

    从图中我们可以看到地址表被进一步细分出了城市(city)维。supplier_type表被进一步细分出来supplier维。

    星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重。


    事实星座模式(Fact Constellation)或星系模式(galaxy schema)

    数据仓库由多个主题构成,包含多个事实表,而维表是公共的,可以共享,这种模式可以看做星型模式的汇集,因而称作星系模式或者事实星座模式。本模式示例如下图所示:

    [903014-20160324175828948-2089267269.jpg]

    [200924338912918.jpg]

    如上图所示,事实星座模式包含两个事实表:sales和shipping,二者共享维表。

    事实星座模式是数据仓库最常使用的数据模式,尤其是企业级数据仓库(EDW)。

    前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

    这也是数据仓库区别于数据集市的一个典型的特征,从根本上而言,数据仓库数据模型的模式更多是为了避免冗余和数据复用,套用现成的模式,是设计数据仓库最合理的选择。


    三种模式对比

    归纳一下,星形模式/雪花模式/星座模式的关系如下图所示:

    [903014-20160324103125073-1838397443.jpg]


    实例

    在进行维度建模前,首先要了解用户需求。而笔者在数据库系列的第一篇就讲过,ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后,得到以下ER图:
    [903014-20160324160704776-1647702727.png]

    随后可利用建模工具将ER图直接映射到关系图:
    [903014-20160324160724151-2139740081.png]

    需求搜集完毕后,便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式,维度建模的关键在于明确下面四个问题:

    1.哪些维度对主题分析有用?

    本例中,根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的;

    2.如何使用现有数据生成维表?

    a. 维度PRODUCT可由关系PRODUCT,关系VENDOR,关系CATEGORY连接得到;

    b. 维度CUSTOMER和关系CUSTOMER相同;

    c. 维度STORE可由关系STROE和关系REGION连接得到;

    d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到;

    3.用什么指标来”度量”主题?

    本例的主题是销售,而销量和销售额这两个指标最能直观反映销售情况;

    4.如何使用现有数据生成事实表?

    销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到;

    明确这四个问题后,便能轻松完成维度建模:

    [903014-20160324160936308-1545323262.png]

    细心的读者会发现三个问题:1. 维表不满足规范化设计(不满足3NF);2. 事实表也不满足规范化设计(1NF都不满足); 3. 维度建模中各维度的主码由***ID变成***Key;

    对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。

    因此虽然可以以雪花模型进行维度建模,如下所示:

    [903014-20160324162335339-887948324.png]

    但这样会加大查询人员负担:每次查询都涉及到太多表了。因此在实际应用中,雪花模型仅是一种理论上的模型。星座模型则出现在”维度建模数据仓库”中,本文后面将会讲到。

    对于第三个问题,***Key这样的字段被称为代理码(surrogate key),它是一个通过自动分配整数生成的主码,没有任何其他意义。使用它主要是为了能够处理”缓慢变化的维度”。


    经典星座模型

    前文已经讲过,有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用:共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析:

    1. 共享维度

    以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:

    [903014-20160324163010683-2065536046.png]

    1. 细节/聚集事实表

    细节事实表(detailed fact tables)中每条记录表示单一事实,而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看,细节事实表通常有设置TID属性,而聚集事实表则无。

    两种事实表各有优缺点,细节事实表查询灵活但是响应速度相对慢,而聚集事实表虽然提高了查询速度,但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中,聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表:

    [903014-20160324163348964-833179105.png]

    展开全文
  • 工厂整体规划模型

    2019-12-27 05:41:04
    工厂整体规划模型适用于鸟瞰规划展示模型设计
  • 详细设计说明

    万次阅读 多人点赞 2019-06-22 23:08:06
    本详细设计说明书是针对电子科大校园地图(UESTC Campus Map)小程序的项目编写。目的是对该项目进行详细设计,在概要设计的基础上进一步明确系统结构,详细地介绍系统的各个模块,为进行后面的实现和测试做准备。...

    F.1 引言

    F.1.1  编写目的

          本详细设计说明书是针对电子科大校园地图(UESTC Campus Map)小程序的项目编写。目的是对该项目进行详细设计,在概要设计的基础上进一步明确系统结构,详细地介绍系统的各个模块,为进行后面的实现和测试做准备。本详细设计说明书的预期读者为本项目小组的成员以及对该小程序感兴趣,在以后想对系统进行拓展和维护的人员。

    F.1.2  背景

    说明:

    a、待开发软件系统的名称:电子科大校园地图小程序(UESTC Campus Map)

    b、本项目的任务提出者:金成哲,陆冠臣,罗子建

               本项目的开发者:金成哲,陆冠臣,罗子建

               本项目的用户:在校学生,教师,校园游客

               本项目的计算中心:微信小程序

    F.1.3  定义

    (1) MVC Model View Controller ,是模型 ( model )-视图 ( view )-控

    制器(Controller)的缩写。

    (2) CURD 代表创建( Create )、更新 Update )、读取 Retrieve

    和删除( Delete )操作。

      (3)    UCM 是 UESTC Campus Map 的简称。

     

     

    F.1.4  参考资料

    (1)《软件工程》(第三版)·钱乐秋等编著·清华大学出版社

    (2)《设计模式之禅》)《设计模式之禅》(第二版)·秦小波著·机械工业出版社(第二版)·秦小波著·机械工业出版社

    (3)《玩转DjangoDjango 2.0》·黄永祥著·清华大学出版社》·黄永祥著·清华大学出版社

    (4)《数据库要求说明书》

    (5)《数据库设计说明书》

    (6)微信小程序开发文档

    F.2 程序系统的结构

    整体架构:整体架构设计演示如下:

                                           

     

    名称

    标识符

    说明

    客户端

    Client

    客户系统提供本地服务

    服务端

    Server

    向客户端提供资源,保存客户端数据

    数据库系统

    Database

    存储客户端资源及相关信息

    本地操作系统

    Local operating system

    客户端提供交互界面的服务

    电子科技大学统一身份认证系统

    Authentication system

    电子科技大学学生认证系统,提供学生认证平台

    微信服务器

    Wechat  server

    提供UCM的应用生态服务

    微信小程序后台管理系统

    Miniprogram admin system

    小程序开发者管理小程序的版本更新及用户数据分析

     

    客户端:采用 MVC 软件架构设计,框图演示如下

     

                   

     

    模型(即数据表):

    名称

    标记符

    说明

    标记点表

    Location

    记录校园地图的地点描述以及具体地理位置

    功能表

    Function

    记录标记点的功能信息以及标签分类

    轮播图表

    RollingImage

    记录某标记点的轮播图片

    讨论表

    Discussion

    记录用户发布讨论的内容信息

    评论表

    Comment

    记录用户参与评论的信息

    用户表

    User

    记录用户登录账户以及学生认证等基本信息

     

    控制:

    名称

    标记符

    说明

    网络请求

    Internet request

    提供连接服务,响应界面

    存储处理

    Storage Processing

    根据存储请求,将相关数据存储到对应数据表

    数据清洗

    Data cleaning

    根据内置算法设计,对数据表的数据进行再处理

     

    视图:

    名称

    标记符

    说明

    地图界面

    Map

    根据不同校区的需要,提供地图的功能介绍

    讨论界面

    Discussion

    给用户提供论坛讨论的服务,针对不同标记点发布讨论内容

    功能界面

    Function

    给对应标记点提供不同的功能介绍

    认证界面

    Authentication

    为区分不同用户,利用电子科大校园信息门户的平台,本小程序设计了一个校园身份认证的系统

    历史关注界面

    Historical Concerning

    为方便用户查看以前参与的讨论与功能的建设,故提供历史关注的服务

    轮播图界面

    Rolling Image

    为丰富用户对该标记点的认知与理解,提供对该标记点的轮播图展示服务

    登录界面

    login

    用户首次登录小程序

    服务端:

                                         

     

    名称

    标记符

    说明

    日志系统

    Logging System

    自动记录流式数据,各进程,异常信息

    网络模块

    Network module

    提供连接服务

    控制模块

    Controling module

    根据服务请求,进行不同模块的控制

    数据库操作模块

    Database operation module

    写入,查询,修改或删除数据库的信息

    F.3 网络模块

    F.3.1  程序描述

    网络模块主要是客户端对服务器的网络请求功能的模块化实现,整个客户端采用规范化的统一格式对服务器进行网络请求。主要是为了更好的鲁棒性以及可读性。

    F.3.2  功能

    功能范例:

     

    功能

    输入

    输出

    格式/请求

    校园身份认证

    openid、学号、密码

    codemsg

    identity

    json/POST

    微信登录

    code

    encryptedData

    iv

    code、msg、uid

    uNickName、uavaUrl:

    json/POST

    发布功能

    uid

    functionCode

    locationID

    code

    msg

    uid

    identity

    datatype

    data:[

    {functionID

    functioncontent

    functiondescription

    locationID

    locationdescription

    locationLatitude  

    locationLongitude}]

    json/POST

    发布讨论

    uid

    discussionCode

    locationID

    code

    msg

    uid

    identity

    datatype

    data:[

    discussionID  

    presenttime

    locationID

    locationLatitude

    locationLongitude

    ]

    json/POST

    评论他人

    uid

    uidor

    discussionID

    commentCode

    locationID

    code

    msg

    datatype

    commentID

    json/POST

    获取发布历史

    identity

    uid

    dataType

    code

    msg

    uid

    identity:

    dataType

    data:[

    discussionID

    discussionContent:                

    locationID

    locationLatitude

    locationLongitude

    imgUrls:[

    "https:********",          

    ]    

    ]    

    json/POST

    获取讨论列表

    locationID

    uid

    code

    msg

    dataType

    data:[

    {

    discussionID

    discussionCode

    discussioncontent:

    uNickName

    uavaUrl

    imgUrls:[]

    presenttime

    locationID

    locationLatitude

    locationLongitude

    comment:[

    {commentID

    commentcontent

    uNickName

    uorNickName}]}]

    json/POST

    获取功能列表

    uid

    locationID

    dataType

    code

    msg

    data:[{

    functionID:

    functionCode

    functioncontent

    functiondesription:

    locationID

    locationLatitud

    locationLongitude:

    }]

    json/POST

    获取轮播图

    uid

    string

    dataType

    code

    msg

    imgUrls:[

    "https://123.png",

    "https://124.png",]

    json/POST

    获取所有标记点

    uid

    dataType:

    code

    msg

    locationID:[]

    json/POST

    删除

    dataType

    uid

    dataType

    uid

    code

    msg:

    json/POST

    F.3.3  性能

    运行

    模块组合

    响应时间(ms)

    校园身份认证

    网络模块、数据库模块

    1000

    微信登录

    登录模块、数据库模块、网络模块

    500

    发布功能

    功能模块、数据库模块、网络模块

    200

     

    发布讨论

    数据库模块、讨论模块

    1000

    评论他人

    数据库模块、讨论模块、评论模块、网络模块

    200

     

    获取发布历史

    数据库模块、讨论模块、评论模块、功能模块、网络模块

    1000

    获取讨论列表

    数据库模块、讨论模块、评论模块、网络模块

    1000

     

    获取功能列表

    功能模块、网络模块、数据库模块

    300

    获取轮播图

    轮播图模块、数据库模块、网络模块

    1000+

    获取所有标记点

    数据库模块、网络模块、标记点模块

    200

    删除

    所有模块

    100

     

    添加标记点

    数据库模块、网络模块、标记点模块

    200

     

    F.3.4  输入项

    输入输出等参考功能F.3.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.3.5  输出项

    输入输出等参考功能F.3.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.3.6  算法

    1. API接口防止重放攻击和第三方滥用攻击算法:

    算法示例:

    字段名

    类型

    含义

    必填

    备注

    a

    text

    请求的字段

    True

     

    b

    text

    请求字段

    True

     

    appKey

    text

    客户端应用标识

    True

    一段唯一标识客户端的字符串

    salt

    text

    随机数(建议使用UUID)

    True

     

    timestamp

    long

    Unix时间戳(精确到秒)

    True

     

    sign

    text

    sha256签名

    True

    计算方法:sha256(a+b+appKey+salt+timestamp+密钥)

    例如:

    a:"123",

    b:"地图",

    appKey:"57673e9f4b774dd9a739ee668e38c0a1",

    salt:"66785bb6-2df8-5e7e-a51b-cb7d257738e5",

    timestamp:"1560761282",

    密钥:"651d-4bbf-350f-b477-fe1b",

    客户端利用sha256计算签名:

    sha256(123地图57673e9f4b774dd9a739ee668e38c0a166785bb6-2df8-5e7e-a51b-cb7d257738e51560761282651d-4bbf-350f-b477-fe1b)

    结果:423cb7cf98d7e11c4efa3ce042e4e4546ae342a565a460fd8443f814258d63b3

     

    服务器流程说明:

    服务器接收到数据后,首先验证appKey是否合法,然后从数据库中获取该appKey对应的密钥,然后再获取当前服务器的时间戳,计算t = 服务器时间戳-timestamp,若t>60,则是一条重放消息,若小于60,则开始验证签名,即服务器利用相同的算法计算请求的sha256,对比是否相同,若相同,则做下一步操作,否则这是一条非法请求,直接响应错误信息。

    F.3.7  流程逻辑

                                  

    F.3.8  接口
    用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一模块、参数赋值和调用方式,说明与本程序具有直接关系之数据结构(数据库、数据文卷)。

    F.3.9  存储分配

        无特别要求

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    服务器

    内存:50-100MB,

    硬盘:50GB

    适当情况下可以扩容,采用分布式集群的方式运行服务端

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

     

    F.3.10  注释设计

    1.单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.3.11  限制条件

    必须在连接互联网的情况下才能使用本模块,否则将提示网络异常信息。

    F.3.12  测试计划

    需要结合其它模块才能测试,此处不做说明。

    F.3.13  尚未解决的问题

    接口字段的模糊混淆处理,所以还是存在非法用户进行恶意发送脏请求的可能。

     

    F.4 日志模块

    F.4.1  程序描述

    小程序日志系统

    F.4.2  功能

    提供日志记录功能,为系统错误和恢复提供保障。

    F.4.3  性能

    日志信息分类

    (1)等级由低到高:debug<info<warn<Error<Fatal;

    (2)区别:

    debug :级别最低,可以随意的使用于任何觉得有利于在调试时更详细的了解系统运行状态的东东;

    info : 重要,输出信息:用来反馈系统的当前状态给最终用户的;

    warn:可修复,系统可继续运行下去;

    Error: 可修复性,但无法确定系统会正常的工作下去;

    Fatal: 相当严重,可以肯定这种错误已经无法修复,并且如果系统继续运行下去的话后果严重。

    F.4.4  输入项

         日志输入针对不同的日志类别有所区别。

    F.3.5  输出项

    1. 日志文档
    2. 文档格式

    log.error(“[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do].”);

    log.error(String.format(“[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do].”, params));

    log.error(“[Some Error Msg] happens to 错误参数或内容 when [in some condition]. [Probably Because]. [Probably need to do].”);

    log.error(String.format(“[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do].”, parameters));

    [Probably Reason]. [Probably need to do]. 在某些情况下可以省略; 在一些重要接口和场景下最好能说明一下。

    每一条错误日志都是独立的,尽可能完整、具体、直接说明何种场景下发生了什么错误,由什么原因导致,要采用什么措施或步骤。

    F.3.6  算法

    日志分析方法:

    1.特征字符分析(Signature-based)

         在日志中查找已知的漏洞特征,去发现黑客攻击行为, 是最简单的方法。

    2.访问频率分析(Frequency analysis)

    在黑客攻击过程中,需要对系统进行各种特定的访问,这些访问与正常用户访问有很大差别, 每种攻击行为都有不同的特征。

    通过对大量用户访问数据的挖掘,可以发现这些异常访问行为。

     

    日志检测方法:

    1.漏洞扫描检测:

    黑客使用漏洞扫描器对 Web 应用进行扫描,可以用匹配 User-Agent 特征的方式进行检测。如果自定义扫描器的 User-Agent,这个方法的效果可能会不好。但可匹配扫描器扫描的行为,

    ·访问目标离散

    ·来源地址相对固定

    ·访问结果大多数失败

    根据这些特征对 Web 访问日志进行分析,即可提取出来可疑的扫描行为。

    2.暴力破解检测:

    暴力破解密码的特征是:

    ·相对固定的来源地址

    ·对登录URL短时间内高频率发起请求

    ·与漏洞扫描的区别主要是目标 URL 固定。

    3.webshell 检测

    如果黑客发现系统漏洞,并且利用漏洞获得上传权限,会向系统 上传 webshell。webshell 是一种后门程序,此程序由脚本语言编写, 可以在 Web 服务器上运行,攻击者可以通过网页执行系统命令,读写 系统文件。从访问行为的角度看,webshell 通常:

    ·只有攻击者访问

    ·来源地址相对固定

    ·访问时间相对集中

    ·无内嵌其他页面

    通过这些特征即可提取出可疑文件,再通过人工确认的方式,检测出 webshell。

    F.3.7  流程逻辑

    日志产出 ——>采集——>储存——>分析——>储存——>可视化

    F.3.8  接口

    结构设计:

                                          

     

     

    日志工作流:

                                           

    F.3.9  存储分配

    文件

    存储

    备注

    log

    2GB

    每天24:00进行当天日志归档

    F.3.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.3.11  限制条件

    无特别要求

    F.3.12  测试计划

       结合其它模块进行测试

    F.3.13  尚未解决的问题

       日志自动化分析工具的集成

     

    F.5    数据库操作模块

    F.5.1  程序描述

       数据库操作的封装模块

    F.5.2  功能

       对数据库的增删查改进行功能封装,提供统一的接口

    F.5.3  性能

    功能操作

    模块组合

    资源占用时间(ms)

    校园身份认证

    网络模块、数据库模块

     

    20

    微信登录

    登录模块、数据库模块、网络模块

     

    20

    发布功能

    功能模块、数据库模块、网络模块

     

    20

    发布讨论

    数据库模块、讨论模块

     

    100

    评论他人

    数据库模块、讨论模块、评论模块、网络模块

     

    20

    获取发布历史

    数据库模块、讨论模块、评论模块、功能模块、网络模块

     

    100

    获取讨论列表

    数据库模块、讨论模块、评论模块、网络模块

     

    100

    获取功能列表

    功能模块、网络模块、数据库模块

     

    50

    获取轮播图

    轮播图模块、数据库模块、网络模块

     

    20

    获取所有标记点

    数据库模块、网络模块、标记点模块

     

    20

    删除

    所有模块

     

    50

    添加标记点

    数据库模块、网络模块、标记点模块

     

    20

     

    F.5.4  输入项

    F.5.5  输出项

    操作反馈

    F.5.6  算法

    多表查询算法:

    一、交叉连接

      交叉连接即笛卡儿乘积,是指两个关系中所有元组的任意组合。一般情况下,交叉查询是没有实际意义的。

    例如:如果希望得到学生表和选课表两个关系模式的乘积,查询语句为:

          SELECT *

          FROM学生表CROSS JOIN选课表

    二、内连接

      内连接是一种最常用的连接类型。内连接查询实际上是一种任意条件的查询。使用内连接时,如果两个表的相关字段满足连接条件,就从这两个表中提取数据并组合成新的记录,也就是在内连接查询中,只有满足条件的元组才能出现在结果关系中。

    例如:要查询每个已经选课的学生的情况,查询语句为

    SELECT*

    FROM学生表INNER JOIN选课表ON学生表.学号=选课表.学号

    分类:

    1)等值连接:在连接条件中使用等于号(=)运算符比较被连接列的列值,其查询结果中列出被连接表中的所有列,包括其中的重复列。

    2)不等连接:在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括>、>=、<=、<、!>、!<和<>。

    3)自然连接:在连接条件中使用等于(=)运算符比较被连接列的列值,但它使用选择列表指出查询结果集合中所包括的列,并删除连接表中的重复列。

    三、自然连接

      如果在一个连接查询中,涉及到的两个表都是同一个表,这种查询就称为自连接查询。同一张表在FROM字句中多次出现,为了区别该表的每一次出现,需要为表定义一个别名。自连接是一种特殊的内连接,它是指相互连接的表在物理上为同一张表,但可以在逻辑上分为两张表。

     例如:要求检索出学号为20210的学生的同班同学的信息,查询语句为

     SELECT学生表.*

     FROM学生表JOIN学生表AS学生表1ON学生表.班级=学生表1.班级

     WHERE学生表1.学号='20210'

     

    四、外连接

      内连接的查询结果都是满足连接条件的元组。但有时我们也希望输出那些不满足连接条件的元组信息。比如,我们想知道每个学生的选课情况,包括已经选课的学生(这部分学生的学号在学生表中有,在选课表中也有,是满足连接条件的),也包括没有选课的学生(这部分学生的学号在学生表中有,但在选课表中没有,不满足连接条件),这时就需要使用外连接。外连接是只限制一张表中的数据必须满足连接条件,而另一张表中的数据可以不满足连接条件的连接方式。

    3种外连接:

    1)左外连接(LEFTOUTER JOIN)

      如果在连接查询中,连接管子左端的表中所有的元组都列出来,并且能在右端的表中找到匹配的元组,那么连接成功。如果在右端的表中,没能找到匹配的元组,那么对应的元组是空值(NULL)。这时,查询语句使用关键字LEFT OUTERJOIN,也就是说,左外连接的含义是限制连接关键字右端的表中的数据必须满足连接条件,而不关左端的表中的数据是否满足连接条件,均输出左端表中的内容。

      例如:要查询所有学生的选课情况,包括已经选课的和还没有选课的学生,查询语句为

      SELECT学生表.学号,姓名,班级,课程号,成绩

      FROM学生表LEFT OUTER JOIN选课表ON学生表.学号=选课表.学号

    左外连接查询中左端表中的所有元组的信息都得到了保留。

    2)右外连接(RIGHTOUTERJOIN)

      右外连接与左外连接类似,只是右端表中的所有元组都列出,限制左端表的数据必须满足连接条件,而不管右端表中的数据是否满足连接条件,均输出表中的内容。

      例如:同上例内容,查询语句为

      SELECT学生表.学号,姓名,班级,课程号,成绩

      FROM学生表RIGHTOUTERJOIN选课表ON学生表.学号=选课表.学号

    右外连接查询中右端表中的所有元组的信息都得到了保留。

    3)全外连接(FULL OUTER JOIN)

      全外连接查询的特点是左、右两端表中的元组都输出,如果没能找到匹配的元组,就使用NULL来代替。

      例如:同左外连接例子内容,查询语句为

      SELECT学生表.学号,姓名,班级,课程号,成绩

      FROM学生表FULL OUTER JOIN选课表ON学生表.学号=选课表.学号

    F.5.7  流程逻辑

    F.5.8  接口

    F.5.9  存储分配

    模块

    存储

    备注

    数据库

    内存:1GB

    硬盘:50GB

    必要可扩容

     

    F.5.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.5.11  限制条件

      数据库不在本地的需要访问网络

    F.5.12  测试计划

     

     

     

    测试名称

    值说明

    输入方式

    写入数据库

    1.每个数据表的测试数据应包括:输入完整,不完整,字段非法等情况

    2.多表插入,单表插入

    自动输入

    查询数据库

    单表查询,多表查询

    自动输入

    从数据库删除

    自动输入

    F.5.13  尚未解决的问题

      大数据量下的数据库的分库分表操作

     

    F.6 讨论模块

    F.6.1  程序描述

        对用户讨论功能的封装,提供统一接口。

    F.6.2  功能

        将讨论功能进行封装,负责与底层数据库交互,提供统一的添加,修改和删除接口。

    F.6.3  性能

    功能

    模块组合

    延时(ms)

    发布讨论

    数据库模块、讨论模块

    网络:1000

    数据库:100

    获取讨论列表

    数据库模块、讨论模块、评论模块、网络模块

    网络:1000

    数据库:100

     

    F.6.4  输入项

    操作

    输入

    输出

    格式

     

    发布讨论

    uid

    discussionCode

    locationID

    code

    msg

    uid

    identity

    datatype

    data:[

    discussionID  

    presenttime

    locationID

    locationLatitude

    locationLongitude

    ]

    json/POST

     

    获取讨论列表

    locationID

    uid

    code

    msg

    dataType

    data:[

    {

    discussionID

    discussionCode

    discussioncontent:

    uNickName

    uavaUrl

    imgUrls:[]

    presenttime

    locationID

    locationLatitude

    locationLongitude:

    comment:[

    {commentID

    commentcontent

    uNickName

    uorNickName}]}]

    json/POST

           

    F.6.5  输出项

    F.6.4  输入项

    F.6.6  算法

    F.6.7  流程逻辑

    (1)发布

     

    (2)获取

    F.6.8  接口

    F.6.9  存储分配

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

     

    F.6.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.6.11  限制条件

    F.6.12  测试计划

    结合评论模块、网络模块、数据库模块进行测试

    F.6.13  尚未解决的问题

     

    F.7 评论模块

    F.7.1  程序描述

    评论模块主要是对校园论坛讨论的评论模块,通过发布评论,用户可以在线参与标记点的讨论建设。评论模块,提供一个评论收集与显示的界面。

    F.7.2  功能

    用户在评论界面,根据界面信息的渲染,对某些标记点的相关讨论评论进行展示。其逻辑为用户对某特定标记点发出评论列表的请求,向讨论表获取对应的评论列表,然后得到对应信息更新到界面中去。

    如果用户想要发布某些评论,发出发布评论请求,将评论更新到评论表中。

    功能

    输入

    输出

    格式/请求

    评论他人

    uid

    uidor

    discussionID

    commentCode

    locationID

    code

    msg

    datatype

    commentID

    json/POST

     

    F.7.3  性能

     

    运行

    精度

    响应时间(ms)

    评论某人

    数据库的写入与查询,精度较高

    200

     

     

     

    F.7.4  输入项

    输入输出等参考功能F.7.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.7.5  输出项

    输入输出等参考功能F.7.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.7.6  算法

    F.7.7  流程逻辑

    F.7.8  接口

    F.7.9  存储分配

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

     

    F.7.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.7.11  限制条件

    评论界面类似微信朋友圈的风格,但是只有评论内容的显示,对评论内容的文字长度也有部分限制。

    F.7.12  测试计划

    结合讨论模块,网络模块一起测试,这里不做解释。

    F.7.13  尚未解决的问题

     

    F.8 功能模块

    F.8.1  程序描述

    功能模块主要是对校园固定标记点进行功能信息的采集与标签化的模块,通过发布功能系统,采集用户对标记点的功能模块化介绍,以及标签的集成处理,得到对应的功能介绍。

    F.8.2  功能

    用户在功能界面,根据界面信息的渲染,对某些标记点的功能信息进行展示。其逻辑为用户对某特定标记点发出功能列表的请求,向功能表获取对应的功能列表,然后得到对应信息更新到标记点表中。

    如果用户想要发布某些功能信息,发出发布功能请求,将功能描述更新到功能表中。

    功能

    输入

    输出

    格式/请求

    获取功能列表

    uid

    locationID

    dataType

    code

    msg

    data:[{

    functionID:

    functionCode

    functioncontent

    functiondesription:

    locationID

    locationLatitud

    locationLongitude

    }]

    json/POST

    发布功能

    uid

    functionCode

    locationID

    code

    msg

    uid

    identity

    datatype

    data:[

    {functionID

    functioncontent

    functiondescription

    locationID

    locationdescription

    locationLatitude  

    locationLongitude}]

    json/POST

    F.8.3  性能

    运行

    精度

    响应时间(ms)

    发布功能

    根据对应的数据项多少,其性能可能略有些区别

    200

     

    得到功能列表

    数据库的表项查询精度较高,查询速度响应较快

    20

    F.8.4  输入项

    输入输出等参考功能F.8.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.8.5  输出项

    输入输出等参考功能F.8.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.8.6  算法

    F.8.7  流程逻辑

    F.8.8  接口

    F.8.9  存储分配

     

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

     

    F.8.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.8.11  限制条件

          无

    F.8.12  测试计划

    结合网络模块、数据库模块进行测试

    F.8.13  尚未解决的问题

     

    F.9 标记点模块

    F.9.1  程序描述

    标记点模块主要负责针对电子科技大学校园地图界面上出现的标记点进行管理。

    F.9.2  功能

    地图界面的展示的所有标记点就是标记点模块的功能,用户自动产生查询所有标记点的请求,标记点模块根据特定语句查询标记点表中的所有标记信息,并根据界面显示需要,渲染出对应的标记点状态信息。

    功能

    输入

    输出

    格式、请求

    获取所有标记点

    uid

    dataType:

    code

    msg

    locationID:[]

    json/POST

    F.9.3  性能

    运行

    精度

    响应时间(ms)

    标记点管理

    数据库的表项查询精度较高,查询速度响应较快

    20

     

    F.9.4  输入项

    输入输出等参考功能F.9.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.9.5  输出项

    输入输出等参考功能F.9.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.9.6  算法

    F.9.7  流程逻辑

     

     

    F.9.8  接口

    F.9.9  存储分配

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

    F.9.10  注释设计

    1. 单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.9.11  限制条件

    对于合理的标记点,后台管理系统必须要有初步审查的过程,管理员手动编辑标记点的合法性,普通用户无法主动更新及添加合法标记点。

    F.9.12  测试计划

    测试名称

    值说明

    输入方式

    写入数据库

    1.每个数据表的测试数据应包括:输入完整,不完整,字段非法等情况

    2.多表插入,单表插入

    自动输入

    查询数据库的所有标记点

    多表查询

    自动输入

    从数据库删除非法标记点

    自动输入

    F.9.13  尚未解决的问题

    用户无法根据实际需要添加更多标记点,后台管理员系统需要手动编辑合法标记点,提供用户固定的标记点信息推送。

     

     

     

     

     

    F.10 微信授权模块

    F.10.1  程序描述

    微信授权模块主要是请求微信用户的授权,以及得到用户微信基本信息。基于微信平台,对用户进行授权请求,根据登录凭证校验请求对用户进行校验。根据用户校验的自定义登录态,写入用户信息表中。

    F.10.2  功能

    用户在微信授权界面,根据微信系统的载入提示,根据启用协议的凭证验证请求结果对该小程序的启用结果进行永久存储,对得到授权的用户信息写入用户信息表。

    功能

    输入

    输出

    格式/请求

    微信登录

    code

    encryptedData

    iv

    codemsguid

    uNickNameuavaUrl:

    json/POST

    F.10.3  性能

    运行

    精度

    响应时间(ms)

    微信授权

    基于微信平台的认证,对用户的凭证请求做出正确的响应

    500

     

    F.10.4  输入项

    输入输出等参考功能F.10.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.10.5  输出项

    输入输出等参考功能F.10.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.10.6  算法

    数据签名校验方法

        为了确保开放接口返回用户数据的安全性,微信会对明文数据进行签名。开发者可以根据业务需要对数据包进行签名校验,确保数据的完整性。

        通过调用接口(如 wx.getUserInfo)获取数据时,接口会同时返回 rawData、signature,其中 signature = sha1( rawData + session_key )

    开发者将 signature、rawData 发送到开发者服务器进行校验。服务器利用用户对应的 session_key 使用相同的算法计算出签名 signature2 ,比对 signature 与 signature2 即可校验数据的完整性。

    如 wx.getUserInfo的数据校验:

    接口返回的rawData:

     

    {

      "nickName": "Band",

      "gender": 1,

      "language": "zh_CN",

      "city": "Guangzhou",

      "province": "Guangdong",

      "country": "CN",

    "avatarUrl":"http://wx.qlogo.cn/mmopen/vi_32/1vZvI39NWFQ9XM4LtQpFrQJ1xlgZxx3w7bQxKARol6503Iuswjjn6nIGBiaycAjAtpujxyzYsrztuuICqIM5ibXQ/0"

    }

    用户的 session-key:

    HyVFkGl5F5OQWJZZaNzBBg==

    用于签名的字符串为:

     

    {"nickName":"Band","gender":1,"language":"zh_CN","city":"Guangzhou","province":"Guangdong","country":"CN","avatarUrl":"http://wx.qlogo.cn/mmopen/vi_32/1vZvI39NWFQ9XM4LtQpFrQJ1xlgZxx3w7bQxKARol6503Iuswjjn6nIGBiaycAjAtpujxyzYsrztuuICqIM5ibXQ/0"}HyVFkGl5F5OQWJZZaNzBBg==

    使用sha1得到的结果为

      75e81ceda165f4ffa64f4068af58c64b8f54b88c

    加密数据解密算法:

        接口如果涉及敏感数据(如wx.getUserInfo当中的 openId 和 unionId),接口的明文内容将不包含这些敏感数据。如需要获取敏感数据,需要对接口返回的加密数据(encryptedData) 进行对称解密。 解密算法如下:

    (1)对称解密使用的算法为 AES-128-CBC,数据采用PKCS#7填充。

    (2)对称解密的目标密文为 Base64_Decode(encryptedData)。

    (3)对称解密秘钥 aeskey = Base64_Decode(session_key), aeskey 是    16字节。

    (4)对称解密算法初始向量 为Base64_Decode(iv),其中iv由数据接口返 回。

    F.10.7  流程逻辑

     

    F.10.8  接口

    F.10.9  存储分配

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

    F.10.10  注释设计

    1.单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.10.11  限制条件

    如需获取用户头像、昵称等信息,会弹出登录弹窗引导用户授权,开发者在交互设计上兼容弹窗,避免出现多个弹窗叠加、重复提示等不好的体验。

    F.10.12  测试计划

    测试名称

    值说明

    输入方式

    请求微信服务器(服务器网络模块)

    客户端从微信获取的code

      和加密数据

    自动输入

    F.10.13  尚未解决的问题

          无

     

     

    F.11 校园身份认证模块

    F.11.1  程序描述

    校园身份认证模块主要是对校园用户的身份进行认证,基于电子科技大学信息门户平台,对学生以及教职工进行认证,根据认证结果对用户提供对应服务。根据实际用户身份的认证状态,写入用户信息表中。

    F.11.2  功能

         用户在校园身份认证界面,提供对应正确的学号以及密码,小程序的认证模块基于电子科大的信息门户系统,对其输入身份信息进行验证,根据认证结果对用户提供对应的服务,并将其认证结果写进用户信息表。

     

    功能

    输入

    输出

    格式/请求

    校园身份认证

    openid、学号、密码

    code、msg

    identity

    json/POST

    F.11.3  性能

    运行

    精度

    响应时间(ms)

    校园身份认证

    基于电子科大信息门户的认证精度,对正确的学号及密码能够正确认证

    1000

     

    F.11.4  输入项

    输入输出等参考功能F.11.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.11.5  输出项

    输入输出等参考功能F.11.2;

    安全保密:对请求数据进行签名,防止非法请求和重放攻击,同时,对用户敏感数据进行加密;

    F.11.6  算法

    用户密码加密算法采用AES对称加密,加密流程如下:

    解密流程(encryptedData 为加密数据):

    (1)对称解密使用的算法为 AES-128-CBC,数据采用PKCS#7填充。

    (2)对称解密的目标密文为 Base64_Decode(encryptedData)。

    (3)对称解密秘钥 aeskey = Base64_Decode(session_key), aeskey 是    16字节。

    (4)对称解密算法初始向量 为Base64_Decode(iv),其中iv由数据接口返 回。

    F.11.7  流程逻辑

                          

    F.11.8  接口

    F.11.9  存储分配

    软件

    存储分配

    备注

    客户端

    内存:500KB(<=2MB),本地存储:10MB

    微信限制

    数据库

    内存:1GB;

    硬盘:50GB

    适当情况下可扩容

    F.11.10  注释设计

    1.单行注释(single-line)://注释内容

      一次只能注释一行,一般是简单注释,用来简短描述某个变量或属性,程序块。

    2.块注释(block):/*注释内容*/

     为了进行多行简单注释,一般不使用。

    3.文档注释:/**注释内容 */

     /**

     * projectName: xxx

     * fileName: xxx

     * packageName: xxxx

     * date: 2019年6月18日下午12:28:39

     * copyright(c) 2019-2020 xxx

     */

    4.类注释

    类注释(Class)主要用来声明该类用来做什么,以及创建者、创建日期版本、包名等一些信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @className: user

     * @packageName: user

     * @description: 这是用户类

     * @data: 2019-06-28 12:20

     **/

    5.方法注释

    方法注释(Methods)主要用来声明该类的作用、入参、返回值、异常等信息:

    /**

     * @version: V1.0

     * @author: Lulusimili

     * @methodsName: addUser

     * @description: 添加用户

     * @param:  xxxx

     * @return: String

     * @throws: IOException

     **/

    F.11.11  限制条件

    需要根据电子科技大学信息门户验证系统保持一致,如果电子科技大学信息门户验证界面有部分更新(如多次输入后,可能需要用户输入图片验证码),小程序的校园身份认证模块也要及时更新。

    F.11.12  测试计划

    测试名称

    输入项

    输入方式

    结果

    说明

    请求电子科技大学信息门户验证平台

    学号或工号,密码

    手动输入

    验证成功

    多次请求电子科技大学信息门户验证平台

    学号或工号,密码,验证码

    手动输入

    验证成功

    多次输入错误,强制输入图片验证码

    F.11.13  尚未解决的问题

       无

     

     

    展开全文
  • 软件架构设计分层模型和构图思考

    千次阅读 2021-03-20 00:17:33
    点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。架...

    点击上方“朱小厮的博客”,选择“设为星标”

    后台回复"书",获取

    后台回复“k8s”,可领取k8s资料

    今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。

    架构思维概述

    对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到业务驱动技术,技术为最终的业务服务。要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡。

    在前面多篇文章已经提出,架构设计中有两个重点,一个是分解,一个是集成。

    分解是最基础的,架构的重点就是要对复杂问题进行分而治之,同时保证分解后的各个部分还能够高内聚,松耦合,最终又集成为一个完整的整体。分解核心是定义问题,因此架构首先仍然需要理解清楚需求。

    集成是配合分解完成的动作,最终分解完成的各个组件或子系统,通过合适的接口设计,最终还能够集成为一个完整的整体,分解仅仅是加速开发和降低问题复杂度,如果分解后的内容无法集成在一起,那么分解就没有任何意义。

    分解+集成可以理解为架构最核心的思考方式和方法。

    在分解完成后,一个大的系统已经拆分为了诸多的小模块,或者一个小模块实现本身又分为了多个步骤阶段。那么零散的节点必须向上汇集和归纳,形成一个完整的架构。

    而这个架构的形成要给关键就是要又分层思维。架构分层是谈架构绝对绕不开的一个点,通过架构分层可以更好地全面理解业务系统或功能实现。

    云平台三层架构:资源-平台-应用

    在规划大架构的时候,常会参考云计算的标准三层架构,即IaaS层,PaaS层,SaaS层。对于IaaS层重点是IT基础设施和虚拟化;PaaS层重点是构建平台层服务能力;而对于SaaS层则是具体的应用。

    对于资源层从物理资源,再到虚拟化逻辑资源,从虚拟机到现在更加轻量的容器资源。而对于平台层原来只谈技术平台,但是当前又进一步拆分出业务平台,也可以理解成当前说得比较多的中台层。

    同时在平台层和应用层之间增加了服务层,实现资源和服务的解耦。

    如果涉及到物联网类应用,一般还会在底层增加网络层和感知层,比如一个智慧城市标准平台和应用的架构图类似如下:

    在平台+应用构建模式下,一般在平台和应用之间还会有一个单独的服务层来实现接口服务对外的能力开放。资源+服务+应用也是我们常说的SOA分层架构模式,因此对于服务层也可以单独拆分出来作为一个小分层。

    问题1:数据库和数据层

    在构建一个完整的总体架构的时候,实际上没有数据层这个概念,数据层是在表达单个应用系统的分层架构实现的时候才会出现的内容。

    在总架构图里面把类似结构化数据库,非结构化数据等全部列出单独一层这个也不对,这个应该是在技术架构里面体现。

    还有一种是单独分出一个数据层,将大的公共基础数据列出,比如上面谈的智慧城市架构图。如果这些基础数据存在共性能力朝上提供,那么可以归纳到PaaS平台层,在PaaS平台层单独分出一个数据平台域来进行体现。

    问题2:服务层和服务

    在构建整体架构的时候可以单独出一个能力开放平台或服务层,但是不用体现具体有哪些业务服务能力。因为单独出业务服务能力本质已经属于应用层内容,即应用又细化拆分为了业务中台和前台应用,中间衔接的服务。我们可以参考网上的另外一个构图,如下:

    这个构图既不像云平台中的分层架构,也不像应用功能实现中的分层架构。实际可以看到如果体现单独的支撑层,支撑层已经类似现在经常说到的业务中台和能力提供。

    那么整个架构应该为 技术平台+中台+应用 方式来进行构图。

    SOA分层:组件-服务-流程

    对于SOA架构分层,重点要体现的就是服务,对于组件本身是属于逻辑资源层的概念,而对于服务则是资源对外暴露的能力抽象。

    SOA架构分层重点就是要体现出独立的服务层,注意不是画服务总线,这里可以单独画出具体提供哪些业务服务能力,技术服务能力。在采用SOA架构进行开发的时候,整体业务系统拆分为4个组件,10类服务域,5类流程,那么在构建的时候重点就是将上述组件,服务域和流程类体现出来。对于参考SOA架构来进行的构图,参考如下:

    这里的数据层最好改为标准的组件层,更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大,一般只会划分到服务域,比如用户中心服务,采购类服务等。在这种方式下构图参考如下:

    在上图中结合了云和SOA两种架构融合在一起,对于上图中的服务层实际可以理解为组件资源层和服务接口层的融合。更好的构图方式应该是拆分为标准的中台资源层-服务层-应用层。

    云和SOA架构融合

    注意对于云分层架构重点强调的是基础设施,平台和应用三层架构。而对于SOA架构强调的是资源,服务和应用三层。而对于对于传统的应用系统的构建一般又包括了IT基础设施,技术平台,数据库,中间件和应用。再到应用系统本身的分层架构可能又是标准的三层架构模式等。

    这些架构分层方法都帮助我们进一步融合分层架构模式。

    架构分层有很多方法,包括基础设施层,平台层,组件层,支撑层,服务层,应用层,数据层,展现层等。多种分发导致分层模型反而出现歧义和模糊。

    在这里我们从技术架构和应用架构两个层面来谈,技术架构沿用云计算的三层模型;而对于应用架构则采用eTOM模型标准的资源,服务,应用三层模型。那么两种分层架构模型的融合则是一个完整的云和SOA融合的分层架构模型。

    即云计算的三层中,每一个层次本身又可以进一步拆分为资源,服务和应用三层。

    拿IaaS层来说,最底层的物理资源虚拟机等是属于资源层内容,通过IaaS层资源能力提供API接口作为技术服务进行能力开放,即是服务层;最终基于资源能力,构建了一个公有云的面向公众的运营服务平台,本身又属于应用层的内容。而对于SaaS层,则底层的业务组件是资源,抽象的API接口是服务层,最终的前端业务或流程是应用功能实现。

    应用架构分层

    回到单个应用的架构分层,谈得最多的就是常说的三层架构模式。在软件架构中,经典三层架构自顶向下由用户界面层(User Interface Layer)、业务逻辑层(Business Logic Layer)与数据访问层(Data Access Layer)组成。

    在整个实现过程中,可能还会增加独立的Facade层,或独立的API接口服务提供层,统一的DTO数据传输对象层等,但是这些都不影响整体的三层逻辑结构。

    三层架构本身也和一个业务功能实现的完整对应,在数据访问层处理数据获取和持久化操作,在业务逻辑层对业务规则进行处理,在界面展现层进行相应的前端展现和用户交互。而谈到领域建模的时候,又引入了领域模型中的分层架构,如下:

    领域驱动设计在经典三层架构的基础上做了进一步改良,在用户界面层与业务逻辑层之间引入了新的一层,即应用层(Application Layer)。同时,一些层次的命名也发生了变化。将业务逻辑层更名为领域层自然是题中应有之义,而将数据访问层更名为基础设施层(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。

    当然,也有融合了领域模型和传统三架构思路后的技术架构如下:

    领域层和业务逻辑层

    在领域建模的一个核心是领域模型,领域模型不再是一个个独立的数据库表或数据对象,而是一个业务对象或领域对象。因此领域层是面向领域对象而设计实现,而业务规则能力本身也是属于领域对象对外提供的能力接口。即业务规则本身也是领域对象暴露的能力。

    传统业务逻辑层实现往往是一个数据对象对应一个DAO,一个Service和一个Interface。而领域模型下DAO可以是分开的,但是Service逻辑层往往则更多应该按领域模型思路对DAO层的能力进行组装和聚合。

    独立应用层拆分

    在我原来理解里面,领域层提供领域模型和领域服务能力接口,而应用层更多的是对领域层多个领域对象模型提供的服务能力进一步进行组装和编排,然后再暴露给前端应用。

    谈到应用层的概念,实际上可以理解为前端应用中存在的共性能力的进一步下沉。即应用本身只是用户业务功能实现的承载,但是这个功能的实现可以通过多种前端展现形式,比如传统的CS桌面应用,BS应用,或手机端APP。

    在电商里面,一个商品订购就是一个独立的应用,用户可以在APP完成,也可以在BS端完成,但是不论在哪里完成最终应用层提供的能力都应该一样。比如完成一个商品订购需要同时和底层的订单,库存,支付多个服务进行交付和协同。那么这个逻辑显然不适合同时在BS端应用和APP端应用中进行重复编写和开发。那么这个内容就应该在应用层实现。

    如果回到微服务和中台架构下,这个应用层拆分更加必要,即通过应用层来下沉共性的服务组合和组装逻辑,这个逻辑和协同不应该属于任何一个前端应用。

    界面层还是接口层

    在开发一个聚合能力的中台微服务模块的时候,可以看到这个微服务模块本身并没有界面展现层,那么该微服务的最上层仅仅是提供API接口的接口服务层。

    该API接口服务能力既可以提供给APP前端,也可以提供给BS端使用。

    软件技术架构分层

    软件技术架构构图,分层仍然可以沿用软件三层分层模型,重点是说明清楚各层用到的关键技术组件或技术服务能力。比如软件开发三层模型的技术架构分层如下:

    如果本身就是一个技术平台,类似大数据平台,那么我们在整体构图的时候仍然需要考虑先进行分层,再详细说明每层里面的技术内容。

    比如对应一个大数据平台,包括了大数据采集,大数据存储,大数据处理,大数据分析和应用,那么这个就是关键的分层,可以基于这个分层再来考虑各层采用的关键技术。

    对于技术栈构图基本也可以参考技术架构构图模式进行。

    技术架构重点需要回答的就是你在进行软件架构设计过程中,究竟会用到哪些关键技术,哪些开源产品或工具等。可以细化到具体的技术产品,也可以仅细化到产品类型。

    比如消息中间件,你可以细化到采用RabbitMQ,也可以在技术架构中只体现采用消息中间件。

    技术架构和软件功能分层架构唯一相同的就是分层,技术架构在各个分层里面都没有具体的业务功能点和实现内容,仅仅是关键技术点说明。

    单个应用功能架构

    注意应用功能架构完全是重点描述应用系统具备哪些功能,一个功能究竟是采用什么三层技术架构实现并不用关心。因此功能架构不应该体现数据层,逻辑层,技术点这些内容。

    那么对于一个应用系统的功能如何分层?

    我们可以参考业务分层分类,将业务分为基础支撑层,执行层,决策管理层。这样基本的分层模式就出来了,基于该方式可以完成一个功能架构构图。

    对于单个应用来说一般不会自身有云平台,PaaS平台这类概念。但是单个应用构建一定存在共性技术支撑平台能力,比如有自己的流程管理,各自共性技术功能组件等。因此单应用构建还可以采用基础技术支撑层+应用层+门户层的方式进行构图。

    在应用层再按具体的业务域或业务阶段进行进一步细分。

    架构图的分层构图逻辑

    在前面基本给出了不同类型的架构图的核心分层逻辑,可以看到在画架构图的时候尽量不要混合使用不同场景下的构图方式,否则就导致整体架构图混乱。

    在画整体架构的时候一般需要重点参考云三层架构,SOA三层架构的构图模式进行构图。而在细化到某一个应用系统的时候,仍然还需要分清是构建技术架构图还是功能架构图,两者本身的分层逻辑也存在很大的差别而不能混用。

    架构图的构图逻辑

    要完成一个完整的架构图构图,可以先拆分为两边+中间。两边一般是放具体的标准,规范等,比如安全管理,质量管理,技术标准规范,开发运维规范等。

    中间即是重点需要考虑进行分层构建的地方。

    在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层,平台层,应用层,门户层。而对于应用层本身又可以考虑业务域进一步拆分,或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。

    在云和SOA下,更加强调平台+应用构建模式。

    而两者之间一般是服务层,通过SOA平台或API能力开放平台来统一接入和发布服务,以形成一个完整的资源+服务+应用的松耦合架构。同时一个完整的架构本身就是多视角的,如下:

    功能架构往往可以给具体用户和业务人员看,而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用,而导致架构图混乱。

    想知道更多?描下面的二维码关注我

    后台回复"技术",加入技术群

    后台回复“k8s”,可领取k8s资料

    【精彩推荐】

    点个赞+在看,少个 bug ????

    展开全文
  • 数据库——关系模型设计

    千次阅读 2019-10-04 21:48:33
    数据库关系模型设计 背景 目前公司内部主流数据库是关系型数据库MySQL,数据库设计是对数据进行组织化和结构化的过程,即关系模型的设计。 对于项目规模小、用户数量少的情况,处理数据库中的表结构相对轻松;目前...
  • 之前一直想将Navicat中的数据表通过导出sql语句,然后在PowerDesign中逆向生成模型,突然发现Navicat本身就自带这项功能 一、在Navicat中逆向数据库到模型 二、开启数据库表模型的中文注释显示 默认的模型是没有...
  • 数据库设计说明书的编写

    万次阅读 多人点赞 2019-06-17 19:46:34
    G.1 引言 G.1.1 编写目的 数据库的表结构设计是整个项目开发中一个非常重要的环节,一个良好的数据库设计,可以提高开发效率,方便系统维护,并且为...我们也希望通过写数据设计说明书,规范数据名称、数据范围...
  • 【软件工程】概要设计文档——概要设计说明

    万次阅读 多人点赞 2021-03-28 17:22:05
    文章目录1 引言1.1 编写目的1.2 范围1.2.1 系统目标1.2.2 主要软件需求1.2.3 软件设计约束、限制1.3 术语和缩略词1.4 参考资料2 体系结构设计2.1 需求复审2.2 软件体系结构2.3 模块设计3 接口设计3.1 用户接口3.2 ...
  • 架构设计说明书该怎么写?

    千次阅读 2020-05-05 22:38:35
    前言架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。承接上文:如何做架构设计说明书 (点击直达)本文来说一下如何写架...
  • 模型机CPU设计——设计的整体架构(1)

    千次阅读 多人点赞 2019-12-21 20:48:33
    一、设计目的 完整、连贯地运用《数字逻辑》所学到的知识,熟练掌握 EDA 工具基本使用方法,为 学习好后续《计算机原理》课程做铺垫。 二、设计内容 ① 按照给定的数据通路、数据格式和指令系统,使用 EDA 工具设计...
  • 智能家居系统模型设计2.0

    千次阅读 多人点赞 2021-06-11 15:17:30
    智能家居系统模型设计引言实现的功能硬件选型主控模块无线通信模块数据采集模块温湿度监测空气质量监测光照监测数据展示模块家具模拟模块云平台选择代码编写主函数结果展示实物图与手机界面展示云平台数据可视化界面...
  • 软件系统分析与设计 | 用例模型

    千次阅读 2019-05-26 00:41:04
    每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。编写用例时要避免使用技术术语,而应该用最终用户或者领域专家的语言。...
  • 模型定义 模型设计主要包括维度及属性的规范定义,维表、明细事实表和汇总事实表的模型设计。 1)维度设计 ​ 维度是维度建模的基础和灵魂。在维度建模中,将度量称为"事实",将环境描述为"维度",维度是用于分析...
  • 浅谈12306核心模型设计思路和架构设计

    万次阅读 多人点赞 2017-11-17 09:36:15
    浅谈12306核心模型设计思路和架构设计 出处:观察者网站+cnblogs 网址:http://m.guancha.cn/Science + http://www.cnblogs.com/netfocus 1月11日起,12306网站开始销售除夕当日火车票。每到此时,铁路...
  • 目录0引言1、课本介绍1.1理论的书1.2 R语言的书2、构造数据3、相关性分析4、多元回归模型的建立4.1建立模型5.2模型分析5.3方差分析表5、变量选择5.1 逐步回归5.2所有子集法5.3套索法6、回归模型常用函数总结7、参考...
  • 总第498篇2022年 第015篇Twins 是美团和阿德莱德大学合作提出的视觉注意力模型,相关论文已被 NeurIPS 2021 会议接收。...导读背景视觉注意力模型设计的难点Twins 模型设计Twins-PCPVTTwins-SVT实验Image...
  • 二、代码模型 其实DDD并没有标准的代码模型,最多只能说是给出了建议模板,在实际的架构设计中,不同人有不同的理解,设计出来的结构就不相同,也可以根据公司和业务的情况做适当的调整。 以下的文件目录名不是固定...
  • JSP开发模型与MVC设计模型

    千次阅读 2018-06-22 22:46:32
    JSP开发模型与MVC设计模型 一、概述 ​ JSP的开发模型即JSP Model,在web开发中,为了更方便地使用JSP技术,SUN公司为JSP技术提供了两种开发模型:JSP Model1和JSP Model2。 二、特点 JSP Model1:简单轻便...
  • 构建线性回归模型

    千次阅读 2022-03-07 12:22:38
    构建线性回归模型 ...下面展示了 y = 2x + 3 的函数图像: 图1:函数图像y=2x+3 函数中斜率 k 与 截距 b 控制着“直线”的“旋转”与“平移”。如果斜率 k 逐渐减小,则“直线”会向着“顺时针”方向旋转,为 k
  • 前言:本文旨在简单介绍DS的概述和架构上的设计,对其安装等不做展开介绍。之前了解了一下,很多小伙伴也在使用该产品。我呢,也是到现在公司后才开始接触并使用,对其 “开发” 的还不够深,这里根据官方文档和项目...
  • 十、数据仓库模型设计基础 10.1 维度数据模型 10.2 维度数据模型建模过程 10.3 维度规范化 10.4 维度数据模型的特点 10.5 星形模型(star schema) 10.6 雪花模型(snowflake schema) 10.7 事实星座模型(Fact ...
  • 前言 在电商系统中,商品模型至关重要,是整个电商的核心,下面通过一个简单的分析,设计一个基础的商品模型。商品模型的演化 在以前,那时CMS很流行,最常见的模型是栏目-文章模型。于是做电商的时候,自然就继承...
  • 版权声明:本文为博主原创博文,未经允许不得转载,若要转载,请说明出处并给出博文链接 最近一段时间,朋友圈被MATLAB禁止哈工大、哈工程等科研院校使用刷屏了,顿时各种声音都有,有的网友说可以转去使用Python...
  • DDD领域模型 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。 业务对象...
  • 五种IO模型设计模式

    千次阅读 2019-06-10 16:30:01
    在《Unix网络编程》一书中提到了五种IO模型,分别是:阻塞IO、非阻塞IO、多路复用IO、信号驱动IO以及异步IO。 下面就分别来介绍一下这5种IO模型的异同。 1.阻塞IO模型  最传统的一种IO模型,即在读写数据过程中...
  • V模型:需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试 V模型的优缺点 优点 1. 包含了底层测试(单元测试)和高层测试(系统测试);2. 清楚地标识了开发和测试的各个阶段;3. 每个阶段...
  • 软件设计说明书模版(申请软件著作权可供参考)

    万次阅读 多人点赞 2019-06-20 14:59:22
    1.引言 1.1 编写目的 1.2 项目背景 ...3.2.1 软件概要设计说明 3.2.3 基本设计概念和处理流程 3.3 软件的详细设计 3.3.1 系统结构 3.3.2 模块设计说明 3.3.3 爬虫模块 3.3.4 日志模块 3.3.5 数...
  •  多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。 二、星型模式(star schema)  星型模式的核心是一个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 114,325
精华内容 45,730
关键字:

展示模型设计说明