需求分析到软件设计复习
什么是需求分析？
需求分析就是需求分析师对用户期望的软件行为进行表述。
谁来表述 -> 需求分析师
谁有期望-> 用户
期望什么？-> 期望的软件行为
怎样表述？-> 在获取需求的基础上，用对象或实体的状态、属性和行为来进行准确描述和建模。
需求的类型
功能需求：根据所需的活动描述所需的行为
非功能需求：软件必须具备的一些质量特性
设计约束：决策时的约束，如选择平台和接口组件
过程约束：可用构建系统的技术或资源的限制
需求分析的两种方法
1.原型化方法
由用户与开发者共同确定系统的基本要求和主要功能，由于有用户的参与，可以很好的整理用户接口。
2.建模的方法
给出事件发生的时序和活动约束，逻辑上形成模型来整理需求细节。
高质量的需求是什么样子？（九点）
1.需求可测试
2.冲突可解决
3.正确性、持续性、无二义性、完整性、可行性、相关性，Traceable
用例满足的四个必要条件（准确提取用例的基本方法）
1.寻找业务领域的动名词或动名词短语
2.验证该动名词是不是用例
- 它是不是一个业务过程？
- 它是不是由某个参与者触发
- 它是不是显式或隐式的终止与某个参与者？
- 它是不是为某个参与者完成了有用的业务工作？
3.在需求中识别出参与者、系统或子系统
统一过程的核心要义是什么
- 用例驱动
- 以架构为中心——保持软件架构相对稳定，减少架构层面的重构
- 增量且迭代
敏捷统一过程的四个关键步骤
敏捷统一过程将软件过程中的迭代过程进一步分为计划阶段和增量阶段。主要有四个关键步骤
-------------------------------计划阶段------------------------------
-
确定需求
-
通过用例来满足需求
-
分配用例到各个增量阶段
------------------------------增量阶段-------------------------------
- 具体完成各增量阶段所计划的任务。
敏捷统一过程增量阶段的五个步骤
- 用例建模
- 业务领域建模
- 对象交互建模
- 形成设计类图
- 编码和部署
用例的三个抽象层级（用例建模的基本步骤）
----------------计划阶段-----------------------
抽象用例——一个简单的动名词短语指明
高层用例——用例在什么时候什么地方开始，以及在什么时候什么地方结束
（按照子系统或者系统的不同方面进行分类，描述用例与用例，用例与参与者之间的上下文关系，画出用例图）
---------------增量实现阶段------------------------
扩展用例——将参与者和待开发系统的交互过程一步步详细描述。
业务领域建模的基本步骤
- 收集业务领域信息
- 头脑风暴
- 对相关业务领域的概念进行分类，找出关联关系，引入关联类
- 用UML类图画出来
对象交互建模的四个基本步骤
对象交互建模是在扩展用例的基础上完成如下步骤：
- 在扩展用例右侧找到关键步骤
- 对每一个关键步骤，完成剧情描述
- 将剧情描述转换成剧情描述表
- 将剧情描述表转换成时序图
形成设计类图的基本步骤
-
识别每个序列图中使用的所有类，并将它们记录在设计类图中
-
确定属于每个类的方法并将其填入设计类图
-
识别并填写序列图和域模型中的属性
-
识别并填写序列图和域模型中的关系
形成软件设计方案的基本方法
分析
----分解大问题变为易于理解的小问题
综合
----将一个个小问题的解决方案整合起来构建整体解决方案。
MongoDB
ACID——原子性，一致性，隔离性，持久性
一对多建模需要考虑的情况：一对很少，一对许多，一对非常多。
- 一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方。（优先考虑，如果需要单独访问则不能内嵌）
- 一对很多且很多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的。（数组不能无限制增大）
- 一对非常多的情况下，请将一的那端引用嵌入进多的一端对象中。
反范式化：——>先确认读写比
- 在一个读写比高的多的系统里，反范式是有使用的意义的。
- 一旦你冗余了一个字段，那么对于这个字段的更新将不再是原子的
