软件工程1

week2——软件工程

#软件工程的概念

软件工程指软件开发的工程化。

编写程序固然重要，更重要的是需求分析，具体为问题抽象、抽象问题、问题理解。

#软件工程的内容层次

1.“质量”关注点——软件开发所需实现的功能正确性、高性能、高可靠性、用户友好型等方面的质量目标

2.过程——软件开发的整体过程，一系列活动之间的顺序及开展方式。重点

3.方法——软件开发的各种活动中，相应的方法支持需求分析、软件设计、软件构造、软件测试等，这些方法为开发人员开展相应的活动提供具体的指导

4.工具——软件开发过程中一些环节需要的自动化工具的支持，软件需求分析工具、软件设计工具、辅助编码工具、代码静态分析工具、软件测试工具等

#软件过程模型

1.瀑布模型

2.增量模型

3.迭代模型

4.原型化模型

5.统一过程模型​​​​​​​

#小组项目

本周确定了软件工程小组项目。开发一款安卓app，为了促进校园的音乐活动，开发一款音乐场馆、地点的预约和音乐活动发布的软件。能做到动态同步校园内场馆是否被使用的实时信息，校园场馆的预约，音乐活动的邀请与分享。
 

​​​​​​​week3——需求

#需求的概念

需求，是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求將作为系统开发，测试，验收，提交的正式文档依据。

#需求的内容

• 需求是系统为满足容广期望的目标而完成的行为
• 需求要体现出对问题领域的清晰理解
• 给出系统的使用场景和上下文

为什么要设计该系统

系统由谁使用

系统要做什么

系统涉及哪些信息

对解決方案有何额外限制

如何使用该系统

质量需达到何种程度

#需求的定义

• 领域性质：无论系统存在与否均存在的应用领域的性质。
• 需求：由系统的存在西使能的应用领城性质。
• 规约描述：描述系统为满足需求而应具有的行为。
• 需求证明的标准：1.运行在某台机器上的程序满足规约描述；2.针对给定的领域性质，规约描述满足需求。
• 需求验证的标准：1.是否已发现所有重要需求？2.是否已发现所有有夫的领域性质？

#需求的撰写

• 文档需要有逻辑组织结构                                                                                                      例如：参照IEEE的模板​​​​​​​
• 典型的组织形式包括​​​​​​​                                                                                                                 按系统能够响应的各种外部环境情况来组织；按系统特征来组织；按系统的响应方式来组织；按所管理的外部数据对象来组织；按用户类型来组织；按软件的工作模式来组织；按子系统的划分来组织

#高质量需求

• 正确性二经过验证的
• 无歧义
• 完整的
• 可测试二可以证明的
• 可修攻的
• 可跟踪的
• 易理解
• 一致的
• 有序的
• 项目或产品特定的其他特征

#小组项目

本周确定了小组音乐活动管理软件的需求，根据音乐活动组织来进行需求分析，以音乐活动场地出借，音乐活动发布，音乐器材出借为中心进行更深入的需求分析，明确了应用领域和机器领域。

​​​​​​​week4——用例图

#用例图

        ​​​​​​​由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。

用例模型的表示 

#用例图的主要元素

        参与者(Actor) 与系统交互的人或外部系统

        用例(Use case) 系统为参与者提供的有价值的服务功能

        关联(Association) 用例图中用例与参与者之间的交互关系

#构建用例模型的步骤

•  第一步:1.找到所有的参与者和用例2.识别出参与者并做简单的描述3.识别出用例并做简单的介绍

•  第二步:1.编写用例,列出用例2.给用例事件流程划分重要等级3.按照重要程度排序详细描述事件流程

#用例粒度

用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
　　如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。
　　如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。
比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。

　　我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。
​​​​​​​ 

去掉所有的CRUD 类的用例， 创建(Create), 查找(Retrieve), 更新(Update), 删除(Delete)

#UML图

        统一建模语言（UML，Unified Modeling Language）是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。

1. 为建模者提供可用的、富有表达力的、可视化的建模语言，以开发和交换有意义的模型。
2. 提供可扩展性和特殊化机制以延伸核心概念。
3. 支持独立于编程语言和开发过程的规范。
4. 为理解建模语言提供正式的基础。
5. 推动面向对象建模工具市场的成长。
6. 支持更高级的开发概念。

        包括用例图、状态图、活动图等等。

#小组项目

本周在学习了UML图中的用例图建模后，根据音乐活动组织来进行需求分析，确定了学生用户、场地管理员、器材管理员为参与者，根据实际音乐活动组织软件需求分析出用例和用例与参与者之间的关系，比如发布场地——场地管理员、查看场地——学生用户、提交预约信息——学生用户。

​​​​​​​week5——数据库建模与设计

#数据库建模与设计​

数据库建模的过程：概念模型->逻辑模型->物理模型。表达计算机世界的模型称数据模型;表达信息世界的模型称概念数据模型，简称概念模型，信息世界是对现实世界的理解与抽象。

#E-R模型 ——概念模型​​​​​​​

概念模型的用途:

• 概念模型用于信息世界的建模

• 是现实世界到机器世界的一个中间层次

• 是数据库设计的有力工具

• 数据库设计人员和用户之间进行交流的语言

对概念模型的基本要求:

• 较强的语义表达能力

• 能够方便、直接地表达应用中的各种语义知识

• 简单、清晰、易于用户理解

E-R模型的基本概念

E-R模型给出了一组基本概念，用这组概念可以刻画信息世界 

实体；属性；联系 ；关键字/码

#实体与实例

1.实体:客观存在并可相互区分的事物。

2.实体有类(实体，实体的型)和个体(实体的实例，实体的值)的概念。

3.用属性来刻画实体。

 #联系

1.​​​​​​​联系，指一个实体的实例和其他实体实例之间所可能发生的联系。

2.参与发生联系的实体的数目，称为联系的度或元。联系有一元联系、二元联系和多元联系。

3.联系的基数(Cardinalities):实体实例之间的联系的数量，即一个实体的实例通过一个联系能与另一实体中相关联的实例的数目。完全参与联系，即该端实例至少有一个参与到联系中, 最小基数为1 (1..m); 部分参与联系，即该端实例可以不参与联系，最小基数为0 (0..m)。

#E-R模型-表达方法之chen方法

 

​​​​​​​

#本周我们小组进行了对于音乐活动组织系统的E-R图建模。

​

Week6——Git

#软件配置管理工具

软件配置管理是一种标识、组织和控制修改的技术，它作用于整个软件生命 周期，其目的是使错误达到最小并最有效地提高生产率。

Git是一个开源的分布式版本控制系统，它最初由 Linux Torvalds 编写，用作 Linux 内核代码的管理，后来在许多其他项目中取得很大的成功。它除了常见的 版本控制管理功能之外，具有处理速度快、分支与合并表现出色的特点。

•  记录软件产品的演化过程
•  确保开发人员在软件生命周期的每一个阶段都可以获得精确的产品配置
•  保证软件产品的完整性、一致性和可追溯性

#软件配置项

软件配置项(Software Configuration Item，简称SCI)是为了配置管理而作为 单独实体处理的一个工作产品或软件。​​​​

​​​​​​​

#版本

版本是在明确定义的时间点上某个配置项的状态;版本管理是对系统不同的版本 进行标识和跟踪的过程，从而保证软件技术状态的一致性。

#基线

基线(Baseline)是软件配置项的一个稳定版本，它是进一步开发的基础， 只有通过正式的变更控制过程才能改变

​​​​​​​

#版本控制问题

出现两个程序员修改同一个 代码文件的问题。

1.独占工作模式  2.并行工作模式

#git的操作

• 创建与提交
• 克隆到本地
• 从远端拉取
• 提交到远端 
• 撤销变动
• 合并
• 冲突处理
• 删除

#gitee的使用

1.git网站上的注册登录

2.准备工作

        1.工具一：git-bit的安装 https://git-scm.com/

        2. 配置RSA公钥    打开git bash；输入代码来实现git账户和本地的关联 ssh-keygen -t rsa -C       ；结束后输入来查看自己的密钥  cat ~/.ssh/id_rsa.pub ；将密钥复制到网站上去；测试是否连接到远程自己的账号   ssh -T git@gitee.com；创建远程仓库

3.上传文件到gitee 

1）新建文件夹

2）进入刚刚新建的文件夹，即进入“gitspace”，点击鼠标右键，选择"Git Bash Here"

3）进行基础配置，也叫全局设置，作为 git 的基础配置，作用是告诉 git 你是谁，你输入的信息将出现在你创建的提交中，使用下面两条命令：  git config --global user.name "你的名字或昵称"     git config --global user.email "你的邮箱"

 4）输入初始化命令 git init  回车，文件夹出现了隐藏文件夹。这步是将本地文件初始化为本地仓库。

5）输入要链接到码云的地址，（前面我们复制的地址）  回车——git remote add origin 地址

6）在这个新建文件夹里随便放个文件。

        插入一下，输入可以查看这个文件夹的文件装填——git status 命令用于查看在你上次提交之后是否有对文件进行再次修改

7）输入命令：git add .
8）添加注释，来说明自己为什么要上传，方便以后自己查阅 例如： git commit -m "第一次上传" 
9）提交到码云上面，git push origin master；第一次提交 git push -u origin master
 

4.下载克隆仓库

新建个文件夹方便看，进入到这个文件夹，鼠标右键-打开git bash命令窗口--复制网站上的ssh链接-在刚才的Git窗口中输入命令 git clone 然后右键即可。git clone url

5.基本命令汇总

Week7——数据库

#数据库

•  数据库就是对数据的管理
•  业务中包括了对数据的增，删，改，查等操作
•  数据管理中包括用户访问权限，持久化，分布式等不同的方案选择

常用数据库介绍

 ​​​​​​​

#小组项目

        确定MySQL为本项目的数据库。学习Android Studio开发。

Week10、11——面向对象

#面向对象分析 (Object-Oriented Analysis, OOA)

•  面向对象分析技术关注应用领域中的实体，并将其建模为对象
•  面向对象分析技术主要基于分类、泛化、聚合关系在对象集合之间建⽴结构 

•  对象的行为是执⾏行预定的动作(服务/活动)
•  对象通过执⾏动作来完成状态变迁

•  “对象”是问题领域中真实存在的实体，

        有“定义清晰的边界”

•  对象中封装有属性和行为

•  面向对象分析的五个核心概念:
        对象、属性、结构、服务和主题

#对象建模原则1: 抽象​​​​​​​

•  抽象
        •  在对象间找出共性，忽略不相关细节

        •  关注对象间的一般/特殊关系

                •  将具有相同属性或角色的对象放入同一个类集合中
                •  再通过父子关系，将由共性的类定义为同一个父类的子类

  继承/一般-特殊结构(Gen-Spec Structures)

•  一般-特殊结构将类组织成基于继承关系的分类层次结构

•  ⾃底向上是从特殊到⼀般的类 (generalization)

 •  ⾃顶向下是从一般到特殊的类(specialization).

#对象建模原则2:分解

•  分解

        •  表达整体部分关系，细分为聚合和组合

整体-部分结构(Whole-Part Structures)

•  整体部分结构描述对象间的组合关系.

#UML类图表达法

#类

类是具有以下特征的对象集合

 •  相同性质(attributes)

 •  相同行为(operations) 

 •  相同的对象关系

 •  相同语义(“semantics”)

#对象

对象是类的实例 

#类属性

类性质(attributes)的描述

属性在类图标的属性分隔框中用文字串说明：

        UML规定属性 的语法为:

        [可见性] 属性名 [:类型] [ [多样性 [ 次序]] ] [= 初始值] [{约束}]

#类关系

•  UML中，关注以下几种类型的关系:

•  关联关系(AssociaRon)
•  聚合与组合关系(AggregaRon and ComposiRon)

•  泛化关系(GeneralizaRon)

•  依赖关系(Dependency) 

•  实现关系(RealizaRon)

#关联关系的种类

•  按照关联所连接的类的数量，对象类之间的关联可分为:⾃返关联，二元关联，N元关联

•  ⾃返关联(reflexive association)⼜称递归关联(recursive association)，是一个类与本 ⾝身的关联，即同⼀一个类的两个对象间的联系。

•  ⼆元关联(binary association) :⼆元关联是在两个类之间的关联。 

•  N元关联(n-ary association): 是在3个或3个以上类之间的关联。

#聚合(Aggregation)与组合(Composition)关系

•  聚合(Aggregation)用于表达一个整体对象与其成员对象之间的关系

        •  “Has-a” 或是 “Whole/part”

•  组合(Composition)用于表达一个整体对象与其组成部分之间的关系

         •  组合关系所表达的整体类与部分类之间的所属关系更强

                •  整体类的对象不存在时，部分类的对象也不存在 

                •  整体类对象撤销之前要负责将部分类对象撤销

#继承/泛化(Inheritance/Generalization)

 •  子类继承父类的属性、关联和操作

•  子类可以覆盖继承来的内容

•  父类可以声明为抽象类{abstract}，则 将不会为它直接创建实例对象

UML例图 

#设计抽象的接口

        抽象的接口:向用户暴露尽可能少的实现细节

        •  让用户知道的关于类的内部实现细节越少越好: 

                •  只给看必须的
                •  只看公开的
                •  只为⽤用户的业务需求考虑

        #开闭原则(Open/Closed Principle, OCP)

        软件实体在扩展性方面应该是开放的，⽽在更改性⽅面应该是封闭的。

       # Liskov替换原则 (Liskov Substitution Principle, LSP) 

        子类可以替换父类出现在父类能出现的任何地方

        #依赖倒置原则 (Dependency Inversion Principle, DIP)

         依赖倒置原则指的是依赖关系应该是尽量依赖接口(或抽象类)，而不是依赖于具体类

        #接口分离原则(Interface Segrega:on Principle, ISP)

        在设计时采用多个和特定客户类(client)有关的接口要比采用一个通用的接口要好

        

#优秀的对象设计

        高内聚，低耦合 

        在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则是高内聚低耦合。从模块粒度来看，高内聚：尽可能类的每个成员方法只完成一件事（最大限度的聚合）； 低耦合：减少类内部，一个成员方法调用另一个成员方法。从类角度来看， 高内聚低耦合：减少类内部，对其他类的调用；从功能块来看 高内聚低耦合：减少模块之间的交互复杂度（接口数量，参数数据）即横向：类与类之间、模块与模块之间；纵向：层次之间；尽可能，内容内聚，数据耦合。

#个人任务

完成圆、三角形、圆柱和三棱柱的对象设计

#小组任务

        完成业务逻辑层的设计。具体：对象的抽象，接口的抽象。 

Week12-编写高质量代码

#编写过程和规范

软件编程是一个复杂而迭代的过程，它不仅仅是编写代码，还应该包括代码审查、单元 测试、代码优化、集成调试等一系列工作。

#编程规范:程序模板 

 

#编程规范:注释 

#编程规范:命名 

•  唯一能完整并正确地描述代码的文档是代码本身 

•  编写可以阅读的代码，其本身简单易懂

 #编程规范:语句

        根据不同语言的语句规范

        注意缩进、空格和换行

#代码静态检查

#代码评审技术

代码审查(Code Review)是一种用来确认方案设计和代码实现的质量保证 机制，它通过阅读代码来检查源代码与编码规范的符合性以及代码的质量。

代码审查的作用

• •  检查设计的合理性

• •  互为 Backup

• •  分享知识、设计、技术

• •  增加代码可读性

• •  处理代码中的“地雷区”

#缺陷检查表 

 

#代码静态分析工具 

1.Python:

•  Pylint:检查代码风格是否符合PEP8规范,检查代码是否存在常见的错误和违反最佳实践,检查重复的代码

2.Java:

•  Checkstyle:通过对代码编码格式、命名约定、Javadoc、类设 计等方面进行代码规范和风格的检查。

•  FindBugs:通过检查类文件或JAR文件，将字节码与一组缺陷 模式进行对比从而发现代码缺陷，完成静态代码分析。

•  PMD:通过其内置的编码规则对Java代码进行静态检查，主要 包括对潜在的Bug、未使用的代码、重复的代码、循环体创建 新对象等问题的检验。

•  Jtest:能够按照其内置的超过800条的Java编码规范自动检查 并纠正这些隐蔽且难以修复的编码错误，同时还支持用户自定 义编码规则，帮助用户预防一些特殊用法的错误。

3.C++:

•  微软Visual Studio中的代码分析工具可以检查代码中是否存在一 些常见缺陷和违反良好编程习惯的情况。

•  Lint是一种静态程序分析工具，目前已形成了一系列工具。它侧 重于代码的逻辑分析，发现代码中一些潜在的错误，如数组访问 越界、内存泄漏、使用未初始化变量等。

#week13——单元测试

#单元测试

#单元测试概念

单元测试(Unit Testing)是对软件中的最小可测试单元进行检查和验证

#单元测试内容 

#单元测试原则 

#单元测试过程 

#单元测试质量 

 #单元测试方法

黑盒测试 

 白盒测试

 

# 测试用例

#测试用例的概念

 #测试用例设计的要求

#测试用例等价类划分 

# 测试用例等价类类型

#白盒测试方法 

#白盒测试技术

 白盒测试是将测试对象看做一个透明的盒子，允许测试人员利用程序内部的逻辑
 结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

#控制流图

控制流图(CFG， Control Flow Graph)是一个过程或程序的抽象表示。 控制流图的基本符号:

•  矩形代表了连续的顺序计算，也称基本块
•  节点是语句或语句的一部分，边表示语句的控制流

#基于控制流的测试 

 #流图

• 节点：在流图中用圆表示 ，一个圆代表一条或多条无分支语句
• 边：流图中的箭头线，和程序流程图中的箭头线类似，代表控制流。
• 在流图中一条边必须终止于一个节点，即使这个节点并不代表任何语句（实际上相
  当于一个空语句）
• 区域：由边和节点围成的面积，当计算区域数时应该包括图外部末被国起来的那个
  区域

#环形复杂度 

        环形复杂度定量度量程序的逻辑复杂性：
        1. 流图中的区域数        

        2.V(G)=E-N+2，其中E是流图中边的条数，N是流图中节点数。

        3.V(G)=P+1，其中P是流图中判定节点的

#代码覆盖标准 

代码覆盖率描述的是代码被测试的比例和程度，通过代码覆盖率可以得知哪些 代码没有被覆盖，从而进一步补足测试用例。

        #语句覆盖

                程序中的每个可执行语句至少被执行一次。 

                语句覆盖是最弱的逻辑覆盖准则。

        #判定覆盖(分支覆盖)

                程序中每个判断的取真和取假分支至少经历一次，即判断真假值均被满足。

               判定覆盖具有比语句覆盖更强的测试能力，但仍是弱的逻辑覆盖。

        #条件覆盖

                每个判断中每个条件的可能取值至少满足一次。

                条件覆盖只能保证每个条件至少有一次为真，而没有考虑整个判定结果。

        #判定条件覆盖

                判断中所有条件的可能取值至少执行一次，且所有判断的可能结果至少执行一次。

                没有考虑条件的各种组合情况。

        #条件组合覆盖

                判断中每个条件的所有可能取值组合至少执行一次，并且每个判断本身的 结果也至少执行一次。

                覆盖了所有组合，但覆盖路径有限

#基本路径测试

基本路径测试是在程序控制流图基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

基本路径测试满足语句覆盖

#示例:基本路径测试

#示例:基本路径测试

V(G) = 6

独立路径数为6

独立路径：

路径1：1-2-10-11-13

路径2：1-2-10-12-13

路径3：1-2-3-10-11-13

路径4：1-2-3-4-5-8-9-2-

路径5：1-2-3-4-5-6-8-9-2-

路径6：1-2-3-4-5-6-7-8-9-2-