软件工程读书报告2-1

读书报告2-1

一、参考书1（4-5）参考书2（4-6）

1.UML中定义了哪些主要类型的图？综述用例建模中如何对交互模型、结构模型、行为模型进行描述，举例说明。

1）UML提供的基本模型图包括

(1)、用例图

展示系统外部的各类执行者与系统提供的各种用例之间的关系

(2)、类图

展示系统中类的静态结构(类是指具有相同属性和行为的对象 类图用来描述系统中各种类之间的静态结构)

(3)、对象图

是类图的一种实例化图(对象图是对类图的一种实例化)

(4)、包图

是一种分组机制。在UML1.1版本中 包图不再看作一种独立的模型图) (5)、状态图

描述一类对象具有的所有可能的状态及其转移关系(它展示对象所具有的所有可能的状态以及特定事件发生时状态的转移

情况)

(6)、顺序图

展示对象之间的一种动态协作关系(一组对象组成随时间推移对象之间交换消息的过程 突出时间关系)

(7)、合作图

从另一个角度展示对象之间的动态协作关系(对象间动态协作关系突出消息收发关系)

(8)、活动图

展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程)

(9)、构件图

展示程序代码的物理结构(描述程序代码的组织结构 各种构件之间的依赖关系)

(10)、配置图

展示软件在硬件环境中(特别是在分布式及网络环境中)时间推移对象之间交换消息的过程 突出时间关系)

2）

交互模型

也是针对每个用例而言的，是在用例描述和Robustness分析的结果的基础上进行的。因此，我们还将以用例为蓝本，来说明如何构建交互模型。我的习惯是将用例描述中的基本事件流与扩展事件流部分，以及Robustness分析的结果打印出来，以便在设计时参考。而且这也方便了设计时团队成员之间的交流，可以获得较好的效果。

交互建模之后，到此为止，我们就完成了用例所对应的交互模型。不过，事件还没有结束，我们需要在这个成果的基础上进一步工作，将其发挥更大的作用。这些工作包括添加类的属性和方法、质量评审、引入基础类以及用设计模式进行优化，下面我们就一一作个简单的介绍。添加个类的属性与方法。

在构建交互模型时，我们将会发现类应该具有的方法，也会在设计时找到一些新的属性，而这些东西将进一步地完善我们的静态模型。我们基于域模型的基础，结合Robustness分析、交互模型构建时所引入的设计类，画出相应的设计类图，并且将这里所找到的属性、方法补充在类图中去，这样我们将获得一个较完整的类模型。质量评审当我们通过引入基础类之后，将获得一个较完整的类模型，接下来我们就需要运用面向对象设计的一些基本原理，对其进行质量评审。低耦合：耦合性是指两个类之间的连接强度，耦合性越低，说明类之间的独立

性越高，相应的系统的灵活性也越高。

高内聚：内聚性则是指一个类的属性与方法高度地集成，内聚性越高，说明类的设计越合理，系统的稳定性也越高。

效率：低耦合与高内聚都是一个相对的概念，衡量的要点在于解决方案的执行效率是否满足系统的需求。

完整性：类的完整性是指在任何环境下都可以重复使用，完整的类也就意味着其具有较高的内聚性，也就意味着它与其它类之间的耦合较低。

简单性：每一个类越简单，出错的可能性越小，系统的灵活性和可维护性也越好。

而把类当作一个框，什么都往里装的代码风格，就是一个具有“坏味道”的代码，需要重构它

我们需要将这些包中，将要使用的类引入，然后从中派生（使用继承）应用系统所需要的类。如果你使用Rose进行类建模，那么你就可以很方便地引入这些基础类，因为Rose都将这些基础类做好了。应该看出一个学习开发知识的要点，即应该花足够多的时间来了解各种基础框架、库函数的功能与特性，以便在设计时做出最优的选择；另外，还应该对这些基础框架、库函数的类结构有一个清晰的了解，这样就可以最有效地找到基础类，最高效地使用。用设计模式进行优化

如果你在质量评审中发现了问题，那么你可以使用两种武器，那就是设计模式与重构。它们都将帮助你使代码更加的高质量，重构技术侧重于代码结构的重新整合，而设计模式则是通过引入新的设计类，还提高代码的可维护性、灵活性。交互建模是详细设计阶段的重要工具，当我们完成了交互模型之后，我们就会发现所有的类跃然纸上，而且这些类所需的属性和方法（即行为）也被清晰地找到，还清楚地掌握了类与类之间的交互，然后通过引入基础类、利用设计模式优化，将会使得紧接下来的代码编写工作将变得更加清晰。不幸的是，由于篇幅的限制，我们从用例建模开始，只对其中的一个用例进行了分析，完成了用例描述，也仅对一个用例进行了Robustness 分析（初步设计）、构建交互模型（详细设计）。因此，我想大家也不知不觉地走进了细节，也许让您感到“只见树木，不见森林”了。不过没关系，我将在下一期中再次从更宏观地角度帮助大家整理一下思绪，然后再继续进发。

结构模型

设计模式中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短

开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。二、框架与架构之间的关系框架不是构架（即软件体系机构）。体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。三、框架与设计模式之间的关系设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。1)从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。2)从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。3)以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。行为模型