软件工程串讲.docx
《软件工程串讲.docx》由会员分享，可在线阅读，更多相关《软件工程串讲.docx（30页珍藏版）》请在冰豆网上搜索。
软件工程串讲
《软件工程》串讲资料
第1章绪论
1.1软件工程概念的提出与发展
软件工程的概念
软件工程是应用于计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户要求的软件产品的工程,或以此为研究对象的学科.
1.2软件开发的本质
1.软件的概念
计算机软件一般是指计算机系统中的程序及其文档.其中,程序是计算机任务的处理对象和处理规则的描述;文档为了理解程序所需的阐述性资料.
由软件的定义可知,软件是对一个特定问题域的抽象,是被开发出的一种逻辑实体,而不是一种”有形”的物理部件.
2.模型概念
简单地说,模型就是待建模系统的任意抽象,其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节。
进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及他们之间关系的语义描述。
3．求解问题的基本途径
问题的结构化谱系如下图所示：
图问题求解的基本手段
为了求解其中的非结构化和半结构化问题，其基本途径是问题建模，问题建模是指运用所掌握的知识，通过抽象，给出该问题的一个结构。
常用的建模手段包括：
结构化方法、面向对象方法以及诸多面向数据结构方法等。
第2章软件需求与软件需求规约
2．1需求与需求获取
1．需求定义及其基本特征
一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。
对于单一一个需求，必须具备5个基本特征：
（1）必要的，该需求是用户所要求的。
（2）无歧义的，该需求只能用一种方式解释。
（3）可测的，该需求是可进行测试的。
（4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
（5）可测量的，该需求是可测量的。
2．功能需求和非功能需求
功能需求规约了系统或系统构件必须执行的功能。
非功能需求：
分为性能需求、外部接口需求、设计约束和质量属性需求。
3、需求发现技术
需求发现技术，如下表所示：
名称
适用情况
成功条件
存在风险
自悟
需求人员不能直接与用户进行交流，自悟就可能是一种切实可行的、比较有吸引力的方法。
需求人员必须具有比最终用户还要多的应用领域和过程方面的知识，并具有良好的想象能力。
无法验证发现的需求是否满足用户的要求，无法验证发现的需求是不是正确的。
交谈
客户支持需求人员与最终用户进行有关系统需求的交流。
依赖于：
（1）需求人员是否具有“正确提出问题”的能力。
（2）回答人员是否具有“揭示需求本意”的能力。
在交谈期间需求可能不断增长，或是以前没有认识到的合理需求的一种表现，说是“完美蠕行”病症的体现，以至于很难控制，可能导致超出项目成本和进度的限制。
观察
用户允许需求人员进入工作现场，并可进行观察，可与有关人员就有关问题进行交流。
需求人员具有洞察事物本质的能力。
（1）客户可能抵触这一观察。
其原因是他们认为开发者打扰了他们的正常业务。
（2）客户还可能认为开发者在签约之前，就已经熟悉了他
们的业务。
小组会
各方组织在管理层面上重视需求工作，并有能力提供人力资源。
会议组织得当，包括责权分明，参与会议的人员具有良好的需求发现能力，并允许发表不同的观点，以便很快地标识需求，揭示需求中存在的问题，并与客户达成共识。
如果会议组织不到位或受到某些客观环境的限制，就有可能过多地召开这样的会议，并产生一些相互矛盾的需求。
提炼
提炼方法是针对已经有了部分需求文档的情况。
依据产品的本来情况，可能有很多文档需要复审，以确定其中是否包含相关联的信息。
有时，也可能只有少数文档需要复审。
已存在项目背景文档以及一些紧密相关的需求文档，并且需求人员具有良好的想象力和需求标识能力，包括熟悉相关的技术标准和法规政策等。
与自悟方法一样，无法验证所发现的需求是否满足用户的要求，无法验证发现的需求是否正确。
2．2需求规约
1．需求规约的定义及其基本特性
需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型。
需求规约一般要满足4个基本特性：
（1）j重要性和稳定性程度（Rankedforimportanceandstability）.按需求的重要性和稳定性，对需求进行分级，例如:
基本需求、可选的需求和期望的需求。
（2）k可修改的（Modifiable）:
在不过多地影响其它需求的前提下，可以容易地修改一个单一需求.
（3）完整的（Complete）:
没有被遗漏的需求.
（4）一致的（Consistent）:
不存在互斥的需求.
2．规约需求的三种语言
在实际工程中，需求规约的表达主要存在三种不同的风格。
（1）非形式化的需求规约。
（2）半形式化的需求规约。
（3）形式化的需求规约。
3．需求规约在软件开发的作用
第一，需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
第二，对于项目的其余大多数工作，它是一个管理控制点。
第三，对于产品的设计，需求规约是一个正式的、受控的起始点。
第四，需求规约是创建产品验收测试计划和用户指南的基础,即基于需求分析规规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。
第3章结构化方法
3．1结构化需求分析
1．表达问题域信息的基本术语及其表示
（1）数据流。
在结构化分析方法中，数据流是数据的流动，如图3-1所示。
图3-1“数据流”表示
（2）加工。
在结构化分析方法中，加工是数据的变换单元，即它接受输入的数据，对其进行处理，并产生输出，如图3-2所示。
图3-2“加工”表示
（3）数据存储。
数据存储是数据的静态结构，如图3-3所示。
图3-3“数据存储”表示
（4）数据源和数据潭。
数据源是数据流的起点。
数据潭是数据流的归宿地。
数据源和数据潭是系统之外的实体，可以是人、物或其他软件系统。
它们均用一个矩形表示，如图3-4所示。
图3-4“数据源”和“数据潭”表示
2．表达功能模型的工具-----DFD图
DFD图，即数据流图，是表达功能模型的工具。
它是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。
3．数据结构符号和判定表、判定树
（1）数据结构符号。
如表3-1所示。
表3-1定义数据结构的符号
符号
描述
符号
描述
=
定义为
{}
重复
+
顺序
m．.n
子界
[|]
选择
（2）判定表。
判定表是用以描述加工的一种工具，通常用来描述一些不易用自然语言表达清楚或需要很大篇幅才能表达清楚的加工。
（3）判定树。
判定树也是一种描述加工的工具，判定表可以用判定树等价表示。
4．结构化分析方法中每一术语所基于的原理以及它们在建模中的作用
如表3-2所示。
表3-2结构化分析方法的基本术语
基本术语
基于的原理
建模中的作用
数据流
数据流是数据的流动
用于表达在分析中所要使用的、用于表达“客体”的信息。
加工
加工是数据的变换单元
用于表达在分析中所要使用的、用于表达“处理”的信息。
数据存储
数据存储是数据的静态结构
用于表达在分析中所要使用的、用于表达“结构化客体”的信息。
数据源和数据潭
数据源是数据流的起点。
数据潭是数据流的归宿地。
为了表示系统的环境，可以使用它们和相关数据流来定义系统的边界。
5．构建系统功能模型的步骤
（1）建立系统环境图，确定系统语境。
（2）自顶向下，逐步求精，建立系统的层次数据流图。
（3）定义数据字典。
（4）描述加工。
6．结构化方法存在的问题
从软件方法学研究的角度，结构化方法仍然存在一些问题，其中最主要的问题是仍然没有摆脱冯·诺依曼体系结构的影响，捕获的“功能”和“数据”恰恰就是客观事物的易变性质，，由此建造的系统结构很难与客观实际系统的结构保持一致。
3．2结构化设计
1．变换型数据流图和事务型数据流图
（1）变换型数据流图。
具有较明显的输入部分和变换部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图，如图3-5所示。
图3-5变换型数据流图
（2）事务型数据流图。
数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行，这类数据流图称为事务型数据流图，如图3-6所示。
图3-6事务型数据流图
2．模块以及模块内聚和耦合
（1）模块。
模块是执行一个特殊任务和一个过程以及相关的数据结构，通常有两个部分组成，一部分是接口，另外一部分是模块体。
（2）模块内聚。
内聚是指一个模块内部各成分之间相互关联程度的度量。
常见的内聚类型有：
①偶然内聚②逻辑内聚③时间内聚④过程内聚⑤通信内聚⑥顺序内聚⑦功能内聚
（3）模块耦合。
耦合是指不同模块之间相互依赖程度的度量。
常见的模块间耦合类型有：
①内容耦合②公共耦合③控制耦合④标记耦合⑤数据耦合
3．详细设计工具：
框图、PAD图、N-S图和伪码
（1）框图
程序流程图又称框图，是软件设计的主要工具，是历史最悠久，使用最广泛的软件设计工具。
（2）PAD图
PAD图采用二维树形结构图来表示程序的控制流。
（3）N-S图
N-S图又称为盒图，其基本符号如图3-7所示。
（4）伪码（PDL）
类程序设计语言也称伪码，它是一种用正文形式表示数据结构和处理过程的设计工具。
PDL是一种“混合”语言。
4．变换设计和事务设计
（1）变换设计
变换设计是在需求规约的基础上，经过一系列设计步骤，将变换型数据流图转换成系统的模块结构图。
基本步骤是：
①设计准备-----复审并精化系统模型。
②确定输入、变换、输出这三部分之间的边界。
③第一级分解-----系统模块结构图顶层和第一层的设计。
④第二级分解-----自顶向下，逐步求精。
（2）事务设计
当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。
事务设计的基本步骤和变换设计大体相同。
①设计准备------复审并精化系统模型。
②确定事务处理中心。
③“第一级分解”-----系统模块结构图顶层和第一层的设计。
④“第二级分解”-----自顶向下，逐步求解。
5．“高内聚低耦合”原则以及经验性准则
（1）改进软件结构，提高模块独立性。
（2）力求模块规模适中。
（3）力求深度、宽度、扇出和扇入适中。
（4）尽力使模块的作用域在其控制域之内。
（5）尽力降低模块接口复杂度。
（6）力求模块功能可以预测。
6．详细设计工具的优缺点以及相互转换
（1）程序框架图的优缺点
优点：
对控制流程的描绘很直观，便于初学者掌握。
缺点：
①不是一种逐步求精的工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。
②所表达的控制流，往往不受任何约束可随意转移，从而影响甚至破坏好的系统结构设计。
③不易表示数据结构。
（2）N-S图优缺点
优点：
①它能清晰明确地表示程序的运行过程。
②盒图支持“自顶向下逐步求精”的详细设计。
缺点：
①修改麻烦。
②当分支嵌套层次多时往往在一张纸上难以画下。
（3）PAD图的优点
优点：
①清晰地反映了程序的层次结构。
②支持逐步求精的设计方法，左边层次中的内容可以抽象，然后由左到右逐步细化。
③易读易写，使用方便。
④支持结构化的程序设计原理。
⑤可自动生成程序。
（4）伪码的优缺点
优点：
①PDL不仅可以作为软件设计工具，还可以作为注释工具直接插在源程序中间，以保持文档和程序的一致性，提高了文档的质量。
②可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作。
缺点：
不如图形工具那么形象直观，并且当描述复杂的条件组合与运行间的对应关系时同治如判定表或判定树那么清晰简单。
第4章面向对象方法------UML
4.1 UML术语表
1.类、接口、用况、协作等概念
（1）类
类是一组具有相同属性、操作、关系和语义的对象的描述。
类主要用于抽象客观世界中的事物。
（2）接口
每个操作描述了类、构件或子系统的一个服务，接口就是操作的一个集合。
接口是对系统/产品的“接缝”模型化，表明了一个类、构件、子系统所需要得到的、且与实现无关的行为。
（3）用况
用况是对一组动作序列的描述，系统执行这些动作文治武功产生对特定参与者有值的、可观察的结果。
（4）协作
协作是一个交互，涉及交互的三要素:
交互各方、交互方式以及交互内容。
2.关联、泛化、细化、依赖等概念
（1）关联
关联是对一组有相同结构、相同链的描述，是类目之间的一种结构关系。
关联可以用一条连接两个类目的线段表示，并可对其命名，其结构可以具有方向性，用一个实心三角形来指示关联的方向。
（2）泛化
泛化是一般性类目（超类和父类）和它的较为特殊类目之间的一种关系。
子类可以继承父类的属性和操作，同时，也可以替换父类的声明。
（3）细化
细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约。
（4）依赖
依赖用于描述一个类目使用另一个类目的信息和服务，是一种使用关系。
3.UML的每一个术语所基于的原理以及它们在建模中的应用
UML是一种标准的图形化（即可视化）建模语言，可用于规约系统的制品、构造系统的制品、建立系统制品的文档。
它是一种一般性语言，支持对象方法和构件方法。
从语言学角度，UML规约了八大范畴的事物，引入了8个专业术语，即类与对象、接口、协作、用况、主动类、构件、制品和节点。
（1）类主要用于抽象客观世界的事物，在建立系统模型时，问题域中的大量信息均可用来规约，形成系统建模中具有特定的成分。
（2）接口是操作的一个集合，在建立系统模型时，对系统/产品中的接缝予以模型化。
（3）协作表示交互双方的相互作用，在建立系统模型时，可以通过协作来刻画一种由一组特定元素参与的、具有特定行为的结构。
（4）用况是对一组动作序列的描述，在建立系统模型时，用况一般用于模型化系统的功能行为。
（5）主动类是至少具有一个进程或线程的类，在系统建模时，一般用于模型化系统中的并发行为。
（6）构件是系统设计中一种模型化部件，在建立系统模型是，构件一般用于表达解空间中可独立标识的成分。
（7）制品是系统中包含物理信息、可替代物理部件，在系统建模时，常用于代表有关源代码信息或运行信息的一个物理打包。
（8）节点是在运行时存在的物理元素，通常用于表示一种具有记忆功能和处理能力的计算机资源。
4.类的描述及其语义的表达
类是一组具有相同属性、操作、关系和语义的对象的描述。
通常通过类的名字、属性和操作表达类的语意，为了更好地表达类的含义、增强类的语义，可以通过以下几种方式:
（1）详细叙述类的职责，详细叙述类的职责是对类进行模型化的基础，在此基础上可进一步定义类的属性和操作。
（2）通过类的注解和/或操作的注解，以结构化文本的形式和/或编程语言，详述注释整个类的语义和/或各个方法。
（3）通过类的注解或操作的注解，以结构化文本形式，详述注释各操作的前置条件和后置条件。
（4）详述类的状态机。
（5）详述类的内部结构。
（6）类与其他类的协作。
5.类在建模中的作用
在建模时，类可以对问题域中的大量信息进行规约，从而形成系统模型中具有特定结构的成分。
类的具体功能如下:
（1）模型化问题域中的概念。
（2）建立系统的职责分布模型。
（3）模型化建模中使用的基本类型。
5.表达关联语义的基本手段
UML为了更好地表达关联的含义，采取了以下方法:
（1）关联名。
（2）导航。
（3）角色。
（4）可见性。
（5）多重性。
（6）限定符。
（7）聚合。
（8）组合。
（9）关联类。
（10）约束。
4.2 UML的模型表达格式
1、类图的构成
类图是可视化的表达系统静态结构模型的工具，使用类图所表达的系统静态结构模型，给出的是一些关于系统的说明性信息。
类图可以包含包和子系统；有时为了凸显某个类的作用，还可以包含这样的实例；还可以通过在类图中给出与所包含相关的约事来加强的语义。
2.用况图的构成
用况图是一种表达系统功能模型的图形化工具，它包含六个模型元素，分别是主题、用况、参与者、关联、泛化、依赖。
（1）主题是由一组用况所描述的一个类，通常是一个系统或者子系统。
（2）用况通过一组动作序列规约系统功能，表达了参与者使用系统的一种方式，它是系统开发设计的起点，是类、对象、操作的源，是系统分析和设计阶段的输入之一；是分析和设计、制定开发计划和测试计划、设计测试用例的依据之一；应用于系统的用况是回归测试的最好的源；应用于整个系统的用况是集成测试和系统测试的最好的源。
（3）参与者表达了一组高内聚的角色，当用户与用况交互时，该用户扮演这组角色。
（4）关联是一种参与关系，是操作者与用况之间的唯一关系。
用况图可以为系统建模，描述软件系统行为的功能结构，也可以对业务建模，描述企业或组织的业务过程结构。
不论是对系统建模还是对业务建模都涉及系统/业务语境的模型化和系统/业务需求的模型化。
3.顺序图的构成
顺序图由一组对象以及按时序组织的对象之间的关系组成，是一种交互图，包含对象之间传递的信息。
顺序图能够表达交互行为。
交互中涉及以下一些基本术语:
（1）消息
（2）对象生命线
（3）聚焦控制
4.状态以及状态图的构成
状态图强调了从一个状态到另一个状态的控制流，是显示一个状态机的图。
状态图由状态、事件和状态转移构成。
（1）状态是类的实例在其生存中的一种条件或情况，期间该实例满足这一条件，执行某一活动或等待某一消息。
UML把状态分为3类:
初态、终态和通常状态。
（2）事件是对确定的时空内一个有意义发生的规约，可分为内部事件和外部事件。
（3）状态转移是两个状态间的一种关系，一般包含五个部分:
源状态、转移触发器、监护条件、效应和目标状态。
5.顺序图中的操作子
为了控制交互行为描述的复杂性，以便更好的表达顺序图的复杂控制，UML定义了4种觉的控制操作子:
（1）选择执行操作子
（2）条件执行操作子
（3）并发执行操作子
（4）迭代执行操作子
6.子状态机、简单状态和组合状态
为了有效地组织状态，控制对象状态的复杂性，UML提供了组合状态，在一个状态机中引入了另一个状态机，被引入的状态机称为子状态机。
子状态是被嵌套到另一状态中的状态。
相对地，把没有子状态的状态称为简单状态；把含子状态的状态称为组合状态，组合状态可包含两种类型的子状态机，即非正交（顺序）子状态机和正交（并发）子状态机。
第5章 面向对象方法-------RUP
5.1 RUP的特点
RUP的突出特点是，它是一种以用况为驱动的、以体系结构为中心的迭代、增量式开发。
5.2 核心工作流
1.领域模型、业务模型
领域模型用于捕获系统领域中的一些重要领域对象类，一般是以类图表达的。
领域模型以三种形态出现:
业务对象、实在对象和事件。
业务模型是用于在系统开发中捕获业务处理和其中的业务对象，通过两个层次来抽象一个业务:
业务用况模型和业务对象模型。
2.参与者的标识与描述
参与者是用况模型中的元素之一，对发现的每一个参与者都要进行命名，对每一个参与者都要进行描述，主要给出它的角色和它对环境的要求。
3.用况标识以及标识中的有关准则，用况的事件流描述技术以及描述的基本内容
对于用况的描述一般采用正文的事件流技术，给出用况的前置条件、开始的动作、基本路径、每一个可选路径与参与者的交互以及结束动作和后置条件等。
标识用况应注意三个问题:
（1）建立用况的结构中，应尽可能反映用况的实际情况。
（2）在用况的结构化中，不论是施加什么结构，新引入的用况都不应太小或太大。
（3）在建立用况的结构时，应尽量避免对用况模型中的用况功能进行分解。
4.需求获取层、需求分析层、软件设计层上的术语
（1）需求获取层
需求获取的目的是以UML为基础，使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，从而形成系统的需求获取模型-----一种特定的系统/产品模型，并产生该模型视角下的体系结构描述。
（2）需求分析层
需求分析的目的是在系统用况模型基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述。
①分析类
分析类是RUP为了避免用况模型映射为设计模型时使设计工作变得复杂化引入的，以便有效的控制工作。
分析类是类的一种衍型，分为边界类、实体类和控制类。
边界类的目的在于规约系统与参与者之间的交互，可以用来分离不同用户接口或不同通信接口，形成一个或多个边界类。
实体类用于规约那些需要长期驻留在系统中的模型化对象以及与行为相关的某些现象。
控制类封装了与特定用况有关的控制，表达复杂的推导和计算，用于规约基本动作和控制流的处理与协调，涉及向其他对象委派工作。
②用况细化
用况细化是一个协作，针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为及况细化[分析]。
用况细化对用况模型中的一个特定的用况提供了一种直接跟踪的方式。
③分析包
分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段，一个分析包中包含一些分析类、在分析阶段得到的用况细化，并且还可以包含其他分析包。
其主要特征为:
体现问题的分离；高内聚、低耦合；尽可能体现一个系统的完整顶层设计，尽可能成为一些子系统或成为一些子系统的组成部分。
（3）软件设计层上的术语
软件设计是定义满足需求规约所需要的软件结构。
RUP为了满足系统/产品分析模型规约需求的软件结构，为此，RUP为设计层提供了4个术语:
设计火砖、用况细化[设计]、设计子系统和接口，用于表达软件结构中的基本元素。
5.系统/产品用况模型的构成
6.系统/产品需求分析模型的构成
7.系统/产品设计模型
8.创建系统/产品需求获取模型的四个步骤
为形成特定的系统/产品模型，RUP提出了列出候选的需求、理解系统的语境、捕获功能需求和非功需求四个步骤。
9.创建系统/产品用况模型的活动和任务
创建系统/产品用况模型需要的活动和任务如下:
（1）活动1:
发现并描述参与者。
任务1:
发现参与者，即直接发现一些候选的参与者。
任务2:
描述参与者，即对参与者进行命名并描述。
（2）活动2:
发现用况并对用况进行描述。
任务1:
发现用况
任务2:
描述用况，即确定用况后对其进行描述。
（3）活动3:
确定用况的优先级，目的是在寻找参与者并对其进行描述和发现用况并对用况进行描述的基础上确定哪些用况适合在早期的迭代中开发，哪些适合在后期的迭代中开发。
（4）活动4:
精化用况。
这一活动的目的是详细描述每一用况的事件流，包括用况是怎样开始的，是怎样结束的，是怎样与参与者进行交互的。
最终形成一系列精化的用况。
（5）活动5:
构造用况界面模型。
这一活动的目的在于建造用户界面模型，使用户可以有效地执行用况。
（6）活动6:
用况模型的结构化。
进行用况模型的结构化要做以下工作:
①抽取用况描述中的那些一般性的和共享性的功能并使用泛化关系标识和描述那些共享功能。
②抽取用况描述中附加的或可选的功能。
③标识用况之间的包含关系。
通过用况模型的结构化，最终形成一个系统/产品的精化用况模型，记为用况模型[精化]。
10.创建系统/产品需求分析模型的活动和任务
创建系统/产品需求分析模型的活动和任务如下:
（1）活动1:
升级会员 