面向对象分析与设计(5)-设计模型
- 格式：ppt
- 大小：496.00 KB
- 文档页数：69
下载文档原格式
合集下载
UML面向对象分析、建模与设计课件第五章 类图
即可变、只增与冻结。
类——操作
操作是一个可以由类的对象请求以影响其行为的服务的实现，也即 是对一个对象所做的事情的抽象，并且由这个类的所有对象共享。
操作是类的行为特征或动态特征。 操作的语法格式为：
可见性OPT 操作名 ⌊(参数列表)⌋OPT ⌊:返回类型⌋OPT ⌊{特性}⌋OPT
操作名：操作的标识符。在描述操作时，操作名是必须的，其他部 分可选。
Student
+monitor 1
1..*
自关联
类图中的关系——关联关系
关联名称：放在关联路径的旁边，但远离关联端。 角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联
关系中担任的角色。角色名上也可使用可见性修饰符号。 多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对
象可以与目标类的多少个对象之间有关联。 导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。 限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用
/WorksForCompany
Department * +department 1 WorksForDepartment
* Person
类图中的关系——泛化关系
泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元 关系。其中描述一般的元素称为父，描述特殊的元素称为子。
通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型 的规模，同时也防止了模型的更新所导致的定义不一致的意外。
法了，此时称之为N元关联。
类图中的关系——关联关系
class Logical View
ClassA
AssociationName
+rolename 0..*
类——操作
操作是一个可以由类的对象请求以影响其行为的服务的实现，也即 是对一个对象所做的事情的抽象，并且由这个类的所有对象共享。
操作是类的行为特征或动态特征。 操作的语法格式为：
可见性OPT 操作名 ⌊(参数列表)⌋OPT ⌊:返回类型⌋OPT ⌊{特性}⌋OPT
操作名：操作的标识符。在描述操作时，操作名是必须的，其他部 分可选。
Student
+monitor 1
1..*
自关联
类图中的关系——关联关系
关联名称：放在关联路径的旁边，但远离关联端。 角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联
关系中担任的角色。角色名上也可使用可见性修饰符号。 多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对
象可以与目标类的多少个对象之间有关联。 导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。 限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用
/WorksForCompany
Department * +department 1 WorksForDepartment
* Person
类图中的关系——泛化关系
泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元 关系。其中描述一般的元素称为父，描述特殊的元素称为子。
通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型 的规模，同时也防止了模型的更新所导致的定义不一致的意外。
法了，此时称之为N元关联。
类图中的关系——关联关系
class Logical View
ClassA
AssociationName
+rolename 0..*
uml系统分析与设计uml系统建模基础教程课后习题答案.docx
UML系统建模基础教程课后答案第一章面向对象设计与UML1.填空题(1)UML(2)封装继承多态(3)继承(4)瀑布模型喷泉模型基于组件的开发模型XP开发模型2.选择题(1) C(2) A B C D(3) A B C D(4) A B C(5) A3.简答题1.试述对象和类的关系。
(1)类是具有相同或相似结构、操作和约束规则的对象组成的集合，而对彖是某一类的具体化实例，每一个类都是具有某些共同特征的对象的抽象。
类与对象的关系就如模具和铸件的关系，类的实例化结果就是对象，而对一类対象的抽象就是类.类描述了一组有相同特性和相同行为的对象。
第二章UML通用知识点综述1.填空题(1)依赖泛化关联实现(2)视图图模型元素(3)实现视图部署视图(4)构造型标记值约束(5)规格说明修饰通用划分2.选择题(1) D(2) C(3) A(4) A B(5) D3.简答题(1)在UML中面向对象的事物有哪几种？在UML中，定义了四种基本的面向对象的事物，分别是结构事物、行为事物、分组事物和注释事物等。
(2)请说出构件的种类。
构件种类有：源代码构件、二进制构件和可执行构件。
(3)请说出试图有哪些种类。
在UML中主要包括的视图为静态视图、用例视图、交互视图、实现视图、状态机视图、活动视图、部署视图和模型管理视图。
(4)请说出视图和图的关系。
视图和图是包含和被包含的关系。
在每一种视图中都包含一种或多种图。
(5)请简述UML的通用机制。
UML提供了一些通用的公共机制，使用这些通用的公共机制(通用机制)能够使UML在各种图中添加适当的描述信息，从而完善UML的语义表达。
逋常，使用模型元素的基本功能不能够完善的表达所要描述的实际信息，这些通用机制可以有效地帮助表达，帮助我们进行有效的UML 建模。
UML提供的这些通用机制，贯穿于整个建模过程的方方面面。
前面我们提到，UML的通用机制包括规格说明、修饰和通用划分三个方面。
第三章Rational统一过程1.填空题(1)角色活动产物工作流(2)逻辑视图过程视图物理视图开发视图用例视图(3)设计开发验证(4)二维(5)周期迭代过程里程碑2.选择题(1) A B C D(2) A C D(3) A C D(4) A B C(5) A B C D3.简答题(1)请描述迭代过程有几个阶段。
面向对象分析与设计
面向对象分析与设计在软件开发过程中，面向对象分析与设计（Object-Oriented Analysis and Design，简称OOAD）是一种重要的方法论。
通过OOAD，开发者可以将现实世界中的概念和问题转化为软件系统的结构和行为。
一、什么是面向对象分析与设计？面向对象分析与设计是一种以对象为核心的开发方法。
它强调将问题领域的实体、关系和行为抽象为对象、类和方法。
面向对象的分析阶段主要关注问题领域的需求和约束，而设计阶段则更关注如何将需求转化为可执行的软件系统。
二、面向对象分析与设计的优势1. 模块化：面向对象的方法将复杂的系统拆分为多个独立的对象，每个对象都有清晰的职责和接口。
这种模块化可以提高代码的可维护性和可复用性。
2. 继承与多态：继承是面向对象编程中的重要特性，它允许新的类继承已有类的属性和方法。
多态则允许对象在不同上下文中表现出不同的行为。
这些特性使得代码更加灵活和易于扩展。
3. 封装与信息隐藏：面向对象的方法将数据和操作封装在对象内部，外界只能通过对象的接口进行交互。
这种封装和信息隐藏可以保护数据的完整性和安全性。
4. 规范化的开发流程：面向对象的分析与设计有一套规范的开发流程，包括需求分析、概念设计、详细设计和实现等阶段。
这种流程可以提高开发效率，并减少错误和重复工作。
三、面向对象分析与设计的过程1. 需求收集与分析：在这个阶段，开发者与用户密切合作，收集和分析系统的业务需求。
通过访谈、文档分析等方法，确定系统的功能、性能和约束等方面的要求。
2. 概念设计：在概念设计阶段，开发者将业务需求转化为概念模型。
通过绘制用例图、类图、状态图等工具，描述系统的结构和行为。
3. 详细设计：在详细设计阶段，开发者将概念模型进一步细化，确定具体的类和接口。
同时，还需要考虑系统的性能、安全和可维护性等方面的问题。
4. 编码与测试：在编码阶段，开发者根据详细设计的要求，使用具体的编程语言实现系统。
面向对象分析和设计方法的实践应用
面向对象分析和设计方法的实践应用面向对象分析和设计方法（OOAD），是一种以对象为基础的软件开发方法。
通过面向对象的思想，将软件系统中的各个部分进行抽象化，并通过类与对象的关系构建软件系统的模型。
其主要的思想是将软件系统中的各个部分看作是对象，通过这些对象能够互相沟通与交互。
凭借其严密的实践应用，OOAD已成为日常软件开发中的事实标准。
1. OOAD的基本流程OOAD有自己的基本流程，其主要步骤包括需求捕捉、面向对象的域分析、面向对象的设计、面向对象的编程和测试。
通过这些步骤，软件开发人员可以有效地完成一个软件系统的开发过程。
2. OOAD在实践中的应用在实际的软件开发中，OOAD可以应用于各个方面。
例如，在设计一个可靠的银行账户管理系统时，SOAD就是一个非常实用的面向对象分析和设计模型。
该模型能够在一个对象模型中把系统中所有的角色和过程进行抽象化，并为每个角色和过程分配隶属关系。
这种模型可以帮助开发人员完成系统的编码和维护，同时也可以为银行的人员提供一个清晰的管理界面。
另一个例子是利用OOAD来设计制造业中的产品。
在这一领域，OOAD可以帮助设计人员创建一个稳固的产品模型。
通过这个模型，他们可以快速及准确地观察制造过程的各个方面，并对过程进行调整，确保这个模型最终能够成为一个理想的产品。
与此同时，这种模型也可以为制造企业提供支持，并协助其在全球市场上快速发展。
3. OOAD的优势与挑战虽然OOAD已经成为了软件开发的标准，但其仍然存在着一些挑战和缺陷。
其中最大的挑战之一便是如何确保开发人员始终保持该方法的高标准。
虽然OOAD可在企业中发挥强有力的作用，但开发人员必须始终处于高度专业的状态，才能充分利用OOAD的优势。
管理者也应该为此提供必要的支持，以确保接到的项目能够高效完成。
OCAD最大的优势在于其对软件开发过程的理解与体现。
其通过有效的面向对象的思想，将加速整个软件开发过程。
此外，它可以帮助开发人员更快地实现整体性能的调整和模型的优化。
面向对象分析与设计—四色原型模式
面向对象分析与设计—四色原型模式1.背景介绍至今我都清楚的记得我第一次被面试官问起什么叫“建模”技术时的情景，那是好几年前的事情了，当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。
面试官几乎没问我有关.NET方面的任何技术实现，他就简单的问了问：“你如何把握你所分析出来的系统的正确性？”，我当时有点小激动，觉得这个问题应该很简单嘛，都是概念而已，让他直接点问，结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？”，接着他出了一个小例子，让我对这个例子进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。
他最后重点强调了一下：“创建出来的模型是不允许跟任何具体的代码、工具有关联的”。
在我现在看来，他的意思也就是说创建出来的UML类图模型是领域无关模型（领域通用模型），可以用任何一种编程技术去实现他，作为建模者不需要考虑这些实现细节，考虑的越多越容易分散你对真实业务的等价建模，容易犯技术人员的通病（用技术的思维来考虑业务）。
我当时心想这个容易啊，不就是用UML搞点图出来做做秀嘛，体现出分析、设计的高端嘛，其他还能有啥作用；其实我当时之所以这么想是因为我对UML、建模也尝试过学习、理解和运用，结果我发现这就是一个作秀的工具罢了，对这个东西很不屑，甚至对软件工程中的“建模”领域有一种抵触心理。
我当时随口说了一些我学习UML建模时的心得，心想这个也就是最终答案了，因为它确实就是这个作用（“作秀”），然后我通过代码驱动建模，倒着推导出UML的类图，结果和我意料的差不多；基本上都覆盖了这个小例子的几大方面，反正面试官不知道我是如何得出这个UML类图的，只有天知道，我是通过先构建代码模型然后反方向推到出类图模型的，嘴上说的跟心理想的完全是相反的。
在我感觉非常良好的等着面试官接着问下一个问题的时候，情况出现了。
面试官说我漏掉了东西，说我没有充分考虑到业务场景，没有将业务概念中的关键概念划分清楚，甚至疏忽了很重小的领域实体属性，按照我这个模型图开发出来的软件是不能够满足现在的业务要求的。
面向对象分析与设计
《面向对象的分析与设计》是2013年清华大学出版社出版的图书，作者是邵维忠、杨芙清。
本书是一本全面论述面向对象分析与设计方法的专著。
全书分为3部分。
第一部分为基础篇，论述面向对象方法的基本思想和主要概念，对不同的分析与设计方法进行综述，对统一建模语言(UML)和本书提出的方法做概要介绍。
第二部分为分析篇，详细介绍面向对象分析的全过程，围绕面向对象建模中的需求模型（用况图）、基本模型（类图）、辅助模型（包图、顺序图、活动图以及其他各种UML模型图）和模型规约，对面向对象的分析进行深入讨论，给出详细的过程指导和工程策略，并对相关的UML内容做较详细的介绍。
第三部分为设计篇，介绍如何在面向对象分析模型基础上，针对具体的实现条件进行面向对象的系统设计，包括问题域部分、人机交互部分、控制驱动部分和数据接口部分4个主要部分的设计，最后介绍如何进行构件化与系统部署。
第一部分基础篇第1章面向对象方法概论31.1 什么是面向对象31.2 从认识论看面向对象方法的形成51.2.1 软件开发--对事物的认识和描述51.2.2 语言的鸿沟51.2.3 编程语言的发展使鸿沟变窄51.2.4 软件工程学的作用81.2.5 面向对象是软件方法学的返璞归真121.3.1 对象131.3.2 类141.3.3 封装161.3.4 继承171.3.5 聚合181.3.6 关联201.3.7 消息211.3.8 多态性221.3.9 其他221.3.10 术语对照241.4 面向对象方法的历史及现状261.4.1 历史261.4.2 发展到软件生存周期全过程271.4.3 渗透到计算机软件的各个领域30第2章不同的分析与设计方法332.1 功能分解法332.2 结构化方法342.3 信息建模法35目录面向对象的分析与设计2.4 面向对象方法362.4.1 什么是OOA362.4.2 什么是OOD372.4.4 几种典型的面向对象方法41 2.4.4.1 Booch方法432.4.4.2 Coad/Yourdon方法452.4.4.3 Jacobson方法482.4.4.4 Rumbaugh方法52第3章统一建模语言UML简介56 3.1 UML的背景与发展历史563.2 UML1概况583.2.1 UML1规范的主要组成部分58 3.2.2 语言体系结构和定义方式59 3.2.3 UML1的各种图和扩展机制62 3.3 UML2概况663.3.1 从UML1到UML2663.3.2 UML2的4个规范673.3.2.1 UML基础结构673.3.2.2 UML上层结构683.3.2.3 对象约束语言693.3.2.4 UML图交换703.3.3 UML2的各种图70第4章本书的OOA&D方法概貌74 4.1 引言744.2 主要概念744.2.1 主要模型元素754.2.2 面向对象建模的主要原则764.3 模型及其规约804.3.1 基本模型--类图804.3.2 需求模型--用况图814.3.3 辅助模型--其他各种图824.3.4 模型规约824.3.5 OOA模型框架OOA模型框架834.3.6 OOD模型框架OOD模型框架834.4 建模过程854.4.1 OOA过程854.4.2 OOD过程874.5 OOA与OOD的关系884.5.1 一致的概念与表示法884.5.2 不同的目标、内容和抽象层次894.5.3 在软件生存周期中的位置904.5.4 两种不同的分工观点904.5.5 从模型驱动的体系结构看OOA与OOD的关系92第二部分分析篇第5章建立需求模型--用况图975.1 需求分析和系统分析97 5.2 基于用况的需求分析基本思路985.3 系统边界与参与者98 5.3.1 系统边界985.3.2 参与者995.4 用况1015.4.1 什么是用况1015.4.2 用况的内容与格式103 5.4.3 如何定义用况104 5.5 用况图105。
面向对象分析与设计
面向对象分析与设计面向对象分析与设计（Object-oriented analysis and design）是软件工程领域中的一种方法论，用于解决软件系统开发过程中的问题和需求。
本文将对面向对象分析与设计的基本概念、流程和常用方法进行介绍，并附带答案和解析。
第一部分：面向对象分析（Object-oriented analysis）面向对象分析是软件开发过程中的第一步，旨在理解问题域并建立领域模型。
面向对象分析有以下几个重要概念：1. 对象（Object）：对象是系统中的一个实体，包含数据和方法。
对象可以是具体的实物、虚拟的概念或一组相关的数据和行为。
2. 类（Class）：类是一种抽象的定义，描述了一组具有相同特征和行为的对象。
3. 属性（Attribute）：属性是对象的特征，用于描述对象的状态。
4. 方法（Method）：方法是对象的行为，用于描述对象可以执行的操作。
面向对象分析的主要流程包括以下步骤：1. 需求收集：收集系统的需求，与利益相关者沟通，了解系统的功能和性能要求。
2. 领域建模：对现实世界的问题域进行抽象和建模，识别出系统中的对象和它们之间的关系。
3. 需求分析与规约：通过使用用例、活动图和状态图等工具对需求进行分析和规约，明确功能和交互细节。
4. 领域模型验证：与利益相关者验证领域模型的准确性和实用性，确保模型能够满足系统需求。
第二部分：面向对象设计（Object-oriented design）面向对象设计是在面向对象分析的基础上，进一步细化领域模型，为系统的实现提供指导。
面向对象设计有以下几个常用方法：1. 类图（Class diagram）：类图用于展示类、属性和方法之间的关系。
类图包括类的名称、属性和方法，并通过关联、继承和聚合等关系展示类之间的联系。
2. 对象图（Object diagram）：对象图用于展示类的实例和对象之间的关系。
对象图是类图的实例化表示，展示了系统在某一时刻的对象及其特定的属性值。
UML面向对象分析报告与设计
UML面向对象分析与设计大作业前言“UML面向对象分析与设计”是计算机专业和软件工程等相关专业的一门重要课程，也是其他理工科专业的热门选修课程。
“程序设计语言”、“计算机网络”、“数据库原理”和“数据机构”等是它的前导课程，学好本课程对学生毕业后从事软件开发有着极为重要的作用。
要学好这门课，仅仅通过课堂教学或自学掌握理论知识是远远不够的，还必须加强实践。
特在学期末引入uml的综合分析与设计，从实际项目出发，使学生学会运用软件工程基本理论知识，UML建模语言和rose建模环境，去解决软件开发中的实际问题，达到学以致用的目的。
面向对象软件开发技术项目的引入及需求简易教学管理系统的分析、设计与实现一、设计的目的1.初步了解UML语言的概念、结构、语义与表示方法；2.掌握UML建模工具Rational Rose的使用方法；3.给出某个简单系统的模型，能够熟练地使用Rose工具表达；二、设计理论基础1. 面向对象的程序设计C++或JAVA程序设计课程；2.数据结构或算法课程2.SQLServer或mysql数据库系统；3. 熟悉传统软件工程以及软件测试技术。
三、设计内容与步骤需求陈述：简易教学管理系统主要提供两个方面的服务：➢选课管理，负责新学期的课程选课注册。
➢成绩管理，负责学生成绩管理。
（1）简易教学管理系统---选课管理应提供的服务如下：1.录入与生成新学期课程表教学管理人员在新学期开学前录入新学期的课程，打印将开设的课程目录表，供师生参考选择。
如果某门课实际选课的学生少于10人，则停开该课程，把该课程从课程表中删除；如某课程选课学生多于60人，则停止选课。
2.学生选课注册新学期开始前一周为学生选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请。
每个学生选课可不允许超过4门，每门课最多允许60名学生选课注册。
3.查询可以查询课程信息、学生选课信息和学生、教师信息。
学生、教师、教学管理人员可以查询课程表，获得课程信息。
面向对象分析与设计教学案例
面向对象分析与设计教学案例研究该案例示范了使用Rational Rose如何对系统进行建模。
使用用例和领域分析的方法来对系统进行分析并且设计一个分析模型。
然后把分析模型扩展成设计模型，此设计模型描述了一种技术方案。
最终，设计模型转变为用面向对象的编程语言创建的可以运行的程序。
这里将把某大学课程管理的问题作为本部分的示例。
【案例材料】1. 某大学背景学生登记在大学里是一种非常耗时的活动，学校还面临着给教室排课的问题。
在每个教师决定了他这个学期将讲授什么课程之后，教务处将这些信息输入到一个计算机系统，然后给每个教师打印一份报表，最后要打印一份课程目录给学生。
依照现有系统，学生填写注册表并确定他们所选的课程，然后将所有信息递交到教务处。
一个学生在一段时间内最多选四门课。
教务处将这些信息输入到计算机。
一旦输入了学生所选的课程，就会把学生安排到这些课程。
大多数时候，学生得到他们选课的课程，但是，当发生冲突时，教务处将询问学生以便得到其他的选择。
一旦给所有学生都排好了课，学生的课表将打印出来给学生以便得到他们的确认。
大多数学生登记将在一周内完成，但是有些特殊情况要花两周来进行。
当最初的登记周期结束时，教师会得到他们所讲的每一门课程的学生名单。
2. 课程登记问题的风险开发团队觉得这个系统最主要的风险是有效地存储和获取课程信息。
他们开发了几个原型来评价每一个备选的数据库管理系统的数据和访问机制。
他们还开发了一些原型来研究学校运行联机登记系统的硬件需求。
3. 某大学课程登记问题状态在学期之初，学生会需要一份这个学期要开的课程列表。
每门课程的信息，如教师、部门和课程需要的前提条件将包含在这个清单里来帮助学生们选择课程。
新系统允许学生在每个学期里选四门课。
另外，每个学生还要提交两个备选课程以预防课程被选满或取消的情况。
少于三个学生选择的课将被取消。
一旦学生登记完成，登记系统将信息传入财务系统，学生就可以交这个学期的学费了。
面向对象的分析和设计步骤
1.2.5 定义服务
即定义事件的操作
1.3 面向对象的设计
系统分析主要关心系统必须做什么，而不必太多的考虑其中的实现 细节，它注重的是问题领域与系统责任。系统设计就要考虑实现的细 节问题了，它主要说明如何实现分析中的元素，注重的是实现相关的 问题，并作为实施阶段的依据。即设计是把分析阶段得到的需求转变 成系统实现方案的过程,回答“怎么做”的问题，面向对象的设计是针 对系统的一个具体的实现运用OO方法，其中包括两方面的工作，一 是把OOA模型直接搬到OOD(不经转换，仅作某些必要的修改和调整)， 作为OOD的一部分；另外是针对具体实现中的人机界面、数据存储、 任务管理等因素补充一些与实现有关的部分。大多数系统的面向对象 设计就是实现目标系统的四个子系统：问题域子系统、人—机交互子 系统、任务管理子系统、数据管理子系统。
部 分2
图1.3表示组合关系的图形符号
3.关联关系
库管员
物资
图 1.4 库 管 员 与 他所管理的物资 之间的关系
文件
用户
访问权 限
图1.5链属关系的表示方法
目录
文件 名
文件
图1.6 一个受限的关联
发送者
接收者
图1.7 消息连接的表示符号
（4）消息连接 （5）状态的表示
初始状态
状态1
服务1[条件1] 服务2[条件2]
1.2.3 建立动态模型
各个类的状态图通过共享事件合并起来，构成了系统的动态模型。 动态模型描述了系统投入运行后可能出现的各种正常/异常情况、各 种事件发生的次序、人机界面的情况等。一个系统的动态模型通过 系统脚本、用户界面、事件跟踪图和状态图来描写。 注意：对于仅存储静态数据的系统而言，动态模型毫无意义，可以 不建立；而对于交互式系统，动态模型起着很重要的作用。
即定义事件的操作
1.3 面向对象的设计
系统分析主要关心系统必须做什么，而不必太多的考虑其中的实现 细节，它注重的是问题领域与系统责任。系统设计就要考虑实现的细 节问题了，它主要说明如何实现分析中的元素，注重的是实现相关的 问题，并作为实施阶段的依据。即设计是把分析阶段得到的需求转变 成系统实现方案的过程,回答“怎么做”的问题，面向对象的设计是针 对系统的一个具体的实现运用OO方法，其中包括两方面的工作，一 是把OOA模型直接搬到OOD(不经转换，仅作某些必要的修改和调整)， 作为OOD的一部分；另外是针对具体实现中的人机界面、数据存储、 任务管理等因素补充一些与实现有关的部分。大多数系统的面向对象 设计就是实现目标系统的四个子系统：问题域子系统、人—机交互子 系统、任务管理子系统、数据管理子系统。
部 分2
图1.3表示组合关系的图形符号
3.关联关系
库管员
物资
图 1.4 库 管 员 与 他所管理的物资 之间的关系
文件
用户
访问权 限
图1.5链属关系的表示方法
目录
文件 名
文件
图1.6 一个受限的关联
发送者
接收者
图1.7 消息连接的表示符号
（4）消息连接 （5）状态的表示
初始状态
状态1
服务1[条件1] 服务2[条件2]
1.2.3 建立动态模型
各个类的状态图通过共享事件合并起来，构成了系统的动态模型。 动态模型描述了系统投入运行后可能出现的各种正常/异常情况、各 种事件发生的次序、人机界面的情况等。一个系统的动态模型通过 系统脚本、用户界面、事件跟踪图和状态图来描写。 注意：对于仅存储静态数据的系统而言，动态模型毫无意义，可以 不建立；而对于交互式系统，动态模型起着很重要的作用。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
完整的属性集合，包括详细说明的名称、类型、 可视性和一些默认值（可选的） 将分析类指定的操作转化成一个或多个方法的 完整集合。
设计类图-引入基础类
在着手开发之前，还有一件很重要的事要 去完成，那就是引入基础类。
不管使用什么开发工具进行代码编写，都将以 各种库函数、框架作为开发基础。例 如，.NET、J2EE 、CORBA等框架，MFC、 OWL、BDE、Swing、JDBC 等库函数。
分析模型和设计模型
一个项目可以建分析模型和设计模型两个 模型，也可以只建设计模型
如果分析模型和设计模型的差别很大，那就要 建两个模型 如果分析模型和设计模型的差别不大，那就只 建设计模型
如果你只建了一个设计模型，最好能把分 析后的结果作为一个版本保存。
分析与设计
在分析中，焦点是创建系统的逻辑模型， 该模型捕获系统为满足用户需求而必须提 供的功能。 设计的目的是说明如何才能完全实现这一 功能，整合解域的技术解决方案以提供实 际上可实现的系统模型（设计模型）。
映射到设计元素的途径
一个分析类成为设计模型中的一组功能相 关的类（设计包） 一个分析类成为设计模型中的一个子系统 一个分析类成为设计模型中的一个关系 一个分析类的组成部分可以被硬件实现， 而根本不在设计模型中出现 任何上述方式的组合
设计类图应完成的工作
在设计中，必须准确地说明类是如何履行 它们的职责。必须完成以下事情：
设计元素
子系统和包的区别
子系统比包封装性好
子系统有接口，外部只能通过子系统接口访问子系统内部 包没有接口，外部可以直接访问包中公共的类
子系统具有行为，而包没有
子系统是一种通过一个或多个它所实现的接口来提供行为的包 而包并不提供行为它们只是用来容纳对象的容器
子系统依赖关系
子系统不应暴露自己的任何内容；子系统外部的元素都 不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口，因此它不直接 依赖于子系统外部的任何特定模型元素 。 例外情况
设计阶段的工作
将开发出一个基于面向对象的系统逻辑解 决方案。这个解决方案的核心是要建立交 互模型，它能够展示出为了满足系统需求 各个对象相互之间如何进行通信。 在交互图建立之后，接着要建立设计类图， 它对要实现的软件类（和接口）的定义进 行总结。
浅析交互模型
在面向对象的视角里，整个系统是由一系列的对 象，以及对象之间的交互与协作构成的 交互建模，正是要通过寻找对象之间的交互关系， 从而进行“行为分配”
在某些应用程序中，某些特定信息应该只能由少数几个人 访问。子系统使您能够在需要保守秘密的地方保守秘密 子系统用于代表系统所使用的现有产品和服务（例如 COTS 产品和库）
步骤
识别类和子系统
识别子系统接口 识别复用机会 修改设计模型的组织 评审
识别设计类和子系统
这个活动的主要目的还是根据分析类的交互识别出设计 子系统或包；大部分设计类还是在用例设计和子系统设 计中产生的 子系统的类型
识别设计元素
目的
分析分析类的交互以识别设计模型元素 细化构架，可能时结合复用 识别通用设计问题的通用解决方案 把构架相关的设计模型元素放到Logical view部分 补充规约 设计指南 软件构架文档 分析类 设计模型
输入
输出
设计模型元素（设计类、接口、设计包、设计子系统）
交互模型的步骤
引入实体对象
实体对象就是域模型（类图）中的某个分析类 的一个实例
引入边界对象和参与者 引入控制对象
构建交互模型-新增书籍信息
基本事件流
1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算 机类； 3）图书管理员做出选择后，显示相应界面，让图书管理员输入信 息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、 ISBN 号、开本、页数、定价、是否有CDROM； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。
角色
构架设计师
设计元素——接口和包
接口
接口是定义行为集（即操作集）的模型元素 该行为集由classifier模型元素（即类、子系统或component）提供 classifier可以实现一个或多个接口；一个接口可由一个或多个 classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集
控制子系统 协调子系统 数据采集子系统：从外部环境采集数据 数据分析子系统：分析数据并负责报告和/或显示其他子系统采 集的数据 Server子系统：其它子系统提供服务 用户界面子系统
提供用户界面，并且作为client向用户提供对一个或多个server提 供的服务的访问 对于不同类型的用户，可能会有不同的用户界面子系统 通常是由多个简单用户界面对象组成的组合对象
选择基础类举例(续)
当我们需要进行网络操作时，我们可以从 MFC中选择一个Socket的实现，也可能是 从SUN提供的网络包中选择相应的类 当我们需要进行用户界面设计时，我们可 能使用MFC 中提供的相关类，也可能使用 Java中的AWT或Swing包来实现。
学习开发知识的要点
应该花足够多的时间来了解各种基础框架、 库函数的功能与特性，以便在设计时做出 最优的选择； 另外，还应该对这些基础框架、库函数的 类结构有一个清晰的了解，这样就可以最 有效地找到基础类，最高效地使用。
具体开发流程
应该由同一个团队负责需求和设计，而不 是采用一个分析师团队和一个独立的设计 师团队。 设计模型建立在分析模型的基础之上，也 可以看作是分析模型的精化和细化。
什么时候需要维护两套模型？
庞大的 复杂的 战略性的 受经常变更所支配的 期望长期运行的 外包的
分析模型的价值
Ivar Jacobson 说：“只有在所有的用例为所有 事件进程建立了交互模型之后，才可以确定已 经发现系统所需的每个对象所扮演的角色，以 及它们的责任。”
交互模型表现方式
在UML规范中，交互模型包括两种不同的 表现形式：
一种是强调顺序的顺序图（Sequence diagram），读者可以从中可以很容易地看出 事件发生的次序； 另一种是强调组织的协作图（Collaboration diagram），它通过使用布局图指明了各个对 象之间是如何静态相连的。
确定基础类的原则
首先要根据应用的需要选择相应的框架 然后再根据具体的局部需要还选择相应的 库函数。
选择基础类举例
如果我们需要进行数据库操作，我们将可 能使用ODBC、JDBC、ADO、BDE 等数 据库访问引擎中的一种. 如果我们需要分布式地处理，就可能要从 DCOM、CORBA、EJB、WebServices 中选择一种合适的技术
<<system>> CruiseControl&Monitoring System
<<subsystem>> CruiseControlSu bsytem
<<subsystem>> Monitoring
协调子系统
协调子系统负责协调控制子系统的动作 如果这些控制子系统之间完全独立的话，就不需要协调子系 统 如果控制子系统相对来说比较简单，控制子系统可以自行协 调动作 如果协调的工作相对复杂时，使用一个独立的协调子系统通 常更好些 例如：电梯控制系统中的调度子系统。在这个系统中，所有 的电梯内乘客的服务请求都是由该电梯处理的。但是，在电 梯外某楼层的乘客发出服务请求时，必须要决定由哪部电梯 来对应这个请求，这个决定由调度子系统来做。当调度子系 统从楼层子系统接到服务请求时，它决定是否需要分配一部 电梯到那个楼层；如果需要的话，它对选定的电梯子系统发 出调度请求。
设计包
一个包中可以包含公有类，也可以包含私有类
公有类可以与任何其他类相关联 私有类只能与其所在包中包含的类相关联
包接口由包的公有类组成，包接口隔离并实施对其他包的依赖关系
包耦合的原则
不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下一 层中的包 通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的
面向对象分析与设计
设计模型
分析和设计
分析 侧重于理解问题 功能需求 系统结构 行为(behavior) 小模型 设计 侧重于解决问题 非功能性需求 操作和属性 对象的生命周期 大模型
实现系统行为
分析行为 用例分析活动把系统的 行为分配给分析类，让 分析类交互来完成系统 的行为 设计构件 用例设计活动把系统的行 为分配给设计元素（子系 统、类） 子系统设计活动把子系统 的行为分配给内部的设计 元素 类设计活动完成分配给每 个类的行为
扩展事件流
5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图 书管理员选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5）
构建设计模型
在构建交互模型时，将会发现类应该具有 的方法，也会在设计时找到一些新的属性， 而这些东西将进一步地完善我们的静态模 型(概念模型)。
从分析类到设计元素
设计类图-引入基础类
在着手开发之前，还有一件很重要的事要 去完成，那就是引入基础类。
不管使用什么开发工具进行代码编写，都将以 各种库函数、框架作为开发基础。例 如，.NET、J2EE 、CORBA等框架，MFC、 OWL、BDE、Swing、JDBC 等库函数。
分析模型和设计模型
一个项目可以建分析模型和设计模型两个 模型，也可以只建设计模型
如果分析模型和设计模型的差别很大，那就要 建两个模型 如果分析模型和设计模型的差别不大，那就只 建设计模型
如果你只建了一个设计模型，最好能把分 析后的结果作为一个版本保存。
分析与设计
在分析中，焦点是创建系统的逻辑模型， 该模型捕获系统为满足用户需求而必须提 供的功能。 设计的目的是说明如何才能完全实现这一 功能，整合解域的技术解决方案以提供实 际上可实现的系统模型（设计模型）。
映射到设计元素的途径
一个分析类成为设计模型中的一组功能相 关的类（设计包） 一个分析类成为设计模型中的一个子系统 一个分析类成为设计模型中的一个关系 一个分析类的组成部分可以被硬件实现， 而根本不在设计模型中出现 任何上述方式的组合
设计类图应完成的工作
在设计中，必须准确地说明类是如何履行 它们的职责。必须完成以下事情：
设计元素
子系统和包的区别
子系统比包封装性好
子系统有接口，外部只能通过子系统接口访问子系统内部 包没有接口，外部可以直接访问包中公共的类
子系统具有行为，而包没有
子系统是一种通过一个或多个它所实现的接口来提供行为的包 而包并不提供行为它们只是用来容纳对象的容器
子系统依赖关系
子系统不应暴露自己的任何内容；子系统外部的元素都 不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口，因此它不直接 依赖于子系统外部的任何特定模型元素 。 例外情况
设计阶段的工作
将开发出一个基于面向对象的系统逻辑解 决方案。这个解决方案的核心是要建立交 互模型，它能够展示出为了满足系统需求 各个对象相互之间如何进行通信。 在交互图建立之后，接着要建立设计类图， 它对要实现的软件类（和接口）的定义进 行总结。
浅析交互模型
在面向对象的视角里，整个系统是由一系列的对 象，以及对象之间的交互与协作构成的 交互建模，正是要通过寻找对象之间的交互关系， 从而进行“行为分配”
在某些应用程序中，某些特定信息应该只能由少数几个人 访问。子系统使您能够在需要保守秘密的地方保守秘密 子系统用于代表系统所使用的现有产品和服务（例如 COTS 产品和库）
步骤
识别类和子系统
识别子系统接口 识别复用机会 修改设计模型的组织 评审
识别设计类和子系统
这个活动的主要目的还是根据分析类的交互识别出设计 子系统或包；大部分设计类还是在用例设计和子系统设 计中产生的 子系统的类型
识别设计元素
目的
分析分析类的交互以识别设计模型元素 细化构架，可能时结合复用 识别通用设计问题的通用解决方案 把构架相关的设计模型元素放到Logical view部分 补充规约 设计指南 软件构架文档 分析类 设计模型
输入
输出
设计模型元素（设计类、接口、设计包、设计子系统）
交互模型的步骤
引入实体对象
实体对象就是域模型（类图）中的某个分析类 的一个实例
引入边界对象和参与者 引入控制对象
构建交互模型-新增书籍信息
基本事件流
1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算 机类； 3）图书管理员做出选择后，显示相应界面，让图书管理员输入信 息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、 ISBN 号、开本、页数、定价、是否有CDROM； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。
角色
构架设计师
设计元素——接口和包
接口
接口是定义行为集（即操作集）的模型元素 该行为集由classifier模型元素（即类、子系统或component）提供 classifier可以实现一个或多个接口；一个接口可由一个或多个 classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集
控制子系统 协调子系统 数据采集子系统：从外部环境采集数据 数据分析子系统：分析数据并负责报告和/或显示其他子系统采 集的数据 Server子系统：其它子系统提供服务 用户界面子系统
提供用户界面，并且作为client向用户提供对一个或多个server提 供的服务的访问 对于不同类型的用户，可能会有不同的用户界面子系统 通常是由多个简单用户界面对象组成的组合对象
选择基础类举例(续)
当我们需要进行网络操作时，我们可以从 MFC中选择一个Socket的实现，也可能是 从SUN提供的网络包中选择相应的类 当我们需要进行用户界面设计时，我们可 能使用MFC 中提供的相关类，也可能使用 Java中的AWT或Swing包来实现。
学习开发知识的要点
应该花足够多的时间来了解各种基础框架、 库函数的功能与特性，以便在设计时做出 最优的选择； 另外，还应该对这些基础框架、库函数的 类结构有一个清晰的了解，这样就可以最 有效地找到基础类，最高效地使用。
具体开发流程
应该由同一个团队负责需求和设计，而不 是采用一个分析师团队和一个独立的设计 师团队。 设计模型建立在分析模型的基础之上，也 可以看作是分析模型的精化和细化。
什么时候需要维护两套模型？
庞大的 复杂的 战略性的 受经常变更所支配的 期望长期运行的 外包的
分析模型的价值
Ivar Jacobson 说：“只有在所有的用例为所有 事件进程建立了交互模型之后，才可以确定已 经发现系统所需的每个对象所扮演的角色，以 及它们的责任。”
交互模型表现方式
在UML规范中，交互模型包括两种不同的 表现形式：
一种是强调顺序的顺序图（Sequence diagram），读者可以从中可以很容易地看出 事件发生的次序； 另一种是强调组织的协作图（Collaboration diagram），它通过使用布局图指明了各个对 象之间是如何静态相连的。
确定基础类的原则
首先要根据应用的需要选择相应的框架 然后再根据具体的局部需要还选择相应的 库函数。
选择基础类举例
如果我们需要进行数据库操作，我们将可 能使用ODBC、JDBC、ADO、BDE 等数 据库访问引擎中的一种. 如果我们需要分布式地处理，就可能要从 DCOM、CORBA、EJB、WebServices 中选择一种合适的技术
<<system>> CruiseControl&Monitoring System
<<subsystem>> CruiseControlSu bsytem
<<subsystem>> Monitoring
协调子系统
协调子系统负责协调控制子系统的动作 如果这些控制子系统之间完全独立的话，就不需要协调子系 统 如果控制子系统相对来说比较简单，控制子系统可以自行协 调动作 如果协调的工作相对复杂时，使用一个独立的协调子系统通 常更好些 例如：电梯控制系统中的调度子系统。在这个系统中，所有 的电梯内乘客的服务请求都是由该电梯处理的。但是，在电 梯外某楼层的乘客发出服务请求时，必须要决定由哪部电梯 来对应这个请求，这个决定由调度子系统来做。当调度子系 统从楼层子系统接到服务请求时，它决定是否需要分配一部 电梯到那个楼层；如果需要的话，它对选定的电梯子系统发 出调度请求。
设计包
一个包中可以包含公有类，也可以包含私有类
公有类可以与任何其他类相关联 私有类只能与其所在包中包含的类相关联
包接口由包的公有类组成，包接口隔离并实施对其他包的依赖关系
包耦合的原则
不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下一 层中的包 通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的
面向对象分析与设计
设计模型
分析和设计
分析 侧重于理解问题 功能需求 系统结构 行为(behavior) 小模型 设计 侧重于解决问题 非功能性需求 操作和属性 对象的生命周期 大模型
实现系统行为
分析行为 用例分析活动把系统的 行为分配给分析类，让 分析类交互来完成系统 的行为 设计构件 用例设计活动把系统的行 为分配给设计元素（子系 统、类） 子系统设计活动把子系统 的行为分配给内部的设计 元素 类设计活动完成分配给每 个类的行为
扩展事件流
5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图 书管理员选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5）
构建设计模型
在构建交互模型时，将会发现类应该具有 的方法，也会在设计时找到一些新的属性， 而这些东西将进一步地完善我们的静态模 型(概念模型)。
从分析类到设计元素