本文主要是介绍十、软件工程基础知识(考点篇),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
1 软件工程
软件开发生命周期:
软件系统的文档
软件工程过程
- (1)P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
- (2)D(Do)——软件开发。开发出满足规格说明的软件。
- (3)C(Check)——软件确认。确认开发的软件能够满足用户的需求。
- (4)A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
定义:软件工程过程是把输入转化为输出的一组彼此相关的资源和活动。
定义支持了软件工程过程的两个方面内涵。
第一,软件工程过程是指为获得软件产品,在软件工具支持下由软件工程师完成的一些列软件工程活动。基于这个方面,软件工程过程通常包含4种基本活动:
1. plan——软件规格说明。规定软件的功能及其运行时的限制。
2. do——软件开发。产生满足规格说明的软件。
3. check——软件确认。确认软件能够满足客户提出的要求。
4. action——软件演进。为满足客户的变更要求,软件必须在使用的过程中演进。
事实上,软件工程过程是一个软件开发机构针对某类软件产品为自己规定的工作步骤,它应当是科学的、合理的,否则必将影响软件产品的质量。
第二,从软件开发的观点看,它就是使用适当的资源(包括人员、硬软件工具、时间等),为开发软件进行的一组开发活动,在过程结束时将输入(用户要求)转化为输出(软件产品)。
所以,<软件工程的过程>是将软件工程的方法②和工具③综合起来,以达到合理、及时地进行计算机软件开发的目的。软件工程过程应确定方法使用的顺序、要求交付的文档资料、为保证质量和适应变化所需要的管理、软件开发各个阶段完成的任务。①软件工程包括三个要素:方法、工具和过程。
②软件工程过程中(主要是开发)用到的方法,如结构化方法、面向对象、形式化方法等等
③软件开发过程中的工具,后面有介绍。
④过程主要就是PDCA
软件系统工具
①配置项的管理,这属于管理方面的居多
软件设计
1.1 软件过程模型
参考:第五章 软件工程基础知识-CSDN博客
瀑布模型(SDLC)
原型
螺旋模型
增量模型
喷泉模型
基于构件的开发模型 CBSD
形式化方法模型
敏捷模型
- (1)是“适应性”而非“预设性”。
- (2)是“面向人的”而非“面向过程的”。
这两点特征是与计划驱动或重型开发方法的主要区别。
- (1)敏捷方法是适应型,而非可预测型。拥抱变化,适应变化。
- (2)敏捷方法是以人为本,而非以过程为本。发挥人的特性。
- (3)迭代增量式的开发过程。以原型开发思想为基础,采用法代增量式开发,发行版本小型化。
- (1)极限编程(XP)。基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从4个方面入手进行改善:加强交流:从简单做起:寻求反馈;勇于实事求是。XP 是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。XP提倡测试先行,为了将以后出现bug的几率降到最低。-- 以人为本,近螺旋,测试先行(bug率低下),从交流、朴素(简单)、反馈、勇气四方面入手,
- (2)水晶系列方法。与XP方法一样,都有以人为中心的理念,但在实践上有所不同。其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式、工作产品和实践。-- 以人为本,机动性
- (3)并列争球法(Scrum)。是一种迭代的增量化过程,把每段时间(如 30天)一次的迭代称为一个“冲刺”(Sprint),并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。-- 迭代增量,冲刺,优先级实现
- (4)特性驱动开发方法(FDD)。是一个迭代的开发模型。认为有效的软件开发需要3 个要素:人、过程和技术。有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中,<计划特征开发>根据构造出的<特征列表>、特征间的依赖关系进行计划,设计出包含<特征设计和特征构建>过程组成的多次选代。-- 迭代,3要素,5过程
统一过程模型(RUP)
这9个核心工作流如下。
- 业务建模:理解待开发系统所在的机构及其商业运作,确保所有参与人员对待开发系统所在的机构有共同的认识,评估待开发系统对所在机构的影响。
- 需求:定义系统功能及用户界面,使客户知道系统的功能,使开发人员理解系统的需求,为项目预算及计划提供基础。
- 分析与设计:把需求分析的结果转化为分析与设计模型。
- 实现:把设计模型转换为实现结果,对开发的代码做单元测试,将不同实现人员开发的模块集成为可执行系统。
- 测试:检查各子系统之间的交互、集成,验证所有需求是否均被正确实现,对发现的软件质量上的缺陷进行归档,对软件质量提出改进建议。
- 部署:打包、分发、安装软件,升级旧系统;培训用户及销售人员,并提供技术支持。
- 配置与变更管理:跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
- 项目管理:为软件开发项目提供计划、人员分配、执行、监控等方面的指导,为风险管理提供框架。
- 环境:为软件开发机构提供软件开发环境,即提供过程管理和工具的支持。
总结:
业务建模:理解机构及商业运作,让所有人达成共识,评估上系统的影响。
需求:跟以前学的类似。
分析与设计:需求转分析与设计模型
实现:设计模型转结果,单侧,集成等
测试:集测并改进。
部署:部署、培训
配置与变更管理:跟踪并维护制品的完整性和一致性,比如各种配置项,文档等等
项目管理:项目管理方面的
环境:提供开发环境以及过程管理和工具支持等
RUP 把软件开发生命周期划分为多个循环(每个循环是前的9个核心工作流),每个循环生成产品的一个新的版本,每个循环依次
由4 个连续的阶段组成,每个阶段完成确定的任务。这4个阶段如下。---初始-->细化-->构造-->移交
- ·初始阶段:定义最终产品视图和业务模型,并确定系统范围。
- ·细化阶段:设计及确定系统的体系结构,制订工作计划及资源要求。
- ·构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交。
- ·移交阶段:把产品提交给用户使用。
RUP 中定义了如下一些核心概念,理解这些概念对于理解 RUP 很有帮助。
- ·角色:Who 的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色,如体系结构师、设计人员、实现人员、测试员和配置管理人员等,并对每一个角色的工作和职责都做了详尽的说明。
- ·活动:How 的问题。活动是一个有明确目的的独立工作单元。
- ·制品:What 的问题。制品是活动生成、创建或修改的一段信息。
- ·工作流:When 的问题。工作流描述了一个有意义的连续的活动序列,每个工作流产生一些有价值的产品,并显示了角色之间的关系。
RUP的特点:3点
- (1)用例驱动:需求分析、设计、实现和测试等活动都是用例驱动的。
- (2)以体系结构为中心:包括系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。软件的体系结构是一个多维的结构,会采用多个视图来描述。
在典型的4+1视图模型中
- 分析人员和测试人员关心的是系统的行为,会侧重于用例视图;
- 最终用户关心的是系统的功能,会侧重于逻辑视图;
- 程序员关心的是系统的配置、装配等问题,会侧重于实现视图;
- 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题,会侧重于进程视图;
- 系统工程师关心的是系统的发布、安装、拓扑结构等问题,会侧重于部署视图。
总结:分析、测试------->系统行为----------------------->用例视图用户---------------->功能----------------------------->逻辑视图程序员------------->系统配置、装配-------------->实现视图集成---------------->性能、伸缩性、吞吐率----->进程视图系统工程师------->发布、安装、拓扑----------->部署视图
- (3)迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中,只考虑系统的一部分需求,进行分析、设计、实现、测试和部署等过程;每次迭代是在己完成部分的基础上进行的,每次增加一些新的功能实现,以此进行下去,直至最后项目的完成。
1.2 能力成熟度模型
总结:初始:成功全靠个人英雄级别;可重复(已管理):有了基本的过程管理和项目进度及费用的跟踪,能重复类似的;已定义:在管理和工程2方面的过程已经文档化标准化,成为某个组织行业的标准了已管理级(定量管理):从定性到定量了,对过程有了详细的度量标准。优化级:持续优化更新。
1.3 逆向工程
- 实现级:包括程序的抽象语法树、符号表、过程的设计表示。
- 结构级:包括反映程序分量之间相互依赖关系的信息,例如调用图、结构图、程序和数据结构。
- 功能级:包括反映程序段功能及程序段之间关系的信息,例如数据和控制流模型。
- 领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息,例如 E-R模型。
2 需求工程
2.1 软件需求
分为需求开发和需求管理两大过程,如下所示:图很重要
需求的层次
- 业务需求:反映企业或客户对系统高层次的目标要求,通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
- 用户需求:描述的是用户的具体目标,或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求。
- 系统需求:从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束等。
- 功能需求:也称为行为需求,规定了开发人员必须在系统中实现的软件功能,用户利用这些功能来完成任务,满足业务需要。
- 非功能需求:指系统必须具备的属性或品质,又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
- 设计约束:也称为限制条件或补充规约,通常是对系统的一些约束说明,例如必须采用国有自主知识产权的数据库系统,必须运行在 UNIX操作系统之下等。
2.2 需求获取
常见的需求获取法包括:
- (1)用户访谈:1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。
- (2)问卷调查:用户多,无法一一访谈。
- (3)采样:从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)2
- (4)情节串联板:一系列图片,通过这些图片来讲故事。
- (5)联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。
- (6)需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。
总结:用户访谈要求比较高,自己得懂才行,而且记录比较困难(因为聊嘛);问卷调查要求也比较高,因为设计问卷也得懂的多,联合需求计划JRP是拉一批人开会,
2.3 需求分析
需求分析的任务
总结:分析过程:1. 绘制系统上下文范围关系图:定义系统与外部实体间的界限和接口,确定需求范围。
2. 创建用户界面原型:帮助用户理解系统。
3. 分析需求的可行性:经济、技术、法律、用户使用。
4. 确定需求的优先级:制订系统研发的迭代计划。
5. 为需求建立模型:帮助系统分析师理解系统,为软件设计提供系统的逻辑视图。
6. 创建数据字典:对系统中所有的数据项进行详细说明和定义。
7. 使用QFD将产品的特性、属性和对用户的重要性联系起来。
分析结果---下面的
1. 功能模型:数据流图DFD,描述系统的功能组成。
2. 行为模型:状态转换图STD,描述系统的状态和引起状态转换的事件。
3. 数据模型:实体联系图E-R,描述系统中各个实体之间的关系。
4. 数据字典:确保数据在系统中的完整性和一致性。
结构化的需求分析
三大模型:功能模型(数据流图DFD)、行为模型(状态转换图STD)、数据模型(E-R图)以及数据字典。
数据流图DFD
- 从一个加工流向另一个加工;从加工流向数据存储(写);
- 从数据存储流向加工(读);从外部实体流向加工(输入);
- 从加工流向外部实体(输出)。
数据字典 DD
2.4 需求定义
软件需求规格说明书 SRS
需求定义方法
2.5 需求验证
2.6 需求管理
定义需求基线
需求的流程及状态如下图所示:
需求变更和风险
需求跟踪:
总结:正向跟踪:是否都实现了;反向跟踪:是否多实现了;需求跟踪矩阵:行是需求-列是用例。
3 系统设计
先进行系统的流程设计,然后进行系统设计,最后界面设计。
3.1处理流程设计
◆流程表示工具
◆业务流程重组 BPR
总结:基本原则:流程为中心,团队管理(以人为本)、客户导向。----重要设计规划:战略->流程->数据->功能->系统实现步骤:启动->计划->建团队->分析流程->重新设计流程->实施->持续改进->重新开始
◆业务流程管理 BPM
3.2 系统设计
总结:系统设计的目的是为系统制定蓝图,勾画出详细设计方法,需要采用一系列方法,比如结构化的,面向对象的等方法来实现;其实内容主要就是概设和详设。
系统设计基本原理
- 抽象化;
- 自顶而下,逐步求精;
- 信息隐蔽;
- 模块独立(高内聚,低耦合)。
- 系统设计原则
- 保持模块的大小适中;
- 尽可能减少调用的深度;
- 多扇入,少扇出;-- 多让别人调用,少调用别人,功能尽量通用
- 单入口,单出口;
- 模块的作用域应该在模块之内;
- 功能应该是可预测的。
内聚程度从低到高如下表所示:
总结:偶然内聚:偶然性的;逻辑内聚:这就是逻辑功能相似, 根据参数决定执行哪个;时间内聚:把这些模块组合在一起 同时执行;过程内聚:一个模块能完成多个任务,但是必须按照 指定顺序执行, 是一个过程;通信内聚:在 同一个数据结构上操作, 输入输出相同;顺序内聚:类似管道过滤器; 顺序执行,输入为输出;功能内聚:这个是一个有机整体,共同作用缺一不可。
耦合程度从低到高如下所示:
总结:无直接:相当于偶然;数据:类似值传递;标记:传递数据结构了,比如list控制:类似逻辑内聚, 根据传递的控制变量来执行哪一功能。外部:模块 通过软件之外的环境联合。公共:通过 公共数据结构/环境相互作用内容:模块内部联系,通过非正常入口转入另一模块内
系统结构图(SC)
详细设计的表示工具
详细设计的表示图形工具
程序流程图
NS 流程图
PAD 图
3.3 人机界面设计
- 置于用户的控制之下以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式;
- 提供灵活的交互;
- 允许用户交互可以被中断和取消;
- 当技能级别增加时可以使交互流水化并允许定制交互;
- 使用户隔离内部技术细节;
- 设计应允许用户和出现在屏幕上的对象直接交互。
- 减少用户的记忆负担减少对短期记忆的要求;
- 建立有意义的缺省;
- 定义直觉性的捷径;
- 界面的视觉布局应该基于真实世界的隐喻;
- 以不断进展的方式揭示信息。
- 保持界面的一致性允许用户将当前任务放入有意义的语境在应用系列内保持一致性如过去的交互模型已建立起了用户期望,除非有迫不得已的理由,不要去改变它。
4 测试基础知识
4.1 测试基础
测试原则
- 应尽早并不断的进行测试;-- 尽早不断测试
- 测试工作应该避免由元开发软件的人或小组承担;--避嫌
- 在设计测试方案时,不仅要确定输入数据,而且要根据系统功能确定预期的输出结果;-- 根据功能输出确定
- 既包含有效、合理的测试用例,也包含不合理、失效的用例;-- 用例广,有效无效的都要有
- 检验程序是否做了该做的事,且是否做了不该做的事;-- 做了该做的,不做不该做的
- 严格按照测试计划进行;-- 有测试计划的,按照计划执行
- 妥善保存测试计划和测试用例;-- 妥善保管测试计划和用例
- 测试用例可以重复使用或追加测试。-- 测试用例可重复用并追加
测试类型分为两大类:
- 黑盒测试法:功能性测试,不了解软件代码结构,根据功能设计用例,测试软件功能。
- 白盒测试法:结构性测试,明确代码流程,根据代码逻辑设计用例,进行用例覆盖。
- 灰盒测试法:即既有黑盒,也有白盒。
- 桌前检查:程序员检查自己编写的程序,在程序编译后,单元测试前。-- 单测前自查
- 代码审查:由若干个程序员和测试人员组成评审小组,通过召开程序评审会来进行审查。-- 别的程序员和测试员会议评审
- 代码走查:也是采用开会来对代码进行审查,但并非简单的检查代码,而是由测试人员提供测试用例,让程序员扮演计算机的角色,手动运行测试用例,检查代码逻辑。-- 也是开会不过,测试员给用例,程序员充当电脑,测试
4.2 测试阶段
- 内部确认测试:主要由软件开发组织内部按照 SRS进行测试。
- Alpha测试:用户在开发环境下进行测试。
- Beta 测试:用户在实际使用环境下进行测试,通过改测试后,产品才能交付用户。
- 验收测试:针对 SRS,在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是,在真实的用户工作环境下,检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外,在进行验收测试之前,应确认被测软件系统已通过系统测试。
总结:单侧-->集测-->系测-->确认(内测-->Alpha-->beta-->验收),补充的配置项的测试、变更修改的回归测试,以及针对app和web的AB测试,针对web的web测试、链接测试、表单测试。
4.3测试用例设计
- 等价类划分:把所有的数据按照某种特性进行归类,而后在每类的数据里选取一个即可。等价类测试用例的设计原则:设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。-- 用例分类,每类中选一个即可,新用例设计原则:1).尽可能多的覆盖情况2).只覆盖一种情况
- 边界值划分:将每类的边界值作为测试用例,边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值,如年龄范围为0-150,边界值为0,150,-1,151四个。-- 边界值
- 错误推测:没有固定的方法,凭经验而言,来推测有可能产生问题的地方,作为测试用例进行测试。--经验推测
- 因果图:由一个结果来反推原因的方法,具体结果具体分析,没有固定方法。-- 结果反推
- (1)语句覆盖 SC:逻辑代码中的所有语句都要被执行一遍,覆盖层级最低,因为执行了所有的语句,不代表执行了所有的条件判断。-- 代码语句都执行一遍,但是有可能条件执行不充分
- (2)判定覆盖 DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。-- 判断语句真假执行一遍,但是联合条件的每个条件没执行
- (3)条件覆盖CC:针对每一个判断条件内的每一个独立条件都要执行一遍真和假。-- 这里是补充的判定覆盖的,不管是否联合条件,每个单独的判断真假执行一遍
- (4)条件判定组合覆盖CDC:同时满足判定覆盖和条件覆盖。-- 把判定覆盖和条件覆盖组合
- (5)路径覆盖:逻辑代码中的所有可行路径都覆盖了,覆盖层级最高。-- 所有可行的路径都走
4.4 调试
调试的方法
- 蛮力法:又称为穷举法或枚举法,穷举出所有可能的方法一一尝试。
- 回溯法:又称为试探法,按选优条件向前搜索,以达到目标,当发现原先选择并不优或达不到目标,就退回一步重新选择,这种走不通就退回再走的技术为回溯法。
- 演绎法:是由一般到特殊的推理方法,与“归纳法”相反,从一般性的前提出发。得出具体陈述或个别结论的过程。
- 归纳法:是由特殊到一般的推理方法,从测试所暴露的问题出发,收集所有正确或不正确的数据,分析它们之间的关系,提出假想的错误原因,用这些数据来证明或反驳,从而查出错误所在。
软件度量
试题理解:先找开始和结束,然后找从开始到结束有几条路径。顶点数,包换开始和结束边数13 - 11 + 2 = 4,所以环路复杂度是4。
5 系统运行与维护
5.1 系统转换
- (1)系统虽然完成企业中许多重要的业务管理工作,但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能,很少涉及经营决策。
- (2)系统在性能上已经落后,采用的技术已经过时。例如,多采用主机/终端形式或小型机系统,软件使用汇编语言或第三代程序设计语言的早期版本开发,使用文件系统而不是数据库。
- (3)通常是大型的软件系统,已经融入企业的业务运作和决策管理机制之中,维护工作十分困难。
- (4)没有使用现代信息系统建设方法进行管理和开发,现在基本上已经没有文档,很难理解。
从技术水平和业务价值,两方面入手:两头的:高水平高价值的,改造一下;低水平低价值的扔了;中间的:高水平低价值集成;低水平高价值的继承。
系统转换是指新系统开发完毕,投入运行,取代现有系统的过程,需要考虑多方面的问题,以实现与老系统的交接,有以下三种转换计划:
- 直接转换:现有系统被新系统直接取代了,风险很大,适用于新系统不复杂,或者现有系统已经不能使用的情况。优点是节省成本。
- 并行转换:新系统和老系统并行工作一段时间,新系统经过试运行后再取代,若新系统在试运行过程中有问题,也不影响现有系统的运行,风险极小,在试运行过程中还可以比较新老系统的性能,适用于大型系统。缺点是耗费人力和时间资源,难以控制两个系统间的数据转换。
- 分段转换:分期分批逐步转换,是直接和并行转换的集合,将大型系统分为多个子系统,依次试运行每个子系统,成熟一个子系统,就转换一个子系统。同样适用于大型项目,只是更耗时,而且现有系统和新系统间混合使用,需要协调好接口等问题。
5.2 系统维护概述
- (1)易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
- (2)易改变性。软件产品使指定的修改可以被实现的能力,实现包括编码、设计和文档的更改。
- (3)稳定性。软件产品避免由于软件修改而造成意外结果的能力。
- (4)易测试性。软件产品使已修改软件能被确认的能力。
- (5)维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力。
总结:好不好分析、好不好改、改后稳定不、好不好测试、遵循相关标准不
系统维护包括硬件维护、软件维护和数据维护,其中软件维护类型如下:
- 正确性维护:发现了 bug 而进行的修改。
- 适应性维护:由于外部环境发生了改变,被动进行的对软件的修改和升级。
- 完善性维护:基于用户主动对软件提出更多的需求,修改软件,增加更多的功能,使其比之前的软件功能、性能更高,更加完善。
- 预防性维护:对未来可能发生的 bug进行预防性的修改。
总结:正确性是bug修改,适应性是环境变了适应,完善性是用户提变更,预防性是未来可能的bug。
6 净室软件工程
净室软件工程应用技术手段:
- 统计过程控制下的增量式开发。
- 基于函数的规范与设计。
- 正确性验证。CSE 的核心
- 统计测试和软件认证。
净室软件工程在使用过程的一些缺点:
7 基于构件的软件工程CBSE
总结:就是搞一个构件库,有的开发有的购买,然后用这些构件来组装系统。
用于CBSE 的构件应该具备以下特征。
- (1)可组装性:对于可组装的构件,所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
- (2)可部署性:软件必须是自包含的,必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式,无须在部署前编译。
- (3)文档化:构件必须是完全文档化的,用户根据文档来判断构件是否满足需求。
- (4)独立性:构件应该是独立的,应该可以在无其他特殊构件的情况下进行组装和部署,如确实需要其他构件提供服务,则应显示声明。
- (5)标准化:构件标准化意味着在CBSE 过程中使用的构件必须符合某种标准化的构件模型。
构件模型定义了构件实现、文档化以及开发的标准,其包含的模型要素为:
构件模型提供了一组被构件使用的通用服务,这种服务包括以下两种。
- ·平台服务,允许构件在分布式环境下通信和互操作。
- ·支持服务,这是很多构件需要的共性服务。例如,构件都需要的身份认证服务。
CBSE 过程
过程中的6个主要活动:
- 系统需求概览 -- 看看用户的需求是啥
- 识别候选构件 -- 根据需求来找适应的差不多的构件
- 根据发现的构件修改需求 -- 根据找到的构件匹配一下,有些不完全匹配的适当的修改需求(当然得达到用户的目的)
- 体系结构设计 -- 还是离不开架构设计,不过这个时候要考虑构件库的因素
- 构件定制与适配 -- 能有的构件就用,没有的或不匹配的就开发或者修改构件
- 组装构件创建系统。-- 组装系统
CBSE 过程与传统软件开发过程不同点:
- (1)CBSE 早期需要完整的需求,以便尽可能多地识别出可复用的构件。
- (2)在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求,就应该考虑由复用构件支持的相关需求。
- (3)在系统体系结构设计完成后,会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件,或者修改构件以适合功能和架构的要求。
- (4)开发就是将己经找到的构件集成在一起的组装过程。
构件组装
构件组装的三种不兼容问题(通过编写适配器解决):
这篇关于十、软件工程基础知识(考点篇)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!