四、面对对象方法学介绍(续)
5、UML-物理框架
系统架构：逻辑架构；物理架构。
逻辑架构：描述系统功能。用例图、类图、对象图、状态图、活动图、协作图、顺序图。
物理框架：关心的是实现。类和对象物理上分布在那个程序或进程中；程序进程在哪台计算机上运行；系统有哪些硬件设备，如何连接。用构件图和配置图。
(1)构件图(Component Diagrams)
构件图（Component Diagrams）展现了一组构件的类型、内部结构和它们之间的依赖关系。构件代表系统一物理实现块，一般作为一独立文件存在。
构件种类：部署构件 工作产品构件 执行构件
- 部署构件：是构成一可执行系统必要构件，如操作系统，Java虚拟机。
- 工作产品构件：开发过程产物，包括源代码文件及数据文件。构件不直接参与可执行系统，用来产生可执行系统的中间工作产品。
- 执行构件：构成一可执行系统必要构件，动态链接库、exe文件、CORBA构件、.net构件等。
解析：虚线箭头：依赖关系，这些是执行构件的执行关系。
(2)配置图(Deployment Diagrams)
配置图（Deployment diagram）描述了系统硬件和软件物理配置情况和系统体系结构，显示系统运行时刻的结构。
配置图包含结点和连接两个元素，配置图中的结点代表实际的物理设备以及在该设备上运行的构件和对象，结点的图符是一个立方体。
配置图各结点之间进行交互的通信路径称为连接。用结点间的连线表示。
6、UML扩展机制
利用扩展机制，用户可定义使用自己的模型元素。
(1)UML扩展机制-标签值
标签值是存储元素相关信息字符串，可附加在任何独立元素（图形元素、视图元素）。标签是建模人员需要记录某些特性的名称；值是给定特性的值。
标签值对项目管理特别有用，如元素创建日期开发状态、完成日期和测试状态。 标签值用｛｝扩起。
(2)约束
约束是用文字表达式表达的语义限制，对声明全局的或影响大量元素的条件特别适用。
约束表示为括号中的表达式字符串，附加在类、对象、关系上和注释上等。
(3)版类
版类（版型）在模型本身中定义的一种模型元素，UML元素具有通用语义，利用版类进行专有化和扩展，在已有元素上增加新语义。
版类用放置在基本模型元素符号中或附近的被《》括起的文字串显示，还可为特殊版型创建图标，替换基本元素符号。
7、UML实例
总用例图–>各种子用例图–>各种顺序图–>各种协作图–>各种类图–>生成类核心代码
例如：拟开发一软件，完成学校管理中的教务部门功能，包括班级管理、课程管理、帐户管理等，要求用UML建模。
………等等顺序图+协作图
7、uml建模工具
StarUML
亿图图示专家
Software Ideas Modele
RGui
Astah
Argo UML
五、面对对象方法学分析
1、分析过程
面向对象分析过程：获取需求、整理需求、建立模型、书写需求规格说明书、复审。
- 获取需求：获取需求和传统方法下需求分析一致不再赘述
- 整理需求：整理需求传统方法也类似。书写需求陈述；需求陈述内容包括问题范围，功能需求，性能需求，应用环境及假设条件。
- 建立模型：面向对象分析模型由三个独立模型组成
- 功能模型：指明系统应“做什么”，由“用例图”表示。
- 对象模型：描述静态结构, 定义做事情实体，类图和对象图表示。
- 动态模型：描述交互过程, 由状态图和顺序图表示。
需求陈述：
某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。
总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。
银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。
柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。
拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。
所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。
每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。
当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。
首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。
中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。
如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。
2、功能模型
功能模型用用例图表达，研究需求陈述建立用例图。
步骤：
1.识别外部执行者；
2.识别用例；
3.建立用例图；
4.补充用例描述：为建立对象模型和动态模型打基础。
从需求分析中要点提取：
- 银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。
- 拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。
补充用例描述：为建立对象模型和动态模型打基础。
参与者:就是使用这
前置条件:使用前提
触发器:什么时候出发
替代事件过程：出现问题怎么办
3、对象模型
建立对象模型步骤：
(1)确定分析类
1、找出候选分析类
确定边界类：通常，一参与者与一用例间交互或通信关联对应一边界类
识别实体类：实体类通常是用例中的参与对象，对应着现实世界中“事物”
- ①提取需求陈述中名词
- ②筛选出正确的类：将冗余、无关、笼统、属性、操作进行合适的删除或者合并操作
(2)确定类的关联
初步确定关联：动词或动词词组、隐含关联、与用户及领域专家讨论补充。
- ①直接提取动词短语
- ②找需求陈述中隐含的关联
- ③根据问题域专业知识得出的关联
- ④筛选
- 删除已删去类之间关联
- 与问题无关或与实现密切相关的关联删去
- 瞬时事件删除
- 三元关联分解为二元关联或限定关联。
- *⑤进一步完善：正名、分解、补充 *
(3)划分主题
总行主题、分行主题、ATM主题
(4)确定属性
找需求陈述中的名词
修改：
- 误把类当属性：独立存在更重要，则应为类。
- 误把链属性作为属性：属性要依赖某关联链存在，则为关联类的属性。
- 误把限定当属性：属性值固定下来可减少重数，则应为限定。
- 误把内部状态当属性：误把内部状态当属性
- 过于细化：忽略对大多数操作都没有影响的属性。
- 存在不一致属性：分解两个类。
(5)识别继承
(6)反复修改
4、动态模型
1.编写典型交互行为脚本
2.从脚本中提取事件及相关对象，用顺序图表达
3.确定对象状态及状态间转换关系，用状态图描绘
六、面向对象方法学设计
1、面向对象方法特点
分析：提取、整理用户需求，建立问题域精确模型。
设计：转变需求为系统实现方案，建立求解域模型。
面向对象设计特点：分析和设计活动是一个多次反复迭代的过程。面向对象方法学在概念和表示方法上的一致性，保证了在各项开发活动之间的平滑(无缝)过渡，领域专家和开发人员能够比较容易地跟踪整个系统开发过程，这是面向对象方法与传统方法比较起来所具有的一大优势。（参考瀑布模型，不断迭代）
2、准则及启发规则
传统方法学的准则和启发规则也适用，不再赘述。
①抽象：通过像类抽象机制实现 ，提高可重用性
②信息隐蔽：通过封装性实现 ，提高独立性
③弱耦合：对象间耦合：交互耦合（松散）、继承耦合（紧密）
- 交互耦合：对象间通过消息连接实现，降低消息连接复杂度和信息数（减少参数个数，降低参数复杂度）
- 继承耦合：一般类和特殊类之间耦合。有继承关系基类和派生类是系统中粒度更大模块。
- 所以要保证低交互耦合，高继承耦合
④强内聚：
- 服务内聚：一个函数只完成一个功能。
- 类内聚：一个类只有一个用途，否则分解。
- 继承内聚：设计合理，是对领域知识正确抽取。
⑤可重性：尽量利用已有类（类库、已创建类），创建新类也要考虑以后可重用性
启发规则：
- 设计结果清晰易懂：用词一致、使用已有协议、减少消息模式的数目、避免模糊的定义
- 继承关系深度适当：约100个classes，则设计7±2层
- 设计简单class：避免过多的属性和方法、分配给每个类任务应简单、objects间合作关系简单、
- 使用简单的协议和服务： 经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。
