UML课程设计教案Word下载.docx
《UML课程设计教案Word下载.docx》由会员分享，可在线阅读，更多相关《UML课程设计教案Word下载.docx（66页珍藏版）》请在冰点文库上搜索。
很难精确把握用户的需求，开发过程中用户需求总是不断变化，用户理解的软件研发与真实研发的实际情况不同。
很难发现大型应用项目隐蔽着的复杂性。
人类本身处理复杂现象的能力有限。
很难预估最终输出的执行效果及其是否能满足用户的期望。
难以预测软件开发过程中可能遇到的问题。
3软件生命周期概述
一个人要经过胎儿、儿童、青年、中年、老年，直到最终死亡的生命周期。
一个软件同样有一个从定义、开发、使用和维护，直到最终被废弃的生命周期。
在软件的生命周期中，需要完成许多性质各异的工作，这就要求把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后按照计划对软件的开发与维护工作进行管理。
软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生命周期。
软件工程是把软件生命周期依此划分为若干个阶段，每个阶段有相对独立的任务，然后对每一阶段进行严格管理。
把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；
在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，使得软件开发的全过程以一种有条不紊的方式进行，这样，能保证软件的质量，特别是提高软件的可维护性。
4软件的生命周期通常划分为五个阶段：
4.1需求分析
4.1.1需求分析－概述
需求分析是解决“做什么”的问题，即我们需要做一个什么样的系统。
系统分析阶段的基本任务是：
系统分析员与用户在一起交流，充分了解用户的要求，并把双方的理解用系统方案书表达出来。
4.1.2需求分析－可行性分析
在进行具体需求分析之前，还需要对项目进行可行性分析，可行性分析是解决“做与不做”的问题。
即我们能否做这个项目。
从理论上讲，只要资源和时间不加限制，所有的项目都是可行的。
然而，由于资源缺乏和交付时间限制的困扰以及项目是否能够盈利，对软件项目的可行性做出细致而谨慎的评估是十分必要的。
如果在制定计划阶段及早发现将来可能在开发过程中遇到的问题，及早做出决定，可以避免大量的人力、财力、时间上的浪费。
可行性分析内容主要包括：
市场可行性分析、政策可行性分析、技术可行性分析、成本效益分析、SWOT分析等几个方面。
4.1.3需求分析－难点解析1
开发软件系统最困难的部分就是准确说明开发什么。
最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。
此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
需求是产品的根源，需求工作的优劣对产品影响最大。
就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
4.1.4用户说不清需求
用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。
其实这个并不能怪用户，试想，假如我们去买鞋子，我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。
通常拿鞋子去试，试穿时感觉到舒服才会买鞋。
需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。
无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是分析人员的职责，也是职业的挑战。
4.2系统设计
4.2.1系统设计要回答的中心问题是系统“怎么做”，即如何实现产品需求规格说明书规定的系统功能。
4.2.2依据“分而治之”的思想，我们把系统设计过程划分为两个阶段：
高层设计阶段
高层设计阶段的重点是体系结构设计。
详细设计阶段。
详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计等。
4.2.3系统设计过程
体系结构如同人的骨架，决定着我们整个项目的主体架构。
用户界面如同人的外表，我们在设计软件时不要沉迷于技术，而要多多思考什么样的界面才能让用户更加喜欢。
数据库是存储和处理数据用的。
人体的数据库是大脑，知识相当于数据，存储在大脑里。
模块如同人的器官。
每个器官都具有特定的功能，器官们依附在骨架上。
模块是软件系统的部件，它们安插在体系结构上。
数据结构与算法如同人的神经和肌肉，它分布在全身，让器官具有生命并能发挥功能。
4.2.4数据库设计难点分析
数据库设计的主要工作是：
设计数据库的表（数据就存在表里面），表的结构就是数据的存储结构；
对这些表中的数据进行操作，常见操作如查询、插入、修改、删除等。
数据库设计一般要经历“逻辑设计—>
物理设计－>
安全性设计－>
性能优化”等步骤，通常要迭代进行。
4.2.5模块设计难点分析
对于软件而言，我们习惯从功能角度描述模块。
所以模块泛指软件系统的功能部件。
在软件的体系结构设计完成之际，我们就已经确定了所有模块的功能，并且把模块们安放在体系结构的恰当位置上。
“模块化”（Modularization）是指：
将系统分解为一系列功能模块，然后逐一实现这些模块，最后把所有的模块集成为原来的系统。
这样做的好处是能够大大降低系统的开发难度。
每个模块都具有特定的、明确的功能。
我们在设计模块时应当尽量使模块的功能独立，因为功能独立的模块可以降低开发、测试、维护的代价。
但是功能独立并不意味着模块是绝对孤立的。
所有的模块应当能够被集成为一个系统，所以模块之间必定要交流信息、相互配合。
4.3编码实现
软件实现是将“软件设计”的结果变换成用程序设计语言编写的计算机能识别的程序。
系统实现是在系统分析、系统设计的基础上，将系统设计的每一个细节，用计算机语言（或开发工具）完整地表达出来，在计算机上应用该系统。
系统的实现既是对系统分析、系统设计阶段工作的检验，又是取得用户对系统信任的关键阶段。
系统的规模越大，系统的实现就越复杂。
为此，程序设计人员要具有比较丰富的程序设计经验，具有良好的程序设计风格和丰富的编程技巧。
系统实现的主要任务是进行编程语言的选择、程序的编写与调试。
4.4软件测试
4.5运行维护
5为什么要建模
建模是为了让我们更好地理解将要开发的系统。
在表述一个软件问题时，由于问题本身的复杂性、计算机本身许多概念的晦涩、人员技术水平、交流及理解能力的局限，单单凭自然语言通常是不够，因此往往需要其他工具（如图形等）的协助。
这也就是为什么要建模。
大师说：
“人类看图的能力要远远超过看文档的能力”
6什么是模型
模型是用某种工具对同类或其他工具的表达方式。
模型从某一个建模观点出发，抓住事物最重要的方面而简化或忽略其他方面。
工程、建筑和其他许多需要具有创造性的领域中都使用模型。
7建模的原则
7.1分治的原则
不可能单独用一个模型来反映整个系统的任何侧面。
软件系统是复杂的，对于软件模型的任意一个侧面不可能用一个模型来反映所有内容，需要把问题分解为不同的子模型，分别处理这些模型，相对独立但又互相联系，综合起来构成了此侧面的一个完整的模型。
7.2标准的原则
模型必须在某种程度上是通用的。
建模的基本目的是交流，一个开发队伍内部的交流，同一软件的不同时期的版本的开发队伍的交流，不同软件的开发队伍之间的交流，以实现最大程度的软件复用。
交流需要语言，语言是通用的、标准的。
8面向对象的建模
面向对象分析的目的是要构造能够理解实际系统的模型。
分析从用户提供的问题描述开始，这一描述是非完整的或非形式化的。
分析模型强调对象的三个方面：
静态模型、动态模型和功能模型。
模型用对象、关系、动态控制流和功能转换等来描述，并不断获取需求信息，且把与客户间的交流贯穿整个分析过程。
面向对象设计包括系统设计与对象设计。
系统设计是为实现需求目标而对软件的系统结构进行的总体设计，包括系统层次结构设计、系统数据存储设计、系统资源访问设计等。
对象设计是根据具体的实施策略，对分析模型进行扩充的过程。
对象设计包括：
静态结构设计、动态行为模型设计。
通过对象设计和系统设计就可以获得设计模型，这是系统实现的基础。
9UML简介
UML:
统一建模语言（UnifiedModelingLanguage）
UML是一种Language（语言）
UML是一种Modeling（建模）Language
UML是Unified（统一）ModelingLanguage
UML是用于描绘软件蓝图的标准语言.
9.1它可用于对软件密集型系统进行
9.1.1可视化（visualize）
9.1.2详述—说明（specify）
9.1.3构造（construct）
9.1.4文档化（document）
9.1.5这也是对软件系统进行建模的四个目的
9.1.6UML是蓝图
UML是由图形符号表达的建模语言
例如,这是UML的一个模型图（图...）
其上的图形符号是遵循给定的标准的
例如:
类：
（图...）
10什么是UML
UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示它不是一种可视化的程序设计语言而是一种可视化的建模语言，不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准，不是过程也不是方法但允许任何一种过程和方法使用它
10.1UML的目标是
易于使用表达能力强进行可视化建模，与具体的实现无关可应用于任何语言平台和工具平台，与具体的过程无关可应用于任何软件开发的过程，简单并且可扩展具有扩展和专有化机制便于扩展无需对核心概念进行修改。
为面向对象的设计与开发中涌现出的高级概念（例如协作框架模式和组件）提供支持，强调在软件开发中，对架构、框架模式和组件的重用，与最好的软件工程实践经验集成，可升级，具有广阔的适用性和可用性，有利于面对对象工具的市场成长。
11草图与蓝图的区别
蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型，草图则通常是指手工绘制的、规范度较低的在纸张的UML模型，大胆地绘制草图，尽可能基于草图进行讨论。
对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；
对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中
12UML为模型可视化提供表示法
12.1说明用户与系统的交互的用例图
12.2说明逻辑结构的类图
12.3说明对象和链接的对象图
12.4说明行为的状态图
12.5说明软件的物理结构的构件图
12.6显示软件与硬件配置之间的映射关系的部署图
12.7说明行为的交互图（即协作图和时序图）
12.8说明用例中事件流的活动图
13在软件开发生命周期中的应用
13.1初步调查：
通过用例来捕获客户的需求
需求分析：
UML的用例视图可以表示客户的需求。
通过用例建模，可以对外部的角色以及它们所需要的系统功能建模，角色和用例是用它们之间的关系、通信建模的。
每个用例都指定了客户的需求；
他或她需求系统干什么，不仅要对软件系统，对商业过程也要进行需求分析
13.2分析：
在真实世界中的抽象层面上创建类图，以描述它们的存在和关系。
分析：
分析阶段主要考虑所要解决的问题，可用UML的逻辑视图和动态视图来描述；
类图描述系统的静态结构，协作图、状态图、序列图、活动图和状态图描述系统的动态特征。
在分析阶段只为问题领域的类建模---不定义软件系统的解决方案的细节（如用户接口的类数据库等）；
13.3设计：
对类进行建模
开发：
程序员参考在设计阶段准备的各种UML图表来理解和开发代码。
设计：
在设计阶段，把分析阶段的结果扩展成技术解决方案。
加入新的类来提供技术基础结构--用户接口，数据库操作等。
分析阶段的领域问题类被嵌入在这个技术基础结构中。
设计阶段的结果是构造阶段的详细的规格说明；
构造：
在构造（或程序设计阶段），把设计阶段的类转换成某种面向对象程序设计语言的代码，在对UML表示的分析和设计模型进行转换时，最好不要直接把模型转化成代码。
因为在早期阶段，模型是理解系统并对系统进行结构化的手段；
13.4测试：
UML通过不同的图表来支持软件的测试
测试：
对系统的测试通常分为单元测试、集成测试、系统测试和接受测试几个不同级别。
单元测试是对几个类或一组类的测试，通常由程序员进行；
集成测试集成组件和类，确认它们之间是否恰当地协作；
系统测试把系统当作一个“黑箱”，验证系统是否具有用户所要求的所有功能；
接受测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。
不同的测试小组使用不同的UML图作为他们工作的基础；
单元测试使用类图和类的规格说明，集成测试典型地使用组件图和协作图，而系统测试实现用例图来确认系统的行为符合这些图中的定义。
14UML的组成
14.1视图-意味着“观察”或“检查”
视图用来表示被建模系统的各个方面（从不同的目的出发,建立为系统建立多个模型，这些模型都反映同一个系统，且具有一致性）。
视图由多个图（Diagrams）构成，它不是一个图片（graph），而是在某一个抽象层上，对系统的抽象表示。
如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了。
另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。
给复杂的系统建模是一件困难和耗时的事情。
从理想化的角度来说，整个系统像是一张画图，这张图画清晰而又直观地描述了系统的结构和功能，既易于理解又易于交流，但事实上要画出这张图画几乎是不可能的，因为，一个简单的图画并不能完全反映出系统中需要的所有信息。
完整地描述系统通常的做法是，用一组视图反映系统的各个方面，每个视图代表完整系统描述中的一个抽象，显示这个系统中的一个特定的方面。
每个视图由一组图构成，图中包含了强调系统中某一方面的信息。
通常，UML由四种视图组成，分别是用例视图（Use-caseview）逻辑视图（Logicalview）组件视图（Componentview）和布局视图（Deploymentview）。
14.2图-是特定视图的一部分，图表绘制完后，就会被指定给视图
图由各种图片（graph）构成，用来描述一个视图的内容，UML语言定义了9种不同的图的类型，把它们有机地结合起来就可以描述系统的所有视图。
图（diagram）由图片（graph）组成。
图片是模型元素的符号化。
把这些符号有机地组织起来形成的图表示了系统的一个特殊部分或某个方面。
一个典型的系统模型应有多个各种类型的图。
图是一个具体视图的组成部分，在画一个图时就相当于把这个图分配给某个视图了。
依据图本身的内容，有些图可能是多个视图的一部分。
UML中包含，用例图、类图、对象图、状态图、序列图、协作图、活动图、组件图、展开图共九种。
14.3关系-提供了对象之间通信的途径
14.4建模元素-由帮助准备图和视图的符号组成
模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。
一个模型元素可以用在多个不同的图中，无论怎样使用它总是具有相同的含义和相同的符号表示。
15视图–用例视图
UML由四种视图组成，分别是用例视图（Use-caseview）逻辑视图（Logicalview）组件视图（Componentview）和布局视图（Deploymentview）。
用例视图是其他视图的“心脏”，描述了系统应该做什么，在集成其他视图的内容中扮演了重要角色。
用例视图定义了系统的外部行为，帮助用户理解和使用系统。
他包括以下图：
用例图、序列图、协作图、活动图。
序列图和协作图都属于交互图，描述了系统对象之间相互协作的过程。
从用户角度描述系统功能，并指出各功能的操作者
用例视图---序列图
序列图描述了对象之间的相互作用，什么时候对象之间发送怎样的消息进行交互。
它按照时间序列进行组织，操作中的对象按照消息发生的次序列表。
用例视图----协作图
协作图反映的信息和序列图相同，但是它侧重于对象的角色而不是消息发送的时序关系。
对象之间流动的消息用消息箭头表示，箭头中间用标签标识消息被发送的序号、条件、迭代（iteration）方式、返回值等等。
通过识别消息标签的语法，开发者可以看出对象间的协作，也可以跟踪执行流程和消息的变化情况。
协作图中也能包含活动对象，多个活动对象可以并发执行。
用例视图---活动图
活动图（activitydiagram）反映一个连续的活动流。
活动图更常用于描述某个操作执行时的活动状况。
活动图由各种动作状态（actionstate）构成，每个动作状态包含可执行动作的规范说明。
当某个动作执行完毕，该动作的状态就会随着改变。
这样，动作状态的控制就从一个状态流向另一个与之相连的状态。
16逻辑视图
逻辑视图（logicalview）描述了支持用例图功能的逻辑结构。
包括类图（Classdiagram）和状态图（Statediagram）。
类图描述了系统中类的组成及他们之间的关系，方框内表示的是类，类与类之间的连线表示来的关联。
逻辑视图---状态图显示对象的可能状态以及状态之间的迁移，它回答的问题是对象在某时刻处于什么状态。
17组件视图
在UML中，描述实现的视图成为组件视图（componmetview）。
它对模型中的组件建模，描述应用程序搭建的软件单元以及组建之间的依赖，从而可以估计更改的影响。
他还对类以及其他元素在组件中的分配建模。
如图为银行取款系统的组件视图，系统分别为：
界面组件、银行业务组件和访问数据库组件。
界面组件负责和用户的交互，银行业务组件处理业务逻辑，BankDB提供与数据库的接口。
18布局视图
布局视图包括布局图（deploymentdiagram），显示了系统的软件和硬件的物理配置。
如图是布局图，标记WindowsPc的节点上安装了系统的用户界面，标记AppServerUnix的节点上安装了业务逻辑，标记DBServerUnix的节点上安装了数据库管理系统。
19UML软件分析与开发步骤
以关注重点的软件的开发被分为以下几个阶段：
19.1、初级阶段：
提出系统（用户）需求。
它使问题得提出过程，需要确定软件的大体要实现什么功能，有哪些参与者。
用例图表达的正式参与者的软件应用，应用和系统响应之间的关系。
19.2、细化阶段：
是系统分析阶段，在这个阶段，需要把软件的功能细化，同时考虑数据间的关系（层次），然后建立与之对应的对象，接着分析对象间的关系（即软件结构），并定义对象的属性和方法。
最后得到想要的产品和它的体系结构在该阶段还要求明确系统的需求，按重要性对需求进行排序，每个需求都说明了特定的功能，并为测试打下基础。
常用的分析方法有流程图、泡泡图和自顶向下分析方法等，但每种方法只能反映系统的某一方面，如果结合起来，就形成了UML的分析方法。
具体方法如下：
首先对用例图进行分析，按时间顺序一个个的过程标注出来，形成顺序图，同时，用力图中还可以使用协作图和状态图。
其次把上一步分析的过程和数据整理成对象的方法和属性，并在类图中画出来。
完成类图后，把相近的类放在一起，形成一个包，接着把这些类用相应的关系连接起来，最后，在给予操作系统的特定语言的基础上，分析整个系统需要哪些模块，对应于什么文件（比如在windows中的exe、dll等文件）、可在组建中注释出来。
19.3、构造阶段：
就是软件实现过程。
这一过程把抽象的软件模型转变为具体的代码，并准备将概念模型移交给用户。
使用基于UML的CASE工具建立相应的模型，进而使用软件直接产生基于此模型的对应代码框架。
一个清晰的软件系统雏形就形成了，往后阶段之需要把具体代码填充到框架中。
19.4、移交阶段：
在本阶段将软件交给用户。
在这个阶段中，软件开发并没有结束，还要继续改善系统，根除错误。
对于UML设计出来的软件，模型中不同视角图表就可以把软件结构清晰地表达出来，同时在建立模型时所写的文档，也会自动加入到源代码中。
20英文版启动界面
21选择UseCase的界面
22汉化的界面
第三章用例图
学习目标
掌握用例图的基本概念
理解用例图内元素间的关系
能够分析系统的用例、活动者与活动者之间的关系
能够使用Rose创建用例图
学习重点
学习难点
1能够分析系统的用例、活动者与活动者之间的关系
用例视图表示活动者和用例之间的交互，能帮助理解和使用系统。
2用例图的基本概念
用例试图由用例图（Use-casediagram）与协作图（collaborationdiagram）、序列图（sequencediagram）和活动图（activitydiagram）组成。
如图所示：
在UML中，用例图用椭圆（oval）表示，它用来记录用户或外界环境从头到尾使用系统的一系列事件。
用户被称为“活动者”（actor）。
活动者可以是人，也可以是另外的一个系统。
它与当前的系统进行交互，向系统提供输入或者获得输出。
用例图显示了用例和活动者之间、用例之间以及活动者之间的关系（relation），关系描述了模型元素之间的语义连接。
在UML中，关系使用实线表示，实线可以有箭头，也可以没有。
2.1活动者
活动者是人或与系统进行交互的外部系统，如何判断活动者呢？
分析如下问题：
2.1.1谁对系统的某一需求感兴趣？
2.1.2组织中哪一部分使用系统？
2.1.3谁从系统的使用中受益？
2.1.4谁向系统提供信息？
2.1.5谁将维护系统？
2.1.6系统使用外部资源吗？
2.1.7系统和已经存在的系统交互吗？
2.2用例图的基本概念-----用例和用例图
用例是系统使用片段的集合，描述了所有的功能需求。
它来自于客户需求的分析，这个过程称为用例分析，是整个系统开发中非常关键的过程。
用例分析有助于如下工作：
2.2.1、捕捉需求
2.2.2、计划开发过程的循环往复
2.2.3、验证系统
升级会员 