面向对象的需求分析方法.docx
- 文档编号:6301625
- 上传时间:2023-01-05
- 格式:DOCX
- 页数:26
- 大小:196.34KB
面向对象的需求分析方法.docx
《面向对象的需求分析方法.docx》由会员分享,可在线阅读,更多相关《面向对象的需求分析方法.docx(26页珍藏版)》请在冰豆网上搜索。
面向对象的需求分析方法
面向对象的需求分析方法
面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于20世纪60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk语言与其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML〔UnifiedModelingLanguage,统一建模语言〕是面向对象技术发展的一个重要里程碑。
UML统一了面向对象建模的基本概念、术语和表示方法,不仅为面向对象的软件开发过程提供了丰富的表达手段,而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后,以“家庭保安系统〞为实例,介绍与需求分析相关的部分UML语言机制以与基于UML的面向对象的需求分析方法和过程。
第一节 面向对象的概念与思想
一、面向对象的概念
关于“面向对象〞,有许多不同的看法。
Coad和Yourdon给出了一个定义:
“面向对象=对象+类+继承+消息通信〞。
如果一个软件系统是使用这样4个概念设计和实现的,则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象,计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象〔object〕
一般意义来讲,对象是现实世界中存在的一个事物。
可以是物理的,如一个家具或桌子,如图5-1-1所示,可以是概念上的,如一个开发项目。
对象是构成现实世界的一个独立的单位,具有自己的静态特征〔用数据描述〕和动态特征〔行为或具有的功能〕。
例如:
人的特征:
XX、性别、年龄等,行为:
衣、食、住、行等。
图5-1-1 对象的定义
〔1〕对象、属性、操作、消息定义
对象可以定义为系统中用来描述客观事物的一个实体,它是构成系统的一个基本单位,由一组属性和一组对属性进行操作的服务组成。
属性一般只能通过执行对象的操作来改变。
操作又称为方法或服务,在C++中称为成员函数,它描述了对象执行的功能,若通过消息传递,还可以为其他对象使用。
而所谓的消息是一个对象与另一个对象的通信单元,是要求某个对象执行类中定义的某个操作的规格说明。
发送给一个对象的消息定义了一个操作名和一个参数表〔可能是空的〕,并指定某一个对象。
由一个对象接收的消息则调用消息中指定的操作,并将传递过来的实际参数与参数表中相应的形式参数结合起来。
接收对象对消息的处理可能会改变对象中的状态,即改变接收对象的属性,并发送一个消息给自己或另一个对象。
可以认为,这种消息的传递大致等价于过程性X型中的函数调用。
〔2〕对象的分类
·外部实体:
与软件系统交换信息的外部设备、相关子系统、操作员或用户等。
·信息结构:
问题信息域中的概念实体,如信号、报表、显示信息等。
·需要记忆的事件:
在系统运行过程中可能产生并需要系统记忆的事件,如单击鼠标左键、击打键盘“?
〞键等。
·角色:
与软件系统交互的人员所扮演的角色,如经理、部长、技术支持等。
·组织机构:
有关机构,如单位、小组等。
·位置:
作为系统环境或问题上下文的场所、位置,如客户地址、收件人〔机构〕地址等。
·操作规程:
如操作菜单、某种数据输入过程等。
在标识对象时必需注意遵循“信息隐蔽〞的原则:
必需将对象的属性隐藏在对象的内部,使得从对象的外部看不到对象的信息是如何定义的,只能通过该对象界面上的操作来使用这些信息。
对象的状态通过给对象赋予具体的属性值而得到。
它只能通过该对象的操作来改变。
对象有两个视图,分别表现在分析设计和实现方面。
从分析与设计方面来看,对象表示了一种概念,它们把有关的现实世界的实体模型化。
从实现方面来看,一个对象表示了在应用程序中出现的实体的实际数据结构。
之所以有两个视图,是为了把说明与实现分离,对数据结构和相关操作的实现进行封装。
2.类〔class〕和实例〔instance〕
把具有相同特征和行为的对象归在一起就形成了类。
类成为某些对象的模板,抽象地描述了属于该类的全部对象的属性和操作。
属于某个类的对象叫做该类的实例。
对象的状态则包含在它的实例变量,即实例的属性中。
如图5-1-2所示。
从“李杰〞、“王辉〞和“杨芳〞等对象可得到类“学生〞,而这些对象就称为该类的实例。
图5-1-2 对象、类与实例
类定义了各个实例所共有的结构,类的每一个实例都可以使用类中定义的操作。
实例的当前状态是由实例所执行的操作定义的。
面向对象程序设计语言,如C++和smalltalk都定义了一个new操作,可建立一个类的新实例。
C++还引入了构造函数,用它在声明一个对象时建立实例。
此外,程序设计语言给出了不同的方法,来撤消〔称为析构〕实例,即当某些对象不再使用时把它们删去,把存储释放以备其他对象使用。
C++给出了一个操作delete,可以释放一个对象所用的空间。
C++还允许每个类定义自己的析构方法,在撤消一个对象时调用它。
smalltalk没有提供一个机制来撤消对象,但可以进行无用单元收集。
类常常可看做是一个抽象数据类型〔ADT〕的实现。
但更重要的是把类看做是表示某种概念的一个模型。
事实上,类是单个的语义单元,它可以很自然地管理系统中的对象,匹配数据定义与操作。
类加进了操作,给通常的记录赋予了语义,可提供各种级别的可访问性。
3.继承〔inheritance〕
如果某几个类之间具有共性的东西〔信息结构和行为〕,抽取出来放在一个一般类中,而将各个类的特有的东西放在特殊类中分别描述,则可建立起特殊类对一般类的继承,如图5-1-3所示。
各个特殊类可以从一般类中继承共性,这样避免了重复。
图5-1-3 特殊类对一般类的继承关系
建立继承结构的好处:
·易编程、易理解代码短,结构清晰;
·易修改:
共同部分只要在一处修改即可;
·易增加新类:
只须描述不同部分。
4.多继承
如果一个类需要用到多个既存类的特征,可以从多个类中继承,称为多继承。
例如退休教师是继承退休者和教师这两个类的某些特征或行为而得到的一个新类。
图5-1-4 多继承
5.多态性和动态绑定
对象互相通信,即一个对象发消息给另一个对象,执行某些行为或又发消息给另外的对象,从而执行系统的功能。
发送消息的对象可能不知道另一个对象的类型是什么。
如在C程序中使用命令ClearInt〔〕时要严格区分该命令适合一个整数,还是一个整数数组。
但在C++情形,ClearInt〔〕对两者都适用,它自己判断对象是哪一个。
这就是多态性。
它意味着一个操作在不同类中可以有不同的实现方式。
如清零操作ClearInt〔〕针对消息对象是intarray还是int,其实现是不同的。
在一个面向对象的多态性语言中,可能代替一个特定类型的类型的集合就是它的子类集合。
例如,图5-1-5给出了4个类的继承层次。
使用这个继承结构,发送给多边形类的所有消息,它的所有子类都能够响应。
又例如,想要在屏幕上画一系列多边形,多态性允许一个表的元素可以属于一组指定的类型而不仅仅是一个类型,可以认为这是一个类族。
通过遍历这个表,发送给各个表元素以draw消息,画出所有的多边形。
图5-1-5 4个类的继承层次
动态绑定把函数调用与目标代码块的连接延迟到运行时进行。
这样,只有发送消息时才与接收消息实例的一个操作绑定。
它与多态性可以使我们建立的系统更灵活,易于扩充。
做为动态绑定的例子,考虑在多边形类中的方法contains?
〔aPoint〕。
这个操作可以在类层次的各层重新实现,以有效利用各个子类的特殊的特征。
例如,假定一个矩形有某些边与屏幕的边平行,这时,检查一个点是否包含在矩形内,比检查一个点是否在一个一般的四边形内的效率要高一些。
二、面向对象软件开发的分析模型
面向对象分析过程分为论域分析和应用分析。
论域分析建立大致的系统实现环境,应用分析则根据特定应用的需求进行论域分析。
1.OOA分析的基本原则和任务
为建立分析模型,要运用如下的5个基本原则:
①建立信息域模型;②描述功能;③表达行为;④划分功能、数据、行为模型,揭示更多的细节;⑤用早期的模型描述问题的实质,用后期的模型给出实现的细节。
这些原则形成OOA的基础。
OOA的目的是定义所有与待解决问题相关的类〔包括类的操作和属性、类与类之间的关系以与它们表现出的行为〕。
为此,OOA需完成的任务是:
〔1〕软件工程师和用户必须充分沟通,以了解基本的用户需求;
〔2〕必须标识类〔即定义其属性和操作〕;
〔3〕必须定义类的层次;
〔4〕应当表达对象与对象之间的关系〔即对象的连接〕;
〔5〕必须模型化对象的行为;
〔6〕反复地做任务①~⑤,直到模型建成。
2.OOA概述
目前已经衍生许多种OOA方法。
每种方法都有各自的进行产品或系统分析的过程,有一组可描述过程演进的图形标识,以与能使得软件工程师以一致的方式建立模型的符号体系。
现在广泛使用的OOA方法有以下几种:
〔1〕Booch方法:
Booch方法包含“微开发过程〞和“宏开发过程〞。
微开发过程定义了一组任务,并在宏开发过程的每一步骤中反复使用它们,以维持演进途径。
BoochOOA宏开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系,以与进行一系列求精从而实现分析模型。
〔2〕Rumbaugh方法:
Rumbaugh和他的同事提出的对象模型化技术〔OMT〕用于分析、系统设计和对象级设计。
分析活动建立三个模型:
对象模型〔描述对象、类、层次和关系〕,动态模型〔描述对象和系统的行为〕,功能模型〔类似于高层的DFD,描述穿越系统的信息流〕。
〔3〕Coad和Yourdon方法:
Coad和Yourdong方法常常被认为是最容易学习的OOA方法。
建模符号相当简单,而且开发分析模型的导引直接明了。
其OOA过程概述如下:
·使用“要找什么〞准则标识对象;
·定义对象之间的一般化∕特殊化结构;
·定义对象之间的整体∕部分结构;
·标识主题〔系统构件的表示〕;
·定义属性与对象之间的实例连接;
·定义服务与对象之间的消息连接。
〔4〕Jacobson方法:
也称为OOSE〔面向对象软件工程〕。
Jacobson方法与其他方法的不同之处在于他特别强调使用实例〔usecase〕——用以描述用户与系统之间如何交互的场景。
Jacobson方法概述如下:
·标识系统的用户和它们的整体责任;
·通过定义参与者与其职责、使用实例、对象和关系的初步视图,建立需求模型;
·通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子系统和模型,建立分析模型。
〔5〕Wirfs―Brock方法:
Wirfs―Brock方法不明确区分分析和设计任务。
从评估客户规格说明到设计完成,是一个连续的过程。
与Wirfs―Brock分析有关的任务概述如下:
·评估客户规格说明;
·使用语法分析从规格说明中提取候选类;
·将类分组以表示超类;
·定义每一个类的职责;
·将职责赋予每个类;
·标识类之间的关系;
·基于职责定义类之间的协作;
·建立类的层次表示;
·构造系统的协作图。
〔6〕统一的OOA方法〔UML〕。
统一的建模语言〔UML〕已经在企业中广泛使用,它把Booch、Rumbaugh和Jacobson等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。
UML允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。
在UML中用5种不同的视图来表示一个系统,这些视图从不同的侧面描述系统。
每一个视图由一组图形来定义。
这些视图概述如下:
·用户模型视图:
这个视图从用户〔在UML中叫做参与者〕角度来表示系统。
它用使用实例〔usecase〕来建立模型,并用它来描述来自终端用户方面的可用的场景。
·结构模型视图:
从系统内部来看数据和功能性。
即对静态结构〔类、对象和关系〕模型化。
·行为模型视图:
这种视图表示了系统动态和行为。
它还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。
·实现模型视图:
将系统的结构和行为表达成为易于转换为实现的方式。
·环境模型视图:
表示系统实现环境的结构和行为。
通常,UML分析建模的注意力放在系统的用户模型和结构模型视图,而UML设计建模则定位在行为模型、实现模型和环境模型。
第二节 UML概述
一、UML的语言机制
在UML诞生之前,面向对象领域已经涌现出了许多开发方法与相应的表示机制,它们各有千秋,却又有很多类似之处,往往让使用者无所适从。
UML在这样的背景下应运而生。
它主要以BOOCH方法、OMT方法〔71〕和OOSE方法为基础,同时也吸收了其他面向对象建模方法的优点,形成一种概念清晰、表达能力丰富、适用X围广泛的面向对象的标准建模语言。
UML通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画。
它共定义了10种视图,并将其分为如下4类:
〔1〕用例图〔usecasediagram〕。
从外部用户的角度描述系统的功能,并指出功能的执行者。
〔2〕静态图。
包括类图〔classdiagram〕、对象图〔objectdiagram〕和包图〔packdiagram〕。
类图描述系统的静态结构,类图的节点表示系统中的类与其属性和操作,类图的边表示类之间的联系,包括继承、关联、依赖、聚合等。
对象图是类图一个实例,它描述在某种状态下或在某一时间段,系统中活跃的对象与其关系。
在对象图,一个类可以拥有多个活跃的对象实例。
包图描述系统的分解结构,它表示包(package)以与包之间的关系。
包由子包与类组成。
包之间的关系包括继承、构成与依赖关系。
〔3〕行为图。
包括交互图〔interactivediagram〕、状态图〔statechardiagram〕与活动图〔activitydiagram〕,它们从不同的侧面刻画系统的动态行为。
交互图描述描述对象之间的消息传递,它又可分为顺序图〔sequencediagram〕与合作图〔collaborationdiagram〕两种形式。
顺序图强调对象之间消息发送的时间序。
合作图更强调对象间的动态协作关系。
合作图也可通过消息序号之间消息发送的时间序。
只不过这种表示不如顺序图那样直观。
状态图描述类的对象的动态行为,它包含对象所有可能的状态、在每个状态下能够响应的事件以与事件发生时的状态迁移与响应动作。
活动图描述系统为完成某项功能而执行的操作序例,这些操作序列可以并发和同步。
活动图中包含控制和信息流。
控制流表示一个操作完成后对其后操作的触发,信息流则刻画操作之间的信息交换。
〔4〕实现图〔implementatindiagram〕。
包括构件图〔componentdiagram〕与部署图〔deploymetndiagram〕,它们描述软件实现系统的组成和分布状况。
构件图描述软件实现系统中各组成部件以与它们之间的信赖关系。
一个部件可能是一个资源描述文件、一个二进制文件或一个可执行文件。
构件图主要用于理解和分析软件各部分之间的相互影响程度。
部署图描述作为软件系统运行环境的硬件与网络的物理体系结构,其节点表示实际的计算机和设备,边表示节点之间物理连接关系,也可显示连接的类型与节点之间的依赖性。
在节点内部,可以放置可执行部件和对象以显示节点与可执行软件单元之间的对应关系。
部署图对于软件安装工程师有着重要的参考价值。
例如,图5-2-1表示某大学的课程注册管理系统包含3个用例:
“课表维护〞、“个人课程规划〞和“选课学生花名册查询〞。
教务管理人员使用“课表维护〞用例设置或修改课程属性〔课程的时间、地点、上课老师等〕和增删课程;学生使用“个人课程规划〞用例选课和修改自己的个人课表,收费管理系统根据每个学生的选课情况计算其应缴费用;老师使用“选课学生花名册查询〞用例获取选定其所开课程的学生花名册。
图5-2-1 课程注册管理系统的用例图
图5-2-2表示前述的课程注册管理系统包含“教务管理人员〞、“学生〞、“老师〞、“课程〞、“课程设置〞、“课程注册表〞、“课程注册管理器〞和“课程管理器〞8个类。
前3个类为一般化的“用户〞类的子类。
一门“课程〞可由一到多个“课程设置〞构成,例如,对于全校性的公共基础课,由于选修的学生太多,必须安排不同的老师、不同的教室和不同的时间段。
“学生〞、“老师〞与“课程设置〞之间,“课程注册表〞与“课程注册管理器〞之间以与“课程注册管理器〞与“课程〞之间存在着关联关系。
图5-2-2 课程注册管理系统的类图
图5-2-3通过UML顺序图刻画了“个人课程规划〞用例中学生选课功能的实现过程。
图5-2-3 用UML顺序图表示“个人课程规划〞用例中的学生选课过程
图5-2-4用UML协作图刻画学生选课过程,该图与图5-2-3等价。
图5-2-4 用UML协作图表示“个人课程规划〞用例中的学生选课过程
图5-2-5“课程设置〞对象的状态图。
它表示每个“课程设置〞最多只能容纳50个选课学生。
图5-2-5 UML状态图示例
本章的后继章节结合需求分析过程更具体地介绍UML的用例图、包图、类图和活动图,第八章将结合软件设计过程详细介绍顺序图、协作图、状态图和活动图。
对其他UML图形机制感兴趣的读者,以与希望进一步深入了解UML与其软件开发方法的读者。
二、基于UML的软件开发过程
虽然UML是独立于软件开发过程的,即UML能够在几乎任何一种软件开发过程中使用,但是熟悉一种有代表性的面向对象的软件开发过程,并知悉UML各语言要素在过程中不同阶段的应用,对于理解UML将大有裨益。
图5-2-6表示一种迭代的渐进式软件开发过程,它包含4个阶段:
初启、细化、构造和移交。
图5-2-6 面向对象的迭代、渐进式软件开发过程
1.初启
在初启阶段,软件项目的发起人确定项目的主要目标和X围,并进行初步的可行性分析和经济效益分析。
2.细化
细化阶段的开始标志着项目的正式确立。
软件项目组在此阶段需要完成以下工作:
〔1〕初步的需求分析。
采用UML的用例描述目标软件系统所有比较重要、比较有风险的用例,利用用例图表示参与者与用例以与用例与用例之间的关系。
采用UML的类图表示目标软件系统所基于的应用领域中的概念之间的关系。
这些相互关联的概念构成领域模型。
领域模型一方面可以帮助软件项目组理解业务背景,与业务专家进行有效沟通;另一方面,随着软件开发阶段的不断推进,领域模型将成为软件结构的主要基础。
如果领域中含有明显的流程处理成分,可以考虑利用UML的活动图来刻画领域中的工作流,并标识业务流程中的并发、同步等特征。
〔2〕初步的高层设计。
如果目标软件系统的规模比较庞大,那么经初步需求分析获得的用例和类将会非常多。
此时,可以考虑根据用例、类在业务领域中的关系,或者根据业务领域中某种有意义的分类方法将整个软件系统划分为若干包,利用UML的包图刻画这些包与其间的关系。
这样,用例、用例图、类、类图将依据包的划分方法分属于不同的包,从而得到整个目标软件系统的高层结构。
〔3〕部分的详细设计。
对于系统中某些重要的或者比较高的用例,可以采用交互图进一步探讨其内部实现过程。
同样,对于系统中的关键类,也可以详细研究其属性和操作,并在UML类图中加以表现。
因此,这里倡导的软件开发过程并不在时间轴上严格划分分析与设计、总体设计与详细设计,而是根据软件元素〔用例、类等〕的重要性和风险程度确立优先细化原则,建议软件项目组优先考虑重要的、比较有风险的用例和类,不能将风险的识别和解决延迟到细化阶段之后。
〔4〕部分的原型构造。
在许多情形下,针对某些复杂的用例构造可实际运行的耐用消费品型是降低技术风险、让用户帮助软件项目组确认用户需求的最有效的方法。
为了构造原型,需要针对用例生成详尽的交互图,对所有相关类给出明确的属性和操作定义。
综上所述,在细化阶段可能需要使用的UML语言机制包括:
描述用户需求的用例用用例图、表示领域概念模型的类图、表示业务流程处理的活动图、表示系统高层结构的包图和表示用例内部实现过程的交互图等。
细化阶段的结束条件是,所有主要的用户需求已通过用例和用例图得以描述;所有重要的风险已被标识,并对风险应对措施了如指掌;能够比较精确地估算实现每一用例的时间。
3.构造
在构造阶段,开发人员通过一系列的迭代完成对所有用例的软件实现工作,在每次迭代中实现一部分用例。
以迭代方式实现所有用例的好处在于,用户可以与早参与对已实现用例的实际评价,并提出改进意见。
这样可有效降低大型软件系统的开发风险。
在实际开始构造软件系统之前,有必要预先制定迭代计划。
计划的制定需遵循如下两项原则:
〔1〕用户变为业务价值较大的用例应优先安排;
〔2〕开发人员评估后认为开发风险较高的用例应优先安排。
在迭代计划中,要确定迭代次数、每次迭代所需时间以与每次迭代中应完成〔或部分完成〕的用例。
每次迭代过程由针对用例的分析、设计、编码、测试和集成5个子阶段构成。
在集成之后,用户可以对用例的实现效果进行评价,并提出修改意见。
这些修改意见可以在本次迭代过程中立即实现,也可以在下次迭代中再予以考虑。
构造过程中,需要使用UML的交互图来设计用例的实现方法。
为了与设计得出的交互图协调一致,需要修改或精化在细化阶段绘制的作为领域模型的类图,增加一些为软件实现所必需的类、类的属性或方法。
如果一个类有复杂的生命周期行为,或者类的对象在生命周期内需要对各种外部事件的刺激作出反应,应考虑用UNL状态图来表述类的对象的行为。
UML的活动图可以在构造阶段用来表示复杂的算法过程和有多个对象参与的业务处理过程。
活动图尤其适用于表示过程中的并发和同步。
在构造阶段的每次迭代过程中,可以对细化阶段绘出的懈图进行修改或精化,以便包图切实反映目标软件系统最顶层的结构划分状况。
综上所核对,在构造阶段可能需要使用的UML语言机制包括:
用例与用例图。
它们是开发人员在构造阶段进行分析和设计的基础。
类图。
在领域概念模型的基础上引进为软件实现所必需的类、属性和方法。
交互图。
表示针对用例设计的软件实现方法。
状态图。
表示类的对象的状态—事件—响应行为。
活动图。
表示复杂的算法过程,尤其是过程中的并发和同步。
包图。
表示目标软件系统的顶层结构。
构件图。
部署图。
4.移交
在移交阶段,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 对象 需求 分析 方法