[]北邮面向对象课程7第七章细化迭代1：分析.pptVIP

第七章 细化迭代1：分析 吴建林 jlwu@ 提纲 §7.1 用例模型：绘制系统顺序图 §7.2 领域模型：可视化概念 §7.3 领域模型：添加关联 §7.4 领域模型：添加属性 §7.5 用例模型：用操作契约增加细节 §7.6 迭代中的从需求到设计 §7.1 用例模型：绘制系统顺序图 用例图表达了角色使用系统的目标，那么角色是如何激活系统操作满足其目标的呢？ 面向对象思想中，通过事件激活。 系统事件有哪些？?系统顺序图（SSD） 系统顺序图用于说明与系统相关的输入和输出事件，它是系统行为的一部分。 系统行为描述系统做什么，不解释系统如何做，由三部分组成： 用例 系统顺序图（描述系统事件） 系统契约（处理系统事件的操作执行规范） §7.1 用例模型：绘制系统顺序图 系统顺序图： 针对特定用例的主要成功场景以及频繁或复杂的替代场景而设计的； 描述外部角色与系统（作为一个黑箱）之间交互的事件； 本次迭代主要考虑主要角色产生的事件； 也可以描述次要角色接收系统产生的事件。 描述事件的顺序。 §7.1 用例模型：绘制系统顺序图 §7.1 用例模型：绘制系统顺序图 §7.1 用例模型：绘制系统顺序图 §7.2 领域模型：可视化概念 用例模型：强调领域的过程视图 领域模型： 是现实世界（问题域）概念类的一种可视化表示，它不是软件组件的一种表示，不是描述软件类的图集，也不是有着职责的软件对象。 概念类的识别是问题域调研工作的一部分。 别名：概念模型、领域对象模型、分析对象模型。 可以用不定义操作的一组类图来说明 领域对象或者概念类 概念类之间的关联 概念类的属性 §7.2 领域模型：可视化概念 §7.2 领域模型：可视化概念 领域模型不是软件组件模型 §7.2 领域模型：可视化概念 识别概念类 指导原则： 只针对当前迭代的用例场景识别概念类，不要牵涉更多的情况。? 部分领域模型 用大量细粒度的概念类充分描述领域模型比粗略描述要好。 无属性的概念类，或者在问题域中仅担当行为的角色而非信息的角色的概念类，都可以是有效的概念类。（比如：销售、支付） 识别策略： 1.使用概念类分类列表 2.识别名词短语 §7.2 领域模型：可视化概念 §7.2 领域模型：可视化概念 根据名词短语识别找出概念类 用例是通过名词短语识别领域概念的丰富源泉，因此，应该详述用例。 名词可以是概念类，也可能是概念类的属性。 属性一般是可以赋值的，比如数字或者文本，该名词可以这样赋值吗？ 如果不行的话，那么就有可能是一个概念类。 §7.2 领域模型：可视化概念 领域模型创建步骤： 1.用概念类分类列表和名词短语识别方法找出当前需求中的候选概念类； 2.在领域模型中描述这些概念类。 用问题域中的词汇对概念类进行命名； 将与当前需求无关的概念类排除在外； 不用描述非问题域中的概念。 §7.2 领域模型：可视化概念 3.在概念类之间添加必要的关联来记录那些需要保存记忆的关系。 4.添加用来实现需求的必要属性。 §7.3 领域模型：添加关联 关联通常意味着我们必须知道这个关系的存在，并且这个关系需要保存一段时间，时间的长短取决于关联所处的语境。 领域模型中需要考虑下面的关联： 需要将概念之间的关系信息保持一段时间的关联－需要知道（need-to-know）型关联 从通用关联列表中派生出的关联。 §7.3 领域模型：添加关联 §7.3 领域模型：添加关联 关联的指导原则： 将注意力集中在那些需要将概念之间的关系信息保持一段时间的关联（需要知道型关联）。只需理解型关联反映了理解概念类所需的本质信息。 根据“需要知道型”原则获取最小集合的关联，然后利用“只需理解型”关联增强对领域中关键概念的理解。 识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。 太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。 避免显示冗余或导出关联。 §7.4 领域模型：添加属性 领域模型中包含的属性：需求（用例）建议或者暗示我们需要记忆的那些信息。 有效属性类型原则： 概念模型中的属性应当被优先定义为简单属性或数据类型。 如：boolean、date、number、string、text、time，其他常见的简单数据类型如：address、color、zip等。 用关联而不是用属性来联系概念类。避免用属性表达一个复杂的领域概念，用关联。 §7.4 领域模型：添加属性 §7.4 领域模型：添加属性 属性应该是数据类型，因此，用来标识属性唯一性身份的值是没有意义的属性。 如果属性的数据类型是有结构的，应该采用非原始数据类型类。 由可以分开的段组成的数据：电话号码 经常对该数据进行分析和验证：身份证 包含其他属性的数据：促销价格有有效期 带有单位的数量值：