桃子网站,网站开发买什么书,wordpress 首页加速,上海网站建设v芯ee8888e#x1f308; 个人主页#xff1a;十二月的猫-CSDN博客 #x1f525; 系列专栏#xff1a; #x1f3c0;软件开发必练内功_十二月的猫的博客-CSDN博客 #x1f4aa;#x1f3fb; 十二月的寒冬阻挡不了春天的脚步#xff0c;十二点的黑夜遮蔽不住黎明的曙光 目录
1. 前… 个人主页十二月的猫-CSDN博客 系列专栏 软件开发必练内功_十二月的猫的博客-CSDN博客 十二月的寒冬阻挡不了春天的脚步十二点的黑夜遮蔽不住黎明的曙光 目录
1. 前言
2. 软件工程概念
2.1 定义
2.2 软件工程与软件工程学
3. Why 软件工程
3.1 什么是软件工程
3.1.1 问题分析
3.1.2 问题解决
3.2 软件工程存在的问题
3.2.1 区分fault、error、failure
3.3 高质量软件
3.4 软件工程的参与者
3.5 总结
4. 开发方法
4.1 系统化开发方法
4.2 工程化开发方法
5. 软件开发的Wasserman规范基本概念
5.1 抽象
5.2 分析和设计方法以及表示法
5.3 用户界面原型化
5.4 软件体系结构
5.5 软件过程
5.6 复用
5.7 测度
5.8 工具和集成环境 1. 前言
软件工程包括什么
项目管理层面的内容技术研发层面的内容软件工程学范畴内的知识点
软件工程要求什么
了解软件工程用工程方法、工程思想完成软件开发的实际操作流程了解工程问题如何解决 软件工程学作用 采用高质量的环境及工具使软件能够按照某种能够反映软件开发规律的规范/模式来开发 。 一句话解释软件工程学的目标 研究规范/模式。这个规范/模式能够体现软件开发过程的自然规律并通过遵循开发过程的自然规律达到 提升软件质量/开发效率 的效果。 2. 软件工程概念
2.1 定义
将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护即将工程化方法应用于软件开发。 软件工程 软件开发技术软件工程学软件项目管理 2.2 软件工程与软件工程学
想要用工程化的方法开发一个软件
完整流程如下
1、学会软件开发相关的技术数据库、编程语言、算法等
2、学会软件工程学利用软件工程学的思想 加上 软件开发相关技术 完成 软件开发
3、软件生命周期整个过程都需要 软件项目管理 从 软件筹划 到 软件落地 再到 软件维护 全部过程都需要项目管理能力 软件工程学是软件工程的一部分软件工程是一个更宏观的概念软件工程学是狭义上的软件工程软件工程学研究的是软件开发的规范/模式 3. Why 软件工程
3.1 什么是软件工程 从词汇本意出发 软件工程 软件工程 定义一用系统化、工程化方法解决软件开发问题 从问题论角度出发 软件工程本质是解决问题软件开发中遇到的问题 定义二 软件工程 问题分析问题解决 针对技术问题项目进展 从定义二出发软件工程关键就在于 问题分析、问题解决
3.1.1 问题分析
对于一个复杂的问题 我们的分析都可以采用如下流程 分解为子问题-解决子问题-合并子问题 3.1.2 问题解决
软件工程中的问题解决就是运用各种技术来有针对、具体的解决所遇到的问题。 针对具体问题提出具体解决方法。例如 提高并发能力分布式开发 提高代码复用率面向对象开发 3.2 软件工程存在的问题
3.2.1 区分fault、error、failure
fault缺陷。程序在功能的实现上存在缺陷但是这个缺陷如果不造成程序运行的error或者不造成程序结果的failure就不会被发现。如果造成程序运行的error/failure那就可以根据error/failure定位到fault的位置。
error错误。错误程序代码运行错误/错误理解需求。
failure失败。程序能够运行但是运行结果有问题。 一个error错误理解需求能造成很多faultfault又将造成failure fault是永远存在的failure、error不一定存在只要永远没运行到fault所在代码就永远不会有error/failure 3.3 高质量软件
软件质量包括
最终产品质量过程的质量软件开发及维护的质量商业质量 目标商业价值和技术价值统一起来两者不一定相伴随 过程提高过程的商业价值软件开发过程中 工作量就是投资就是花费的商业价值 3.4 软件工程的参与者
客户、开发者、使用者 3.5 总结 软件工程 软件工程技术软件工程学软件项目管理 软件工程是一个系统工程包括软件项目开发、项目管理两个方面 项目开发包括问题分析、问题解决需要软件开发技术和软件工程学 项目管理包括过程管理、人员管理等 项目开发中的问题分析和问题解决都依靠软件工程学、软件开发技术的知识。所以这里就引入了两个软件工程概念——1、软件工程包括三方面内容2、软件工程包括两个过程
4. 开发方法
在前一个栏目 3. Why 软件工程 中我们研究了软件工程的两种定义一个是内容定义、一个是过程定义。从内容定义中我们意识到软件工程中的核心在于软件工程学以及软件项目管理在过程定义中软件项目开发过程中也是持续需要软件工程学的知识作为补充。
因此软件工程学是核心
软件工程学前面我们接触了1、问题分析法/问题解决法2、软件工程质量的判断3、软件工程的问题。
其中问题分析和解决是软件工程开发的前言软件工程问题是前序软件工程质量判断是后言。 最核心的部分是如何根据实际问题分析后的结果构建软件通过软件工程质量判断 4.1 系统化开发方法
软件是一个系统因此构建软件最宏观的角度就是从整个系统角度来看软件。 构建软件第一步确定软件系统边界 系统的要素
想要确定系统边界先要了解系统由哪些部分组成
活动对象实体关系系统边界 活动发生在系统中的事件由一个事务转变为另一个事务 对象活动中的所有东西 关系对象与活动之间的所有相互关系 系统边界活动/对象/关系的一个整体工作范围 一个例子 上图只有活动和边界将活动细分才会有关系和对象 活动有Date validation、calculation、printing 实体有打印机、计算员、数据测试员等 关系有活动之间关系、实体活动之间关系 边界是所有活动、关系、实体的范围 4.2 工程化开发方法
将软件开发看作一个工程项目让软件开发也遵从工程项目开发的一个具体流程。 工程化系统化、规范化、模块化 具体流程
需求分析系统设计程序设计程序实现单元测试集成测试系统测试系统提交维护 让软件开发严格遵守上面的具体开发流程从而提高软件质量 5. 软件开发的Wasserman规范基本概念
自从20世纪70年代以来软件开发一直发生着巨大的变化Wasserman 1995。例如早期的应用软件是运行在单处理器上的通常是大型机。输入是线性的往往是一副卡片或一个输入磁带而输出是字母数字。系统用两种基本方式来设计转换transformation它将输入转换为输出事务transaction由输入决定哪个功能将被执行。如今基于软件的系统已经大不相同并且更为复杂。它们通常运行在多个系统上有时配置在具有分布式功能的客户/服务器体系结构中。软件不仅执行用户需要的主要功能而且还要执行网络控制、安全性、用户界面表示和处理以及数据或对象管理。
传统的“瀑布”开发方法假定开发活动是线性前进的即只有在一个活动完成以后才会进行下一个活动将在第2章中学习。这种方法不再灵活也不再适合于当今的系统了。
因此我们需要新的方法这些新的方法需要满足一些规范这就是Wasserman规范
Wasserman指出7个技术变化中的任何一个都对软件开发过程有着重大的影响Wasserman 1996。它们合在一起改变了我们的工作方式。在DeMarco的介绍中描述了这种根本的转变我们首先解决了容易的问题——这意味着尚未解决的一组问题比以前更加困难了。Wasserman通过提出软件工程中存在的8个基本概念来应对这一挑战。这些概念构成了有效的软件工程规范的基础。在这里给出它们的简要介绍在后面的章节中将回过头来探讨它们在什么地方适用于我们所做的事情以及如何应用于我们所做的事情。
5.1 抽象
有时在一个问题的“自然状态”即如同客户和用户表达的那样考虑这个问题是一件令人畏惧的事情。在问题的“自然状态”下我们不可能发现以有效的或者甚至只是可行的方法处理问题的显而易见的方式。抽象abstraction是在某种概括层次上对问题的描述使得我们能够集中于问题的关键方面而不会陷入细节。这个概念与转换transformation不同转换是把问题转移到另外一个我们理解得更好的环境中。转换通常用于将一个问题从现实世界转移到数学世界中这样我们能够利用数字的知识来解决问题。
通常我们使用抽象标识对象的类以便能够把多个项组合在一起。这样我们处理的事情可以更少而且可以集中考虑每个类中各个项之间的共性。我们可以讨论一个类中各个项的性质或属性检查属性以及类之间的关系。例如假定我们要为一条大的、复杂河流构建一个环境监测系统。监控设备可能包括监测空气质量、水质、温度、流速以及其他环境特性的传感器。但是为了达到目的我们可能决定定义一个称为“传感器”的类。类中的每个项具有固定的属性不论它监测哪个特性高度、重量、电力需求、维护进度等。我们在了解问题环境的过程中或在设计解决方案的过程中处理的是类而不是它的元素。因此类的使用有助于简化问题陈述并使我们集中于问题的本质要素或特性。
抽象也可以按层次的方式进行组织。例如传感器是一种类型的电子设备而我们可能有两种类型的传感器水传感器和空气传感器。
因此可以构成图1-13所示的简单层次结构。通过隐藏其中一些细节我们可以集中精力考虑必须处理的对象的本质特性并且得到简单、优雅的解决方案。我们将在第5章、第6章和第7章中更详细地讨论抽象和信息隐藏。 5.2 分析和设计方法以及表示法 当设计一个作为课程作业的程序时通常需要自己完成工作。产生的文档是一个正式描述它告诉你自己为什么选择这个特定的方法、变量名的含义是什么以及实现的算法。但是当与团队一起工作的时候必须与开发过程中的其他参与者进行交流。大多数工程师无论他们是做什么样的工程都会使用标准的表示法来帮助他们进行交流以及文档化相关决策。例如建筑师画了一张图或蓝图任何其他的工程师都能够理解他画的图。更为重要的是公共的表示法使得建筑承包商能够理解建筑师的意图和想法。正如将在第4章、第5章、第6章和第7章中看到的软件工程中没有类似的标准由此产生的误解是当今软件工程中的一个关键问题。
分析和设计方法不止是提供了交流媒介还使我们能够建立模型并检查模型的完整性和一致性。再者我们可以更容易地从以前的项目中复用需求和设计组件从而相对容易地提高生产率和质量。
但是在我们能够决定一组标准的方法和工具之前仍然有许多悬而未决的问题需要解决。正如我们将在后面的章节中看到的那样不同的工具和技术处理的是问题的不同方面我们需要标识建模原语以便用一种技术就能获取问题的所有重要的方面。或者我们需要开发一种供所有方法使用的表示技术当然可能需要某种形式的剪裁。
5.3 用户界面原型化 原型化prototyping意味着构建一个系统的小版本通常只有有限的功能它可用于
帮助用户或客户标识系统的关键需求 证明设计或方法的可行性。 通常原型化过程是迭代的首先构建原型然后对原型进行评估利用用户和客户的反馈考虑如何改进产品或设计之后再构建另外一个原型。当我们和客户认为手头问题的解决方案令人满意时迭代过程就终止了。
原型化通常用来设计一个良好的用户界面user interface即系统与用户交互的部分。但是在其他场合也可以使用原型甚至是在嵌入式系统embedded system即其中的软件功能不是明确地对用户可见的系统中。原型能够向用户展示系统将会有什么样的功能而不管它们是用硬件还是用软件实现的。因为从某种意义上讲用户界面是应用领域和软件开发团队之间的桥梁所以原型化可以把使用其他需求分析方法不能明确的问题和假设表面化。我们将在第4章和第5章讨论用户界面原型化的作用。
5.4 软件体系结构 系统的整个体系结构不仅对实现和测试的方便性很重要而且对维护和修改系统的速度和有效性也很重要。体系结构的质量可能成就一个系统也可能损害一个系统。事实上Shaw和Garlan将体系结构独自作为规范它影响整个开发过程Shaw and Garlan 1996。一个系统的体系结构应该体现我们将在第5章和第7章学习的良好设计的原则。
系统的体系结构根据一组体系结构单元以及单元之间的相互关系来描述系统。单元越独立体系结构越模块化就越容易分别设计和开发不同的部分。Wasserman指出至少有5种方法可以将系统划分为单元Wasserman 1996。
(1) 模块化分解基于指派到模块的功能。
(2) 面向数据的分解基于外部数据结构。
(3) 面向事件的分解基于系统必须处理的事件。
(4) 由外到内的设计基于系统的用户输入。
(5) 面向对象的设计基于标识的对象的类以及它们之间的相互关系。
这些方法并不是相互排斥的。例如可以用面向事件的分解设计用户界面同时使用面向对象或面向数据的方法来设计数据库。我们将在后面的章节中进一步详细分析这些技术。这些方法之所以重要是因为它们体现了我们的设计经验并通过复用已经做过的和所学到的充分利用过去的项目。
5.5 软件过程 自从20世纪80年代后期以来很多软件工程师已经在密切留意开发软件的过程以及由此产生的产品。活动中的组织和规范对软件的质量和软件开发的速度的积极作用已经得到承认。然而Wasserman指出
不同应用类型和组织文化之间的巨大差异使得不可能对过程本身进行预先规定。因此软件过程不可能以抽象和模块化的方式作为软件工程的基础。Wasserman 1996
相反他提出不同的软件类型需要不同的过程。尤其是Wasserman指出企业范围的应用程序需要大量的控制而单个的或部门级的应用程序可以利用快速应用程序开发如图1-14所示。 利用目前的工具很多中小规模的系统可以由一两个开发人员来完成其中每个开发人员必须担任多个角色。这样的工具可能包含文本编辑器、编程环境、测试支持工具还可能包含一个获取关于产品和过程的关键数据元素的小型数据库。因为项目的风险相对较低所以需要很少的管理支持或评审。
但是大型、复杂的系统需要更多的结构、检查和平衡。这些系统通常涉及很多客户和用户并且开发会持续很长时间。再者因为某些关键子系统可能由他人提供或用硬件实现开发人员并不总是能够控制整个过程。这种类型的高风险系统需要分析和设计工具、项目管理、配置管理、更复杂的测试工具以及对系统更严格的评审和因果分析。第2章将详细讨论若干可选的过程以了解不同的过程是如何处理不同的目标的。然后在第12章和第13章中我们评估一些过程的有效性并探讨对它们进行改进的方法。
5.6 复用 在软件开发和维护中通常通过复用以前开发项目中的项来利用应用程序之间的共性。例如在不同的开发项目中我们使用同样的操作系统和数据库管理系统而不是每次都构建一个新的。类似地当我们构建一个与以前做过的项目类似但有所不同的系统时可以复用需求集、部分设计以及测试脚本或数据。Barnes和Bollinger指出复用并不是一个新的思想他们还给出了很多有趣的例子说明复用的不仅仅是代码Barnes and Bollinger 1991。
Prieto-Diaz介绍了这样一种理念可复用构件是一种商业资产Prieto-Diaz 1991。公司和组织机构对那些可复用的项进行投资而当这些项再次用于后面的项目中的时候就可以获得巨大的收益。但是制定一个长期、有效的可复用计划可能很困难因为存在如下这些障碍。
有时候构建一个小的构件比在可复用构件库中搜索这样一个构件要更快。 要使一个构件足够通用、可以在将来被其他开发人员很容易地复用则可能需要花费格外多的时间。 由于难以对做过的质量保证和测试的程度进行文档化可能会导致一个潜在的复用人员认为构件的质量是令人满意的。 如果某个复用的构件失效或需要进行更新不清楚谁应该对此负责。 理解和复用一个由他人编写的构件其代价可能是高昂的也可能很耗时。 在通用性和专业性之间通常存在冲突。 我们将在第12章中更详细地讨论复用并研究几个成功复用的例子。
5.7 测度 改进是软件工程研究的驱动力通过改进过程、资源和方法我们可以生产和维护更好的产品。但是我们有时只能概况地表示改进目标原因是没有量化地描述我们做了什么以及我们的目标是什么。正因为如此软件测度已经成为好的软件工程实践的一个关键方面。通过量化我们做了什么以及我们的目标是什么就可以用通用数学语言来描述我们的行动和结果从而能够评估我们的进展。另外量化的方法允许我们比较不同项目的进展。例如当John Young担任惠普公司的CEO时他设置了“10X”的目标即无论对于何种应用的类型和领域对于惠普的每一个项目在质量和生产率方面都要有10倍的提高Grady and Caswell 1987。
在较低的抽象层次上测度有助于使我们的过程和产品的特定特性更加可见。将我们对现实的、经验世界的理解转换为形式化的、数学世界中的要素和相互关系通常是有益的这样我们可以操纵它们从而得到进一步的理解。正如图1-15所示的那样可以使用数学和统计的方法来解决问题、寻找趋势或刻画一种情形例如使用平均值和标准差。而这个新的信息可以接着被映射回现实世界作为我们试图解决的现实问题的解决方案的一部分。在本书中我们将看到测度如何应用于支持分析和决策的例子。 5.8 工具和集成环境 多年以来厂商一直推荐使用CASE计算机辅助软件工程工具其中的标准化的集成开发环境将增强软件开发。但是我们已经看到不同的开发人员是如何使用不同的过程、方法和资源的。因此一个统一的方法说起来容易做起来就难了。
另一方面研究人员已经提出了几个框架使我们能对已有的环境和打算构建的环境进行比较和对照。这些框架还允许我们检验每个软件工程环境提供的服务决定哪一个环境最适合于给定的问题或应用程序的开发。
对工具进行比较主要的难点之一是厂商很少针对整个开发生命周期。相反他们集中于小的活动集例如设计或测试等并且由用户把选择的工具集成到一个完整的开发环境中。Wasserman指出了在任何工具集成中必须处理的下列5个问题Wasserman 1990。
(1) 平台集成工具在异构型网络中的互操作能力。
(2) 表示集成用户界面的共性。
(3) 过程集成工具和开发过程之间的链接。
(4) 数据集成工具共享数据的方式。
(5) 控制集成一个工具通知和启动另一个工具中的动作的能力。 如果觉得对你有帮助麻烦点个赞啦~~~·
