软件工程 实践和导论 资料.docx
《软件工程 实践和导论 资料.docx》由会员分享，可在线阅读，更多相关《软件工程 实践和导论 资料.docx（71页珍藏版）》请在冰豆网上搜索。
软件工程实践和导论资料
第1章UML建模语言概述
UML：
UnifiedModelingLanguage；
一种可视化的，用于详细描述的建模语言；
它能够让系统构造者用标准的、易于理解的方式建立起能够表达他们设计思想的系统蓝图；
提供一种机制，以便于不同的人之间有效的共享和交流设计成果。
UML的用处：
客户和开发人员之间沟通的桥梁。
UML借助一套图形和符号，可以完成这座桥梁的作用。
●UML不是一门程序设计语言。
但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML。
●UML不是一种可用于定理证明的高度形式化的语言。
这样的语言有很多种，但它们通用性较差，不易理解和使用。
●UML是一种通用建模语言。
对于一些专门领域，例如用户图形界面（GUI）设计、超大规模集成电路（VLSI）设计、基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。
●UML是一种离散的建模语言。
UML不适合对诸如工程和物理学领域中的连续系统建模。
它是一个综合的通用建模语言，适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。
UML的目标
●利用面向对象概念为系统建模；
●建立概念上的与可执行制品的一个显式耦合；
●解决复杂系统和关键任务系统中固有的规模问题；
●创建一种所有人和所有机器都可使用的建模语言。
UML包括以下几个部分：
●视图：
它是由许多图组成的一个抽象，用于建模系统的某个方面。
视图只是表达系统某一方面特征的UML建模组件的子集。
在每一类视图中使用一种或两种特定的图来可视化地表示视图中的各种概念。
●图：
它是描述UML视图内容的图形。
UML有9种不同的图，通过它们的相互组合提供被建模系统的所有视图。
●模型元素：
即UML图中使用的概念，例如类、对象、消息等。
●通用机制：
它为模型元素提供额外的注释、信息和语义。
UML包含五类视图:
●用例视图：
强调从用户角度看到的或需要的系统功能,并指出各功能的操作者。
●逻辑视图：
逻辑视图从系统的静态结构和动态行为角度显示如何实现系统的功能。
●组件视图：
显示的是代码组件的组织关系。
●并发视图：
显示的是系统的并发性，解决在并发系统中存在的通信和同步问题。
●部署视图：
显示系统的具体部署，即目标计算机的物理组成。
图就是用来显示各种模型元素符号的实际图形，这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。
UML中的图包括：
用例图p28、类图、对象图p45、包图p47状态图、顺序（序列，时序）图、协作图、活动图、组件（构件）图和部署（配置）图等
用例图：
用例分析的一个好处是它能够展现出系统和外部世界之间的边界。
参与者（Actor）是典型的系统外部实体，而用例（UseCase）是典型的属于系统内部。
系统的边界（Boundary）用一个矩形来代表，里面写上系统的名字。
系统的用例装入矩形之内。
类图：
属性是类的一个特性，它描叙了类的对象（也就是类的实例）所具有的一系列特性值。
操作是类能够做的事情或者你（或者另一个类）能对类做的事情
对象图：
类的属性在该类的每个对象中都有具体值。
对象名首写字母小写，后面根一个冒号，冒号后面是该对象所属的类名，并且整个名字要带下划线。
包图：
包用附有标签的矩形表示
状态图：
状态用具有圆形拐角的矩形表示,状态间带箭头的实线代表状态的迁移，箭头指向目标状态。
图中的实心圆代表状态转移的起点，带圆圈的实心圆代表终点。
活动图：
活动状态表示成带有圆形边线的矩形，它含有活动的描述（普通的状态盒为直边圆角）。
简单的完成转换用箭头表示。
和状态图相似，活动图也有起点和终点符号，表示法和状态图一样。
协作图：
协作图除了展示出对象之间的关联还显示出对象之间的消息传递。
通常在协作图中省略掉关联的名字。
关联线附近的箭头线表示对象之间传递的消息，箭头指向消息接收对象。
消息名称和消息序号附在箭头线附近。
消息一般含义是触发接收消息的对象执行它的一项操作。
在协作图中，在消息名前面加上消息的序号，它代表该消息在消息序列中的顺序。
消息名和序号之间用冒号隔开。
构件图：
构件用一边有两个小矩形的一个长方形表示，它可以用实线与代表构件接口的圆圈相连。
构件图表示了构件之间的依赖关系。
每个构件实现（支持）一些接口，并使用另一些接口。
如果构件间的依赖关系与接口有关，那么构件可被具有同样接口的其他构件替代。
部署图；
节点用带有节点名称的立方体表示，节点间的关联代表通信路径。
关联有用来辨别不同路径的构造型。
节点也有泛化关系。
UML中的模型元素
类、对象、状态、节点、包、组件和各种关系
UML中通用机制：
修饰，注释，规格说明
扩展UML：
构造型]，标记值，约束
构造型：
基于一个已知的模型元素定义一种新的模型元素，即加入了额外语义的一个已存在元素。
第2章软件建模概述
建模的定义
●建模是捕捉系统本质的过程，是对现实的简化。
●把复杂的系统变成小的系统，采用“各个击破”原则逐一解决。
●把问题从问题领域转移到解决领域。
建模目的：
要生产合格的软件就要有一套关于体系结构、过程和工具的规范。
建模的好处
●使用模型便于从整体上、宏观上把握问题，可更好的解决问题；
●建模是使你逐层深入解决问题的办法；
●便于确认应用系统的功能需求；
●可以加强人员之间的沟通；
●可以更早地发现问题或疏漏；
●模型为代码生成提供依据。
建模的目标
●帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化；
●允许我们详细说明系统的结构和行为；
●给出一个指导我们构造系统的模板；
●对我们的决策进行文档化。
建模的误区
●建模就等于是写文档
●从开始阶段你可以考虑到所有的一切
●建模是在浪费时间
●有的开发人员都知道如何建模
建模十条原则
1仅有数据模型对于现代软件是不够的。
2接受变化，并且允许你的模型能够随着时间进行改进。
你不能冻结它们，然后就期待着成功。
3模型并不一定就是文档，文档也不一定就是模型。
4大多数的模型可能也应该被丢弃。
5只有代码才能与代码保持真正的同步。
6一些简单的工具，比如白板，就完全足以应付大多数建模工作。
7思考，然后再编码。
8你总能从别人身上学到东西。
9建模可以用一种轻盈的方式。
10设计直到代码发布后才算完成。
怎样成为优秀的软件模型设计者
1人远比技术重要2理解你要实现的东西3谦虚是必须的品格4需求就是需求5需求其实很少改变，改变的是你对需求的理解6经常阅读7降低软件模块间的耦合度8提高软件的内聚性9考虑软件的移植性10接受变化
11不要低估对软件规模的需求12性能仅仅是很多设计因素之一13管理接口14走近路需要更长的时间15别信赖任何人16证明你的设计在实践中可行17应用已知的模式18研究每个模型的长处和弱点19在现有任务中应用多个模型20教育你的听众21带工具的傻瓜还是傻瓜22理解完整的过程23常做测试，早做测试24把你的工作归档25技术会变，基本原理不会
软件全程建模：
在软件工程的全部实施过程中都采用模型的方式而非文字的表达方式来进行描述的实现过程。
全程建模的特点：
模型相互之间是有关联的，模型成为软件工程过程各阶段展现的主体而不是文字描述作为主体存在。
基于UML的软件建模
需求建模：
用例图
静态结构建模：
类图、对象图、包图、部署图
动态结构建模：
顺序图、协作图、状态图、活动图
软件界面建模
●首先确定界面元素，通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等等。
●对用户工作效率有明显影响的元素包括：
输入输出方式、交互方式、功能分布。
●界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。
●再次要通过对软件的背景，使用的行业特点、用户的使用水平、喜好等方面的了解提出针对用户的一些设计。
●最后建立用户界面模型，并且同用户进行交互。
这个工作对于界面建模是很重要的，因为用户对于功能的需求相对是比较明确的，对于界面方面的需求却比较模糊，但是当一个系统展现在他们面前的时候，他们却有很多的要求和想法，通过这个工作可以将用户对界面的需求挖掘出来，而且也比较容易暴露设计中的缺陷。
（1）整个类层次结构使用一张表
（2）每个具体类使用一张表
（3）每个类使用一张表
（4）所有类映射到一个通用的表结构
以上几类仿照下面的画
P129
数据库建模之属性拓展模式书p120
第3章软件需求建模-用例模型
用例模型主要组件是：
用例、参与者和被建模系统。
系统边界：
由该系统处理的功能定义。
系统功能：
由用例表示，每个用例指定了一个完整的功能。
用例的主要目的：
●决定和描述系统的功能需求，促成客户与将负责建立系统的开发人员对此达成一致协议。
●对系统应该做什么给出清晰的和一致的描述。
●为系统测试的执行提供一个基础。
●提供将功能需求追溯到系统中实际的类和操作的能力。
用例的定义：
●系统执行的一组动作序列，这些动作可以产生一个特定参与者可观察的结果。
●这些动作会涉及与多个参与者之间的通信，以及在系统内部执行的计算和任务。
用例的特征：
1用例总是由参与者启动
2用例为参与者提供结果3用例是完整的
用例之间的关系：
扩展关系使用关系包含关系分组关系
描述用例：
使用文本来对用例进行详细描述，应包括：
用例的目标
用例如何被启动
参与者和用例之间的消息流
用例的其它流程
用例如何结束并向参与者传递结果
测试用例：
1）验证（verification）：
完成用例建模之后即可与用户一起进行用例的验证。
2）确认（validation）:
当系统开发出来了以后，即可进行用例的确认。
UML在协作中实现用例的任务：
将用例描述中那些不同步骤和动作转换为各个类、类的操作以及这些类之间的关系。
即将用例中的每一步职责分配给参与此协作的所有类。
识别系统边界
需要注意的问题
界定系统边界就是确定哪些需求是在系统之内，哪些需求是在系统之外，即搞清楚我们需要做什么，不需要做什么。
当发现一些系统需求要由某一Actor来实现时，可能这个Actor实际上是系统的一部分，否则这个需求就不是系统要实现的功能。
通过分析需求是否在系统之内来界定系统的边界。
第4章深入需求建模
Include：
若你发现在写用例文档时经常使用拷贝/粘贴操作，则说明用例中包含一些通用的内容可以被重用，这时应该考虑用例之间是否存在包含关系。
Extend：
●扩展通常用于在一定条件下扩展现存用例的行为，这是在不改变原始用例的情况下，添加新行为到用例之中的一种有效方法。
●通常在现存系统的更新版本中或当一种产品可以被客户定制时使用扩展方法。
●使用扩展方法时需要在用例图中加入扩展点（extensionpoints），扩展点标注了用例中的什么地方可以被扩展，扩展可能发生在什么地方。
●每个扩展点必须有一个名字及其在用例中的位置的描述。
●用例是在一定的条件下被扩展的，当执行用例时，若扩展条件为真，则扩展用例中的操作步骤就被执行。
●系统需要提供老主顾价格折扣和季节性商品价格折扣功能。
Inheritance
●在多个Actor和用例之间可能存在继承关系。
●Actor之间存在继承关系意味着一个Actor拥有和另一个Actor相同的角色，这两个Actor以同样的方式和某一用例进行交互。
●用例间的继承关系意味着一个用例是另一用例的特殊版本。
●Inheritance是一种akindof的关系。
Interfaces
Actor和用例都可以定义接口，接口描述了实体能完成的操作。
接口不是用例和Actor的一部分，它只是描述了怎样与Actor和用例交互。
一个Actor或者用例可以拥有多个接口。
一个接口包括接口的名字和一个操作声明集合。
角色接口
具有特定接口的Actor和用例必须支持接口定义的行为，但是我们并不关心接口的实现。
用例接口是为Actor的使用而定义的。
假设NationalWidgets允许大公司进行批量订货，NationalWidgets必须提供一个接口，以使得大公司可以调用。
第5章软件系统静态结构分析与设计
对象就是我们可以谈论和操纵的一个事物，它总是以某种方式与我们对现实世界的理解相关联。
类是对象类型的描述，所有对象都是相应类的实例，类描述了一种对象的特征和行为。
面向对象分析与设计的基础是类、对象，以及它们之间的关系。
类图的一个目的是为其它图定义一个基础，例如在动态图中显示对象的状态以及对象之间的协作。
发现类的任务应该由系统问题域专家来完成
类的名称应该来自系统的问题域，并且应该尽可能地明确，不会造成歧义。
类的名称应该是一个名词。
类属性捕获了描述和识别该类的一个特定实例的信息。
类只应该包括当前正建模的系统感兴趣的属性。
常用的关系：
关联（Association）泛化（Generation）
依赖（Dependency）精化（Refinement）
关联表示两个类的对象之间存在一个链接。
受约束的泛化关系重叠overlapping互斥disjoint
完全complete不完全incomplete
子系统：
一个模型元素不能被一个以上的包拥有。
模型质量：
实用性、易于交流和维护、一致性、完整性、集成性
第6章软件动态行为分析与设计
对象通过相互发送消息来进行交互，消息包括以下几种类型：
简单消息、同步消息、异步消息
用来展示对象之间是如何交互的：
一般形态、实例形态
活动图目的：
●当一个操作正在执行时，捕获其将执行的工作。
●捕获一个对象的内部工作。
●显示一组相关的动作将如何执行，以及它们将怎样影响周围的对象。
●显示用例的实例在动作和对象状态变化方面是如何执行的。
●显示业务在工作者、工作流程、组织和对象等方面是如何工作的。
第7章RUP过程
瀑布过程的假设：
●需求预先可知；
●需求很少变化；
●客户知道他们的所需，而且不需要对需求进行可视化；
●可以用抽象的方法完成设计；
●所采用的技术能解决项目中出现的所有问题。
结构化分析与设计存在的问题：
数据散布在许多不同的函数中，代码重用复杂。
经常是通过粘贴/复制方式在多个地方重用代码。
当逻辑改变时：
•需要在多个地方修改代码。
•改变函数将导致依赖于该函数的其他函数受影响。
•经常需要在函数中动态改变数据类型。
RUP（RationalUnifiedProcess）：
•是一种软件工程过程
•是一个过程产品
•有自己的过程框架
•捕获了现代软件开发中的最佳实践
RUP的目标：
按照预先制定的时间计划和经费预算，开发出高质量的软件产品以满足最终用户的需求。
角色：
描述某个人或者一个小组的行为与职责。
RUP预先定义了很多角色。
活动：
是一个有明确目的的独立工作单元。
工件：
是活动生成、创建或修改的一段信息。
RUP捕获的6项最佳商业实践：
被证明是解决软件开发过程中根本问题的方法，是软件开发过程的经验总结。
RUP的三大特点：
用例和风险驱动、以架构为中心、迭代和增量开发
RUP的六大经验：
1迭代式开发。
2管理需求。
3基于组件的体系结构。
4可视化建模。
5验证软件质量。
6控制软件变更。
1迭代式开发
•在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。
•实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。
•迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。
•迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。
2管理需求
•确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。
•RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本已被证明是捕获功能性需求的有效方法。
3基于组件的体系结构
•组件使重用成为可能，系统可以由组件组成。
•基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。
•RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
4可视化建模
•RUP往往和UML联系在一起，可视化模型有助于提高人们管理软件复杂性的能力。
•RUP告诉我们如何可视化地对软件系统进行建模，获取有关体系结构、组件结构及行为的信息。
5验证软件质量
在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
6控制软件变更
迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。
RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
RUP是一种可伸缩的软件开发框架，具有以下特点：
迭代开发、需求管理、基于组件的架构可视化、可视化建模、质量管理、变化管理
RUP中有9个核心工作流，分为：
16个核心过程工作流（CoreProcessWorkflows）；
23个核心支持工作流（CoreSupportingWorkflows）。
尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。
9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
1．商业建模（BusinessModeling）
商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程、角色和责任。
2．需求（Requirements）
需求工作流目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。
为了达到该目标，要对需求的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
3．分析和设计（Analysis&Design）
分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。
分析设计的结果是一个设计模型和一个可选的分析模型。
设计模型是源代码的抽象，由设计类和一些描述组成。
设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。
4．实现（Implementation） 实现工作流的目的包括：
●以层次化的子系统形式定义代码的组织结构；
●以组件形式（源文件、二进制文件、可执行文件）实现类和对象；
●将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
5．测试（Test）测试工作流要：
●验证对象间的交互作用；
●验证软件中所有组件的正确集成；
●检验所有的需求已被正确的实现；
●识别并确认缺陷在软件部署之前被提出并处理。
RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
6．部署（Deployment）
部署工作流的目的是成功地生成版本并将软件分发给最终用户。
部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：
软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。
在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
7.配置和变更管理（Configuration&ChangeManagement）
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。
配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。
该工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。
同时也阐述了对产品修改原因、时间、人员保持审计记录。
8．项目管理（ProjectManagement）
软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。
其目标包括：
为项目的管理提供框架，为计划人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9．环境（Environment）
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
RUP是一个二维开发模型
●RUP软件开发生命周期是一个二维的软件开发模型。
●横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期（Cycle）、阶段（Phase）、迭代（Iteration）和里程碑（Milestone）.
●纵轴以内容来组织自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、制品（Artifact）、工作者（Worker）和工作流（Workflow）。
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：
初始阶段（Inception）;细化阶段（Elaboration）;
构造阶段（Construction）;交付阶段（Transition）。
●每个阶段结束于一个主要的里程碑（MajorMilestones）
●每个阶段本质上是两个里程碑之间的时间跨度。
●在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。
●如果评估结果令人满意的话，可以允许项目进入下一个阶段。
InceptionPhase
初始需求捕获、成本效益分析、初始风险分析、项目涉及范围分析、定义备选的架构、开发初始的原型、初始的用例模型（10%-20%complete）、初步建立问题域模型
●本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。
●初始阶段结束时是第一个重要的里程碑：
生命周期目标（LifecycleObjective）里程碑。
生命周期目标里程碑评价项目基本的生存能力。
生命期目标里程碑必须满足的条件
ElaborationPhase
用例分析：
●用例（80%writtenandreviewedbyendofphase）
●用例模型（80%done）
●场景：
SequenceandCollaborationDiagrams
Class,Activity,Component,StateDiagrams
需求词汇表（sousersanddeveloperscanspeakcommonvocabulary）
领域模型：
理解系统要解决的问题
精华风险评估
创建可执行的架构路线
为构造阶段创建详细的计划
计划资源、时间、设备、人员及成本标价
●细化阶段的目标
升级会员 