analysis
仅仅从用户的需求来看得到的消息不全面，还需要分析。用户可能认为你明白了，或者他考虑不全面，觉得一些地方是不需要的。
因此我们需要分析来 Refining requirements。
gather requirements-analyse in real world context-develop the architecture
分析包括：Textual analysis (针对文档分析)，Entities and concepts（应用层面分析），Experience（过往经验分析）
conceptual model
面向对象的UML图。
边界类用于系统外部环境与内部交互进行建模的类。我的理解是不同系统之间的胶合层。能够减少系统之间的耦合。
控制类用于对一个或几个用例所特有的控制行为进行建模。控制类源于对用例场景中行为的定义。
实体类是对必须存储的信息和相关行为建模的类。
UML-分析类_Iron_Sky的博客-CSDN博客
attributes: 属性和相应数据类型。比如姓名，字符串。
Operations：行为方法。一个operation一般只做一件事。
relationships: – Association – Inheritance.
- associations 指两个类之间存在双向联系。比如一个老师教多个学生。有1对1,1对多等关系。
- Inheritance 继承，父类泛化子类特化。
Activities:
- Identify Entity, Boundary and Control classes
- Identify class relationships
- A conceptual class diagram
- Identify attributes for each entity class
- Add constraints
design
design 是把分析模型转换成设计模型，不是代码实现！implementation才是实现。
design must have a purpose: how things works.
A software design: enough information for a development team to implement the solution.
roles
- finish non-functional requirements
- break down the overall task.
- Create a ‘skeleton’ of the system 创建易于实现的骨架结构。
Fundamental Concepts
- Abstraction：抽象类和行为的功能。
- Encapsulation：information hiding。限制某些对象对内容的直接访问。
- Modularity：封装成模块，提供接口给其他模块。
- Coupling：耦合，模块间关系紧密程度。最好是loose 松耦合，这样不容易牵一发而动全身。
- Cohesion：内聚，模块内部自己元素的相关度。最好是high的。
- Refactoring：在代码正常完成要求的前提下修正代码减少重复。主要改进非功能属性。
面向对象设计的好处：对象就是实体；对象可以重用，继承；有的系统对象是现实世界的明显映射。
steps
conceptual class diagram
Class Relationships
operations
Describing methods
Captures implementation requirements
Produce detailed design class diagram
Implementation
分析和设计阶段基本上把创意都列出来了。实现就是比较机械地按照前面的设计去敲代码。
利用一些组件去实现。组件主要包括：excutable 可执行文件，file 源码和数据，document，table 数据库表。
implementing subsystem 实现部分功能，利用打包功能导出一个有接口的模块.
Integration Build Plan 迭代构建项目,每次构建指出构建实现的功能和构建需要的子系统、组件。
OOP：有类，对象，方法。但是关联不是双向的，而是只能单向的，比如：
一对多可以在一个类里包含另一个类的一个对象集合。
类的实现要从最小耦合到最大耦合 least coupled to most coupled。
Testing
在交付给用户前尽可能发现错误，验证每个阶段的结果。测试占据了40%。
组件层面：开发者测试。
集成测试：测试工程师，专注于质量。
- Validation testing：验证测试，测试系统正常需求已经满足。
- Defect testing：检测系统的缺陷。
Testing policies
我们不可能把所有可能情况都找到并且测试出来。因此只能选取有代表性的子集。
好的测试：测试人员能预料到可能哪里出错；没有多余的测试用例；应选取“最可能出错”的用例；合适的复杂程度。
test case：输入的规范和预期的输出。
test data：输入。
testing strategy
what 测试用例？when 测试？how to 测试？如何比对输出是否正确？
test cases 示例（正确的输入。错误的输入比如学号输入英文）：
Test Procedures 测试程序，通常设置为可通用的，便于之后修改重用。这个程序不一定是代码，可能以流程指导的形式（比如按下login按钮，输入账号99001122登录……）
test matrix:
发现缺陷：比如上例，错误的密码也能登录，于是测试工程师把错误信息返回给开发者：
Testing: Techniques
黑盒测试，black box/behavior test，即我们要测试的模块，对我们来说像一个内部结构不可见的黑盒子，我们重点关注他行为对不对，与外界的接口是否正确，访问外界数据库正不正确。
- Partition testing：典型的黑盒测试，把数据分成等效的几个区域，比如正数负数0.
- Scenario-based testing：从用户角度触发，分析用户可能的正确和错误操作。
- Regression Testing：集成测试，随着添加增量也不断添加新测试，每次运行所有测试用例，确保系统更新的时候以前的功能没有受干扰。
白盒测试，white/glass/clear box test，主要关注程序内部结构按规范运行，所有内部组件都正确。
确保盒内的所有路径都被正确执行过；考虑正确和错误用例；在边界内外测试；尽量使用内部数据结构。
- Basis Path Testing：执行所有路径的最少用例数。
总体测试流程：白盒测试，建立 test harness 测试装置，测试正确性，测试健壮性；然后黑盒测试。
TDD
assertEquals(20, student.getAge());//判断返回值是不是20岁
在开发代码前编写测试。 simple, short-cycled mechanism。
small cycle：编写测试，编写代码，测试失败，修改代码，测试通过。
