第6章 面向对象方法与UML-1.pptx

第6章 面向对象方法与UML6.1面向对象的软件工程方法 6.1.1面向对象的基本概念面向对象对象类消息类的特性（抽象、继承、封装、多态、重载）包包的接口类6.1面向对象的软件工程方法 6.1.2面向对象的软件工程方法的特征与优势1.面向对象的软件工程方法的特征把数据和操作封装在一起，形成对象。对象是构成软件系统的基本构件。把特征相似的对象抽象为类。类之间可以存在继承或被继承的关系，形成软件系统的层次结构。对象之间通过发送消息进行通信。将对象的私有信息封装起来。外界不能直接访问对象的内部信息，而必须是发送相应的消息后，通过有限的接口来访问。面向对象的方法的最重要的特点就是把事物的属性和操作组成一个整体，从问题域中客观存在的事物出发来识别对象并建立由这些对象所构成的系统。6.1面向对象的软件工程方法 2.面向对象的软件工程方法的优势(1)符合人类的思维习惯。(2)稳定性好。(3)可复用性好。(4)可维护性好。基于以上这些优点，面向对象的软件工程方法越来越受到人们的青睐。6.1面向对象的软件工程方法 6.1.3 面向对象的实施步骤（1）面向对象分析：从问题陈述入手，分析和构造所关心的现实世界问题域的模型，并用相应的符号系统表示。模型必须是简洁、明确地抽象目标系统必须做的事，而不是如何做。分析步骤如下。确定问题域，包括定义论域，选择论域，根据需要细化和增加论域区分类和对象，包括定义对象、定义类、命名区分整体对象以及组成部分，确定类的关系以及结构定义属性，包括确定属性、安排属性定义服务，包括确定对象状态、确定所需服务、确定消息联结确定附加的系统约束6.1面向对象的软件工程方法（2）面向对象设计：面向对象的设计与传统的以功能分解为主的设计有所不同。具体设计步骤如下。应用面向对象分析，对用其他方法得到的系统分析的结果进行改进和完善设计交互过程和用户接口设计任务管理，根据前一步骤确定是否需要多重任务，确定并发性，确定以何种方式驱动任务，设计子系统以及任务之间的协调与通信方式，确定优先级设计全局资源，确定边界条件，确定任务或子系统的软、硬件分配对象设计6.1面向对象的软件工程方法（3）面向对象实现：使用面向对象语言实现面向对象的设计相对比较容易。如果用非面向对象语言实现面向对象的设计时，特别需要注意和规定保留程序的面向对象结构。（4）面向对象测试：对面向对象实现的程序进行测试，包括模型测试、类测试、交互测试、系统（子系统）测试、验收测试等。6.2统一建模语言UML 6.2.1 UML简述 统一建模语言（Unified Modeling Language，UML）是一种通用的可视化建模语言，可以用来描述、可视化、构造和文档化软件密集型系统的各种工件。它由信息系统和面向对象领域的三位著名的方法学家Grady Booch、James Rumbaugh和Ivar Jacobson提出的。它记录了与被构建系统的有关的决策和理解，可用于对系统的理解、设计、浏览、配置、维护以及控制系统的信息。这种建模语言已经得到了广泛的支持和应用，并且已被ISO组织发布为国际标准。UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示UML用来捕获系统静态结构和动态行为的信息UML是独立于过程的，它适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具UML不是一种程序设计语言，但用UML描述的模型可以和各种编程语言相联系6.2统一建模语言UML 6.2.2 UML的特点 UML具有以下几个特点。统一标准面向对象可视化，表达能力强大独立于过程容易掌握使用与编程语言的关系用Java、C+等编程语言可以实现一个系统。支持UML的一些CASE工具（如Rose)可以根据UML所建立的系统模型自动产生Java、C+等代码框架，并且支持这些程序的测试及配置管理等环节的工作。6.2统一建模语言UML 6.2.3 UML的应用范围UML以面向对象的方式来描述系统。最广泛的应用是对软件系统进行建模，但它同样适用于许多非软件系统领域的系统。理论上来说，任何具有静态结构和动态行为的系统都可以使用UML进行建模。当UML应用于大多数软件系统的开发过程时，它从需求分析阶段到系统完成后的测试阶段都能起到重要作用。在需求分析阶段，可以通过用例捕获需求。通过建立用例模型来描述系统的使用者对系统的功能要求。在分析和设计阶段，UML通过类和对象等主要概念及其关系建立静态模型，对类、用例等概念之间的协作进行动态建模，为开发工作提供详尽的规格说明。在开发阶段，将设计的模型转化为编程语言的实际代码，指导并减轻编码工作。在测试阶段，可以用UML图作为测试依据：用类图指导单元测试，用构件图和协作图指导集成测试，用用例图指导系统测试等。6.2统一建模语言UML 6.2.4 UML的图 UML主要用图来表达模型的内容，而图又由代表模型元素的图形符号组成。UML的主要内容可以由下列5类图（共9种图形）来定义。用例图静态图类图、对象图、包图行为图交互图顺序图、协作图。实现图构件图、部署图6.2统一建模语言UML 当采用面向对象技术设计系统时，首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；接着是描述系统的行为。其中在前两步中所建立的模型都是静态的，包括用例图、类图（包含包）、对象图、构件图和部署图等5个图，是UML的静态建模机制。其中在最后一步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系，它包括状态图、活动图、顺序图和协作图等4个图，是UML的动态建模机制。因此，UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。6.2统一建模语言UML 6.2.5 UML“4+1”视图UML用模型来描述系统的静态特征结构及动态特征行为，从不同的角度为系统建模，形成不同的视图。每个视图代表完整系统描述中的一个对象，表示这个系统中的一个特定的方面，每个视图有由一组图组成，每张图强调系统中某一方面的信息。为了更好地表现同一事物的不同方面，我们经常采用不同的视图，每个视图从一个角度看待和描述问题；在UML中，存在“4+1”视图。6.2统一建模语言UML 用例视图，描述项目干系人的需求，所有其他视图都是从用例视图派生而来，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础。逻辑视图，描述系统功能和词汇。作为类和对象的集合，重点是展示对象和类是如何组成系统、实现所需系统行为的。6.2统一建模语言UML 实现视图，描述系统组装和配置管理，对组成基于系统的物理代码的文件和构件进行建模。它同样展示出构件之间的依赖，展示一组构件的配置管理以定义系统的版本。部署视图，描述系统的拓扑结构、分布、移交和安装。建模过程把构件物理地部署到一组物理的、可计算节点上，如计算机和外设上。它允许建模横跨分布式系统节点上的构件的分布。6.3静态建模机制 6.3.1 用例图用例图是从用户的角度描述系统的功能，由用例（User Case）、参与者（Actor）以及它们的关系连线组成。在UML中，参与者使用人形符号表示，并且具有唯一的名称；用例使用椭圆表示，也具有唯一的名称。参与者和用例之间使用带箭头的实现连接，由参与者指向用例正确识别系统的参与者尤为重要。在分析系统的参与者时，除了考虑操作者是否与系统交互之外，还要考虑参与者是否在系统的边界之外，只有在系统边界之外的参与者才能称为参与者，否则只能是系统的一部分在分析用例名称是否合适之时，一个简单有效的方法是将参与者和其用例连在一起读，看是否构成一个完整场景或句子参与者之间可以存在泛化关系，类似的参与者可以组成一个层级结构6.3静态建模机制“小型网上书店系统”部分用例6.3静态建模机制 用例之间的关系有3种1.包含关系如果系统用例较多，不同的用例之间存在共同行为，可以将这些共同行为提取出来，单独组成一个用例。当其他用例使用这个用例之时，它们就构成了包含关系。2.扩展关系在用例的执行过程中，可能出现一些异常行为，也可能会在不同的分支行为中选择执行，这时可将异常行为与可选分支抽象成一个单独的扩展用例，这样扩展用例与主用例之间就构成了扩展关系。3.泛化关系用例之间的泛化关系描述用例的一般与特殊关系，不同的子用例代表了父用例的不同实现。6.3静态建模机制 6.3.2 类图和对象图类图使用类和对象描述系统的结构，展示了系统中类的静态结构，即类与类之间的相互关系。类之间有多种联系方式，如关联（相互连接）、依赖（一个类依赖于或使用另一个类）、泛化（一个类是另一个类的特殊情况）。一个系统有多幅类图，一个类也可以出现在几幅类图中。对象图是类图的实例，它展示了系统在某一时刻的快照。对象图使用与类图相同的符号，只是在对象名下面加上下划线。6.3静态建模机制 图书管理系统中的示例类图图书管理系统中的示例对象图在UML中，类图用具有3个分隔线的矩形表示。顶层分隔表示类和对象的名字，中间表示属性，底层表示操作。对象图通常只有名称和属性。通常情况下，类名称的开头字母用大写，对象名称的开头字母用小写，对象名引用时常常后面跟着类名。另外属性和操作前面的符号表示其可见性。6.3静态建模机制 类与类之间的关系有关联、依赖、泛化和实现等。1）关联（Association）表达模型元素间的一种语义关系，对具有共同的结构特性、行为特性、关系和语义的链的描述。UML中使用一条直线表示关联关系，直线两端上的数字表示重数。关联关系还分为二元关联、多元关联、受限关联、聚集和组合等。6.3静态建模机制 三元关联二元关联指两个类之间的关联。多元关联指一对多或多对多的关联。三元关联使用菱形符号连接关联类。6.3静态建模机制 受限关联用于一对多或多对多的关联。如果关联时需要从多重数的端中指定一个对象来限定，可以通过使用限定符来指定特定对象。比如，一个学生可以借多本书，但这多本书可以根据书的书号不同而区分，这样就可以通过限定符“书号”来限定这些图书中的某一本图书。如图所示。6.3静态建模机制 聚集关联组合关联聚合和组合表示整体-部分的关联，有时也称之为“复合”关系。聚合的部分对象可以是任意整体对象的一部分，比如，“目录”与该目录下的“文件”，班级与该班级的学生等。组合则是一种更强的关联关系，代表整体的组合对象拥有其子对象，具有很强的“物主”身份，具有管理其部分对象的特有责任，比如“窗口”与窗口中的“菜单”。聚合关联使用空心菱形表示，菱形位于代表整体的对象一端；组合关联与聚合关联表示方式相似，但使用实心菱形。6.3静态建模机制 关联类是一种充当关联关系的类，和类一样具有自己的属性和操作。关联类使用虚线连接自己和关联符号。关联类依赖于连接类，没有连接类时，关联类不能单独存在。如图所示的关联类关系，一次借阅中，学生可以借阅一本书，借阅类就是该例子中的关联类。实际上，任何关联类都可以表示成一个类和简单关联关系，但常常采用关联类的表示方式，以便更加清楚地表示关联关系。6.3静态建模机制 重数是关联关系中的一个重要概念，表示关联链的条数。链的两端的数字“1”和符号“*”表示的就是重数。重数可以一个任意的自然数集合，但实际使用中，大于1的重数常常用“*”号代替。所以实际使用的重数多为0、1和符号“*”。一对一关联的两端重数都是1；一对多关联的一端的重数是1，另一端是“*”；多对多关联的两端重数都是0n，常表示为“*”。6.3静态建模机制 2）依赖依赖关系表示的是两个元素之间语义上的连接关系。对于两个元素X和Y，如果元素X的变化会引起对另一个元素Y的变化，则称元素Y依赖于X。其中，X被称为提供者，Y被称为客户。依赖关系使用一个指向提供者的虚线箭头来表示，如图所示。对于类图而言，主要有以下需要使用依赖的情况：客户类向提供者类发送消息提供者类是客户类的属性类型提供者类是客户类操作的参数类型6.3静态建模机制 3）泛化泛化关系描述类的一般-特殊关系，是更一般描述与更特殊描述之间的一种分类学关系，特殊描述常常是建立在一般描述基础上的，特殊类是一般类的子类，而特殊类还可以是另一个特殊类的子类。泛化的这种特点构成泛化的分层结构。在面向对象的分析与设计时，可以把一些类的公共部分（包括属性与操作）提取出来作为它们的父类。这样，子类继承了父类的属性和操作，子类中还可以定义自己特有的属性和操作。子类不能定义父类中已经定义的属性；但可以通过重载的方式重定义父类的操作，这种方式称为方法重载。当操作被重载时，在子类对象的父类引用中调用操作方法，对象会根据重载定义调用该操作在子类中的实现，这种行为称为多态。6.3静态建模机制 类的泛化与继承关系多重继承6.3静态建模机制 4）实现实现关系将一个模型连接到另一个模型，通常情况下，后者是行为的规约（如接口），前者要求必须至少支持后者的所有操作。如果前者是类，后者是接口，则该类是后者的实现。实现与泛化很相似，区别是泛化是针对同层级元素之间的连接，而实现是针对不同语义层上的元素的连接。如子类与父类关系是泛化，类与接口关系是实现。比如，定义“图形”接口，类“圆”则是该接口的实现，如图所示。6.3静态建模机制 6.3.3 包图 包是一种对元素进行分组的机制。如果系统非常复杂，常常包含大量的模型，为了利于理解以及将模型独立出来用于复用，对这些元素进行分组组织，从而作为一个个集合进行整体命名和处理。包的符号如图所示。6.3静态建模机制 包中的元素需要与其它包或类中的元素进行交互，交互过程的可访问性包括：Public（公有访问）（+）：包中元素可以被其他包的元素访问。Private（私有访问）（-）：包中元素只能被同属于一个包的内含元素访问。Protected（保护访问）（#）：包中的元素只能被此包或其继承包内的元素访问。包的一些特征如下：包是包含和管理模型内容的一般组织单元，任何模型元素都可以包含其中。一个模型元素只能存在于一个包中，包被撤销时，其中的元素也被撤销。包可以包含其他包，构成嵌套层次结构。包只是一个概念化的元素，不会被实例化，在软件运行中不会有包存在其中。6.3静态建模机制 组织用例的包图例如，我们可以将“检查信用等级”与“修改信用等级”用例添加到“信用评价”包中，将“登录”与“注册”添加到“登录注册”包中，将“设定航班操作”添加到“后台操作”包中，将其余用例添加到“核心业务”包中，这样，我们可以创建一个包图来显式地显示出系统包含的包，如图所示。6.4 动态建模机制 系统中的对象在执行期间的不同时间点如何通信以及通信的结果如何，就是系统的动态行为，也就是说，对象通过通信相互协作的方式以及系统中的对象在系统生命期中改变状态的方式，是系统的动态行为。UML的动态建模机制包括顺序图、协作图、状态图和活动图。6.4 动态建模机制 6.4.1 顺序图 顺序图描述了一组对象的交互方式，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。顺序图由对象（参与者的实例也是对象）、生命线、控制焦点、消息等组成。生命线是一条垂直的虚线，表示对象的存在时间；控制焦点是一个细长的矩形，表示对象执行一个操作所经历的时间段；消息是作用于控制焦点上的一条水平带箭头的实现，表示消息的传递。6.4 动态建模机制 顺序图消息类型6.4 动态建模机制 6.4.2 协作图协作图又称通信图（或合作图），用于显示系统的动作协作，类似顺序图中的交互片段，但协作图也显示对象之间的关系（上下文）。实际建模中，顺序图和协作图的选择需要根据工作的目标而定。如果重在时间或顺序，那么选择顺序图；如果重在上下文，那么选择协作图。顺序图和协作图都显示对象之间的交互。协作图显示多个对象及它们之间的关系，对象间的箭头显示消息的流向。消息上也可以附带标签，表示消息的其他信息，如发送顺序、显示条件、迭代和返回值等。6.4 动态建模机制 在图中，一个匿名的User类对象首先向登录界面对象输入了用户信息，接着用户界面向用户数据对象请求验证用户信息是否正确并得到请求的返回结果，最后登录界面根据返回的结果向用户反馈对应的登录结果。6.4 动态建模机制 6.4.3 状态图 状态图由状态机扩展而来，用来描述对象对外部对象响应的历史状态序列，即描述对象所有可能的状态，以及哪些事件将导致状态的改变。包括对象在各个不同状态间的跳转以及这些跳转的外部触发事件，即从状态到状态的控制流。状态图侧重于描述某个对象的动态行为，是对象的生命周期模型。并不是所有的类都需要画状态图。有明确意义的状态、在不同状态下行为有所不同的类才需要画状态图。6.4 动态建模机制 6.4 动态建模机制 6.4.4 活动图活动图中的活动是展示整个计算步骤的控制流（及其操作数）的结点和流的图。执行的步骤可以是并发的或顺序的。活动图可以看作特殊的状态图，用于对计算流程和工作建模（后者是对对象的状态建模）。活动图的状态表示计算过程中的所处的各种状态。活动图的开始结点和结束结点与状态图相同，活动图中的状态称为动作状态，也使用圆角矩形表示。动作状态之间使用箭头连接，表示动作迁移，箭头上可以附加警戒条件、发送子句和动作表达式。活动图是状态图的变形，根据对象状态的变化捕获动作（所完成的工作和活动）和它们的结果，表示了各动作及其间的关系。如果状态转换的触发事件是内部动作的完成，可用活动图描述；当状态的触发事件是外部事件时，常用状态图表示。6.4 动态建模机制 某银行ATM机中的取款活动图6.5 描述物理架构的机制 系统架构分为逻辑架构和物理架构两大类。逻辑架构完整地描述系统的功能，把功能分配到系统的各个部分，详细说明它们是如何工作的。物理架构详细地描述系统的软件和硬件，描述软件和硬件的分解。在UML中，用于描述逻辑架构的图有：用例图、类图、对象图、状态图、活动图、协作图和顺序图；用于描述物理架构的图有：构件图、部署图6.5 描述物理架构的机制 6.5.1 构件图 构件图根据系统的代码构件显示系统代码的物理结构。其中的构件可以是源代码构件、二进制构件或者可执行构件。构件包含了其实现的一个或多个逻辑类信息，因此也就创建了从逻辑视图到构件视图的映射。根据构件视图中构件之间的关系，可以轻易地看出当某一个构件发生变化时，哪些构件会受到影响。6.5 描述物理架构的机制 图书管理系统构件示例图6.5 描述物理架构的机制 6.5.2 部署图部署图用于显示系统中硬件和软件的物理结构，可以显示实际中的计算机和设备（节点），以及它们之间的互连关系。在部署图中的节点内，已经分配了可以执行的组件和对象，以显示这些软件单元具体在哪个节点上运行。部署图也显示了各组件之间的依赖关系。部署图是对系统实际物理结构的描述，不同于用例图等从功能角度的描述。对一个明确定义的模型，可以实现完整的导航：从物理部署节点到组件，再到实现类，然后是该类对象参与的交互，最后到达具体的用例。系统的各种视图合在一起，从不同的角度和细分层面完整地描述整个系统。6.5 描述物理架构的机制 图书管理系统物理结构部署图