考试重点知识

十个选择:基本概念（20分）

综合题（80分）：给一个场景，需要把一个案例从头到尾设计出来就ok了

• 数据库设计40
  • 1,2,3范式
  • RBAC
  • 完整性约束
  • sql
• 面向对象设计40
  • 整个系统DFD建模
  • 用例角度,用例描述
  • 事件流刻画角度
  • activity图
  • 时序图
  • 类图
  • 状态图
  • 以及一些基本原则（7个，类图中的5+2对类图做一些优化

如何复习

• 看书，形成知识框架，对于所有知识形成脑图，如何与业务场景衔接，如何建立一个实际开发需要的东西
• 将开发好的系统重新设计出来
• 将上课设计的案例看老师如何设计，能不能找到更好的方法
• 图书馆找教材，UNL实训教材，数据库设计教材

假设有一个信息管理系统，不管什么端，

• 先将用户找出来
• 确认需求

下面是从ppt上整理的一些基础知识，虽然我整理的时候记得挺多的，把觉得重点知识都整理出来了，但是考试证明整理的都没有用，主要还是去真正的设计一个系统，所以对于下面的概念可以选择性阅读，不要求背过，但是一定要理解，后面与UML相关的东西一定需要牢牢掌握，尤其是上面写到的那些UML图，必须必须必须得会！！！是在不会的话可以去图书馆借一些UML的书，然后对照着里面的例子去设计
我最后的总评成绩由于平时作业的加分获得了大学中的第一个满分，对于这门科目的考试我的感觉就是考试时间非常的紧，看上面的考试重点就知道我们需要从头去设计一个系统，包括功能模型，动态模型，静态模型，而设计一个系统肯定不是一天两天就能设计好的，因此需要在考试两个半小时设计一个系统的难度可想而知了，这就要求如果想获得一个比较好的成绩就必须要能够熟练的设计一个系统，包括数据库，数据库的优化，用例图，活动图，时序图，类图以及类图的优化，这些东西必须必须必须掌握！！！不然考完试就等着郁闷吧
这门课程相对来说背诵的知识还是比较少的，大部分都是需要自己动手实践的，这从平时作业也可以看的出来，饶老师非常鼓励我们自己去动手完成一些东西，也非常强调coding的重要性，所以哪怕下面的东西都不会，也需要把上面的那些东西掌握了！！！

系统+设计

什么是系统

定义

系统是相互联系，相互作用的诸元素的综合体

三个特性

• 多元性
  • 系统是多样性的统一，差异性的统一
• 相关性
  • 系统不存在孤立元素组分，所有元素或组分间相互依存、相互作用、相互制约
• 整体性
  • 系统是所有元素构成的复合统一整体

软件系统核心要素

软件系统：指在一定的软件开发与应用环境下，为了达到某一目的而相互联系、相互作用的若干个软件要素所组成的有机整体

软件系统的要素

模型驱动->灵活且可扩展

设计原则

功能分解法

• 以系统需要提供的功能为中心组织系统
• 首先定义各种功能，然后把功能分解为子功能
• 对较大的子功能进一步分解，直到可给出明确的定义
• 设计功能、子功能所需要的数据结构
• 定义功能、子功能之间的接口
• 作为一种早期的建模方法，没有明确地区分分析与设计

结构化设与功能分解法基本相同，基于模块的概念建立设计模型，分为概要设计和详细设计

• 概要设计：确定系统中包含哪些模块以及模块之间的调用关系，得到模块结构图（MSD）
• 详细设计：描述每个模块内部的数据结构和操作流程

结构化方法的优缺点

• 优点
  • 强调研究问题域，并由严格的法则
• 缺点
  • 仍然是间接映射问题域
  • 分析与设计的概念不一致，从分析到设计的过渡比较困难
  • 数据流和加工的数量太多，引起分析文档的膨胀

信息建模法

信息建模法（information modeling）

• 核心概念是实体和关系。实体描述问题域中的事务，关系描述事务之间在数据方面的联系，都可以带有属性
• 发展之后的方法也把实体称为对象，并使用了类型和子类型的概念，作为实体（对象）的抽象描述

需求工程

需求语义断连现象的分析

软件分析本质：识别并解决问题

• 语义断连是需求分析中常见的现象
  • 需求分析中所有的涉及物需要明确定义，避免不一致或二义性的发生
  • 划清角色与系统的边界，形成完整的业务关联场景至关重要
• 需求目标的缺失是需求分析中常见的现象
  • 需求中边界的确实，往往会造成全局性的失败
  • 需求分析中必须避免目标确实问题的发生
  • 建立起所涉及物之间的关系，形成完整的业务关联场景至关重要

语义断连错误的原因

需求的重要性

• 开发软件系统最困难的部分就是准确说明开发什么。
• 最困难的概念性工作是编写出详细的需求，包括面向用户，面向机器和其他软件系统的接口。

需求关键特征属性

软件需求特征属性

• 层次化
• 过程（评审vs版本）
• 追踪vs状态
• 客户角色

层次化

需求又分为业务需求，用户需求，功能需求以及系统需求，此外还包括一些非功能需求

• 业务需求
  • 表示组织或客户高层次的目标，业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标
• 用户需求
  • 描述的是用户的目标，或用户要求系统必须能完成的任务
• 功能需求
  • 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求
• 系统需求
  • 用于描述包含有多个子系统的产品（即系统）的顶级需求

追踪vs状态

需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。在跟踪的过程中最重要的一个属性便是需求的状态，这个用来标识需求当前情况的一个属性，可以帮助我们更好了解需求变更的过程以及当前情况

需求工程

什么是需求工程

• 把所有与需求直接相关的活动统称为需求工程
• 需求工程中的活动可以分为两大类
  • 一类属于需求开发
    • 需求调查
    • 需求分析
    • 需求定义
  • 一类属于需求管理
    • 需求确认
    • 需求跟踪
    • 需求变更控制

需求获取的方法

• 对现有的文档，表单和数据库进行抽样

• 研究和现场访问

• 对工作环境的观察

• 调查问卷

• 采访

• 原型设计（ProtoTyping）

  • 原型设计是交互设计师与PD、PM、 站开发工程师沟通的最好工具。而该块的设计在原则上必须是交互设计师的产物，交互设计以用户为中心的理念会贯穿整个产品。利用交互设计师专业的眼光与经验直接导致该产品的可用性。

  • 应该是按照已经有了的模板进行设计/p>

• 联合需求规划（Joint requirements planning，JRP）

如何进行需求分析

需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排出错误和弥补不足，确保需求文档正确地反映用户的真实意图

撰写《产品需求规格说明书》

需求分析方法有两类

• 文档分析法
• 建模分析法

问答分析法

• 问答分析最重要的问题是是什么和为什么
  • 每个需求都应当用陈述句说明”是什么”，如果“是什么”的内涵不够清晰，则应该补充说明“不是什么”
  • 追究“是什么”和“为什么”的目的是获得正确、清晰的需求

建模分析法

• 需求建模就是指用图形符 来表示，刻画需求
• 建模分析方法主要有两大类
  • 结构化分析法
  • 面向对象分析法
• 在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用

需求分析工具

• 业务流程图、泳道图：反映业务信息处理的具体过程

• WBS

• 用例驱动的分析

  候选流程反映了系统的健壮性，是区分系统设计好坏的一个前提，需要体现在活动图中

小结

好设计的十项原则

软件系统开发的十大原则

数据类型：指的是一个值的集合和定义在该值集上的一组操作的总称

抽象数据类型（ADT）：是指一个数学模型以及定义在该模型上的一组操作

数据建模的基本概念

• 数据建模：是一组组织和记录系统数据的技术，即数据库建模
• 实体关系图（ERD）：是一种利用符 标记实体与关系，实现对数据刻画的一种数据模型
• 实体：是我们需要收集数据与存储数据的人，地点，对象，事件或概念的类
• 属性：是实体的描述性的性质或特征，同义词包括要素，性质或域
• 组合属性：由其他属性组成的属性，它在不同的数据建模中有不同的名称：串联属性，合成属性，数据结构

属性的特征

• 数据类型：是属性的一个参数，定义了这个属性中可以存储什么类型的数据
• 域：是属性的一个参数，定义了这个属性可以取的合法数据值
• 默认值：如果用户没有指定值的话，将被记录的值
• 键：是一个属性（或一组属性），他们对每个实体实例具有唯一的值，也称为标识符
• 候选键：是一组可以作为一个实体主键的键，也称为候选标识符
• 主键：是最终用来唯一表示或者确定一个实体实例的候选键
• 替代键：是没有被选中作为主键的其他候选键

关系的特征

• 关系：是存在于一个或多个实体之间的业务联系
• 聚数：定义了一个实体相对于另一个关联实体的某个具体指的最大或最小具体值的数量
• 度数：是参与某一个关系的实体数量
  • 二维关系：两个实体之间的关系
  • 单一实体之间的关系，即递归关系
  • 页存在多个实体之间，即多维关系

外键的特征

• 外键，是一个实体的主键，但被复制到另一个实体以确定一个关系实例
  • 外键总是与另一个实体的主键匹配
  • 获得外键的实体为子实体
  • 提供外键的实体为父实体
• 非确定性关系：是每个参与关系的实体都有各自的独立主键关系
  • 不共享主键属性
  • 实体被称为独立实体（强实体）
• 确定性关系：是父实体提供其转称为子实体的主键的一部分的关系
  • 不共享主键属性
  • 子实体被称为关联实体（弱实体）
• 非特定关系：是一个实体的多个实例同另一个实体的多个实例相关联的关系，即多对多的关系

实体的泛化

• 泛化（Generalization）：是指将几类实体公共的属性组合成独立的实体
• 超类（SuperType）：是一个实体，其实例存储了一个或多个实体子类的公共属性
• 子类（SubType）：是一个实体，其实例从一个实体超类中继承了一些公共属性

信息工程设计核心视角

在软件系统中需要处理的数据是系那是世界中存在的事物及其联系的反映

人们通常将于数据处理有关的领域分为三个世界

• 现实世界
• 信息世界
• 数据世界

现实世界

现实世界是存在于人们头脑之外的客观世界，现实世界中的事务可分成对象和性质两大类

• 对象可以是人、是物，还可以是实际的东西或者概念
• 对象还可以指事务与事务之间的联系
• 性质则是指事务的性质或特征

信息世界

信息世界也叫做观念世界，是现实世界在人们头脑中的反映

• 客观世界中的事务在信息世界中叫做实体，反映事务之间联系的叫做实体模型
• 实体是由若干属性的属性值组成
• 属性是实体某一方面的特征，相应于事务的性质

数据世界

数据世界则是信息世界中信息的数据化，显示世界中的事务及其联系在数据世界中用数据模型描述

• 描述每一实体的数据称为记录，描述属性的数据叫做数据项或字段
• 与实体集相对的称为文件

信息工程设计的方法和原则

数据库设计的基本步骤

数据库设计分成6个阶段

• 需求分析
• 概念结构设计
• 逻辑结构设计
• 物理结构设计
• 数据库实施
• 数据库运行和维护

需求分析和概念设计独立于任何数据库管理系统

E-R方法和实体模型

Unique约束

外键约束

用例图

• 用例图是被称为参与者的外部用户所能观察到的系统功能的模型图
• 用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行

活动者(角色,Actor)：系统外部的参与者，可以是人、外部硬件、其他系统，甚至时间

关系

• 包含：基用例可以看到包含用例，并需要依赖于包含用例的执行结果
  • 当某个都会做片段在多个用例中都出现了的时候，可以将其分离出来从而形成一个单独的用例
• 扩展：使用扩展用例，可以在不改变基用例的同时，根据需要自由地向用例中添加行为

用例描述

类图

类图以反映类的结构(属性、操作)以及类之间的关系为主要目的，描述了软件系统的结构，是一种静态建模方法

类图中的事物及解释

从上到下分为三部分，分别是类名、属性和操作。类名是必须有的

活动图

描述系统的动态行为。包含活动状态(ActionState)，活动状态是指业务用例的一个执行步骤或一个操作，不是普通对象的状态。

时序图

顺序图用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。

顺序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。顺序图属于动态建模。

事务及解释

面向对象设计基本原则

• 单一职责原则
• 开放封闭原则
• 接口隔离原则
• 依赖倒置原则
• 李氏替换原则
• 合成/聚合复用原则
• 迪米特原则

接口分离原则