设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

第一部分

文档类型：

Microsoft Word 文档文档大小：2.9M

第一部分软件开发活动软件开发综述用UML建模需求提出需求分析系统设计对象设计结构化的分析与设计面向对象的分析与设计什么是分析与设计
分析(analysis):要创建一个系统,需要对问题和需求进行描述.问题是什么以及系统必须做什么,它强调对问题的调查.例如,如果要开发一个新的图书馆信息管理系统,这个系统的业务过程是什么这是一个分析问题
设计(design):对系统如何满足需求和约束进行高层描述和具体说明,它强调问题的逻辑解决方案.例如,图书馆信息系统能够多大程度地精确地捕获和记录书的借出情况这是一个设计问题.设计最终可以用硬件和软件来实现分析与设计的两种模式结构化分析(structured analysis and design)对问题的分解尺度主要是依据功能或过程.
而面向对象的分析与设计强调以对象为尺度
第一章结构化的分析与设计结构化分析方法(简称SA方法)就是面向业务流或数据流的自顶向下逐步求精地进行需求分析的方法.
结构化设计方法(简称SD方法)就是将需求分析转化为层次功能模型的方法.
设计通常分概要设计和详细设计两步进行、概要设计将软件系统分解成许多个模块,并决定每个模块的外部特征、即功能(做什么)和界面(输入和输出);详细设计确定每个模块的内部特征、即每个模块内部的执行过程(怎样做),通过这样的设计过程,就为编程制订了一个周密的计划,下面就可直接过渡到编程阶段了.
本章主要内容模型图概要设计详细设计
第一节模型图
结构化分析使用的模型图有:业务流程图数据流图功能结构图(或功能树)网络结构图程序流程图n业务流程图是反映用户业务过程的图.
n业务流程图包括:任务名称,执行者、任务步骤,流转的信息等业务流程图例业务流程例图数据流图反映信息的来源,加工,存放和输出.数据流图例数据流例图功能结构图
IDEF方法族介绍:IDEF的含义是集成计算机辅助制造(Integrated 最初的IDEF方法是在美国空军ICAM项目建立的,最初开发3种方法:功能建模(IDEF0),信息建模(IDEF1),动态建模(IDEF2),后来,随着信息系统的相继开发,又开发出了下列IDEF族方法:数据建模(IDEF1X),过程描述获取方法(IDEF3),面向对象的设计(OO设计)方法(IDEF4),使用C语言的OO设计方法(IDEF4C),实体描述获取方法(IDEF5),设计理论(rationale)获取方法(IDEF6),人-系统交互设计方法(IDEF8),业务约束发现方法(IDEF9),网络设计方法(IDEF14)等.
IDEF0图被用于表示功能结构.它的每一个方框表示一个功能块,方框的左边箭头表示输入,右边箭头表示输出、上方箭头表示控制,下方箭头表示支持条件.IDEF0图的同一页上的功能块是属于同一层次的,一般不要超过六个.图的右上角有一个层次索引.
功能结构例图功能树功能树是功能结构图的简化,它只保留了功能的层次性,忽略了功能块之间的信息传递关系.在中小型系统中较常用.
功能树例(略)
第二节需求分析需求分析是软件工程中一个最重要的环节.需求分析中的任何一个小错误都可能导致整个工程的失败.
需求分析的任务需求分析的步骤需求分析的原则需求分析的方法用户和软件人员双方一起来充分地理解用户的要求,并把双方共同的理解明确地表达成一份书面文档需求说明书.
任务可分为四个方面:
1. 理解当前的现实环境、获得当前(人工)系统的具体模型.
2. 从当前系统的具体模型抽象出当前系统的逻辑模型.
3. 分析目标系统与当前系统逻辑上的差别、建立目标系统的逻辑模型.
4. 为目标系统的逻辑模型作补充. 调查研究分析与综合书写文档需求分析评审
需求分析步骤一:调查研究
一、需求调研准备: 1) 调研前应该将所有项目前期资料进行汇总,与和立项相关的前期人员进行交流、以便对项目有一个基本轮廓的认识.
2) 做好调研前使用资料的准备,如需求调研模板,需求调研问题列表等.
3) 做好不怕一切困难的准备.
二、调研活动:1)软件运行环境调查(软件应用域人员组织结构,网络分布地域,企业经营目标,当前系统情况等)2)软件涉及的业务流程3)业务流程中的数据描述及数据变换关系
三、注意事项1)自上而下地调查2)图形描述(业务流程,数据流程)3)多次反馈交流
需求分析步骤二:分析与综合
多角度地考察需求:
按使用者分布图:任务落实到人
按功能块分布图:任务落实到软件模块
按地域分布图:任务落实到机器工作地数据流量,数据积累速率逐步细化所有软件功能,找出系统各元素之间的联系,接口特性和设计上的限制,分析它们是否满足功能要求,是否合理.
图形描述(初始功能结构图,网络结构图)定义数据,建立数据字典描述数据处理算法
需求分析步骤三:书写文档系统规格说明(功能,性能,运行环境)数据要求(数据字典及存储分析)用户系统描述(初步的用户手册)修正的开发计划
需求分析步骤四:需求评审功能的正确性完整性清晰性清晰地表达问题的数据域和功能域,使之易于理解按自顶向下的顺序逐层分解问题要给出系统的逻辑视图和物理视图
面向功能:以软件功能为出发点、分析结果易被开发人员理解,但不利于与用户交流
面向业务流程:从企业→部门→承办人和目标→事务→步骤的分解入手,提取要计算机处理的部分,构成软件模块
面向数据流:以数据的输入,变换,输出为过程,逐层分解
第三节概要设计概要设计任务概要设计过程概要设计原则概要设计方法将系统划分成物理元素,即程序,文件,数据库,文档等设计软件结构,即将需求规格转换为体系结构,划分出程序的模块组成,确定模块间的相互关系,并确定系统的数据结构.
设计系统方案分析及选取最佳实施方案功能分解软件结构设计数据库设计,文件结构设计制定测试计划编写概要设计文档审查文档一些概念
模块化:把程序划分成若干模块
抽象:把共性集中和概括起来,暂时忽略它们之间的差异
信息隐蔽和局部化:每个模块的实现细节对于其它模块来说是隐蔽的,即其所包含的信息不允许其它模块调用.
模块独立性:1)耦合衡量不同模块彼此间互相依赖的程度,2)内聚衡量一个模块内部各个元素彼此结合的程度提高模块的独立性模块规模应该适中适当选择深度,宽度,扇出和扇入模块的作用域应该在控制域之内力争降低模块接口的复杂程度设计单入口单出口的模块模块功能可以预测变换分析
变换型结构的数据流图可分成三部分:输入,主加工和输出.主加工是系统的中心工作,主加工的输入数据流称为系统的逻辑输入,主加工的输出数据流称为系统的逻辑输出.系统输入端的数据流称为物理输入,系统输出端的数据流称为物理输出事务分析
事务分析也是由顶向下逐步细化地进行:先设计主模块,再为每一种类型的事务处理设计一个事务处理模块,然后为每个事务处理模块设计下面的操作模块,再为操作模块设计细节模块.
由事务分析导出的程序结构,也是同问题结构相对应的,它符合事务型程序的标准形式,其质量也是较好的.
Jackson方法:使程序结构同数据结构相对应Jackson 方法是一种面向数据结构的方法,这个方法适用于数据处理类问题,特别是企事业管理的一类软件系统.
Jackson方法的目标:获得简单清晰的设计方案,因为这样的方案易于理解,易于修改.
Jackson方法的设计原则:使程序结构同数据结构相对应.
第四节详细设计详细设计的任务详细设计的原则详细设计的方法确定模块采用的算法确定模块使用的数据结构确定模块的接口细节设计模块的测试用例模块的逻辑描述要清晰易读,正确可靠采用结构化的方法,提高程序的可读性,可测试性,可维护性选择恰当描述工具详细设计的表示方法
程序流程图流程图包含下面三种基本成分:加工步骤用方框表示.逻辑条件用菱形表示.控制流用箭头表示.
N-S图(盒图)NS图是用于取代传统流程图的一种描述方式.NS图仅含有顺序,条件,选择,循环(DO WHILE, REPEAT UNTIL)5种基本成分PAD图(问题分析图)问题分析图是一种改进的图形描述方式,可以用来取代流程图.它仅具有顺序,选择,循环三类基本成分.
PDL图(程序设计语言)PDL的总体结构同一般程序相同、它也包括注释部分,数据说明部分和过程部分;其内层则可以是任意的英语语句.PDL仅仅是对算法的一种描述,它是不可执行的.
第二章面向对象的分析与设计面向对象方法概述面向对象的分析面向对象的设计
第一节面向对象方法概述对象与面向对象面向对象技术产生的原因面向对象方法的基本思想面向对象方法的一些概念面向对象技术的特点面向对象语言及系统
对象:对象一词的使用使用源远流长,从亚里士多德的哲学论著到笛卡尔的哲学原理都以客观对象为中心看待哲学问题.而自然世界由主观对象与客观对象组成
面向对象:Object Oriented,其使用只有十几年的历史,面向对象技术所追求的目标是现实问题空间和软件系统解空间的近似和直接模拟面向对象技术产生的最重要的原因就是由于计算机科学对软件工程学的需要、其表现形式是所谓的软件危机.美国权威部门对软件项目在70年代末进行了统计,结果如图所示造成遗憾工程的主要原因是在概念设计阶段,用户对系统的需求是比较笼统和抽象的,而此时设计者的自由度较大.但随着时间的推进、用户的需求越来越细致和具体,但设计者对系统修改的自由度却越来越小了,而新原理,方法,工具,环境、构件,器件的水平是日益提高的.因此系统越大,周期越长,造成遗憾工程的可能性越大.
对问题域进行自然分割,以接近人类思维的方式建立问题域模型,从而使设计出的软件尽可能地描述现实世界、构造出模块化的,可重用的,可维护性好的软件,并能控制软件的复杂性和降低开发维护费用.
概念对象(object) 对象是人们要进行研究的任何事物,对象是一个封装数据属性和操作行为的实体.
消息对象之间进行通讯的一种构造叫做消息.类类定义了一组大体上相似的对象.继承性继承性是父类和子类之间共享数据和方法的机制封装性结构与连接多态性在收到消息时,对象要予以响应.不同的对象收到同一消息可产生完全不同的结果,这一现象叫做多态.
主动对象基于Parnas的信息隐蔽和Cuttag的抽象数据类型概念,把所有资源如数据,模块及系统看成对象,把数据类型和一组过程(即对数据的加工)封装在一起,因此:面向对象=数据抽象信息隐蔽继承性动态连接
面向对象技术有以下几个特性:
1)模块性:对象是功能和数据独立的单元、互相之间只能通过对象认可的途径通信
2)封装性:为信息隐蔽提供具体的实现手段.用户只要了解对象的功能描述即可
3)代码共享:继承性提供了代码共享的手段
4)灵活性:对象的功能执行在消息传递时确定,支持对象的主体特征
5)易维护性:实现了抽象与封装、使错误限制在对象自身、不会向外传播
6)增量型设计:可以通过继承机制不断扩充功能,而不影响原有软件的运行
SmallTalk:第一个面向对象语言、意为少说话、多做事.最初由Alan Kay 1972年在施乐公司PARC实验室工作时设计C由ATT公司的Bjarne Stroustrup对C语言进行改进扩充而得到
ABCL1:日本东京工学院的Akinori Yonezawa领导下用Common Lisp语言开发
POOL:阿姆斯特丹大学开发,强调并发性另外还有等.目前较为流行的有Visual C,Borland C,Visual 等使用最多的是Java,C, Common-LISP等
第二节面向对象的分析分析的任务分析的层次性分析原则分析过程OOA分析的任务识别问题领域内的对象,并分析它们相互间的关系,最终建立起问题域的简洁、精确,可理解的正确模型.模型包括:静态模型对象模型动态模型交互次序功能模型数据变换OOA分析的原则抽象分类聚合关联消息通信粒度控制行为分析OOA分析过程识别对象标识对象的属性识别对象的行为识别对象所属的类定义主题词多视点需求分析
第三节面向对象的设计设计的任务是把客观世界的对象和操作变换成计算机可接受的形式.设计的模型设计的三条重要原则面向对象设计的概念面向对象的设计方法设计的三条重要原则,即抽象,信息隐藏和模块化,与其他方法相比、OOD的模块化不再仅仅局限于过程处理部分,而是通过将数据及对数据的操作封装在一起,共同完成信息和处理的双重模块化.
设计方法必须提供的机制:①数据结构的表示;②处理过程的说明;③处理过程的调用.在OOD中、它们分别用对象,操作和消息实现
类,实例和继承:具有相同(私有)数据结构和操作的一组对象用类定义、相同类的所有对象性质相同、每个具体对象称为其类的个实例
对象描述:在OOD中、对象可用协议或实现两种方式描述.协议描述给出对象可接收的消息种类以及接收到消息后应执行的操作,即定义出对象与外界的界面;实现描述给出对象实现的细节,包括对象的私有数据及每个操作的过程控制信息.
面向对象分析(OOA)与面向对象设计(OOD)很难截然分开、一般认为OOA是一个分类活动,即从问题陈述中把直接反映问题域和系统行为的对象,类及类之间的联系孤立出来,而OOD进一步说明为实现需求必须引入的其他类和对象,以及从提高软件设计质量和效率方面考虑如何改进类结构,重用类库中的类.此外00D还应提供某种表示法,用以刻画对象之间的关系.
面向对象设计模型OOD由主体部件(PDC),用户界面部件(HIC),任务管理部件(TMC)和数据管理部件(DMC)四部分构成.每个部件又由主题词、对象及类,结构,属性和外部服务五层组成,分别对应在面向对象分析一节中已介绍的五个活动:定义主题词、标识对象,标识对象所属的类,标识对象的属性和标识对象的行为.
主体部件(PDC)的设计以OOA模型为基础、通过适当地扩展和调整,使之适应需求的变化,并为那些完成系统功能所需的类,对象,属性和操作提供实现途径.
扩展和调整主要采取下列方法和措施:
(1) 重用软部件(2) 引入新父类,分组管理系统相关类(3) 引入新父类捕获共性,简化软件设计与编码(4) 转换继承结构适应实现的限制(5)调整OOA模型,提高软件执行速度(6)依据高内聚度,低耦合度及简单性等软件设计原则进行设计复审,检查对OOA模型所做的修改是否合理,是否满足需求的变化.
用户界面部件(HIC)的设计在设计阶段要给出有关人机交互的所有系统成分.包括:用户如何操作系统(菜单),系统如何响应命令,系统显示信息,报表格式,等等.
HIC设计的策略与步骤为:
(1)熟悉用户并对用户分类(2)按用户类别分析用户工作流程与习惯(3)设计命令系统并进行优化(4)设计用户界面的各种细节(5)增加用户界面专用的类与对象(6)利用快速原型演示、改进界面设计任务管理部件(TMC)的设计任务是由目标软件系统中一段代码决定的处理行为.在OOD中引进任务管理部件的原因有两点.一是在多用户,多任务或多线程操作系统上开发应用程序的需要、二是通过任务描述目标软件系统中各子系统间的通信和协同.引入任务概念能简化某些应用的设计和编码.
(TMC)设计的步骤与策略:
(1)识别由事件驱动的任务(2)识别时间驱动的任务(3)识别关键性任务及任务优先级(4)定义任务协调器(5)定义任务(6)必要时在OOD中扩充有关任务的类及对象,调整原有的语法成分,以适应任务定义的要求.
数据管理部件(DMC)的设计
设计数据管理部件的目的是:将目标软件系统中依赖开发平台的数据存取部分与其他功能分离,数据存取通过般的数据管理系统(如文件系统,关系数据库或面向对象数据库)实现,但实现细节集中在DMC中.这样既有利于软件的扩充、移植和维护,又简化了软件设计,编码和测试的过程.
DMC设计包括定义数据格式和定义相应操作两部分
第三章UML概述UML对软件工程的重大影响UML的概念模型UML的建模思想UML的软件开发生命周期UML的缺点与不足UML的支撑环境RoseUML的发展方向促使了用RUP替代原来的软件生命周期用可视化的语言实现各阶段的建模文档全部由UML建模工具自动产生使得分析,设计,实现,维护的岗位界线逐渐趋向模糊.UML是一种可视化的图形符号建模语言、利用它可以进行需求分析,概要设计,详细设计,编程实现,项目计划,测试,原型迭代,产品发布和产品维护.
理解UML的建模元素,关键是要学习它的三个要素:面向对象的基本构造块支配这些构造块的建模规则运用于整个UML的公共机制UML的构造块
事物:结构事物(类,接口,协作,用例,主动类,构件,节点)、行为事物(交互,状态机)
关系:依赖,关联、泛化,实现,累积
图:类图,对象图,用例图,顺序图,协作图,状态图,活动图,构件图,实施图UML的五种规则
命名:为事物,关系和图命名
范围:给一个名字以特定含义的语境
可见性:怎样使用或看见名字
完整性:事物如何正确,一致地相互联系
执行:运行或模拟动态模型的含义是什么UML的四种公共机制
规格说明:对UML构造块的语法和语义的文字叙述
修饰:元素符号的其它细节,如:一个类是否是抽象类,它的属性和操作是否可见.
通用划分:两种通用划分:类是一个抽象,对象是该抽象的一个实例,可同时对类和抽象建模;接口声明一个契约,实现表示对该契约的具体实施,可同时对接口和实现建模
扩展机制:3种类型(丰富了UML的语言表达能力)1)构造型:扩展UML的词汇,允许创造新的构造块,该构造块既可从现有构造块派生,也可针对要解决的问题另建.2)标记值:扩展UML构造块的特性,允许创建元素的新信息.3)约束:扩展UML构造块的语义、允许增加新的规则或修改现有的规则.
宏观建模思想:9个模型,9种图,5张视图
微观建模思想:基本结构模型,高级结构模型,基本行为模型,高级行为模型,体系结构模型(5个方面,66个微观建模)
宏观建模思想:9个模型
业务模型:业务操作流程,建立组织的一个抽象
领域模型:业务操作规程,建立系统的语境
用例模型:用户功能需求列表,建立系统的功能需求
分析模型:系统的逻辑设计,建立概念设计
设计模型:物理设计(含字典设计),建立问题的词汇以及解决方案
过程模型:系统的进程设计,建立系统的并发和同步机制
部署模型:系统的网络节点设计,建立系统的硬件拓扑网络结构
实现模型:系统的软硬件配置设计,建立用于实施和发布物理系统的各部件
测试模型:系统的测试计划设计,建立验证和校验系统的路径
宏观建模思想:9个图
类图:一组类,接口和协作及其相互关系,静态结构图
对象图:一组对象及相互关系,静态结构图
用例图:一组用例,参与者以及关系,动态行为图
顺序图:交互的时间排序,动态行为图
协作图:交互中消息传递的对象结构组织,动态行为图
状态图:状态机中事件到事件的控制流、动态行为图
活动图:状态机中活动到活动的控制流、动态行为图
构件图:一组构件及相互关系,静态结构图
实施图:一组节点及相互关系,静态结构图
宏观建模思想:5张视图用例视图设计视图进程视图实现视图实施视图
微观建模思想:基本结构模型
对类建模:对系统的事物词汇,系统中的职责分布、非软件事物,简单类型建模(4)
对关系建模:对依赖关系,继承关系,结构关系(关联)建模(3)
对公共机制建模:对注释,新构造块,新特性,新语义建模(4)
对图建模:对静态结构,动态行为、复杂视图建模(3)
对类图建模:对类图上的简单协作,数据库逻辑模型建模(2)
微观建模思想:高级结构模型对类的语义建模对关系网络建模对接口,类型和角色建模对成组的元素建模,使其成为包;对体系结构视图建模,使其成为子系统对具体实例,原型实例建模对对象结构建模
微观建模思想:基本行为模型对交互建模对用例建模
对用例图建模:对系统的语境、系统的需求建模
对交互图建模:按时间顺序和按组织结构对控制流建模
对活动图:对工作流、操作建模
微观建模思想:高级行为模型对信号族,异常情况建模
对状态机建模:对象的生存期模型
对进程和线程建模:对多控制流和进程通信建模
对时间空间建模:对时间约束,对象空间分布、移动对象建模
对状态图建模:对事件转换时的反应型对象建模
微观建模思想:体系结构模型
对构件建模:对可执行体,对象库,表,文件,文档,应用程序接口API,源代码建模
对实施建模:对网络拓扑结构,构件在节点上的分布建模
对协作建模:对用例的实现,操作的实现,机制建模
对模式和框架建模:对设计模式,体系结构模式建模
对构件图建模:对源代码产品、可执行体的发布、物理数据库,可适应的系统建模
对实施图建模:对嵌入式系统,CS 系统,分布式系统建模
对系统建模:对体系结构,子系统系统建模
第四章用UML建模UML为广泛的应用而设计,因此,它为较大范围的系统和活动提供结构(例如:实时系统,分布式系统,分析,系统设计,配置).系统开发集中于系统的3个不同模型:功能模型在UML中由用例图表示、从用户观点描述系统功能.对象模型在UMl中由类图表示、以对象,属性,关系和操作形式描述系统结构.
动态模型在UML中由顺序图,状态图和活动图表示、描述系统的内部行为.顺序图把行为描述为一组对象间的信息交换序列.而状态图根据单个对象的状态及状态间可能的转换描述行为.
以下介绍建模概念和UML的主要图形符号.
第一节建模概念系统,模型和视图概念和现象数据类型,抽象数据类型和实例类,抽象类和对象事件类,事件和消息面向对象的建模证伪和原型化系统是为特定目的设计的由相互关联的部分组成的集合.一辆车,由4个轮子,一个底盘,一个车身和一台发动机组成,是设计来搭载乘客的.一块手表,由一块电池,一个集成电路,齿轮和指针组成,是用来测量时间的.一个工资系统,由主机、打印机、磁盘,软件和发薪职员组成,负责给公司职员分发工资.
一个系统的各个组成部分可以依次被看作是更简单的系统,称为子系统.一辆车的发动机、由汽缸、活塞,喷油嘴模块以及许多其他部分组成,它们都是一辆车的子系统.
许多系统由大量的子系统组成,这些子系统以复杂的方式彼此互相联系.这种情况常常如此复杂,以致任何单个的开发人员都不可能管理系统的整体.建模是处理这种复杂性的一种手段.建模允许我们通过一种分而治之的办法来处理复杂性,建模关注的是构建一个能使人完全领会的足够简单的模型.一条准则就是,每个实体最多包括7±2部分[Miller,l956.
建模意味着构造系统的抽象,它只关注感兴趣的方面而忽略无关细节.复杂系统通常由不止一个的模型描述,每个模型集中对系统的不同方面或不同层次进行准确的描述.
不幸的是,即便是单个模型,也可能因过于复杂而不易理解.与系统一样,我们采取同样的分而治之的办法来处理模型的复杂性.视图集中在使模型易于理解的单个子集上.例如,建造一架飞机必需的所有蓝图组成一个模型.解释燃料系统功能所必需的叙述组成燃料系统视图.视图可能重叠:表示飞机电子配线的视图也包括燃料系统配线的视图.
符号是表示视图的图形规则或文字规则.UML类图是对象模型的图形视图.可以用不同的符号来表示同一个视图. 在软件开发中、对系统建模也可以用许多其他的符号表示.UML以类,事件,状态、交互和活动描述一个系统.数据流图[De Marco,1978]描述了怎样检索,处理并存储数据.每种符号都专门用来处理不同的问题.
现象是可被感知到的世界的对象.下述都是现象:这本书;当前的存款利率是3;我的黑色手表;峡谷垂钓俱乐部.
概念是用来描述一组现象的抽象.下面都是概念:面向对象软件工程的教科书;存款利率;黑色手表;垂钓俱乐部.
概念描述一组现象共有的属性.一个概念由三个要素定义:它的名称(将它与其他概念区分开来),它的用途(判断一个现象是否属于该概念的属性),以及它的成员(属于该概念的现象集合).概念的三个要素也称作概念的名称,内涵和外延.
抽象是将现象归类为概念.建模是进一步的抽象,用来回答与一组现象有关的具体问题.与对应的一组现象相比、其抽象更易于处理和检验、因为它包含更少的信息:去除了无关的细节.
在工程中、模型可以先于它表示的对象而存在.例如,一个UML模型可以描述一个还没有实现的系统.在科学中、模型可以声明系统的存在并导出证明其存在的实验.例如,在CEBN的加速器实验证明夸克存在之前就已经阐述了夸克理论.
总的说来,建模是软件工程师设计一个系统时进行的活动.建模的目的是忽略无关细节,构造系统的抽象.软件工程师从应用域(即系统运行的环境)和求解域(即构建一个系统的技术)中抽象出概念.结果,模型比环境或系统简单,从而更易于操纵.在系统开发或验证阶段,软件工程师需要就系统与其他工程师,客户或使用者交流讨论.他们根据自己的想象,用CASE工具,使用不同的符号表示出模型,这种模型甚至可以表示在餐巾纸上.在这样做的过程中、他们为支持他们特定的交流需要构造出模型的视图.
数据类型是编程语言环境中的抽象.数据类型有一个独有的名字,以区别于其他数据类型.它有一个用途(即在该数据类型的所有成员中有效的结构和操作)并有自己的成员(即数据类型的成员).数据类型用在类型化的语言中、以确保只有合法的操作应用于指定的数据成员上.例如int对应于所有在-232~(232-1)之间的有符号整数.该类型成员的合法操作是所有的整数运算(例如:加,减,乘,除)以及具有int型参数的函数和方法(例如:mod).如果一个浮点数操作应用到int类型的成员上(例如:trunc或floor),那么Java运行环境会出现异常.
抽象数据类型是一类特殊的数据类型,其结构对系统的其余部分来说是隐藏的,这使得开发人员在修改抽象数据类型的内部结构和实现时不会影响系统的其余部分.例如,抽象数据类型person定义了操作getName, getAddress和 .而一个人的社会安全号码是存储为一个数字还是一个字符串的问题对系统其他部分来说是不可见的.
一个实例是一个特定数据类型的任一个成员.例如,3.14是float类型的一个实例.一个数据类型的实例可以被该数据类型定义的操作所操纵.
数据类型和实例之间的关系与概念和现象之间的关系类似:数据类型是描述一组具有共同特点的实例的抽象.例如,对person的实例重命名的操作只需在person数据类型重定义一次,就能对所有person的实例应用.
类是面向对象编程语言的抽象形式.与抽象数据类型相同的是,类封装了结构和行为.与抽象数据类型不同的是,类能通过归纳用其他类来定义.假定我们有一块也能用作计算器的手表,则类计算器手表可以看作是手表类的改进.一个基类和一个细化类之间的关系叫做归纳.基类(例如:手表)叫做超类,细化的类称为子类(例如:计算器手表).在归纳关系中、子类通过定义新的属性和操作细化了超类.计算器手表定义了进行简单数学运算的功能,而普通手表则没有.
当一个超类仅仅用来为共享的属性和操作建模时,也就是说,如果超类从来没有实例化,此时它被称作抽象类.抽象类通常表示应用域要归纳的概念.当我们把现象归类为概念时,通常会创建抽象类来管理分类的复杂性.例如,化学中、苯可以看作是属于抽象类有机化合物的一类分子.注意,有机化合物是一个归纳,不对应于任何一个分子,也就是说,它没有任何实例.当对软件系统建模时,抽象类有时不对应于任何存在的应用域概念,而只是被引入来减少模型中的复杂性或为了改善重用.
类定义了能被应用于实例的操作.超类的操作能被继承并也可用在子类的对象上.例如,用来设置手表类当前日期的设置日期操作对计算器手表类也是可用的.然而定义在计算器手表类中的输入计算模式操作则在手表类中是不可用的.
类定义了可应用到其所有实例的属性.属性是实例中可以存放数值的一个命名空间.属性在类和类型中具有惟一的名字,手表具有时间和日期属性.计算器手表具有计算状态属性.
对象是类的实例,一个对象具有标识并能存储属性值,每个对象只能属于一个类.在UML中、实例用长方形表示、其名称用下划线表示.UML中始终使用这个惯例来区别实例和类型.上图中、简单手表1291是手表的一个实例,而计算器手表1515是计算器手表的一个实例.注意,虽然手表的操作可用于计算器手表1515,但是计算器手表1515并非手表类的一个实例.与抽象数据类型不同的是,在某些编程语言中、一个对象的属性对系统其他部分可能是可见的.例如,Java允许实现者详细指出哪些属性是可见的,哪些是不可见的.
抽象类型
抽象类型:如果类型T的每个实例还必须是它的一个子类型的成员,那么类型T就被称为一个抽象类型(abstract type)
抽象类和抽象方法:如果一个抽象类型在软件的设计阶段被实现为一个类,则称为抽象类(abstract class),抽象类意味着不能创建这个类的实例.抽象方法(abstract method)是在抽象类中声明但没有实现的方法,用斜体表示类层次和继承在面向对象程序设计语言中、一个子类型通过类层次(class hierarchies)的创建、继承(inherit)了它的超类型的属性和方法的定义.继承(inheritance)是一种实现子类型和超类型定义一致的软件机制事件类是对一类系统有共同响应的事件的抽象.一个事件是事件类的一个实例,是系统中相关地发生的事情.例如,一个事件可能是来自执行者的一个激励(例如,手表用户按下了左边的按钮),一次暂停(例如,两分钟后),或者是两个对象间发送的消息.
发送消息是一套机制,发送对象通过这套机制要求接收对象执行某项操作.消息由一个名称和一组参数组成.接收对象把消息名字与它的一项操作相匹配、并将参数传递给该操作,结果返回给发送对象.例如,手表对象向时间对象发送getTime消息和向时区对象发送getTimeDelta消息,以分别得到格林尼治时间和时间差,从而计算出当前时间.
事件和消息都是实例:它们表示了系统中具体发生的事情.事件类是对一类事件的抽象,系统对此类事件有共同的响应.在实际中、术语事件可以指实例或类,这种指代的模糊性可以通过检查该术语使用的上下文来解决.
应用域描述了用户问题的所有方面,它包括物理环境、用户和其他人、他们的工作进程等.分析者和开发人员对一个系统应用域的理解对系统有效地完成预想的任务是很关键的.注意,当工作进程和人事发生变化时,应用域也随着时间而改变.
求解域是所有可能系统的空间.求解域比应用域更丰富、也更脆弱.这是由于新技术总是不断地涌现,而且当实现技术逐渐成熟或者开发人员构建系统时,对实现技术有了更好的理解带来的变动也不容忽视.对求解域建模表示了开发过程中的系统设计和对象设计活动.注意,系统配置也可能改变应用域,因为用户设计了新的工作过程来应用于系统.
面向对象的分析注重对应用域的建模.面向对象设计关注对求解域的建模.这两个建模活动都使用相同的表示(即:类和对象).在面向对象的分析和设计中、应用域模型也是系统模型的一部分.例如,一个空中交通控制系统有一个交通控制者类来表示每个用户,他们的优先级以及日志信息.系统还有一个飞行器类来表示与监控的飞机相关的信息.交通控制者和飞行器都是应用域概念,这些概念被编码到了系统之中.
只用一种符号对应用域和求解域建模有优点也有缺点.一方面,它功能强大:表示应用概念的求解域的类能够回溯到应用域.而且、这些类能被封装入独立于其他实现概念(例如用户界面和数据库技术)的子系统,并被打包成一个域类的可重用的工具包.另一方面,使用单一的符号可能引起混淆的情况,因为它忽略了现实世界和它的模型之间的差异性.基于此,我们使用单一符号,只在可能出现混淆的情况下我们才对两个域加以区别.大多数情况下,我们是指模型(例如,一个飞行器由装货清单和飞行计划组成就是一个关于模型的声明).
从忽略了相关细节的意义上说,一个模型是对现实情况(下面称本体)的简化,然而、相关细节需要表示.证伪[Popper,1992]就是一个证明相关细节已经被错误地表示或根本没被表示的过程;也就是说,模型与它假定要表示的现实不对应.
证伪的过程在其他学科中是很常见的:研究者提出对应一个现实的不同模型,当支持该模型的数据量不断增加时,该模型逐渐地被接受;然而一旦发现了一个反例该模型即被拒绝.一旦接受伽利略的数据,那么脱勒密关于宇宙的地心说模型就(最终)被证明是错误的,转而选择哥白尼的日心说模型.而一旦其他星系被发现并把星系的概念加入到模型中、也就证明哥白尼的日心说模型为错误的了.
我们也能把证伪应用于软件系统开发.例如,开发系统的一种技术就是原型化:当设计用户界面时,开发人员构建一个仅仅模仿系统用户界面的原型,然后将该原型提交给可能的用户来评估,也就是说,证伪然后修改.在该过程的第一次循环中、由于来自用户的反馈,开发人员可能放弃最初的原型.换句话说,用户证明最初的原型将来系统的一个模型有误,因为它不能准确地表示相关细节.
要注意的是,我们只可能证明一个模型是不正确的.虽然在某些情况下有可能在数学上证明两个模型是等价的,但是,要表明这两个模型都能正确表示现实是不可能的.例如,形式证明技术能使开发人员证明一个特定的软件实现跟一个形式化说明相符.然而、只有领域测试和广泛的使用才能表明系统满足了客户的需要.任何时候,由于需求,实现技术或环境的变化,系统模型都可能被证明是有误的.
第二节UML的主要图形符号
我们现在详细描述5种主要的UML图表:用例图从用户的角度来表示系统的功能,它们定义了系统的边界.类图以对象,它们的属性和关系表示系统的结构.顺序图以一组对象之间的交互来表示系统的行为.它们用来标识应用域和实现域的对象.
状态图用来表示主要对象的行为.活动图是用来表示通过系统的数据流或控制流的流程图.用例图用例在需求提出和分析中用来表示系统的功能.用例从外部的角度关注系统的行为.一个用例描述系统提供的一个功能,而系统对执行者产生一个可见的结果.这里所说的执行者代表的是与系统交互的任意实体(例如,用户,其他系统,系统的物理环境).用例和执行者的识别产生了系统界限的定义、也就是说,区分了系统完成的任务及其环境完成的任务.执行者处在系统界限的外围,而用例处在系统界限的内部.
以下介绍:用例,用例文档,执行者、场景,关系,应用用例图(use case diagram):显示了系统的一组用例,用例的参与者以及用例和参与者之间的关系.用例和参与者之间的连线代表了信息流或控制流的流向图显示了一块简单手表(Simple Watch)的用例图.手表用户既可以通过他们的手表查询时间(用读时间用例),也可以设置时间(用设置时间用例).但是,只有手表修理人可以更换手表电池(用更换电池用例).
用例为描述一个用例,使用一个由6个域组成的模板(见下页):用例的名字在系统中是惟一的,以便开发人员(和项目参与者)能毫不含糊地引用该用例.
参与执行者是与用例交互的执行者.入口条件描述了用例启动前需要满足的条件.事件流描述了用例的动作序列,为引用方便,对它们进行了编号.为清晰起见、通常情况(即经常出现的情况)和例外情况(即极少出现的情况,如错误或不寻常条件)分别在不同的用例中加以描述.
出口条件描述了用例完成后满足的条件.特殊需求是与系统功能无关的需求,这些需求包括系统性能,实现,运行平台等限制.
如果考虑对用例分类和用例之间的引用,还可增加类型和交叉引用两个域.
执行者执行者(actor)是系统外部的一个实体,它以某种方式参与用例的执行过程.执行者由他们参与用例时所担当的角色来代表,如1)人担当的角色,如顾客,出纳员; 2)计算机系统;3)机械或电子设备等对于一个用例来说,存在一个用例的发起者(initiator actor),他发起了用例的执行过程,还可能存在若干参加执行者(participating actor).标出谁是用例中的发起者是一个有用的做法.执行者通常通过向系统输入或者请求系统输出某些事件来触发系统的执行.
用例从执行者的观点描述系统的行为.由用例描述的行为也被称为外部行为.一个用例把系统提供的一个功能描述为一组事件,这组事件对执行者产生一个可见的结果.执行者启动一个用例来访问系统功能.然后,用例能启动其他的用例并从执行者处收集更多的信息.当执行者和用例交换信息时,它们被称为交流.后面我们将看到,我们用交流关系表示这些交换.
例例如,在一个事故管理系统[FRIEND,1994]中、现场工作人员,如一名警官或一个消防员,可以访问一台无线计算机、该计算机使得他们能与一名调度员联系.反过来,该调度员能在计算机屏幕上看见所有资源的当前状态(例如警车或卡车),然后通过一个工作站发出指令分配资源.本例中、现场工作人员(FieldOfficer)和调度员(Dispatcher)是执行者.
下图描述了执行者现场工作人员调用用例报告紧急情况来通知执行者调度员出现了一个新的紧急情况.作为响应、调度员调用打开事件(OpenIncident)用例来创建一个事件报告,并启动事件处理.调度员将来自现场工作人员的原始信息输入到事件数据库,并用分配资源用例将其他的资源调度到现场.
用例图例用例文档的例子用例名报告紧急情况参与执行者由现场工作人员启动与调度员进行交流入口条件1.现场工作人员激活她的终端中的报告紧急情况功能.事故管理系统(FRIEND)响应并提交一份表格给工作人员.事件流2.现场工作人员通过选择紧急的级别、类型,发生地点和情况的简短描述填写表格.现场工作人员也描述对紧急状况的可能反应.一旦完成该表格,现场工作人员便将其提交,从而通知调度员.
3.调度员浏览提交的信息并通过调用打开事件用例在数据库中创建一个事件.调度员选择一个响应并答复紧急情况报告.出口条件4.现场工作人员收到答复并选择响应.特殊需求现场工作人员的报告在30s之内得到答复.选择的响应在发送之后30s之内到达.场景用例是描述关于所介绍功能的所有可能场景的抽象.场景是用例的真实例子,它描述一组具体的动作.场景作为举例用来说明普通情况,它们的重点在于可理解性.用例用来描述所有可能的情况,它们的重点在于完整性.我们用一个带有3个域的模板来描述一个场景:场景的名字让我们能明确地引用它.场景的名字使用下划线表明它是一个实例.参与执行者实例域指明该场景中涉及哪一个执行者实例.执行者实例也具有带下划线的名字.一个场景的事件流逐步地描述了事件序列.
请注意,在场景中不需要入口或出口条件.入口和出口条件是一种抽象,它使开发人员能够描述一系列用例被调用的条件.考虑到场景仅仅描述单一的事件流、这样的条件是不必要的(见图).
场景例场景名仓库着火
参与执行者实例Bob, Alice:现场工作人员
John:调度员事件流
1.Bob驾驶着他的巡逻车沿主要街道巡逻,发现一个仓库有浓烟冒出.他的同事Alice,从她的FRIEND手提电脑中激活报告紧急情况功能.
2.Alice输入建筑物的地址、它所处位置的简短描述(如西北角)以及紧急等级.考虑到该地区显得相对繁忙,Alice除了请求消防单位外,还请求了现场的几个医疗单位.她确认了自己的输入并等待答复.
3.调度员John由工作站的警笛声注意到紧急情况.他查看了Alice提交的信息,然后答复了这个报告.他分配了一个消防单位和两个医疗单位到事件现场、并发送它们的估计到达时间(ETA)给Alice.
4.Alice收到答复和ETA. 用例图的关系
用例图可能包括4种关系:交流、包含、扩展和一般性交流关系当信息在执行者和用例之间交换时,它们进行了交流.交流关系由执行者和用例符号之间的一条实心直线描述.在例图中、执行者现场工作人员和调度员用报告紧急情况用例交流.只有执行者调度员与打开事件和分配资源用例交流.执行者和用例间的交流关系可用来表示对功能的访问.在例子中、向现场工作人员和调度员提供访问系统的不同界面并访问不同的功能.
包含关系当描述一个复杂系统时,它的用例模型可能变得相当复杂,而且可能包含冗余.我们通过识别不同用例中的共性来减少模型的复杂性.例如,设定在任何时刻调度员都能够按一个按钮获得帮助.这可以用一个用例帮助调度员来建模,该用例包含在打开事件和分配资源用例(以及其他任何能由调度员访问的用例)中.结果模型只描述了帮助调度员功能一次,从而减少了复杂性.如果两个用例中的其中一个在其事件流中包含了第二个,那么它们之间就有包含关系.在UML中、包含关系由一条虚线描述,该虚线起始于包含的用例.包含关系用字符串标注.
在用例中、我们用两种方法中的一种来表示它自身的包含关系.如果被包含的用例能在事件流的任何一点被包含(例如:帮助调度员用例),我们在用例的特殊需求中指出该包含.如果被包含的用例明确地在某个事件中被调用,我们在事件流中指出该包含.
关联多个用例销售点终端系统中不同支付过程可被表示成单独的几个用例,并且也可与其他用例发生关联.因此,要创建一个经过更新的用例图,该用例图能够显示出这些额外的用例和它们之间的关系UML定义了特殊的表示法来说明用例间的关系,如包含关系(includes),扩展关系(extends)何时创建单独的用例在Buy Item用例子段里记录了不同的支付过程.作为选择,它可以被分成几个单独的用例.
问题在于:在什么情况下应该将一个用例中的主要步骤或者分支活动写成另一个单独的用例而不是子段呢
在以下两种情况中、写成单独的用例:1)它们在其他的用例中被复制2)它们是复杂,冗长的,并且分离它们有助于将用例分解为可管理和易理解的单元在销售点终端的应用中、不同的支付方法是可能在其他的用例如Exchange Items或Contribute toaLay-away Plan 中出现的分支行为、因此可将其作为单独的用例,并命名为:现金支付,信用卡支付,支票支付使用includes关系的用例图如果一个用例初始化或包含另一个用例的行为、就称一个用例use(使用)第二个用例,并且称这两个用例之间有includes (包含)关系假设在Buy Items过程中的支付过程被描述成单独的用例Pay by Cash, Pay by Credit, Pay by Check. Buy Items用例将初始化这三个用例中的一个用例,因此它与这三者之间是一种includes关系在UML中、includes关系用一根标签修饰的依赖线表示使用includes关系的用例文档当用例处于一个includes关系之中时,需要用文字形式将关联表示出来.包含了其他用例行为的用例必须在用例文档中用initiate(发起)关键字指出这种连接
用例:Buy Items
顾客选择支付方式:1)如果选择现金支付,则发起Pay by Cash用例2)如果选择信用卡支付,则发起Pay by Credit用例3)如果选择支票支付,则发起Pay by Check用例扩展关系扩展关系是在用例模型中减少复杂性的又一可选手段.一个用例能够通过增加事件扩展其他用例.一个扩展关系指出、一个被扩展用例的实例可能(在某种条件下)包含扩展用例所指明的行为.扩展关系的一个典型应用是异常行为的说明.例如,假设在调度员和现场工作人员间的网络连接可能在任何时刻中断(例如,如果现场工作人员进入一条隧道).用例连接中断描述了当连接丢失时系统和执行者正在从事的事件集.连接中断扩展了打开事件和分配资源用例.将异常行为与通常行为分离,能使我们编写更短更集中的用例.
在一个用例的文本表示中、我们把扩展关系表示为扩展的用例的入口条件.例如,图中描述的扩展关系被表示为连接中断用例的入口条件.
用例名连接中断参与执行者与现场工作人员和调度员交流.入口条件该用例扩展了打开事件和分配资源用例.无论何时现场工作人员和调度员之间的网络连接丢失,它即由系统启动.
事件流1.包含关系和扩展关系的区别在于相关性的位置.假设我们给执行者调度员添加了几个新的用例.如果用包含关系给帮助调度员建模,每一个新的用例将需要包含帮助调度员用例.如果代之以扩展关系,仅仅需要修改帮助调度员用例以扩展到附加的用例.总的说来,例外情况如帮助,错误或其他意外的情况等、用扩展关系建模.描述一套固定用例共同行为的用例用包含关系建模.
一股性关系一般特殊关系是减少模型复杂性的第三种机制.一个用例能通过增加更多的细节来特殊化一个较一般的用例.例如,在现场工作人员使用FBlEND之前要求他们通过身份验证.在需求提出的初期阶段,身份验证被建模为一个高级的身份验证(Authenticate)用例.接下来,开发人员更详细地描述了身份验证用例,并适用于几个不同的硬件平台.这种求精活动产生两个新的用例,密码身份验证(使得现场工作人员无需任何指定硬件就能登录)和卡式身份验证(要求现场工作人员用一张智能卡登录).这两个新的用例都表示为身份验证用例的特殊化(见下图).
应用用例图用例在需求引出阶段通常随着客户和其他使用者的要求不断完善.在分析阶段,在包括开发人员在内的更多的人员检查的过程中不断纠正,用例不断求精和完善并由实际情况来验证.
用例是对领域过程的描述,用例也展示和体现出了其所描述的过程中的需求情况.可以采用用例增进对需求的理解,但用例不是需求或者功能的规格说明.
用例的使用要依赖于至少已经部分地理解了系统需求,并用需求规格说明文档很好地表达出了这些需求.
用例和领域过程用例描述一个业务过程,而过程(process)描述事件,动作和事物处理的自始至终的发生顺序.这些事件或动作的发生顺序要产生一些对用例的参与者或组织机构有意义的结果.
过程的例子如1)在学校选课注册2)在文本编辑器中检查一个文档的拼写错误3)处理一次电话呼叫系统及其边界用例和执行者定义了系统的界限.典型的系统边界包括:1)硬件设备或计算机系统的硬件软件边界2)一个组织中的部门3)整个组织定义系统边界是为了识别出什么在系统之内以及什么在系统之外,进而识别出什么是系统的职责.
用例的识别
基于参与者的方法:识别出与系统或者组织有关的参与者;对每个参与者、识别出他们发起或参加的执行过程.
基于事件的方法:识别出系统必须响应的外部事件;把事件,参与者和用例联系起来.使用用例时的常见错误用例是相对较大的由起点到终点的过程的描述,往往包含许多步骤和事务的处理,它通常不是过程中的一个单独步骤或活动.如打印数据只是购买商品用例中的一个步骤.
识别用例时另一个常见的错误是把用例当成是一个单独的步骤,操作或事务处理.
不要把步骤当作用例,也不要把用例当作步骤类图我们用类图来描述系统的结构.类是用来指定一组对象共有的结构和行为的抽象.对象是类的实例,而实例则在系统执行过程中被创建、修改并撤销.对象具有包括其属性值及其与其他对象的关系的状态.
类图以对象,类,属性,操作及其关系对系统进行描述.例如,下图是一个描述简单手表类中所有手表元素的类图.这些手表的对象都与按钮类对象,显示屏类对象,时间类对象,以及电池类对象有关系.关系末端的数字表示每个简单手表对象能链接的指定类的对象数目.例如,一块简单手表有2个按钮,1个显示屏,2个电池,1个时间.同样,所有的按钮,显示屏,电池,时间对象只能与一个简单手表对象相关联.
类图例类图的表示类图以类和对象的形式描述了系统结构.类是一种抽象,它指明了一组对象的属性和行为.对象是封装了状态和行为的实体.每一个对象有一个标识符:它能被单独的引用,并与其他对象区别开来.
在UML中、类和对象由包含3个部分的方框描述.顶部的部分显示类或对象的名字,中间部分显示它的属性,底下的部分显示它的操作.为清楚起见、属性和操作部分可以省略.对象名使用下划线表示它们是实例.按照惯例,类名以大写字母开头.为方便引用,对象图中的对象也可能有名字(后面紧跟它们的类).在那种情况下,它们的名字以小写字母开头.
在FRIEND例子中(见下图),Bob和Alice是现场工作人员,在系统中表示为现场工作人员对象,叫做和现场工作人员是一个描述所有现场工作人员对象的类,然而Bob和Alice由两个单独的现场工作人员对象来表示.
类图例(图222)对象图例类图的属性
上图中、现场工作人员类有两个属性:名字和证件号.这表明所有的现场工作人员对象都有这两个属性. 和对象对这些属性有特定的值,分别为Bob D.和A1ice W.现场工作人员名字是字符串类型,它表明只有字符串实例才能分配给现场工作人员的名字属性.
一个属性的类型用来指明该属性取值的合法范围.注意,当属性类型对系统定义并不重要时,属性类型可推迟到对象设计时再定义.这就允许开发人员能致力于系统功能,从而当修改系统功能时能减少琐碎变化的数量.
关系和链接一个链接表示两个对象间的一个联系.关系是类之间的联系,表示成组的链接.
每一个现场工作人员对象有由现场工作人员写的紧急情况报告的列表.在现场工作人员类和紧急情况报告类之间的直线是一个关系.
对象和报告1291:紧急情况报告对象之间的直线是一个链接.这种链接表示了保持在系统中的一种状态、它指出产生了报告1291:紧急情况报告.
角色关系的每端以字符串标识,称为角色.现场工作人员类和紧急情况报告类之间关系的角色是作者和产生的报告.给关系的每端用角色标识使得我们能区分一个类发出的多重关系.同时角色清楚指明了该关系的目的.
重数关系的每端都能用一组数字表示、指明链接的数目,而链接只能连接关系起点的类的一个实例.关系起点作者的重数为1,表明所有紧急情况报告只能由一个现场工作人员书写.换句话说,每一个紧急情况报告对象与现场工作人员类的一个对象只能有一个链接.关系终点产生的报告角色的重数是许多,用星号表示.许多重数是从0.n的速记.这表明任何给定的现场工作人员可以是0个或更多的紧急情况报告的作者.
关联角色的名称一个关联的每一端都是一个角色,它有不同的属性,如名称,多重性.一个关联角色名标识了关联的一个端点、在理想情况下它描述了关联中对象所扮演的角色.在设计类图中使用的关联角色可能在编码阶段被解释成一个属性名的基础作为概念的角色与关联中的角色的对比在概念模型中、对一个现实世界的角色尤其是一个人的角色可能以多种方式对其建模,例如表达成一个离散的概念或表达成一个关联中的角色
关联中的角色:以一种相对精确的方法表达了一个人的相同实例在不同的关联中表现为多重的并动态改变的角色的概念.一个人、同时或按次序地可能表现为教师,对象技师,父亲等角色
作为概念的角色:在增加独特的属性,关联以及额外的语义方面提供了更大的方便性和灵活性.角色作为分离的类来实现更容易.现在流行的面向对象程序设计语言的限制不便于动态地将一个类的实例变异为另一个类的实例,或随着一个人的角色的改变而动态地增加属性和行为关系类关系可以有与之相关的属性和操作,在这个意义上它们与类是相似的.这样的关系叫做一个关系类并用一个类符号描述,用一条虚线与关系符号相连.例如,把现场工作人员分配给一个事件被表示为带有属性角色和通知时间的关系类.
任何关系类都能转换成一个类和简单的关系.虽然两种表述是相同的,但关系类表述更为清晰:一个关系不可能独立于它链接的类而单独存在.类似地,分配对象不可能独立于现场工作人员和事件对象而单独存在.虽然携带了同样的信息,这需要读者对图表中的重数进行仔细检查.
关系类的两种表示关联类型商业ID属性应该出现在概念模型的何处呢1)授权服务机构给每个商店分配一个用来在通信期间作为标识的商业ID2)一个商店发往授权服务机构的支付请求需要包含用来确定商店享有服务的商业ID3)更进一步,一个商店针对每一种不同的服务都要有不同的商业ID把商业ID放在商店中是不正确的,因为一个商店可有多个商业ID.也不能放在授权服务机构中在一个概念模型中、如果一个类型T的属性A可以同时有多个值,那么不要将属性A放在T中.要将属性A放在另外一个与T关联的类型中例如,一个人可能有很多电话号码.将电话号码放入另一个类型中、如PhoneNumber, 中、并且使这些类型与Person关联在商业领域中、契约(contract)或帐目(account)正式记录了有关一个服务机构提供给一个顾客的服务信息关联类型(associative 可被建模成一个与Store和之间的关联相关的关联类型.在UML中、用一条从关联到关联类型的虚线来说明
增加关联类型的指导原则:1)一个属性和一个关联相关2)关联类型的实例的生存周期依赖于关联3)在两个概念间有一个多对多的关联和与关联本身相关的一些信息4)只有关联类型的一个实例存在于参与关联的两个对象之间聚集(聚合)与组成关系用来在一组对象中表示大范围的连接.在实践中、常出现的这种关系的特殊情况是构成.例如,一个州包括许多县,而县又包括许多镇.一个警局由警员组成.另一个例子是一个目录包括很多文件.这样的关系能用一个一对多的关系建模.实际上,UML提供了聚集这个概念来表示构成.一个聚集用一条在关系的包含端带有菱形的直线来表示.虽然一对多关系能替换聚集使用,但聚集是更可取的,因为它强调了关系的等级.例如,警员是警局的一部分.
聚合(aggregation):是一种用来为事物之间的整体-部分关系建模的关联.聚合成的整体称为组成(composite),但是部分没有标准的名称通常称为part(部件)或component(构件)例如,物质的组成可以被组织成聚合关系,就象手聚合了手指
UML中的聚合:聚合用位于整体-部分关联的组成端点处的一个空心或实心菱形符号来表示聚合是一个关联角色的属性.由于关联通常被看作具有Has-part语义、因此关联名常常被排除在聚合关系之外
组成聚合实心菱形:组成聚合(composite aggregation)或组成(composition)意味着组成端的多重性可能最多是1,并用一个实心菱形表示.它意味着组成独自拥有部分,是模型中常见的聚合模式例如,一个手指最多是一只手的一部分共享聚合(shared aggregation)空心菱形:其含义是组成端的多重性可能不止是1.共享聚合很少存在于实体物质的聚合中、而是用在非物质的概念中.例如一个元素可能被多个包引用聚合与组成
如何确定聚合:在考虑聚合时,如果不确定的话、可以先忽略它.在如下情况下要考虑显示聚合:1)部分的生存周期被限制在整体的生存周期内部分的创建和删除依赖于整体2)有一个明显的整体部分的物质上或逻辑上的集合3)整体的一些特性传递给部分,如它的位置4)整体的操作传递给部分,如销毁、移动和记录显示出聚合的好处1)聚合阐明了关于部分独立于整体的合格存在的领域限制.在组成聚合里、部分不能在整体的生存周期之外存在.在确定解决方案阶段,聚合对整体和部分软件类之间的创建-删除依赖是有影响的2)聚合有助于运用GRASP模式找出一个创建者3)运用到整体的操作如复制或删除常常必须传递到部分4)确定与一个部分相关的整体支持封装.GRASP中Dont Talk to Strangers模式被用来在整体中隐藏部分归纳归纳是在一个一般类和一个或多个特殊类之间的关系.归纳使我们能描述一组类之间所有共同的属性和操作.例如,现场工作人员和调度员都有名字和证件号属性.不过,现场工作人员与紧急情况报告有关系,而调度员与事件有关系.通过引入一个由现场工作人员和调度员抽象化的警员类,我们能对现场工作人员和调度员的共同属性建模(见下图).一般性类警员称为超类.具体类现场工作人员和调度员称为子类.子类继承了它们父类的属性和操作.抽象类(2.3.4节中定义)通过用斜体字写抽象类名从而与具体的类分开.在面向对象的建模中、用抽象类来给相关概念分类,从而减少模型的总体复杂性.
归纳与抽象类操作和方法对象行为由操作指明.一组操作表示由一个特定类提供的服务.一个对象通过向其他对象发送消息要求其执行一个操作.该消息与一个方法对应、而该方法由接收对象所属的类或其超类定义.而这里所说的一个类

doc文档的标签：部分第一

更多推荐标签：英语科普常见的花感动人的故事测量技师论文新闻发布系统抵押合同消费贷款餐饮类民法模拟试题公开讨论区人员素质财务事迹创建公司交流控制器英语案例经史百家杂钞文化产品毕业设计机械浏览器端技术合同法心得实践活动文稿煤矿企业文化秘书国家小篇小说招聘心理银行会计职责会计环境问题汇票拒付案例宇宙科学论文七喜手机广告