|
|
|
9.3.1节从用户的观点对系统进行了用例建模，但获得了用例并不意味着分析的结束，还要对需求进行深入研究，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信实现系统行为（动态模型）。
|
|
|
|
为了使模型独立于具体的开发语言，需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起始点就是领域模型。领域模型又称为概念模型或域模型，也就是找到代表那些事物与概念的对象，即概念类。概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。在迭代开发过程中，每一个用例对应一个类图，描述参与这个用例实现的所有概念类，用例的实现主要通过交互图来表示。
|
|
|
|
|
|
（1）发现领域对象，定义概念类。发现类的方法有很多种，其中最广泛应用的莫过于“名词动词法”。它的主要规则是从名词与名词短语中提取对象与属性；从动词与动词短语中提取操作与关联；而所有格短语通常表明名词应该是属性而不是对象。
|
|
|
|
（2）识别对象的属性。属性是描述对象静态特征的一个数据项。可以与用户进行交谈，提出问题来帮助寻找对象的属性。属性是概念类所拥有的特性，从概念建模的角度看，属性越简单越好，要保持属性的简单性，应该做到4个方面：仅定义与系统责任和系统目标有关的属性；使用简单数据类型来定义属性；不使用可由其他属性导出的属性（冗余属性）；不为对象关联定义属性。最后，要对属性加以说明，包括名称和解释、数据类型，以及其他的一些要求。
|
|
|
|
（3）识别对象的关系，包括建立类的泛化关系、对象的关联关系。理清类之间的层次关系，决定类之间的关系类型，确定关系的多重性和角色的导向性。多重性指定所在类可以实例化的对象数量（重数），即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联；导向性表示可以通过关联从源类导向到目标类，也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。
|
|
|
|
（4）为类添加职责。找到了反映问题域本质的主要概念类，而且还理清它们之间的协作关系之后，我们就可以为这些类添加其相应的职责。类的职责包括两个主要内容，分别是类所维护的知识、类能够执行的行为。可以使用状态图来描述系统中单个对象的行为。
|
|
|
|
（5）建立交互图。多个对象的行为通常采用对象交互来表示，UML 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。
|
|
|
|
：在整个开发的过程中，分析模型是不断演变的，最初的分析模型主要是围绕着领域知识进行的，对现实的事物进行建模。而后，则不断地加入设计的元素，演变成为运行于计算机上的架构和结构。其演变过程中最主要的变化体现在以下3个方面：
|
|
|
|
（1）根据鲁棒分析和交互分析的结果，补充类的属性和操作，不断地细化其内容，更细致地刻化类之间的关联关系，以便体现代码的核心。
|
|
|
|
（2）添加许多与计算机实现相关的技术类，以体现系统的实现结构。
|
|
|
|
|
