软件工程对象结构模型

1、简述结构化范型和面向对象范型的要点，并分析它们的优缺点。

答：结构化范型要点：结构化范型也称生命周期方法学，属于传统方法学。

传统的软件开发方法大部分采用瀑布模型。

这种模型要求每一阶段都以前一阶段形成的文档为基础完成工作。

每一阶段将要完成时，都要求开发人员进行验证或确认。

瀑布模型要求在软件产品生成之前对用户需求进行尽可能精确的、完全的刻画。

但要完成这种任务相当困难。

优点：把软件生命周期划分成基干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发过程的困难程度.缺点:当软件规模庞大时，或者对软件的需求是模糊的或会承受时间而变化时，开发出的软件往往不成功；而且维护起来仍然很困难。

面向对象范型四个要点：（1）面向对象的软件系统是由对象组成的，软件中的任何元素都是对象，复杂的软件对象由简单的软件对象组合而成。

（2）所有对象划分成各种对象类，每个对象都定义了一组数据和一组方法。

（3）按照子类（派生类）和父类（基类）的关系，把若干个对象类组成一个层次结构的系统（类等级）。

在派生类中对某些特性又做了重新描述，则在派生类中的这些特性将以新描述为准，也就是说，低层的特性将屏蔽高层的同名特性。

（4）对象彼此之间仅能通过传递消息互相联系。

面向对象范型主要优点（1）按照人类习惯的思维方法，对软件开发过程所有阶段进行综合考虑；（2）软件生存期各阶段所使用的方法、技术具有高度的连续性；（3）软件开发各个阶段有机集成，有利于系统的稳定性】6、非渐增式测试与渐增式测试有什么区别？答：【区别：1、非渐增式测试方法把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。

而渐增式测试往往把单元测试与集成测试和在一起，同时完成。

2、非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量较少。

渐增式可以较早的发现接口之间的错误，非渐增式最后组装是才发现。

第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。

如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。

实现方案用UML交互图表示。

（2）设计技术支撑设施。

在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。

这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。

例如，数据的持久存储服务、安全控制服务和远程访问服务等。

在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。

（3）设计用户界面。

（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。

此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。

面向对象的软件设计过程如图8-1-1所示。

图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。

因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。

该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。

一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。

在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。

顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。

第七部分设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改）。

1.1.设备信息包括设备的位置信息、名称、状态。

1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改）。

2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。

2.1场景视图（Use case）使用user case图设计系统的各个场景。

2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。

2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

2.5过程视图（Process View），捕捉设计的并发和同步特征。

4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。

如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。

我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。

在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。

在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。

3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。

软件从工程的角度讲有好几种生命周期模型。

所有的生命周期模型本质上都是功能导向的模型。

这与软件本身的功利性当然是分不开的。

毕竟不管从哪个角度看，它都仍然是一种人类工具。

而不是人类认识。

构建软件的过程本身也与科学基本上没什么关系。

软件是以“用”为其目的的。

软件开发范式本身与软件工程并不冲突。

开发范式在软件领域更象是一种哲学，代表了开发者的软件认识观或结构观。

而软件工程本身研究的则是作为一种过程的软件开发的学问。

一个是哲学，一个是过程，显然不是同一种知识，怎么可能会冲突呢？但是至少有一种周期模型与面向对象有点关系。

那就是迭代。

迭代模型的提出与面向对象在出发点上很可能是一样的，那就是两者都是为了应付“变化”。

面向对象通过模仿人类的知识系统结构达到了构建更稳定系统也即更能应付变化的系统的能力。

而迭代则是通过将需求切成几段也即“分而治之”的方法一点一点地得到了应付变化或者至少说，应付“认知”（其实非面向对象的开发范式中根本就不存在认知的概念。

这种不认知，即它的“认知”）的能力。

一个不采用面向对象作为其开发方法的迭代模型，自然将沿袭“功能分解”的传统哲学。

在这种哲学指导下开发出来的系统最终都是功能性系统。

象很多硬件一样。

是一种非常自然且普遍的系统构建方法。

事实上，这个世界上绝大多数的系统或者说科学，都是基于这样的思想构建起来的。

再说大一点，甚至整个人类文明的绝大部分也是基于这样的思想构建起来的。

从这个角度看，软件开发从一开始就非常自然地走向了功能性道路这一点并不足为奇。

倒是，如果它一开始不这么走，那才会让人觉得奇怪。

因为那不符合科学发展的自然趋势。

科学是功利的。

软件也必须是功利的。

科学的手段也是功利的。

软件的手段在今天，在大部分情况下，也是功利的。

好象无可厚非。

因为此，面向对象一直都是很难被接受的一样东西。

网上有文章说西方人从小就接受这样的思想，所以长大就变成很自然的东西。

这里不能同意。

因为其实西方人最擅长的并不是这么哲学的东西。

软件工程（简要知识点）一、. 软件过程五个模型对比（瀑布模型、快速原型、增量、螺旋、喷泉模型）二、可行性研究：1、任务：用最小的代价在尽可能短的时间内确定问题是否能够解决。

2、四个方面：技术、经济、操作可行性、法律3、数据流图四种成分：1、源点/终点2、处理3、数据存储4、数据流三、需求分析：1、任务：确定系统必须完成哪些工作，对目标系统提出完整、清晰、具体的要求。

2、结构化方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

3、实体联系图：1、数据对象2、属性3、联系（1:1、1：N 、M:N ）四、总体设计：1.任务：回答“概括的说，系统应该如何实现”，用比较抽象概括的方式确定系统如何完成预定的任务，也就是说应该确定系统的物理配置方案，并且进而确定组成系统的每个程序结构。

2. 系统设计阶段（确定系统具体实施方案）、结构设计阶段（确定软件结构）3.模块独立：内聚和耦合4. 耦合表示一个软件结构内各个模块之间的互连程度，应尽量选用松散耦合的系统 问题定义（确定题目）可行性研究需求分析 概要设计详细设计编码和单元测试 综合测试系统设计 系统实现 软件定义 软件开发 运行维护：主要任务是使软件持久地满足用户的需要软件生命周期：5. 内聚(Cohesion): 一个模块内各元素结合的紧密程度6.面向数据流的设计方法：变换流和事务流五、详细设计：1.任务：确定应该怎样具体的实现所要求的系统，也就是说经过这个阶段的设计工作应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

2.过程设计的工具（程序流程图、盒图、PAD图、判定表、判定树）七、测试：1、单元测试：又称模块测试。

每个程序模块完成一个相对独立的子功能，所以可以对该模块进行单独的测试。

由于每个模块都有清晰定义的功能，所以通常比较容易设计相应的测试方案，以检验每个模块的正确性。

2、集成测试：在单元测试完成后，要考虑将模块集成为系统的过程中可能出现的问题，例如，模块之间的通信和协调问题，所以在单元测试结束之后还要进行集成测试。

什么是软件危机，有哪些具体表现形式？其原因？答：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

主要有以下表现形式：1、对软件开发成本和进度的估计常常很不准确 2、用户对“已完成的”软件系统不满意的现象经常发生 3、软件产品的质量往往靠不住 4、软件常常是不可维护的 5、软件通常没有合适的文档资料 6、软件成本在计算机系统总成本中所占的比例逐年上升 7、软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势原因：1、与软件本身特点有关2、与软件开发与维护的方法不正确有关什么是软件生存周期，有哪几个活动？比较模型软件生存周期是指一个软件该软件报废为止的整个时期。

软件生命周期由软件定义、软件开发和软件维护3个时期组成。

1问题定义，解决的问题是是什么；2可行性研究，问题是否有可行的解决办法；3需求分析，确定目标系统必须具备的功能；4总体设计，总体上解决问题，设计软件出层次结构图、5详细设计，具体实现，设计算法；6编码和单元测试，编程和单元测试；7综合测试，系统地设计测试用例；软件维护，修改软件满足用户需要。

瀑布模型：自上而下，相互衔接的固定次序，像瀑布逐级下落，有顺序性和依赖性，推迟实施，质量保证，严格要求输出文档，缺乏灵活性。

快速原型模型：能快速建立。

它所完成的功能往往是最终产品能完成的功能的一个子集，适合中小型，短周期的交互式系统。

增量模型：把软件产品作为一系列增量构件来设计、编码、集成和测试，能在较短的时间完成，有充裕的时间学习。

适合开发需求不明确设计方案有一定风险的软件项目。

螺旋模型：它是风险驱动的。

适合大型系统及软件的开发。

将瀑布模型与增量模型结合起来，喷泉模型：迭代和无缝连接简述软件测试的任务、目的与类型。

答：软件测试是一个为了寻找软件错误而运行程序的过程。

目的就是为了发现软件中的错误。

一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。

一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

EB登记已收款车票D受理收款 A 乘客C 车费计算一个班学生的平均成绩存储成绩 关闭文件并打 记录(3) 印平均成绩(4)计算某个科目的平均成绩创建新的成 绩记录(2) 读取科目和 初始化变量 sum 并打开文件(1) 成绩P 1图3 程序模块互连图3r5ts6uq42图 4 程序流程图a=0,b=1a++Fa<=100a++a>=20TFTa<=100Fa++图 5 程序流程图输入 A/B/C/DA>0 and B>0X=A-B X=A+BC>A and D<BY=C-D Y=C+D终止T学生成绩成绩报告核对后的成绩报告E3 E1成绩 审查 结果成绩管理系统课程 完成 通知E4D2学生成绩D1核对后的 成绩报告验证学生信息无效成绩 有效成绩2记录有效成绩课程完 成通知D5E3D45生成最终成绩单成绩单3记录无效成绩无效成 绩通知4生成成绩列表成绩审查结果成 绩 报 告列表 请求生成 成绩 成绩列表D3E4E1E21生成成 绩列表 请求无效成绩 通知 成绩 列表E2成 绩 单。

简答题：软件工程的内容和方法1.开发文档都有哪些？用图来表示他们之间的关系。

开发文档包括目标程序、源程序、详细设计说明书、概要设计说明书、需求规格说明书、用户需求报告、软件合同，它们之间的关系如图所示。

2.说明软件工程研究的内容。

软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。

其中软件开发方法的内容又含盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。

常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。

软件支持过程由所支持的CASE工具组成，常用的CASE工具有PowerDesigner和RationalRose。

软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。

3.请详细解释软件的定义和程序的定义。

软件的定义：软件=程序+数据+文档。

这里的程序是指程序系统。

这里的数据不仅包括初始化数据、测试数据，而且包括研发数据、运行数据、维护数据，也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据。

这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档。

现在有一种新提法正在引起关注，这种提法是：软件=知识+程序+数据+文档。

程序是计算机为完成特定任务而执行的指令的有序集合。

从应用的角度可理解为：面向过程的程序=算法+数据结构面向对象的程序=对象+信息面向构件的程序=构件+构架4.是否存在这样一种现象：搞系统软件的公司不需要采用CMMI和ISO9000模式？CMMI和ISO模式只适用于搞应用软件的企业？如果是，为什么？如果不是，又是为什么？不是。

因为CMMI和ISO9000模式规定了严格的管理制度、文档和评估软件能力与成熟度等级的一套标准，它们几乎包括了所有的IT的企业，只是一些优秀的企业自己内部形成特有的企业管理文化，但是它们并不排斥CMMI和ISO9000模式，甚至还充分肯定CMMI 和ISO9000体系。

常见的软件开发模型软件开发模型是软件开发全部过程、活动和任务的结构框架。

1. 软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的流水线。

2. 软件开发模型能清晰、直观地表达软件开发全部过程，明确规定要完成的主要活动和任务，它用来作为软件项目工作的基础。

3. 软件开发模型应该是稳定和普遍适用的软件开发模型的选择应根据：1. 项目和应用的特点2. 采用的方法和工具3. 需要控制和交付的特点软件工程之软件开发模型类型1. 边做边改模型2. 瀑布模型3•快速原型模型4. 增量模型5. 螺旋模型6. 喷泉模型边做边改模型（Build-and-Fix Model ）国内许多软件公司都是使用"边做边改"模型来开发的。

在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。

在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；（2）忽略需求环节，给软件开发带来很大的风险；（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

瀑布模型(Waterfall Model )1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

UML建模工具中的五大视图本节和大家一起学习一下UML建模工具方面的知识，本节主要包括面向对象建模概念和UML中的五大视图等内容，相信通过本节的介绍你对UML建模工具有一定的认识。

下面让我们一起来学习UML建模工具吧。

UML建模工具1．面向对象建模建模把复杂得问题分解为易于理解的小元素，以达到问题的求解模型帮助你具体化和指出系统的不同方面，模型也显示不同的部分如何彼此相关并有助于它们的工作形象化。

UML定义了软件工程领域中的不同模型。

下面给出模型和它们的描述：.类模型描述其静态结构，状态模型表示对象的动态行为，用例模型解释用户的要求，交互模型描述消息流，实现模型包含工作单元，部署模型包含属于进程分配的细节。

提供一种简单的、准备使用的、表现为可视的建模语言，是独立于过程的，是独立于语言的2．UML建模工具的五大视图：UML定义了软件工程领域中的不同模型。

下面给出模型和它们的描述：.类模型描述其静态结构，状态模型表示对象的动态行为，用例模型描述用户的要求，交互模型描述消息流，实现模型描述工作单元，部署模型属于进程分配的细节。

◆用户视图–表示系统的目的和目标◆结构视图–表示系统的静态或空闲的状态◆行为视图–表示系统的动态状态或状态的变动◆实现视图–表示系统的逻辑元素的分布◆环境视图–表示系统物理元素的分布3．用户视图系统的用户视图由用例图组成，用例图包含执行者、用例、及它们的关系，用例图表示了系统对外部实体提供的功能，用例图由执行者和用例组成（执行者对系统做什么的）执行者主要可分为四类：主要执行者–直接与系统交互的人，次要执行者–涉及到系统维护的人，外部硬件–运行应用的非计算机的系统部分，其他系统–为其工作需要与你系统交互的外部系统4．结构视图UML建模工具中结构视图代表系统的静态方面，包含类图（描述不同的类和它们的关联，描述系统中声明的类）和对象图（描述不同的对象和它们彼此间的链接）。

类：用来描述具有特征的现实世界的实体。

浅谈《软件⼯程》常⽤的⼏种软件开发⽅法软件⼯程在上个世纪60年代中期爆发了众所周知的软件危机。

为了克服这⼀危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件⼯程这⼀术语，并在以后不断发展、完善。

与此同时，软件研究⼈员也在不断探索新的软件开发⽅法。

软件开发⽅法⽬前常⽤的开发⽅法有四种，分别是结构化⽅法、原型法和⾯向对象⽅法。

接下来我们会⼀⼀叙述这些软件开发⽅法的实现过程和其中的特点以及优缺点。

1. 结构化⽅法结构化⽅法：结构化⽅法是应⽤最为⼴泛的⼀种开发⽅法。

按照信息系统⽣命周期，应⽤结构化系统开发⽅法，把整个系统的开发过程分为若⼲阶段，然后⼀步⼀步她依次进⾏，前⼀阶段是后⼀阶段的⼯作依据；每个阶段⼜划分详细的⼯作步骤，顺序作业。

每个阶段和主要步骤都有明确详尽的⽂档编制要求，各个阶段和各个步骤的向下转移都是通过建⽴各⾃的软件⽂档和对关键阶段、步骤进⾏审核和控制实现的。

它是由结构化分析、结构化设计和结构化程序设计三部分有机组合⽽成的。

它的基本思想：把⼀个复杂问题的求解过程分阶段进⾏，⽽且这种分解是⾃顶向下，逐层分解，使得每个阶段处理的问题都控制在⼈们容易理解和处理的范围内。

以数据流图，数据字典，结构化语⾔，判定表，判定树等图形表达为主要⼿段，强调开发⽅法的结构合理性和系统的结构合理性的软件分析⽅法。

结构化⽅法具有如下特点。

（1）遵循⽤户⾄上原则。

（2）严格区分⼯作阶段，每个阶段有明确的任务和取得的成果。

（3）强调系统开发过程的整体性和全局性。

（4）系统开发过程⼯程化，⽂档资料标准化。

 结构化分析⽅法是⼀种⾯向数据流⽽基于功能分解的分析⽅法, 在该阶段主要通过采⽤数据流程图、编制数据字典等⼯具, 描述边界和数据处理过程的关系, ⼒求寻找功能及功能之间的说明。

该⽅法的优点是：理论基础严密，它的指导思想是⽤户需求在系统建⽴之前就能被充分了解和理解。

由此可见，结构化⽅法注重开发过程的整体性和全局性。