谈谈软件开发的那些事儿 笔记

需求分析----用例-----
用例模型:由三部分组成，用例、参与者和系统边界。用例模型是软件需求分析的开始，是即能让客户看懂又能让技术人员看懂的图形和文字。一方面是为了进一步与客户交流，确认需求，另一方面也是为技术人员分析和设计系统提供依据和基础。


用例就是一个用来描述参与者如何使用系统来实现其目标的一组场景的集合。将用户所要描述的整个问题空间分割成了一个又一个的模块，然后在每个具体模块下再进一步的描述问题。使用用例的另一个作用就是将客户粗犷的需求描述，转换成了非常严谨的语言表述，详细描述清楚了场景中每一个操作流程的整个过程。同时，该描述中用到的专业词汇的外延与内涵都必须表述清楚，避免出现二义性
eg:ATM机上操作是一组场景，也就是银行管理系统中的ATM机管理子模块。它可以继续细分成ATM机取款、ATM机查询、ATM机转账等多个场景，也就是ATM机管理子模块下的取款、查询、转账等功能，它们的每一个也就是用例图中的一个个子用例
参与者:给大家最直观的认识就是操作系统的那些人，但更准确的说应当是操作系统的那些角色
系统边界:系统边界是一个软件系统需要处理的整个问题空间的范围。一个软件系统不可能处理所有问题，我们必须得给它定义这个问题空间的范围。哪些是我们这个软件可以处理的，哪些则是我们这个软件不能处理的，也就是项目管理中所说的项目范围。


需求分析----领域模型----
领域模型：是对业务领域的如实描述，他不包含任何技术实现，也不包含任何分析设计。领域模型关注的是业务领域中的重要概念及其相互之间的关系。领域模型关注的不是业务领域中的所有概念及所有关系。它关注的是对我们要开发的软件系统有用的概念及其关系
系统分析员在需求分析阶段，除了建立和编写用例模型以外，还并不足以支持我们后来的系统分析与设计，他还应当建立领域模型。领域模型是在与客户交流的过程中，整个问题空间包含的所有重要概念，及其相互关系的表述。在领域模型中，问题空间又被表述为业务领域。而业务领域中的所有重要概念被描述成了一个又一个的对象或属性
eg:学籍管理是学籍管理系统的业务领域，在这个业务领域中的学生被描述成了“学生”对象，而学生的姓名被描述为“学生”对象中的“姓名”属性。然而，学生的家庭住址，根据客户的要求，即可以描述为“学生”对象中的“家庭住址”属性，也可以描述为另一个“家庭住址”对象并包含“城市”、“街道”、“通讯地址”和“邮编”等属性。由此可见，领域模型是一堆类图


领域模型应当是一个又一个的场景，我们是在某个场景下描述它的相关概念和关系


分析设计----分析模型----
分析设计阶段的主要工作就是建立分析模型。建立分析模型的工作非常繁杂，它是OOA/D的开始，它需要对需求分析中的每个场景建立静态模型（一系统的类图或对象图，描述系统需要建立的各种类及其相互之间的关系）和动态模型（一系统的行动图、序列图、状态图，描述系统中的所有流程，包括主流程、分支流程，以及流程中各种对象的调用关系，对象在流程中的状态变化）。建立分析模型的工作是一个迭代的过程，起初的迭代是需求的如实描述，接着开始GRASP设计模式以及其它的OO分析理论，对静态模型和动态模型进行优化，寻找更灵活多变、易于维护、高内聚、低耦合的设计方案
分析模型应当是站在整个系统的高度来看待设计中的每个场景，它必须充分考虑各个模块的协作以及公共代码的复用。因此，那些各个模块都要使用的功能和业务逻辑被提取出来。但是，分析模型与设计模型最大的区别是，它不包含任何实际的技术。你的系统不论采用J2EE来实现，还是.Net来实现，分析模型都是一样的。它也不关注你是采用两层结构还是三层结构，采用的Oracle还是SQL Server数据库，这些都不是它关心的


分析设计----设计模型----
分析模型经过数次迭代以后就逐渐过渡到设计模型，并没有一个明确的鸿沟。设计模型的重要区别就是它开始考虑到各种具体的技术。设计模型的产出物就是通过Rational Rose这样的工具正向生成为我们要设计的代码
分析设计是系统分析员完成的，而程序设计是程序员完成的。如果设计模型做得太细了，对系统分析员是一个巨大的工作量，而把好多程序员的工作给做了，同时，对程序员的束缚过大。如果当初的设计存在缺陷，将必须返回系统分析员重新修改设计模型，费时费力，得不偿失。所以我认为，设计模型不宜太细，从整体上把握主要部分就可以了


----程序设计----
序员在设计程序的过程中可以自己设计自己的设计模型，这时我们常说的GoF设计模式可以派上用场了。它对我们提高设计水平和代码质量大有帮助

程序员在设计程序的过程中可以自己设计自己的设计模型，这时我们常说的GoF设计模式可以派上用场了

参考：http://fangang.iteye.com/blog/486355