320 likes | 488 Views
教学目的:理解面向对象的概念、掌握基于 UML 语 言机制的需求分析方法和过程。 教学重点:基于 UML 语言机制的需求分析方法和过 程、 CASE 工具 教学难点: CASE 工具 教 具:多媒体教室、电子教案 作 业:. 第 6 章 面向对象的需求分析.
E N D
教学目的:理解面向对象的概念、掌握基于UML语教学目的:理解面向对象的概念、掌握基于UML语 言机制的需求分析方法和过程。 教学重点:基于UML语言机制的需求分析方法和过 程、CASE工具 教学难点: CASE工具 教 具:多媒体教室、电子教案 作 业: 第6章 面向对象的需求分析
面向对象(Object Oriented)方法是将现实世界的事物以对象的方式映射到计算机世界的方法。用面向对象的方法求解现实世界问题的第一步便是面向对象分析。面向对象分析包含两个可以重叠的过程:用面向对象的方法对现实世界的问题进行分析;用面向对象的工具对分析结果进行描述。 本章重点介绍面向对象的方法,并用“C程序设计上机考试系统”为例来介绍UML语言机制。 6.1面向对象的概念与思想
现实世界 SA SD SP 面向对象方法 结构化生命周期方法 OOA OOD 机器世界 OOP 面向对象方法和面向过程方法的对比
从事物的过程侧面来描述事物的方法被称之为面向过程的方法。该方法在认识现实事物的整个过程中是把事物内部的处理过程作为核心来描述的。从事物的过程侧面来描述事物的方法被称之为面向过程的方法。该方法在认识现实事物的整个过程中是把事物内部的处理过程作为核心来描述的。 从事物的组成部件及每个部件的属性、功能来认识事物。比如,汽车由发动机,底盘,变速箱等组成,发动机有排量,有冲程数等属性,同时发动机还具有启动,加大油门等操作。这就是将现实世界的事物的属性和及其过程一并进行描述的方法,这种方法被称为面向对象的方法。 从事物的属性侧面来描述事物的方法就是面向数据的方法,该方法在认识事物的过程中始终把事物的属性作为描述的核心。 6.1 面向对象的概念与思想
在抽象现实世界的事物时,必须把抽象的范围限定在我们的问题域内。现实世界的事物都有很多侧面,我们只应关心那些跟我们要解决的问题相关的侧面。在抽象现实世界的事物时,必须把抽象的范围限定在我们的问题域内。现实世界的事物都有很多侧面,我们只应关心那些跟我们要解决的问题相关的侧面。 比如:在抽象和描述“学生”对象时,针对不同的问题域,可能得到不同的抽象结果。对于学生管理系统,学生的成绩、所选的课程等在问题域范围内,而学生的病史,过敏史则不在问题域内;如果是一个医管系统,病史,过敏史则落在问题域内。 下面介绍面向对象的五大要素: 6.1 面向对象的概念与思想
对象是现实世界事物或个体的抽象表示,是其属性和相关操作的封装。抽象的结果不仅包括事物个体的属性,还包括事物的操作。属性值表示了对象的内部状态。对象是现实世界事物或个体的抽象表示,是其属性和相关操作的封装。抽象的结果不仅包括事物个体的属性,还包括事物的操作。属性值表示了对象的内部状态。 在分析阶段,对象的操作是对象展现给外部的服务。对象状态的改变是由对对象的操作引起的。 例如,对于民航机场的指挥控制系统,MU9114航班就是该问题域中的对象,该对象的属性可以包含:航班号、起飞机场、降落机场、起飞时间、降落时间,位置等;可能的操作包括离港、到港等。当对MU9114航班对象进行离港操作时,对象的状态将从停靠状态改变成飞行状态。 (1) 对象(Object)
类是对具有共同特征(属性和操作)的对象的进一步抽象。类通常被认为是对象的模板,通过该模板可以创建特性一致的对象。使用类创建对象的过程实际上是类的实例化过程。类是对象的抽象,对象是类的实例。在客观世界存在的是类的实例,即对象。类是对具有共同特征(属性和操作)的对象的进一步抽象。类通常被认为是对象的模板,通过该模板可以创建特性一致的对象。使用类创建对象的过程实际上是类的实例化过程。类是对象的抽象,对象是类的实例。在客观世界存在的是类的实例,即对象。 (3)继承(Inheritance) 继承关系模拟了现实世界中遗传关系的直接模拟,也即一般与特殊关系的模拟。它允许我们在已有的类的特性基础上构造新类。被继承的类我们称之为基类(父类),在基类的基础上新建立的类我们称之为派生类(子类)。派生类的特性比基类的特性更细致。 (2) 类(Class)
聚集模拟了现实世界的部分与整体的关系。它允许利用现有的类组成新类。比如说汽车,它是由发动机、变速箱、底盘等组成,那么我们就可以利用发动机、变速箱、底盘等类聚集成一个新的类:汽车类。聚集模拟了现实世界的部分与整体的关系。它允许利用现有的类组成新类。比如说汽车,它是由发动机、变速箱、底盘等组成,那么我们就可以利用发动机、变速箱、底盘等类聚集成一个新的类:汽车类。 (5) 消息(Message) 消息是对象之间交互的唯一途径,一个对象要想使用其他对象的服务,必须向该对象发送服务请求消息。而接收服务请求的对象必须对请求做出响应。 例如:当我们向银行系统的帐号对象发送取款消息时,帐号对象将根据消息中携带的取款金额对客户的帐号进行取款操作:验证帐号余额,如果帐号余额足够,并且操作成功,对象将把执行成功的消息返回给服务请求的发送对象,否则发送交易失败消息。 (4) 聚集(Aggregation)
小结:面向对象的需求分析方法通过提供对象、对象间消息传递等语言机制,让分析人员在解空间中直接模拟问题空间中的对象,从而消减运用其他分析方法带来的语义断层,为需求建模活动提供直观、自然的语言支持和方法学指导。小结:面向对象的需求分析方法通过提供对象、对象间消息传递等语言机制,让分析人员在解空间中直接模拟问题空间中的对象,从而消减运用其他分析方法带来的语义断层,为需求建模活动提供直观、自然的语言支持和方法学指导。 面向对象=对象+类+继承+聚集+消息。 6.1 面向对象的概念与思想
6.2.1 UML 语言机制 UML通过图形化的表示机制从多个侧面对系统的分析和设计模型进行刻画,共有5类10种视图如下所示: 静态模型 动态模型 逻辑模型 类图 用例图 对象图 顺序图 包图 协作图 状态图 活动图 物理模型 构件图 配置图 6.2 UML 概述
1、用例图(Usecase Diagram):用于表示系统的功能,并指出各功能的操作者; 2、静态图:包括类图(Class Diagram)、对象图(Object Diagram)及包图(Package Diagram),表示系统的静态结构; 3、行为图:包括状态图(State Diagram)及活动图(Activity Diagram),用于描述系统的动态行为和对象之间的交互关系; 4、交互图:包括顺序图(Sequence Diagram)和协作图(Collaboration Diagram),用于描述系统对象之间的动态合作关系; 5、实现图:包括构件图(Compoment Diagram)和配置图(Deployment Diagram),用于描述系统的物理实现。 6.2.1 UML 语言机制
6.2.2 基于UML 的软件开发过程 1、初启:确定项目的主要目标和范围,并进行初步的可行性分析和经济效益分析。 2、细化:细化阶段的开始标志着项目的正式确立。软件项目在此阶段需要完成以下工作: (1)初步的需求分析。采用UML的用例描述目标软件系统所有比较重要、比较有风险的用例,利用用例图表示参与者与用例、以及用例和用例之间的关系。采用UML的类图表示目标软件系统所基于的应用领域中的概念与概念之间的关系。这些相互关联的概念构成领域模型。 (2)初步的高层设计。根据用例、类在业务领域中的关系,或者根据业务领域中某种有意义的分类方法将整个软件系统划分为若干个包,利用UML的包图刻化这些包及其包间关系。
6.2.2 基于UML 的软件开发过程 (3)部分的详细设计。对于系统中某些重要的或者风险比较高的用例, 可以采用交互图进一步探讨其内部实现过程。同样,对于系统中的关键类,也可以详细研究其属性和操作,并在UML类图中加以表现。 (4)部分的原型构造。 综上所述,在细化阶段可能需要使用的UML语言机制包括:描述用户需求的用例及用例图、表示领域概念模型的类图、表示业务流程处理的活动图、表示系统高层结构的包图和表示用例内部实现过程的交互图等。 细化阶段的结束条件是,所有主要的用户需求已通过用例和用例图得以描述;所有重要的风险已被标识,并对风险应对措施了如指掌;能够比较精确地估算实现每一用例的时间。
6.2.2 基于UML 的软件开发过程 3、构造:在构造阶段,开发人员通过一系列的迭代完成对所有用例的软件实现工作,在每次迭代中实现一部分用例。以迭代方式实现所有用例的好处在于,用户可以及早参与对已实现用例的实际评价,并提出改进意见。这样可有效降低大型软件系统的开发风险。 在实际开始构造软件系统之前,有必要预先制定迭代计划。计划的制定应遵循如下两项原则: (1)用户认为业务价值较大的用例应优先安排; (2)开发人员评估后认为开发风险较高的用例应优先安排。
6.2.2 基于UML 的软件开发过程 • 在迭代计划中,要确定迭代次数、每次迭代所需时间及每次迭代中应完成(或部分完成)的用例。 • 每次迭代过程由针对用例的分析、设计、编码、测试和集成5个子阶段构成。在集成之后,用户可以对用例的实现效果进行评价,并提出修改意见。这些修改意见可以在本次迭代过程中立即实现,也可以在下次迭代中再予以考虑。 • 构造过程中,需要使用UML的交互图来设计用例的实现方法。为了与设计得出的交互图协调一致,需要修改或精化在细化阶段绘制的作为领域模型的类图,增加一些为软件实现所必需的类、类的属性或方法。
6.2.2 基于UML 的软件开发过程 • 如果一个类有复杂的生命周期行为,或者类的对象在生命周期内需要对各种外部事件的刺激作出反应,应考虑用UML的状态图来表述类的对象的行为。 • UML的活动图可以在构造阶段用来表示复杂的算法过程和有多个对象参与的业务外理过程。活动图尤其适用于表示过程中的并发和同步。 • 在构造阶段的每次迭代过程中,可以对细化阶段绘出的包图进行修改或精化,以便包图切实反映目标软件系统最顶层的结构划分状况。 • 4、移交 • 在移交阶段,开发人员将构造阶段获得的软件系统在用户实际工作环境(或接近实际的模拟环境)中试运行,根据用户的修改意见进行少量修改。
6. 3 基于UML的需求分析 基于UML的需求分析步骤: (1)利用用例及用例图表示需求。 (2)利用包图及类图表示目标软件系统的总体框架结构。 6.3.1 开发场景 场景:是指从单个执行者的角度观察目标软件系统的功能和行为。这种功能通过系统与用户之间的交互来表征。因此也可以说,场景是用户与系统之间进行交互的一组具体的动作。场景是用例的实例,而用例是某类场景的共同抽象。 场景描述:场景名称、执行者实例、前置条件、事件流和后置条件。
6.3.2 生成用例 执行者:是指外部用户或外部实体在系统中扮演的角色。 用例:从外部用户的视角看,一个用例是执行者与目标软件系统之间的一次典型的交互作用。从软件系统内部的视角出发,一个用例代表系统执行的一系列动作,动作执行的结果能够被外部的执行者所观察。 用例描述:用例名称、参与执行者、前置条件、一个主事件流、零到多个辅助事件流和后置条件。
6.3.3 用活动图表示用例 活动图主要用于系统分析,它描述系统的行为,显示系统中动作之间的转移。活动图一般从开始节点开始,经过若干动作后,最后到达结束节点。 活动图是简化的状态图,它重点说明了活动间所经过的操作和过程。活动图(Activity)只有一个动作(Action),活动的转移有一个相应的触发事件。活动图可用来描述用例、包和类的行为,它把活动描述成正在执行的操作,活动代表了一个完整的动作,即它代表一个类或用例内部的行为。活动图不区分状态、活动和事件,它是一个从活动到活动的简单描述,其中,同步线用粗横线表示,用于表示活动之间的同步。
6.3.3 用活动图表示用例 同步线 考生考试的活动图
6.3.4 生成用例图 执行者和用例之间的关系:触发执行和信息交换。(可能同时兼具这两种关系) 从执行者指向用例的边表示触发执行/信息交换;而从用例指向执行者的边表示用例将其生成的信息传递给执行者。 UML的用例和用例之间的关系:使用关系和扩展关系。 使用关系:如果有一个公共的动作序列存在于多个用例中,为避免重复,并使需求模型更简洁,可以将公共动作序列抽出来构成新的独立用例。这样,原来的多个用例与新的用例之间便通过使用关系来连接。 扩展关系:如果一个用例的动作序列完全包含另一个用例的动作序列,且前者含有后者所不具备的一些特殊情况下的处理动作,则称前者扩展后者。
6.3.4 生成用例图 学生考试用例
6.3.5 建立顶层架构 UML包图:对类进行分组的一种机制。 包间的两种关系:依赖和构成。 依赖关系:如果对类A的修改将导致类B的改变,则称B依赖于A。 构成关系:是指包可以嵌套,即包中不仅可包含类,还可以包含子包。
6.3.5 建立顶层架构 考试系统包图
6.3.6 建立领域概念模型 UML类图:类表示概念,用类图表示领域概念模型。 类图图元:类的名称、属性列表、方法列表。 类间关系:继承、聚集、关联和依赖。 继承关系:表示子类重用父类的属性和操作,子类的对象也是父类的对象,有时也称父类是子类的泛化。子类继承了父类的所有属性和操作,但每个子类又有自己的特殊属性,也就是说父类所具有的属性和操作,子类肯定有,父类能够完成的工作子类肯定能完成,反之不然。
6.3.6 建立领域概念模型 例如在下图所示的泛化关系中,“题库”类是比“选择题”类、“判断题”类和“程序设计题”类更普遍的概念,相反“选择题”类是比“题库”类更特殊的概念。这样“题库”是一个父类,“选择题”、“判断题”和“程序设计题”是这个父类的子类。父类的“题号”、“试题类型”、“试题属性”全部被子类继承,但每个子类又都有自己的特殊属性,比如判断题类的属性“标准答案”,而父类没有。
6.3.6 建立领域概念模型 继承关系/泛化关系
6.3.6 建立领域概念模型 聚集关系:对部分-整体关系的直接模拟。分普通聚集和构成关系两种。 普通聚集和构成是两种类型的关联,它们是对现实世界中部分和整体关系的直接模拟。在普通聚集关系中,一个部件类对象可同时参与多个整体类对象。在构成关系中,一个部件类对象在任意时刻只能参与一个整体类对象,部件类对象与整体类对象共存亡。 在UML中用空心菱形记号表示普通聚集关系,用实心菱形表示构成关系。菱形在整体一端。左图为聚合关系,右图为组合关系。
6.3.6 建立领域概念模型 构成关系 聚集关系
关联关系:关联(association):关系对象间相互独立,通常体现为调用等形式。如果关联关系:关联(association):关系对象间相互独立,通常体现为调用等形式。如果 (1)类A的对象向类B的对象发送一条消息; (2)类A的对象建立类B的对象; (3)类A的对象包含一个属性,属性的取值是类B的对象或类B的对象的集合; (4)类A的对象接受消息,类B的对象是消息的参数; 则类A和类B相互关联。 例如,表示对象“王老师”与“1号试卷”之间存在“出题”的关系,它们之间有消息传递,因此类“考务人员”与“试卷”之间存在关联关系。下图可描述为“1号试卷是由王老师出的”。
6.3.6 建立领域概念模型 关联关系表示在两个类的对象之间存在着一种用于消息传递的稳定通道。 普通关联关系
6.3.6 建立领域概念模型 依赖关系:它是关联关系的弱化,表示被依赖的类的变化会影响到依赖类。 依赖关系的起因:依赖类的对象需要向被依赖类的对象传递消息;被依赖类作为依赖类的操作的形参类型。 前一种情况可以用依赖、关联及其强化形式(聚合和构成)来实现。 区别:依赖关系仅表示一种临时性的消息传递通道,一旦依赖类对象的操作完成,该通道立即消失;而关联关系及其强化形式则表示消息传递通道在整个对象的生命周期中稳定存在。 综上所述:关联是依赖的强化,聚合是关联的强化,构成是聚合的强化。 返回目录