UML建模技术 讲义.pptx

;软件系统有别于工业产品的特征;模型与建模;为什么要建模;误区一：建模就等于是写文档;误区二：从开始阶段解决一切问题;讨论;解决误区二提出的问题;误区三：建模是在浪费时间;误区四：所有的开发人员都知道如何建模;建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。

软件开发非常复杂，一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。

开发者应该有自知之明，学无止境。通过互相取长补短，

建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。

;(1)准确的原则

模型必须准确地反映软件系统的真实情况。模型必须准确，意味着在软件开发的整个周期内模型必须和产品始终保持一致。

(2)标准规范的原则

模型必须在某种程度上是通用的。建模的基本目的是交流，一个开发队伍内部的交流，同一软件的不同时期的版本的开发队伍的交流，不同软件的开发队伍之间的交流，以实现最大程度的软件复用。交流需要语言，语言是通用的、标准的。;(3）子系统划分的原则（横向划分）

不可能单独用一个模型来反映整个系统的任何侧面。软件系统是复杂的，对于软件模型的任意一个侧面不可能用一个模型来反映所有内容，需要把问题分解为不同的子模型，分别处理这些模型，相对独立但又互相联系，综合起来构成了此侧面的一个完整的模型。

;(4）分层的原则（纵向划分）

在建模的过程中，必须有不同的模型，以不同的抽象程度，反映系统的不同侧面。在软件构筑的不同阶段，不同的开发人员如：投资者、管理者、设计者、程序员、测试者和使用者看待软件的侧重面有所不同。因此，软件系统的建模需要不同的模型以反映系统的不同侧面。如，一类模型描绘系统的外部边界和行为，另一类模型描绘系统的内部逻辑关系。

(3)和(4)也合称为抽象，是人们观测和思考世界的基本原则和方法。

;建模建议;怎样成为优秀的软件模型设计者;6.经常阅读别人的设计

7.降低软件模块间的耦合度

8.提高软件的内聚性

9.考虑软件的移植性

10.接受??化，拥抱变化

;11.不要低估对软件规模的需求

12.性能仅仅是很多设计因素之一

13.管理接口

14.简单可靠的设计，不断的重构代码

15.证明你的设计在实践中可行;16.应用已知的模式

17.研究每个模型的长处和弱点

18.在现有任务中应用多个模型

19.理解完整的过程

20.常做测试，早做测试

21.不断的将工作归档

22.技术常变，基本原理不会;

;SDLC（软件开发生命周期）;2、开发阶段：

需求分析阶段

系统分析员深入充分的理解用户需求，明确“做什么”，并以一定规范的格式记录下用户的需求形成需求规约

分为功能性需求和非功能性需求

设计阶段

以需求规约为基础将需求细化为描述处理进程和算法的伪代码，完成“怎么做”的设计蓝图，确定软件的体系结构和模块划分，以一定规范的格式记录下它们形成设计规约。

较多的与编码阶段互相渗透，如设计模式的提出与广泛应用。

区别显著！“做什么”与“怎么做”;3、实现阶段：

代码编写

遵守设计规约定义的体系结构、模块划分等要求，以可在需求规约定义的运行环境下运行的程序实现需求规约定义的需求，并以一定规范形成编码文档。

测试

按照需求规约的要求尽可能多的寻找出没有实现的以及错误的实现，并形成一定规范的测试文档。;4、运行维护阶段：

交付给用户使用，一般需对用户进行操作培训，并对未发现的软件错误及时更正，以及应客户要求加入软件的新特性新功能。

一个趋势是将运维阶段和实现阶段视为一起，例如大量的遗产系统（legacysystem的增量开发维护）以及全生命周期的IT服务。;软件开发过程模型;一个好的软件过程不一定产生好的软件产品

但一个不好的软件过程必然产生低劣的软件产品质量;瀑布模型;瀑布模型—实际的瀑布模型;TomGilb：

“假如你不积极地解决你项目中存在的风险，它们就会积极地解决掉你”

瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时

已无济于事。;瀑布模型的特点;瀑布模型的问题;迭代/增量模型;迭代/增量模型;迭代/增量模型;迭代/增量模型融合了瀑布模型基本成分和原型迭代特性。

例如，使用迭代/增量模型开发字处理软件

基本的文件管理、编辑和文档生成功能。

更完善的编辑和文档生成能力。

实现拼写和文法检查功能。

完成高级的页面布局功能。

第一个增量往往是核心产品

每一个增量均发布一个可操作产品

早期的增量是最终产品的“可拆卸”版本;快速原型法－原型模型;原型模型的适用情况;原型模型从需求收集开始。开发者和用户在一起定义软

件的总体目标，标识出已知的需求，并规划出进一步定义的

区域。

然