《大象》学习小结

[b][color=red]开篇语[/color][/b]：
[b]商业系统无论多复杂，无论什么行业，其本质无非是人、事、物、规则。DDD四色模型？[/b]

[b][color=red]活动图[/color][/b]：
在获取基础业务需求后，对用例场景进行建模：使用活动图虽然有争议，因为是面向过程的，但是对我们获得概念用例、角色和业务对象(业务实体)有着很好的帮助。
1.帮助发现概念用例
2.帮助发现角色(业务主角或业务工人)，通过泳道
3.帮助发现业务实体
4.帮助建立领域模型([b]若在用例场景的不同活动中多次出现某一个名词，要注意该名词，它很可能就是一个关键业务对象，由它与其它对象之间的关系可构建出一个领域模型[/b])

[b][color=red]状态图[/color][/b]：
用于对模型元素的动态行为进行建模，通常用状态图来说明业务角色或业务实体可能的状态--导致状态转换的事件和状态转换引起的操作。
我们可以用状态图来描述业务实体对象、分析类对象和设计类对象。
[b]需要注意的是状态图通常只用于描述单个对象的行为[/b]，如果要描述对象间的交互，最好采用时序图或协作图。

[color=red][b]时序图[/b][/color]：
用于描述按时间书序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。包含了对象和主角实例，以及说明它们如何交互的消息。[b]使用时序图来描述用例实现是一种从现实世界到对象世界的映射方法，它对我们确定对象职责和接口有着显著的作用，而对象的核心就是职责和接口。[/b]

[b][color=red]系统用例建模[/color][/b]：
获得系统用例的基本方法是分析业务用例场景，尤其是活动图。一开始，[b]可以简单的把每个泳道里的活动都作为一个用例，以泳道作为参与者[/b]，把它们绘制出来.

[b][color=red]领域模型[/color][/b]：
其实，[b]使用UML建模并非一定需要用例[/b]。只有在交互密集型的软件里，用例才能发挥其作用。在非交互密集的软件里，由于参与者很少，获取用例意义并不大。这时最适合的是为问题领域建立领域模型(不包括使用者信息和使用过程的模型)。[b]通常，领域模型会跨多个用例，而领域模型最重要的工作，就是描述关键业务对象的行为和交互方式。[/b]

[b][color=red]分析模型[/color][/b]：
[b]分析类用于获取系统中主要的“职责簇”。笔者认为分析模型是面向对象的核心。[/b]
分析类在对象世界和现实世界中精妙的对应关系：人、事、物、规则--参与者、边界类、实体类、控制类。