《大象 Thinking in UML》学习笔记（十三）——在提炼中思考
一、理解用例的本质
用例是系统思维
系统是一个封闭的、由一系列相互关联、相互影响的物质构成的集合。所谓系统思维，就是考虑系统内事物的互相影响，归纳、抽象系统内的运行规律。
软件不是孤立存在的，在设计时我们必须将软件置于它所处的系统环境中：使用者、硬件、网络、应用环境等，并采用系统思维来分析和设计它。
用例具有系统性：
用例是相对独立的；
不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例；
用例的执行结果对参与者来说是可观测的和有意义的；
用例必然是以动宾短语形式出现的。
用例是面向服务的
面向服务架构的第一条准则是：业务驱动服务，服务驱动技术。
SOA的开发过程与用例的分析过程也有着极高的相似程度。
二、理解用例驱动
用例与项目管理
在项目管理中，工作包占据了非常重要的地位。
在UML里，系统用例实现就是项目管理中的工作包。
项目管理中，一个工作包的工作量控制在1至2个人周是比较容易控制的；在系统用例里，如果工作量大于这个时间，则需要通过用例实现来减少每个工作包的工作量。
用例与可扩展架构
业务驱动技术，一个好的可扩展架构是基于好的业务架构之上的。
业务架构从用例而来，每个用例定义了参与者对系统的要求，而业务系统，则需要将这些相对独立的业务单元结合起来，形成更大的业务。
在需要扩展的系统里，用例与用例之间必须避免紧耦合。
可扩展架构，其关键就在如何定义每个用例的接口，以及如何使用是和的技术架构来保证业务单元之间的交互来提供可扩展能力。
用例不但驱动软件过程，也驱动技术架构。
三、理解建模的抽象层次
将事物按层次划分是人们归纳和理解事物的重要形式。
层次不交叉，在描述事物的过程中，同一层的描述内容是“等值”的。
在进行分析设计之前，应当根据业务的复杂程度事先决定需要用多少个抽象层次来描述，并定义每个抽象层次要解决的业务问题，或者说定义每个抽象层次的关键特征。
UML建模是以用例为基础的，用例的粒度则和抽象层次直接相关，
四、划分子系统的问题
计算机子系统描述了一个软件的内部构成，它的划分依据是对象依赖，目标是构建扩展下好的软件结构；
业务子系统描述的是软件的展现形式，以用户部门或者业务为依据进行划分。
用户所谓的子系统，只是软件展示出来的样子，从面向对象的观点来看，软件内部应当维持最佳的对象结构，然后通过接口向外部展现外部所需要的样子。
五、学会使用系统边界
对象是由边界来“封装”的，接口正是边界的体现。
描述系统时候，边界用来定义系统的范围，因为系统是由用例表示的，系统边界由用例构成。
描述用例时候，边界类是用例与外界的唯一通道，边界类“封装”了用例，用例边界由边界类来决定。
描述对象时候，对象封装的结果是出现了一组接口方法，对象的边界由这边接口方法约束。
根据系统的复杂程度、业务需求规模大小决定用例的粒度，用边界分析的方法可以帮助确定用例的粒度。
边界分析的方法主要有两种：一种是根据业务从整体到局部；另一种是按照人边界和物边界进行划分。
采用边界分析方法进行分析，可以得到封装度极好、接口处清晰明了、抽象层次井然有序的分析结果。
六、学会从接口认识事物
人们认知现实世界和认识软件的过程是一致的，是从接口（表象）来认识对象而不是从对象内部（本质）来认识对象的。
将边界分析得到的结果中，每个边界都用接口来替代，就可以确定整个系统行为。
七、学会正确选择
一个系统有多个涉众，也有多个指标，所以对系统有多种期望和多个要求。所以即使在明确的期望和要求下，也需要变换立场来审视问题，做出取舍和平衡，得出最合理的设计。
此时可以用SWTO分析方法来进行判断。
S：stretch（优点）
W：weakness（缺点）
T：threat（威胁）
O： opportunity（机会）
在需求分析和设计过程中，我们也需要改变立场来获得对需求更为深入的理解。
在需求分析中过程，我们还可以多次变换视角，通过边界的改变得出不同参与者与不同用例。
八、学会使用设计模式
设计模式是面向对象设计原则和方法的应用，是在具体实践过程中解决某类问题而产生的经验总结和最佳实践。
要使用好的设计模式首先要打好基础，即你已经完全掌握了设计模式的意图和适用性。
用例是系统思维
系统是一个封闭的、由一系列相互关联、相互影响的物质构成的集合。所谓系统思维，就是考虑系统内事物的互相影响，归纳、抽象系统内的运行规律。
软件不是孤立存在的，在设计时我们必须将软件置于它所处的系统环境中：使用者、硬件、网络、应用环境等，并采用系统思维来分析和设计它。
用例具有系统性：
用例是相对独立的；
不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例；
用例的执行结果对参与者来说是可观测的和有意义的；
用例必然是以动宾短语形式出现的。
用例是面向服务的
面向服务架构的第一条准则是：业务驱动服务，服务驱动技术。
SOA的开发过程与用例的分析过程也有着极高的相似程度。
二、理解用例驱动
用例与项目管理
在项目管理中，工作包占据了非常重要的地位。
在UML里，系统用例实现就是项目管理中的工作包。
项目管理中，一个工作包的工作量控制在1至2个人周是比较容易控制的；在系统用例里，如果工作量大于这个时间，则需要通过用例实现来减少每个工作包的工作量。
用例与可扩展架构
业务驱动技术，一个好的可扩展架构是基于好的业务架构之上的。
业务架构从用例而来，每个用例定义了参与者对系统的要求，而业务系统，则需要将这些相对独立的业务单元结合起来，形成更大的业务。
在需要扩展的系统里，用例与用例之间必须避免紧耦合。
可扩展架构，其关键就在如何定义每个用例的接口，以及如何使用是和的技术架构来保证业务单元之间的交互来提供可扩展能力。
用例不但驱动软件过程，也驱动技术架构。
三、理解建模的抽象层次
将事物按层次划分是人们归纳和理解事物的重要形式。
层次不交叉，在描述事物的过程中，同一层的描述内容是“等值”的。
在进行分析设计之前，应当根据业务的复杂程度事先决定需要用多少个抽象层次来描述，并定义每个抽象层次要解决的业务问题，或者说定义每个抽象层次的关键特征。
UML建模是以用例为基础的，用例的粒度则和抽象层次直接相关，
四、划分子系统的问题
计算机子系统描述了一个软件的内部构成，它的划分依据是对象依赖，目标是构建扩展下好的软件结构；
业务子系统描述的是软件的展现形式，以用户部门或者业务为依据进行划分。
用户所谓的子系统，只是软件展示出来的样子，从面向对象的观点来看，软件内部应当维持最佳的对象结构，然后通过接口向外部展现外部所需要的样子。
五、学会使用系统边界
对象是由边界来“封装”的，接口正是边界的体现。
描述系统时候，边界用来定义系统的范围，因为系统是由用例表示的，系统边界由用例构成。
描述用例时候，边界类是用例与外界的唯一通道，边界类“封装”了用例，用例边界由边界类来决定。
描述对象时候，对象封装的结果是出现了一组接口方法，对象的边界由这边接口方法约束。
根据系统的复杂程度、业务需求规模大小决定用例的粒度，用边界分析的方法可以帮助确定用例的粒度。
边界分析的方法主要有两种：一种是根据业务从整体到局部；另一种是按照人边界和物边界进行划分。
采用边界分析方法进行分析，可以得到封装度极好、接口处清晰明了、抽象层次井然有序的分析结果。
六、学会从接口认识事物
人们认知现实世界和认识软件的过程是一致的，是从接口（表象）来认识对象而不是从对象内部（本质）来认识对象的。
将边界分析得到的结果中，每个边界都用接口来替代，就可以确定整个系统行为。
七、学会正确选择
一个系统有多个涉众，也有多个指标，所以对系统有多种期望和多个要求。所以即使在明确的期望和要求下，也需要变换立场来审视问题，做出取舍和平衡，得出最合理的设计。
此时可以用SWTO分析方法来进行判断。
S：stretch（优点）
W：weakness（缺点）
T：threat（威胁）
O： opportunity（机会）
在需求分析和设计过程中，我们也需要改变立场来获得对需求更为深入的理解。
在需求分析中过程，我们还可以多次变换视角，通过边界的改变得出不同参与者与不同用例。
八、学会使用设计模式
设计模式是面向对象设计原则和方法的应用，是在具体实践过程中解决某类问题而产生的经验总结和最佳实践。
要使用好的设计模式首先要打好基础，即你已经完全掌握了设计模式的意图和适用性。