虽然写这个博客主要目的是为了给我自己做一个思路记忆录，但是如果你恰好点了进来，那么先对你说一声欢迎。我并不是什么大触，只是一个菜菜的学生，如果您发现了什么错误或者您对于某些地方有更好的意见，非常欢迎您的斧正！
目录
领域分析（domain analysis）：关心如何设计出一套准确简洁的、可以理解的和正确的现实世界的模型。
目的：阐明需求，为利益相关人和开发者之间的约定提供依据，而且要把模型当成设计和实现的出发点。
12.1分析概述
√分为两个阶段：
①领域分析：专注于理解问题的真实本质。
②应用分析：构建于领域模型之上——合并了用户可见的主要的应用程序制品，用户必须核准这些制品的使用权。
12.2领域类模型
√在分析过程中，类模型的优先级要高于状态和交互模型，这是因为静态结构易于被更好地定义，而且会较少地依赖于应用程序的细节，并且随着解决方案的逐渐完善也会越来越稳定。
√步骤：
寻找类→准备数据词典→寻找关联→寻找对象和链接的属性→使用继承组织和简化类→验证可能用于查询的访问途径→迭代并细化模型→重新考虑抽象的层次→把类分组打包
12.2.1寻找类
√类包括物理实体（如房屋、树），也包括概念（如座位分配、付款计划）。
√例如，你正在为图书馆创建目录和检出系统，那就要确定不同种类的资料，例如图书、报刊、唱片、录像等。
√图：ATM示例。查看第11章关于ATM的问题陈述（不看也没事），就可以确定以下的暂定类。
12.2.2保留正确的类
①冗余类：相同概念的类，保留最具描述里的那个。
②不相关的类：与问题关系不大或干脆无关。
③含混的类：边界定义比较模糊或过于宽泛。
④属性：着重描述独立对象的名称应该被重新声明成属性。
⑤操作：可以应用于对象但不可以被独立使用。
⑥角色：类的名称应该反映其本质特征，而不是反映它所扮演的角色。比如类Doctor、Teacher，都应该归为Person。
⑦实现制品：与真实世界无关的制品。
⑧派生类：忽略从其它类派生而来的类。
12.2.3准备数据词典
√准确描述每一个类的，包含关联、属性、操作和枚举值的一段话。
12.2.4寻找关联
√关联常常与静态动词或动词短语相对应。
√大部分直接选自问题陈述中的短语动词，有一些隐含在语句当中，有一些依赖于对真是世界的了解或假设。
12.2.5保留正确的关联
√被删除类之间的关联：删除或用其它类来描述。
√无关关联或实现关联：删除位于问题领域之外或处理实现制品的任何关系。
√动作：重新措辞。
√三元关联：拆分成二元关联。
√派生关联：忽略根据其它关联而定义的关联。
√命名不当的连接：谨慎。
√关联终端名：合适的地方添加。
√限定关联：限定符可以区分在关联中“多”放上的对象。
√多重性
√遗漏关联：增加任何被发现遗漏的关联。
√聚合
12.2.6寻找属性
√独立对象的数据特性。
12.2.7保留正确的属性
对象
限定符
名称
标志符
关联上的属性
内部取值
细节
不整合的属性
布尔属性
12.2.8使用继承来细化
自下而上的泛化
自上而下的转化
泛化对枚举
多重继承
相似的关联
调整继承的层次
12.2.9测试访问路径
12.2.10迭代类模型
12.2.11变换抽象的层次
12.2.12把类组织成包
12.3领域状态模型
确定具有状态的领域类 → 寻找状态 → 寻找事件 → 构造状态图 → 评价状态图
12.4领域交互模型
12.5将分析迭代
细化分析模型 → 重述需求 → 分析和设计
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
