精华内容
下载资源
问答
  • 软件工程名词解释

    2013-12-06 22:06:57
    软件工程的考试名词解释
  • 软件工程名词解释汇总

    千次阅读 2020-10-29 20:29:06
     软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件,即把工程化应用到软件上。 软件生存周期  软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用,直至最终退役为止...

    软件
      软件是计算机系统中与硬件相互依存的部分,它是包括程序、数据及相关文档的完整集合。

    软件危机
      软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

    软件工程
      软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件,即把工程化应用到软件上。

    软件生存周期
      软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用,直至最终退役为止的整个过程,一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。

    软件复用
      软件复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。

    质量
      质量是产品或服务满足明确或隐含需求能力的特性和特征的集合。在合同环境下,需求是明确的;在其他环境下,隐含的需求需要识别和定义。

    质量策划
      质量策划包括产品策划、管理和作业策划,以及质量计划的编制和质量改进的准备工作。

    质量改进
      质量改进是以最求最高的效益和效率为目标的持续性活动。

    质量控制
      质量控制是对流程和产品的符合性的评估,独立分析不足并予以更正使得产品与需求相符。

    质量保证
      质量保证是有计划的和系统性的活动,它对部件或产品满足确定的技术需求提供足够的信心。

    软件质量
      软件质量是指明确声明的功能和性能需求、明确文档化的开发标准、以及专业人员开发的软件所具有的所有隐含特征都得到满足。

    正式技术复审
      正式技术复审是一种由软件开发人员进行的软件质量保证活动,其目的是在软件的任何一种表示形式中发现功能、逻辑或实现的错误,验证经过复审的软件确实满足需求,保证软件符合预定义的标准,使软件按照一致的方式开发,使项目更易于管理。

    质量认证
      质量认证是由可以充分信任的第三方证实某一经鉴定的产品或服务符合特定标准或规范性文件的活动。

    软件过程
      软件过程是人们用于开发和维护软件及其相关过程的一系列活动,包括软件工程活动和软件管理活动。

    软件过程能力
      软件过程能力是描述(开发组织或项目组)遵循其软件过程能够实现预期结果的程度,它既可对整个软件开发组织而言,也可对一个软件项目而言。

    软件过程性能
      软件过程性能表示(开发组织或项目组)遵循其软件过程所得到的实际结果,软件过程性能描述的是已得到的实际结果,而软件过程能力则描述的是最可能的预期结果,它既可对整个软件开发组织而言,也可对一个特定项目而言。

    软件过程成熟度
      软件过程成熟度是指一个特定软件过程被明确和有效地定义,管理测量和控制的程度。

    软件成熟度等级
      软件成熟度等级是指软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。

    关键过程域
      每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域,它们的实施对达到该成熟度等级的目标起到保证作用,这些过程域就称为该成熟度等级的关键过程域。

    关键实践
      关键实践是指对关键过程域的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。

    软件能力成熟度模型
      软件能力成熟度模型是指随着软件组织定义、实施、测量、控制和改进其软件过程,软件组织的能力也伴随着这些阶段逐步前进,完成对软件组织进化阶段的描述模型。

    软件需求
      软件需求是指
      (1)用户解决问题或达到目标所需的条件或能力;
      (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力;
      (3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。

    业务需求
      业务需求(business requirement)反映了组织机构或客户对系统或产品高层次的目标要求,它们在项目视图与范围文档中予以说明。

    用户需求
      用户需求(user requirement)描述了用户使用产品必须要完成的任务,可以在用例模型或方案脚本中予以说明。

    功能需求
      功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。

    非功能需求
      非功能需求(non-functional requirement)是从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求。

    需求工程
      需求工程是应用已证实有效的原理和方法,通过合适的工具和符号,系统地描述出待开发系统及其行为特征和相关约束。

    需求分析
      需求分析主要是对收集到的需求进行提炼、分析和仔细审查,以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方,形成完整的分析模型。

    软件需求规格说明
      软件需求规格说明是需求开发的最终结果,它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。

    风险承担人
      风险承担人是任何将从新系统或应用的实现中受到实质性影响的人。

    软件原型
      软件原型是所提出的新产品的部分实现,其目的是为了解决在产品开发的早期阶段需求不确定的问题。

    实体关系图
      实体关系图描述数据对象及其关系。

    数据流图
      数据流图是结构化分析的基本工具,它描述了信息流和数据转换。

    状态转换图
      状态转换图通过描述状态以及导致系统改变状态的事件来表示系统的行为。

    数据字典
      数据字典描述数据流图的数据存储、数据加工(最底层加工)和数据流。

    对象
      对象(Object)是系统中用来描述客观事物的一个实体,它是构成系统的一个基本单位,由一组属性和对这组属性进行操作的一组服务组成。


      类(Class)是具有相同属性和服务的一组对象的集合,它为属于该类的全部对象提供了统一的抽象描述,其内部包括属性和服务两个主要部分。

    封装
      封装(Encapsulation)是把对象的属性和服务结合成一个独立的系统单位,并尽可能隐藏对象的内部细节。

    继承
      继承(Inheritance)是指子类可以自动拥有父类的全部属性和服务。

    消息
      消息(Message)是对象发出的服务请求,一般包含提供服务的对象标识、服务标识、输入信息和应答信息等信息。

    多态性
      多态性(Polymorphism)是指在父类中定义的属性或服务被子类继承后,可以具有不同的数据类型或表现出不同的行为。

    主动对象
      主动对象(Active Object)是一组属性和一组服务的封装体,其中至少有一个服务不需要接收消息就能主动执行(称为主动服务)。

    面向对象分析
      面向对象的分析(OOA)就是运用面向对象的方法进行需求分析,其主要任务是分析和理解问题域,找出描述问题域和系统责任所需的类及对象,分析它们的内部构成和外部关系,建立OOA模型。

    面向对象设计
      面向对象的设计(OOD)就是根据已建立的分析模型,运用面向对象技术进行系统软件设计。它将OOA模型直接变成OOD模型,并且补充与一些实现有关的部分,如人机界面、数据存储、任务管理等。

    面向对象编程
      面向对象的编程(OOP)就是用一种面向对象的编程语言将OOD模型中的各个成分编写成程序。

    面向对象测试
      面向对象的测试(OOT)是指对于运用OO技术开发的软件,在测试过程中继续运用OO技术进行以对象概念为中心的软件测试。

    统一建模语言UML
      统一建模语言(Unified Modeling Language,UML)是一种直观化、明确化、构建和文档化软件系统产物的通用可视化建模语言。

    用例图
      用例图定义了系统的功能需求,它完全是从系统的外部观看系统功能,并不描述系统内部对功能的具体实现。

    类图
      类图描述系统的静态结构,表示系统中的类以及类与类之间的关系。

    对象图
      对象图描述了一组对象以及它们之间的关系,表示类的对象实例。

    状态图
      状态图表示一个状态机,强调对象行为的事件顺序。

    时序图
      时序图表示一组对象之间的动态协作关系,反映对象之间发送消息的时间顺序。

    协作图
      协作图表示一组对象之间的动态协作关系,反映收发消息的对象的结构组织。

    活动图
      活动图反映系统中从一个活动到另一个活动的流程,强调对象间的控制流程。

    组件图
      组件图描述组件以及它们之间的关系,表示系统的静态实现视图。

    分布图
      分布图反映了系统中软件和硬件的物理架构,表示系统运行时的处理节点以及节点中组件的配置。

    软件体系结构
      软件体系结构包括一组软件部件、软件部件的外部的可见特性及其相互关系,其中软件外部的可见特性是指软件部件提供的服务、性能、特性、错误处理、共享资源使用等。

    软件测试
      软件测试是以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。

    静态测试
      静态测试是指被测试程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。

    动态测试
      动态测试是指通过运行程序发现错误,一般意义上的测试主要是指动态测试。

    黑盒测试
      黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有功能的情况下,通过测试来检测每个功能是否都能正常使用。

    白盒测试
      白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。

    软件调试
      软件调试则是在软件测试成功后,根据错误迹象确定错误的原因和准确位置,并加以改正。

    软件测试自动化
      测试自动化是通过开发和使用一些工具自动测试软件系统,特别适合于测试中重复而繁琐的活动。

    软件维护
      软件维护是指在软件运行或维护阶段对软件产品所进行的修改。

    改正性维护
      在软件交付使用后,由于开发时测试得不彻底或不完全,在运行阶段会暴露一些开发时未能测试出来的错误。为了识别和纠正软件错误,改正软件性能上的缺陷,避免实施中的错误使用,应当进行的诊断和改正错误的过程,这就是改正性维护。

    适应性维护
      随着计算机技术的飞速发展和更新换代,软件系统所需的外部环境或数据环境可能会更新和升级,如操作系统或数据库系统的更换等。为了使软件系统适应这种变化,需要对软件进行相应的修改,这种维护活动称为适应性维护。

    完善性维护
      在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。

    预防性维护
      预防性维护是指采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新进行设计、编制和测试,提高软件的可维护性和可靠性等,为以后进一步改进软件打下良好基础。

    软件的可维护性
      软件的可维护性是指软件能够被理解、纠正、适应和完善以适应新环境的难易程度。

    可理解性
      指理解软件的结构,接口,功能和内部过程的难易程度。

    可测试性
      指测试和诊断软件(主要指程序)中错误的难易程度。

    可修改性
      指修改软件(主要指程序)的难易程度。

    可移植性
      指程序转移到一个新的计算环境的难易程度。

    可用性
      一般来讲,系统的可用性是指系统在任何时间都能运行并能够提供有用服务的可能性。(更精确的定义:系统在一特定时间特定环境中为一专门目的而做的无失败操作的可能性。)

    可靠性
      一般来讲,系统的可靠性是系统在给定的时间段内能正确提供用户希望的服务的可能性。(更精确的定义:系统在一个时刻是可操作的和能执行请求服务的可能性。)

    失效率
      单位时间内失效的原件数与原件总数的比例。通常用λ表示。

    平均无故障时间(MTBF)
      两次故障间系统能够正常工作的平均时间。

    平均修复时间(MTRF)
      从故障发生到机器修复所需的平均时间。用于表示计算机的可维修性。

    安全性
     一般来讲,系统的安全性是判断系统将会对人和系统的环境造成伤害的可能性。

    信息安全性保密性
      一般来讲,系统的信息安全性是判断系统能抵抗意外或蓄意的入侵的可能性。

    项目
      项目就是以一套独特而相互联系的任务为前提,有效地利用资源,为实现一个特定的目标所做的努力。

    项目管理
      项目管理就是通过合理地组织和利用一切可以利用的资源,按照计划的成本和计划的进度,完成一个计划的目标,它包含团队管理、风险管理、采购管理、流程管理、时间管理、成本管理和质量管理等。

    来源
    https://blog.csdn.net/qq_36721220/article/details/102936951?utm_medium=distribute.wap_relevant.none-task-blog-title-2

    展开全文
  • 软件工程名词解释.doc

    2021-10-03 15:36:09
    软件工程名词解释.doc
  • 软件工程名词解释.pdf

    2021-10-01 11:05:43
    软件工程名词解释.pdf
  • 软件工程名词解释知识.pdf
  • 软件工程名词解释).doc
  • 软件工程名词解释高频题一览

    千次阅读 2017-12-26 22:16:31
    软件工程 第四版 的名词解释高频题目 暂无答案(都在书上) 供复习软件工程使用

    说明前面加*表示只是理论上会考,有时一个名词会多次出现,有些英文不一样(如过程),则是两个概念。如果英文也一样,看书上定义,如果定义差不多(例如原型和抽象)答哪个都行,如果定义不一样则看情况或者都答
    适用于《软件工程 第4版》人民邮电出版社

    第一章:
    软件工程(SE)
    分析(analysis)
    合成(synthesis)
    工具(tool)
    过程(procedure)
    泛型(paradigm)
    错误(error)
    故障(fault)
    失效(failure)
    *客户(custom)
    *开发者(developer)
    *用户(user)
    系统(system)
    活动(activity)
    *实体(entity)
    *关系(relationship)
    系统边界(system boundary)
    抽象(abstraction)
    原型(prototype)
    复用、重用(reuse)

    第二章
    过程(process)
    阶段化开发(Phased development)
    循环周期(cycle time)
    运行系统(operation system)
    开发系统(development system)
    增量开发(incremental development)
    迭代开发(iterative development)
    极限编程(XP)
    水晶法(crystal)
    并列争球法(scrum)
    统一过程(UP/RUP)

    第三章
    项目进度(project schedule)
    可交付产品(deliverable)
    活动(activity)
    里程碑(milestone)
    风险(risk)
    风险影响(risk impact)
    风险概率(risk probability)
    风险暴露(risk exposure)

    第四章
    需求(requirement)
    软件规格说明(SRS,software requirement specification)
    功能性需求(functional requirement)
    非功能性需求(nonfunctional requirement)
    设计约束(design constraint)
    过程约束(process constraint)
    需求定义(requirement definition)
    需求规格说明(requirement specification)(实际上跟SRS一样)
    用例(use case)百度百科:对一组动作序列的抽象描述,系统执行这些动作序列,产生相应的结果。

    第五章
    设计(design)
    体系结构(architecture)
    体系结构风格(architecture style)
    例程设计(routine design)
    克隆(clone)
    参考模型(reference model)
    设计公约(design convention)
    设计模式(design pattern)
    设计原则(design principle)
    *创新设计(innovation design)

    第六章
    *重构(refactoring)
    设计原则(design principle)区别于系统设计中设计原则
    模块化(Modular)
    模块(Module)

    耦合(coupled)
    非耦合(uncoupled)
    数据耦合(data coupling)
    标记耦合/特征耦合(stamp coupling)
    控制耦合(control coupling)
    公共耦合(common coupling)
    内容耦合(content coupling)

    内聚(cohesion)
    偶然内聚(coincidental cohesion)
    逻辑内聚(logical cohesion)
    时间内聚/时态内聚(temporal cohesion)
    过程内聚(procedural cohesion)
    通信内聚(communicational cohesion)
    顺序内聚(squential cohesion)
    功能内聚(functional cohesion)
    信息内聚(information cohesion)

    接口(interface)
    面向对象一系列名词

    第七章
    结对编程/派对编程(pair programming)

    第八章
    故障(fault)
    失效(failure)和第一章一样但是定义更准确
    算法故障(algorithm fault)
    计算故障(computation fault)/精度故障(precision fault)
    文档故障(documentation fault)
    压力故障(stress fault)/过载故障(overload fault)
    能力故障(capacity fault)/边界故障(boundary fault)
    计时故障(timing fault)
    吞吐量故障(throughput fault)/性能故障(performance fault)
    硬件和系统软件故障(hardware and system software fault)

    标准过程故障(standards and procedure fault)
    正交缺陷分类(orthogonal defect classification)

    模块测试(module testing)/构建测试(component testing)/单元测试(unit testing)
    集成测试(integration testing)

    *忘我编程(egoless programming)
    黑盒测试(black box test)/闭盒测试(close box test)
    白盒测试(white box test)/开盒测试(open box test)
    代码评审(code review)
    代码走查(code walkthrough)
    代码审查(code inspection)

    语句覆盖(Statement coverage)
    分支覆盖/判定覆盖(Branch coverage)
    条件覆盖(condition coverage)
    路径覆盖(path coverage)
    以上四条区分理解即可

    自底向上测试(bottom-up)
    自顶向下测试(top-bottom)
    驱动程序(component driver)
    桩(stub)

    第九章
    功能测试(function test)
    性能测试(performance test)
    验收测试(acceptance test)
    安装测试(installation test)
    系统配置(system configuration)
    配置管理(configuration management)
    版本(version)
    发布(release)
    基线(base line)稳定可用的一个版本(包括程序和文档),是后续开发的基础
    回归测试(regressive test)

    压力测试(stress test)
    容量测试(volume test)
    配置测试(configuration test)
    兼容性测试(compatible test)
    安全性测试(security test)
    *环境测试(environment test)
    *计时测试(timing test)
    质量测试(quality test)
    恢复测试(recovery test)
    *维护测试(maintenance test)
    *文档测试(documentation test)

    基准测试(benchmark test)
    试验性测试(pilot test)
    α测试(alpha test)
    β测试(beta test)
    并行测试(parallel test)

    展开全文
  • 软件工程名词解释题简答题汇总.doc
  • 软件工程名词解释题简答题归纳.doc
  • 软件工程名词解释题简答题汇总.docx
  • 软件危机:软件开发技术的进步未能那满足发展的需求,在软件开发过程中遇到的问题找不到解决的办法,问题积累起来了,形成尖锐的矛盾,导致软件危机。
  • 计算机应用技术独立本科段自考软件工程名词解释整理
  • 精品教育教学资料
  • 软件工程常见的名词解释

    千次阅读 2018-02-22 15:52:35
    软件工程:将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程及上述方法的研究。设计模式:是指以设计复用为目的,采用一种良好定义的、正规的、一致的方式记录的软件设计经验。交互图:描述对象...

    软件:是在计算机系统的支持下,能够完成特定功能和性能的程序、数据和相关文档。

    软件工程:将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程及上述方法的研究。

    设计模式:是指以设计复用为目的,采用一种良好定义的、正规的、一致的方式记录的软件设计经验。

    交互图:描述对象之间通过消息传递进行的交互与协作。

    软件生命周期:是软件的产生知道报废的生命周期,周期内有问题定义、可行性分析、总体描述、编码、调试和测试、验收与运行、维护升级到废弃等阶段。

    软件需求:是利益相关方对目标软件系统在功能、质量等方面的期望,以及对目标软件系统在运行环境、资源消耗等方面的要求或约束。

    测试用例:是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。

    驱动模块:是在进行单元测试是所设置的一种辅助测试模块,它用来模拟被测试模块的上一级模块,相当于被测试模块的主程序。

    软件测试:是通过人工或者自动化的检测方式,检测被测对象是否满足用户要求或弄清楚预期结果与实际结果之间的差异,是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。


    展开全文
  • 软件工程常见名词解释&概念题

    千次阅读 2019-04-19 19:48:20
    有关的教材是南大软院用的教材《软件工程与计算》,覆盖大部分软件工程的知识 可用于准备南大软院专业课842的复习,也可应对面试中有关软件工程的知识。 1. 什么是设计? 设计是一种建造之前的“规划”,包括工程...

    有关的教材是南大软院用的教材《软件工程与计算》,覆盖大部分软件工程的知识
    可用于准备南大软院专业课842的复习,也可应对面试中有关软件工程的知识。

    1. 什么是设计?
    设计是一种建造之前的“规划”,包括工程部分,也包含艺术部分。

    2. 软件设计
    1) 广义的软件设计
    程序代码时对真正软件的规划。编译器负责根据规划建造真正产品,为产生程序代码所进行的一切工作都是设计活动。
    好的设计保证质量
    2) 狭义的软件设计
    为使以软件系统满足规定的需求而定义系统或部件的体系结构,部件,接口和其他特征的过程

    3为什么要设计?
    软件开发的最大挑战就是软件的复杂性,所以控制系统复杂度是软件设计方法的核心问题。

    4软件产品设计
    软件产品设计是规定软件产品特性,功能和接口以满足用户需求和愿望的活动,需要用户界面,交互设计,沟通,工业设计,市场营销等技能。

    5软件工程设计
    软件工程设计是规定程序,子系统以及他们的组成部分和工作方式以满足软件产品规格的活动。需要编程,算法,数据结构,软件设计原则,实践,过程,架构和模式等技能。

    6.软件设计的层次性
    高层设计描述系统的高层结构,关注点和设计决策
    中层设计关注组成构件的模块的划分,过程之间的调用关系,类之间的协作
    低层设计关注具体的数据结构,算法,类型,语句等

    7.关注点分解:多视点方法
    常见设计视角
    设计视角 设计关注 样例设计语言
    上下文 系统服务和用户 Uml用例图
    组合 功能分解和运行时分解,子系统的构造,购买vs建造,构建的重用 Uml包图,构件图
    逻辑结构 静态结构,类型和实现的重用。最重要的层,子系统,包,框架,类,接口等的概念性组织 Uml类图,对象图
    依赖 互联,分享,参数化 包图,构件图
    交互 对象之间的消息通讯 顺序图,通信图
    动态状态 动态状态的转移 状态图

    8.软件设计的标准(外部要简洁,内部要坚固)
    效用:需求(功效是必须的,容易达到的)
    坚固:质量(可修改性等)(坚固是设计的重点任务,是合格设计必须的)
    美感包括1)简洁性,抽象,归纳,取出噪音(美感是卓越者的素质)
    2)结构清新:隐喻显而易见是正确的
    3)一致性:用相同的方法做相同的事情

    9.软件设计过程(软件设计没有严谨,精确地过程
    1)经验主义:在软件设计过程中添加一些灵活性以应对设计中人的因素,文档化,原型,尽早验证,迭代式开发
    2)理性主义:利用模型语言,建模语言,工具支持,将软件设计过程组织成系统,规律的模型建立过程,设计方法学的目标就是不断克服人的弱点,最终得到完美。

    10.软件设计的演化(迭代)性
    完美的理性设计不存在,真实的设计过程是演化和迭代的,不是一次完成的。反复迭代,直到最后兼顾了功效,坚固和美感。

    11.软件设计的决策性 (决策要一致!)
    决策:为解决一个问题而采取的决定
    软件设计是问题求解和决策的过程
    决策的影响因素:经验,类似的系统,参考模型,设计约定,设计原理,体系结构风格,设计模式

    12.区分逻辑设计和物理设计
    1)物理设计=逻辑设计+介质匹配
    2)先逻辑后物理的设计思路,否则,如果介质匹配的复杂度较高,可能会扰乱逻辑设计的思路。
    3)物理是逻辑在载体上的实现。物理设计复杂度=事物(逻辑)复杂度+载体与事物的适配复杂度
    4)物理实现的载体
    《1》低层:基本类型+基本控制结构
    《2》中层:oo编程语言机制
    类声明,实例创建与撤销,实例生命期管理
    类权限控制机制
    复杂机制,继承
    《3》高层:导入导出和名称匹配
    5)比较
    基于抽象的体系结构更好的表现系统结构的组织,抓住系统的基本功能和主要协作机制,利用部件和连接件之间的依赖关系将部分有机的联系起来形成整体。
    而实现模型更多的考虑实现细节。

    13.软件体系结构模型:部件+连接件+配置
    部件:在系统体系结构中封装处理和数据的元素称为软件部件,部件通常提供特定应用的服务,部件主要通过端口(port)元素定义自己的外部可见特征,即部件与外部发生联系的窗口
    连接件:定义了部件间的交互。在复杂系统中,交互可能比独立部件的功能更重要且更有挑战性,连接件通过角色(role)元素定义交互参与者的特征
    连接件分为显式和隐式
    配置:部件和连接件是软件体系结构的独立元素单位,相互没有直接关联,配置是将部件和连接件整合起来的专门机制,配置定义部件端口与连接件角色的适配情况,并以此为基础描述整个软件体系结构

    14.体系结构风格
    一.主程序与子程序风格
    《1》部件:程序,函数,模块
    《2》连接件:他们之间的调用
    《3》约束:(控制从子程序层次结构顶部开始且向下移动)
    1)层次化分解,基于定义使用关系,上层使用下层,下层不能使用上层
    2) 单线程控制,主程序拥有最初控制权,在使用中将控制权转移到下层
    3) 隐含子系统结构,子程序通常合并成模块
    4) 层次化推理,子程序的正确性依赖于他所调用的自程序的正确性
    《4》实现:实现机制:模块实现,每个子程序都实现为一个模块
    主程序/子程序风格是基于部件和连接件建立的高层结构,类似于结构化程序的结构,但是部件不同于程序,是粗粒度的模块,部件的实现模块内部可以用结构化分析方法也可以使用面向对象方法。
    《5》效果
    1) 特点:功能分解,集中控制
    2) 优点:流程清晰,易于理解,强控制性,更好的控制程序的正确性
    3) 缺点:强耦合,依赖于交互方的接口,难以修改和复用,隐含的共享数据交流,不必要的公共耦合,破坏“正确性”控制能力
    《6》应用:功能可以分解为多个顺序执行步骤的系统
    二.面向对象风格
    1)将系统组织成多个对象,每个对象封装其内部的数据,并基于数据对外提供接口
    2)部件:对象或模块
    3)连接件:功能或调用(方法)
    4)约束:
    《1》数据表示对于其他对象是隐藏的,信息内聚
    《2》对象负责保持数据表示的完整性,以此为基础对外提供“正确”的服务
    《3》基于方法调用机制建立连接件,连接对象部件
    《4》每个对象都是自主代理,不同对象之间是平级的,没有主次,从属,层次,分解等关系
    5) 实现:模块实现,将每个对象部件实现为一个模块,基于面向对象分析的实现,基于结构化方法的实现
    6) 应用:适用于核心问题是识别和保护相关结构信息(数据)的应用,数据表示和相关操作封装在抽象数据类型
    7) 效果:
    优点:可修改性,不影响外界情况下变更内部实现
    易开发,易理解,易复用,自治单位,自己负责正确性
    缺点:接口的耦合性:方法调用
    标识的耦合性:调用其他对象需要知道对象的标识
    副作用:难以实现程序的正确性(比如A.B使用C,B对C的修改可能会对A产生不可预期的影响)
    三.分层风格
    1)部件:通常是程序或对象的集合
    2)连接件:通常是有限可见度下的程序调用或方法调用
    3)层次结构,通过分解,将复杂系统划分为多个独立的层次,每一层高度内聚,层与层之间的连接器通过层间交互的协议定义
    4)约束:系统组织成层,其中每一层给上一层提供服务,作为下一层的客户端,不允许跨层,层内部件可以交互。逆向调用也是不允许的
    5)应用:适用于包含不同类服务的应用,而且这些服务能够分层组织,尤其当应用可能在某些层改变。例子:分层通信协议,操作系统
    6)实现:关注点分离(每层逐次抽象),层间接口使用固定协议(固定控制),每层一或多个模块实现
    7)效果:
    优点:设计机制清晰,易于理解,支持并行开发,更好的可复用性和内部可修改性
    缺点:交互协议难以修改,性能损失(禁止跨层调用,每次请求都要层次深入,多次调用,可能生成冗余的调用处理),难以确定层次数量和粒度

    四.模型-视图-控制器风格
    1)model:应用程序的核心,封装了内核功能和数据
    业务逻辑(核心)
    数据以及访问数据的函数(视图使用)
    执行特定应用程序处理的过程(控制器代表用户调用)
    模型对于用不可不见,M和V独立
    模型独立于特定输出表示或者输入方式(M与C独立)
    用户只能通过控制器模型操作(C是M与V之间的桥梁)
    2)View:模型的表示,提供交互界面,向用户展示模型信息
    3)Controller:处理用户和系统之间的交互
    4)变更传播机制
    《1》一个模型可对应多个视图,若用户通过一个视图的控制器改变了模型中的数据,那么依赖于该数据的其他视图也应该反映出这样的变化,一旦模型的数据发生了变化,模型需要通知所有相关的视图做出相应的变化。
    《2》维护数据的一致性
    4) 部件:model部件负责维护领域知识和通知视图变化
    View部件负责给用户显示信息和将用户手势发送给控制器
    Controller改变模型的状态,将用户操作映射到模型更新,选择视图进行响应
    5) 连接件:程序调用,消息,事件
    6) 效果:
    优点:易开发性:三种不同内容的抽象,
    视图和控制的可修改性:模型相对独立,模型所封装的业务逻辑相对稳定
    适宜于网络系统开发的特性:业务逻辑,表现和控制的分离是得模型可以同时建立并保持多个视图
    缺点:不利于理解任务实现
    模型修改困难:视图和控制都依赖与模型
    7) 应用:
    适用于以下应用:在运行时,用户界面的改变很容易且是可能的
    用户界面的调整或抑制不会影响该应用功能部分的设计和编码
    例如:web应用

    15.详细设计?(会画类图,以及知道类之间的关系怎么表示
    1)哪些模块需要详细设计?
     view
     逻辑层:oo设计
     数据层:数据设计:简单设计-数据库课程

    3) 详细设计从哪开始?软件体系结构设计解决了需求中关键性的需求和约束,体系结构原型代码为详细设计提供了主要的代码框架,是初步方案,要进行细化–详细设计
    4) 详细设计的目标:实现所有功能性需求和非功能需求(需求驱动,细化每一个构件)
    5) 结果:要能够指导程序员编程的详细设计文档和详细设计原型代码
    a) 模块结构和接口
    b) 类结构,类的协作,类接口(面向对象分析方法)
    c) 控制结构和函数接口(结构化分析方法)
    d) 重要的数据结构和算法逻辑(如果有必要的方法)
    6) 面向对象的设计方法:
    i. 找到所有的对象(实体或者抽象概念)
    ii. 找到所有的任务/协作
    iii. 将任务/协作分配给对象

    对象:数据+算法
    对象完成自己的职责
    对象自己完成不了的通过互相发送消息请求其他对象完成
    对象:根据单一职责进行分解

    产生典型的面向对象式风格,容易陷入分散式控制风格,可以适当补充控制器,建立委托式控制风格

    7) 面向对象设计过程:
     建立设计模型
    通过职责建立静态设计模型(建立类图的步骤)
    抽象类的职责
    抽象类之间的关系
    添加辅助类
    通过协作建立动态设计模型
    抽象类之间的协作
    明确对象的创建
    选择合适的控制风格
     重构设计模型
    i. 根据模块化的思想重构,目标:高内聚,低耦合
    ii. 根据信息隐藏的思想重构,目标:隐藏职责和变更
    iii. 利用设计模式重构

    8) 通过职责建立静态模型
     抽象对象的职责
     类是对对象的抽象,是对所有具有相同属性和相同行为的对象族的一种抽象
    属性职责:对象的状态
    方法职责:对象的行为
     抽象类的关系
     类之间的关系表达了相应职责的划分和组合
     依赖<关联<聚合<组合<继承
     添加辅助类
     接口类
     记录类
     启动类
     控制器类
     实现数据类型的类
     容器类

    9) 通过协作建立动态的模型
     抽象对象之间的协作,通过顺序图和状态图来表达软件的动态模型
     明确对象的创建:谁负责创建类的新实例?解决方案:根据潜在创建者和被实例化类之间的关系决定哪个类应该创建实例
     建立合适的系统控制风格
    为了完成某一个大的职责,需要对职责的分配做很多决策,控制风格决定了决策由谁来做和怎么做决策
     分散式:所有系统行为在对象网络中广泛传播
     集中式:少数控制器记录所有系统行为的逻辑
     委托式(授权式):决策分布在对象网络中,一些控制器作主要决策

    16.耦合
    描述的是两个模块之间关系的复杂程度
    根据其耦合性的高低也可以以此分为内容耦合,公共耦合,重复耦合,控制耦合,印记耦合,数据耦合

    17.内聚
    表达的事一个模块内部的联系的紧密性
    内聚可以分为7个级别,由高到低包括信息内聚,功能内聚,通信内聚,过程内聚,时间内聚,逻辑内聚,偶然内聚

    18.面向对象中提高内聚的方法
     集中信息与行为
    一个高内聚的类应该是信息内聚的,也就是说类的信息应该和访问这些信息的行为放在一个类中,即集中信息与行为
    每个对象都会拥有数据信息和行为,这些信息和行为应该是有关联的:信息联合起来能够支撑行为的执行:行为完成对这些信息的操纵
     单一职责原则
    一个高内聚的类不仅要是信息内聚的,还应该是功能内聚的,也就是说,信息与行为除了要集中之外,还要联合起来表达一个内聚的概念,而不是单纯的堆砌,这就是单一职责原则

    19.面向对象的信息隐藏
     封装
     类应该通过接口对外表现他直接和间接承载的需求,而隐藏类内部的构造机理,这就是“封装”想要达到的
     封装实现细节
     封装数据和行为
     封装内部结构
     封装其他对象的引用
     封装类型信息
     封装潜在变更
    如果预计类的实现中有特定地方会发生变更,就应该将其独立为单独的类或者方法,然后为单独的类或方法抽象建立稳定的接口,并在原类中使用该稳定接口以屏蔽在变更的影响
     隐藏

    20.多态
     不同类型的值能够通过统一的接口来模拟,只需要不同类型的对象拥有统一定义的公共接口,就可以不论实际类型如何,直接调用该统一接口,这样系统就可以根据实际类型的不同表现出不同的行为
     子类型多态(面向对象编程中的狭义多态)
     使用继承机制实现
     表现为很多不同的子类通过共同的父类联系在一起,通过父类表现统一的接口,通过子类表现不同的行为
     程序员不需要预先知道对象的类型,具体的行为是在运行时才决定的
     多态抽象出多个类共同的行为接口,然后通过动态绑定,在运行时根据实际对象类型执行不同的行为实现

    21.设计模式
     策略模式
     设计分析:
     上下文和策略分割为不同的类,上下文Context类负责满足需求,策略类Strategy负责复杂策略的实现
     上下文类和策略类之间使用组合关系
     各种策略在具体策略类(ContreteStrategy)中提供,上下文类拥有统一的策略接口。由于策略和上下文独立,策略的增减,策略实现的修改都不会影响上下文和使用上下文的客户
     解决方案
     应用场景:
     当很多相关类只在他们的行为的实现上不一样时,策略模式提供了一个很好的方式来配置某个类,让其具有上述多种实现之一
     当我们需要同一个行为的不同实现时,策略模式可以用作实现这些变体
     一个类定义了很多行为,这些行为作为一个switch选择语句的分支执行部分,这时策略模式可以消除这些分支选择
     单件模式(会写代码)
     典型问题
     在某些场景中,对于某个类,在内存中只希望有唯一一个对象存在
     每次想得到这个类的一个对象的引用的时候,都指向唯一的那个对象
     无论创建多少次这个类的对象,其实总共还是只创建了一个对象
     设计分析
     为了实现之创建一个对象,首先要让类的构造方法变为私有的
     通过静态的getInstance方法获得Singleton类型的对象的引用
     类的成员变量中拥有一个静态的Singleton类型的引用变量uniqueInstance
     getInstance方法返回引用变量uniqueInstance,如果uniqueInstance等于null,则说明首次创建,通过关键字new创建Singleton对象,并且将该对象的引用变量赋值给uniqueInstance,否则说明不是首次创建,每次只需要返回已创建的对象的引用uniqueInstance即可
     应用场景
     某个类只有一个实例,并且作为客户公共的访问点
     当单一实现需要被继承,客户能够用一个子类的实例,而不需要修改他的代码

    22.设计可靠的代码
     契约式设计(会写)
     异常方式
     断言方式
     Java中断言语句的实现
    为了方便实现契约式设计,java语言提供了断言语句:assert Expression 1(:Exptression 2);
     Expression 1是一个布尔表达式,在契约式设计中可以将其设置为前置条件或者后置条件
     Expression 2是一个值,各种常见类型都可以
     如果Expression 1为true,断言不影响程序执行
     如果Expression 2 为false,断言抛出AssertionError异常,如果存在Expression 2就使用它作为参数构造AssertionError
     防御式编程(代码)
     基本思想:在一个方法与其他方法,操作系统,硬件等外界环境交互时,不能确保外界都是正确的,所以要在外界发生错误时,保护方法内部不受伤害
     常见情景(异常和断言都可以用来实现防御式编程)
     输入参数是否合法
     用户输入是否有效
     外部文件是否存在
     对其他对象引用是否是null
     其他对象是否已初始化
     其他对象的某个方法是否已执行
     其他对象的返回值是否正确
     数据库系统连接是否正常
     网络连接是否正常
     网络接受的消息是否有效

    23.软件测试
     验证与确认
     验证Verification
     检查开发者是否正确的使用技术建立系统,确保系统能够在预期的环境中按照技术要求正确的运行
     例如,“检查需求文档中的书写错误”,“发现设计思路的不完备”,“审查代码中的编程错误”等就属于验证活动
     确认Validation
     检查开发者是否建立了正确的系统,确保最终产品符合规格
     例如,对“需求文档内容是否反映用户真实意图”,“设计能否跟踪到需求”,“测试是否覆盖需求”等事宜的检查属于确认活动
     测试层次
     单元测试,验证独立软件片段的功能,软件片段可以是单个的子程序,或者是由紧密联系的单元组成的较大的组件
     又称为模块测试
     是对程序单元进行正确性检验的测试工作
     在面向对象编程中,一个单元就是类的一个方法
     通常来说,程序员没修改一次程序就会进行最少一次单元测试
     测试一个单元模块时,需要构建桩程序和驱动程序,将其与其他程序单元隔离
     集成测试,验证软件组件之间的交互
     又被称为组装测试,即对程序模块一次性或采用增量方式组装起来,对系统接口进行正确性检验的测试工作
     集成测试一般在单元测试之后,系统测试之前进行
     分为自顶向下的集成测试和自底向上的集成测试
     系统测试,关注整个系统的行为,评价系统功能需求和非功能性需求,也评价系统与外界环境(例如其他应用,硬件设备等)的交互
     单元测试和集成测试的区别
     单元测试的对象是类的一个方法,集成测试的对象是系统的接口
     单元测试的主要测试方法是基于代码的白盒测试,集成测试主要是基于功能的黑盒测试
     只有单元测试通过之后才能进行集成测试,所以单元测试是集成测试的基础,直接影响着集成测试
     测试技术(经常考什么是黑盒测试和白盒测试以及都包含哪些测试方法)
     黑盒测试
     黑盒测试是把测试对象看做是一个黑盒子,完全基于输入和输出数据来判定测试对象的正确性
     测试使用测试对象的规格说明来设计输入和输出数据
     测试方法
     等价类划分
    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理的假定:测试某等价类的代表值就等于对这一类其他类的测试
    等价类划分可以有两种不同的情况
     有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能
     无效等价类:是指对于程序的规格说明来说是不合理的,无意义的输入数据构成的集合。利用无效等价类可检验程序是否规避了各种错误和异常
     可以将其输入数据划分为三类:
     有效数据:符合前置条件
     无效数据:破坏第一个前置条件
     无效数据:破坏第二个前置条件
     边界值分析
     是对等价类划分方法的补充
     经验表明错误最容易发生在各等价类的边界上,而不是发生等价类内部。因此针对边界情况设计测试用例,可以发现更多的缺陷
     决策表
     用于测试以复杂逻辑判断为规格的测试对象
     决策表既能保证测试的完备性,又能保证成本最小
     决策表的每一列规则选项都是一个等价类
     状态转换
     针对复杂测试对象。该类复杂测试对象对输入数据的反应是多样的,还需要依赖自身的状态才能决定
     通常要先为对象建立状态图,描述测试对象的状态集合,输入集合和输入导致的状态转换集合
     以状态图为基础,可建立测试对象的转换表
     状态转换表每一行都应该被设计为测试用例
     白盒测试(将测试对象看做透明的,按照测试对象内部的程序结构来设计测试用例进行测试工作)
     语句覆盖:确保被测试对象的每一行程序代码都至少执行一次
     条件覆盖:确保程序中每个判断的每个结果都至少满足一次
     路径覆盖:确保程序中每条独立的执行路径都至少执行一次

    25.软件工程定义:
    1)应用系统的,规范的,可量化的方法来开发,运行和维护软件,即将工程应用到软件
    2)对1)中各种方法的研究
    26.软件工程的发展
     20世纪50年代
    科学计算:以机器为中心进行编程,像生产硬件一样生产软件
     20世纪60年代
    业务应用(批量数据处理和事务计算):软件不同于软件,用软件工艺的方式生产软件
     20世纪70年代
    结构化方法:瀑布模型,强调规律和纪律,是后续年代软件工程发展的支撑
     20世纪80年代
    追求生产力最大化,现代结构化方法/面向对象编程广泛应用,重视过程的作用
     20世纪90年代
    企业为中心的大规模软件系统开发,追求快速开发,可变更性和用户价值,web应用出现
     21世纪00年代
    大规模web应用,大量面向大众的web产品,追求快速开发,可变更性,用户价值和创新

    26.团队结构
     主程序员团队
    有一名技术能力出色的成员被指定为主程序员,主程序员负责领导团队完成任务
     民主团队
    因为没有集中的交流点,所以每个成员都可以发挥自己的能动性,能取得更高的士气和工作成就感
     开放团队
    为了创新而存在

    27.软件质量
     质量是一个过于宏观的概念,无法进行管理,所以人们通常会选用系统的某些质量要素进行量化处理,建立质量特征,这些特征被称为质量属性
     为了根据质量属性描述和评价系统的整体质量,人们从很多质量属性的定义选择了一些能够互相配合,互相联系的特征集,他们被称为质量模型
     质量模型例子
     可用性:软件在出现系统故障后保持运行的能力
     扩展性:改进或修改软件效率与功能需要花费的精力
     易学习性:用户理解软件时所花费精力的最小化程度

    28.质量保障
     在软件开发过程中,要监控和执行质量保障计划,在开发活动达到一个里程碑时,要及时根据质量保障计划进行质量验证
     质量验证的主要方法有:
     评审
     评审又称为同级评审
     现在是公认的质量保障最佳实践方法
     分为六个阶段:规划阶段,总体部署阶段,准备阶段,审查会议阶段,返工阶段和跟踪阶段
     在评审中发现问题是整个评审过程的关键阶段
     测试
     质量度量

    29.软件配置管理
     配置管理:用技术和管理的指导和监督方法,来表示和说明配置项的功能和物理特征,控制对这些特征的变更,记录和报告变更处理及其实现状态,并验证与需求规格的一致性
     配置项:置于软件配置管理之下的软件配置的各种有关项目,包括各类管理文档,评审记录与文档,软件文档,源码及其可执行码,运行所需的系统软件和支撑软件以及有关数据等
     基线:已经经过正式评审的规格说明或制品,可以作为进一步开发的基础,并且只有通过正式的变更控制过程才能变更

    30.软件配置管理的主要活动(期末考试)

    1. 标识配置项
      首先要确定有哪些配置项需要被保存和管理。其次要给配置项确定标识,设置唯一的id,最后要详细说明配置项的特征

    2. 版本管理
      为每一个刚纳入配置管理的配置项赋予一个初始的版本号,并在发生变更时更新版本号

    3. 变更控制
      已经纳入配置管理中的配置项发生变化时,需要依据变更控制过程进行处理

    4. 配置审计
      配置审计的目标是确定一个项目满足需求的功能和物理特征的程度,确保软件开发工作按照需求规格和设计特征进行,验证配置项的完整性,正确性,一致性和可跟踪性

    5. 状态报告
      配置状态报告是要标识,收集和维持演化中的配置状态信息,也就是对在动态演化着的配置项信息及其度量取快照

    6. 软件发布管理
      软件发布管理是要将软件配置项发布到开发活动之外,例如发布给客户

      31.软件建立的依据
       开发软件系统的目标:解决实际问题
       单纯的软件系统是不能解决问题的,只有和现实世界之间形成有效的互动才能实现问题的解决
       研究现实世界,分析问题,寻找与现实世界互动的方法

    32需求工程
     定义:所有需求处理活动的总和。他收集信息,分析问题,整合观点,记录需求并验证其正确性,最终描述出软件被应用后与其环境互动形成的期望效应
     三个主要任务:
     需求工程必须说明软件系统将被应用的应用环境及其目标,说明用来达成这些目标的软件功能,同时说明软件需要“做什么”和“为什么”需要做
     需求工程必须将目标和功能反映到软件系统当中,映射为可行的软件行为,并对软件行为进行准确的规格说明
     现实世界是不断变化的世界,因此需求工程还需要妥善处理目标和功能随着时间演化的变化情况
     需求工程的活动
    1) 需求开发
     需求获取
     从人,文档或者环境当中获取需求的过程,
     要利用各种方法和技术来“发现”需求,
     需求工程师两大重要任务:
    目标分析
     根据问题确定目标,问题的反面即为目标
     通过分析利害关系人确定目标
    用户需求获取
     面谈,问答形式,有特定目的的直接会话
     集体获取方法,通过和用户们讨论发现需求,在讨论中达成需求的一致
     头脑风暴,集体面谈,发现潜在的需求(发明需求)
     原型,有形的制品增进用户和需求工程师之间的交流
     需求分析
     通过建模来整合各种信息,以使得人们更好的理解问题
     为问题定义出一个需求集合,这个集合能够为问题界定一个有效的解决方案
     检查需求当中存在的错误,遗漏,不一致等各种缺陷,并加以修正
     需求规格说明
     系统用户之间交流需求信息
     高质量:要简洁,精确,一致和易于理解
     需求工程师的两大重要任务
     定制文档模板
     编写文档
     需求验证
     需求阶段的错误在维护阶段才发现,在维护阶段进行修复的代价可以高达需求阶段修复代价的100-200倍
     需求规格说明文档至少要满足下面几个标准

    1. 文档内每条需求都正确,准确的反映了用户的意图
    2. 文档记录的需求集在整体上具有完整性和一致性
    3. 文档的组织方式和需求的书写方式具有可读性和可修改性
       同级评审,原型等

    2) 需求管理
     需求管理:保证需求作用的持续,稳定和有效发挥
     进行变更控制

    33.需求定义

    1. 用户为了解决问题或达到某些目标所需要的条件或能力
    2. 系统或系统部件为了满足合同,标准,规范或其他正式文档所规定的要求而需要具备的条件或能力
    3. 对1)或2)中的一个条件或一种能力的一种文档化表述

    34.问题域
     现实世界运行规律的一种反映
     需求的产生地,也是需求的解决地
     最终的软件产品要在现实中部署,它能够部分影响问题域,但不能任意改变现实
    软件开发必须尊重问题域,不能因为技术原因妄自修改现实世界的实际情况

    35.规格说明
     软件产品的方案描述,他以软件产品的运行机制为主要内容
     他不是需求但实现需求,不是问题域但需要与问题域互动
     要以关注对外交互的方式描述软件解决方案,它既需要以软件产品的角度而不是用户的角度进行描述,又不能太多的涉及软件产品的内部构造机制

    36.问题,需求,问题域,规格说明
    下面信息内容是哪一种?
     超市的成本太高 问题
     超市的成本应该降低 需求
     超市的成本主要由人力成本和库存成本组成 问题域
     系统的成本计算为:成本=人力成本+库存成本 规格说明

    37.需求层次性(给例子写用户需求,业务需求和系统需求)
    目标:业务需求(解决方案与系统特性)
     系统建立的战略出发点,表现为高层次的目标,他描述了组织为什么要开发系统
     为了满足用户的业务需求,需求工程师需要描述系统高层次的解决方案,定义系统应该具备的特性
    任务:用户需求(问题域知识)
     执行实际工作的用户对系统所能完成的具体任务的期望,描述了系统能够帮助用户做些什么
     用户需求表达了用户对系统的期望,但是要透彻和全面的了解用户的真正意图,仅仅拥有期望是不够的,还需要知道期望所来源的背景知识,因此,对所有的用户需求,都应该有充分的问题域知识作为背景支持

    系统行为:系统级需求(需求分析模型)
     用户对系统行为的期望,每个系统级需求反映了一次外界与系统的交互行为,或者系统的一个实现细节
     直接映射为系统行为,定义了系统中需要实现的功能,描述了开发人员需要实现什么
     一系列的系统级需求联系在一起满足一个用户需求,进而满足业务需求

    38,将用户需求转化为系统需求的过程是一个复杂的过程
     首先需要分析问题域及其特性,从中发现问题域和计算机系统的共享知识,建立系统的知识模型
     然后将用户需求部署到系统模型当中,即定义系列的系统行为,让他们联合起来实现用户需求,每一个系统行为即为一个系统需求
     该过程就是需求工程当中最为重要的需求分析活动,又称为建模与分析活动

    39.软件需求的分类(给出需求让写出属于什么需求)
     功能需求
     定于:和系统主要工作相关的需求,即在不考虑物理约束的情况下,用户希望系统所能够执行的活动,这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互
     最常见,最主要和最重要的需求
     能够为用户带来业务价值的系统行为
     最需要按照三个抽象层进行展开
     软件产品产生价值的基础
     性能需求
     定义:系统整体或系统组成部分应该拥有的性能特征,例如cpu使用率,内存使用率
     速度,系统完成任务的时间
     容量,系统所能存储的数据量
     吞吐量,系统在连续的时间内完成的事务数量
     负载,系统可以承载的并发工作量
     实时性,严格的实时要求
     质量属性
     定义:系统完成工作的质量,即系统需要在一个“好的程度”上实现功能需求例如可靠性程度,可维护性程度等
     通常是隐式的,在需求开发时非常困难
     极大的影响软件体系结构的设计
     可靠性:在规定时间间隔内和规定条件下,系统或部件执行所要求能力的能力
     可用性:软件系统再投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
     安全性:软件阻止对其程序和数据进行未授权访问的能力,未授权的访问可能是有意的,也可能是无意的
     可维护性:软件系统或部件能修改以排除故障,改进性能或其他属性或适应变更了的环境的容易程度,包括可修改性和可扩展性
     可移植性:系统或部件能从一种硬件或软件环境转换至另外一种环境的特性
     易用性:与用户使用软件所花费的努力及其对使用的评价相关的特性
     对外接口
     定义:系统和环境中其他系统之间需要建立的接口,包括硬件接口,软甲接口,数据库接口等
     约束:(总体上限制了开发人员设计和构建系统时的选择范围)
     系统开发及运行的环境
     问题域内的相关标准
     商业规则
     其他数据需求
    功能需求的补充,如果在功能需求部分明确定义了相关的数据结构,那么就不需要再行定义数据需求
    数据需求是需要在数据库,文件或者其他介质中存储的数据描述,通常包括以下内容
     各个功能使用的数据信息
     使用频率
     科访问性要求‘
     数据实体及其关系
     完整性约束
     数据保持要求’

    40.需求分析的任务
     建立分析模型,达成开发者和用户对需求信息的共同理解
    将复杂的系统分解成简单的部分以及这些部分之间的关系
    确定本质特征,抛弃次要特征
     依据共同的理解,发挥创造性,创建软件系统解决方案

    41.模型与建模
     模型是对事物的抽象,帮助人们在创建一个事物之前可以有更好的理解。
     建立模型的过程称为建模。“它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示,这个表示以精确一致的方式描述系统,使得系统的使用更加容易”
     抽象
     关注重要的信息,忽略次要的内容
     将人质保留在适当的层次,屏蔽更深层次的细节
     通过强调本质特征减少问题复杂性
     分解
     将某个复杂难以理解的问题分解成多个相对容易的子问题,并掌握各子问题的联系
     分而治之

    42.需求分析模型
    描述软件解决方案的模型技术
     介于用户概念和软件内部实体之间的模型形式
     使用软件的内部实体作为模型的基本元素(对象,函数,属性等)
     使用问题域的概念描述软件内部实体,使用问题域语言表现语义

    43.用例
     基本特点:目标,交互,场景(行为序列)
     定义:在系统(或子系统或者类)和外部对象的交互当中所执行的行为序列的描述,包括各种不同的序列和错误的序列,他们能够联合提供一种有价值的服务
     用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时的系统条件,系统将执行不同的行为序列,每一个行为序列被称为一个场景,一个用例是多个场景的集合
     用例模型:以用例为单位建立的一个系统功能展示模型,是系统所有用例的集合,以统一,图形化的方式展示系统的功能和行为特性
     基本元素:
     用例,代表了一组典型的场景,帮助构建,关联,和理解基本需求
     参与者是与开发的系统进行交互的用户或其他系统等角色
    用例图中一个单一的参与者可以代表多个用户(或系统)
    一个单一的用户(或系统)可能扮演多种角色
    参与者不一定是人,例如,需要从当前系统获取信息的外部系统也是参与者
     关系,参与者之间的关系:泛化
    用例之间:泛化,包含,扩展
    参与者与用例之间:关联
     系统边界
    系统所包含的系统成分与系统外事务的分界线,用矩形框表示系统边界
    参与者通常在边界外面,用例通唱在边界里面

    44.用例图的建立
     目标分析与确定解决方向
     寻找参与者
     寻找用例
     细化用例
    如果用例的粒度不合适就需要进行细化和调整
     判断标准是:用例描述了为应对一个业务事件,由一个用户发起,并在一个连续时间段内完成,可以增加业务价值的业务
     不要将没有业务价值(而是技术实现需要)的事件作为用例(例如,登录(安全性需求),输入输出数据检查(数据需求或者业务规则),数据库连接,网络传输等)
     不要将没有独立业务价值的单个操作(他们仅仅是技术实现上独立)作为用例,例如删除,增加,修改,保存等等
     常见错误
     不要将用例细化成单个操作
     不要将单个步骤细化成用例
     不要将片面的一个方面细化成用例‘
     不要将登录,数据验证,连接数据库等没有业务价值的内容作为用例

    45.用例描述(给出场景让写用例)
    项目 内容描述
    Id 用例的标识
    名称 对用例内容的精确描述,体现了用例所描述的任务
    参与者 描述系统的参与者和每个参与者的目标
    触发条件 标识启动用例的条件,可能是系统外部的事件,也可能是系统内部的事件,还可能是正产流程的第一个步骤
    前置条件 用例能够正常启动和工作的系统状态条件
    后置条件 用例执行完成后的系统状态条件
    正常流程 在常见和符合预期的条件下,系统与外界的行为交互序列
    扩展流程 用例中可能发生的其他场景
    特殊需求 和用例相关的其他特殊需求,尤其是非功能性需求

    46.交互图
     描述对象之间的协作
     通常描述的是单个用例的典型场景,他也因此被称为“用例的实现”
     交互图有顺序图,通信图,交互概述图和时间图四种类型,其中顺序图是最为常用的一种

    47.顺序图
    以交互行为中的消息序列为主,消息以时间顺序在图中从上到下排列

    48.系统顺序图
     系统顺序图将整个系统看做一个黑箱的对象而描述的简单顺序图形式,他强调外部参与者和系统的交互行为,重点展示系统级事件
     通过建立系统顺序图模型,可以:
     通过匹配“刺激/响应”发现交互行为的缺失
     只有用户发起刺激,系统才会有响应,否则意味着用户行为信息丢失
     用户发起刺激后,系统必须有响应,否则意味着软件响应行为丢失
     一个刺激,通常有一个系统响应,也可以有连续的多个响应
     通过分析每个刺激响应的异常,发现流程的异常

    49.概念类图
     又被称为“领域模型”
     类图是面向对象分析方法的核心
    描述类(对象)和这些类(对象)之间的关系
     概念类图与设计类图有所不同
    关注现实世界问题域,而不是软件系统的内部构造机制
     类型,方法,可见性等复杂的软件构造细节不会在概念类图中
     基本元素
     对象:使用具体问题域事物的抽象
    标识符:对象的引用
    状态:对象的特征描述,包括对象的属性和属性的取值
    行为:状态发生变化或者接收到外界消息时采取的行动
     类:对象的集合
     链接:对象之间的交互协作的关系
     关联:类之间的关系,潜在的链接抽象
    聚合:部分和整体之间的关系,空心菱形
    组合:整体对部分有完全的管理职责,即一个部分只能属于一个整体,实心菱形
     继承:父类是子类的泛化,子类是父类的特化
     将领域对象类组织成层次结构
     最高层的类反应了所有类的共同特点
     对象类从一到多个父类继承属性和服务,这些属性和服务可能在必要时特化

    50.建立概念类图(会画)
     对每个用例文本描述,尤其是场景描述,建立局部的概念类图
     根据用例的文本描述,识别候选类(找名词)
     筛选候选类,确定概念类
     如果候选类的对象实例既需要维持一定的状态,又需要依据状态表现一定的行为,确定为一个概念类
     如果需要维护状态,不需要表现行为,则为其他概念类的属性
     不需要维护状态。却需要表现行为
    首先要重新审视需求是否有遗漏,因为没有状态支持的对象无法表现行为
    如果确定没有需求的遗漏,就应该删除该候选类,并将行为转交给具备状态支持能力的其他概念类

     既不需要维护状态,又不需要表现行为,应该被完全删除

     识别关联
     分析用例文本描述,发现概念类之间的协作,需要协作的类之间需要建立关联
    是否需要协作的第一标准是满足需求的要求
    是否需要协作的第二标准是现实状况
     分析和补充问题域内的关系,例如概念类之间的整体部分关系和明显的语义联系。对问题域关系的补充要适可而止,不要把关系搞得过度复杂化
     去除冗余关联和导出关联

     识别重要属性
     将所有用例产生的局部概念类图进行合并,建立软件系统的整体概念类图

    51.有限状态机
     有限状态机理论认为系统总是处于一定的状态之中,并且,在某一个时刻,系统只能处于一种状态之中
     系统在任何一个状态中都是稳定的,如果没有外部事件触发,系统会一直持续维持该状态
     如果发生了有效的触发事件,系统将会响应事件,从一种状态转移到另一种状态中
     状态图的基本思想:基于有限状态机理论,如果能够罗列出所有可能的状态,并发现所有有效的外部事件,那么就能够从状态转移的角度完整的表达系统的所有行为

    52.状态图的基本概念
     状态:一组观察到的情况,在一个给定的时间描述系统行为
     状态转移:从一个状态到另一个状态的转移
     事件:导致系统表现出可预测行为的事件
     活动:作为转换的结果而发生的过程

    53.状态图的建立
     确定上下文环境
    状态图是立足于状态快照进行行为描述的,因此建立状态图时 首先要搞清楚状态的主体,确定状态的上下文环境,常见的状态主体有:类,用例,多个用例和整个系统
     识别状态
    状态主体会表现出一些稳定的状态,他们需要被识别出来,并且标记处其中的初始状态和结束状态集,在某些情况下,可能会不存在确定的初始状态和结束状态
     建立状态转换
    根据需求所描述的系统行为,建立各个稳定状态之间可能存在的转换
     补充详细信息,完善状态图
    添加转换的触发事件,转换行为和监护条件等详细信息

    展开全文
  • 简答题很有帮助的
  • DMT SREM SRI CML RTM SCRUM 求大神帮忙解释一下
  • 下面是自己在准备考研复试面试时整合的本科模拟题、课本和学姐资料,仅供参考,不足之处欢迎交流 名词解释 软件软件是程序、数据以及相关文档的集合。程序是完成预定功能和性能的可在计算机系统上的指令序列;数据...
  • 软件工程导论名词解释.pdf
  • 这个是我在学习软件工程考试期间整理的资源,绝对不坑,包含软件工程课件,软件工程复习题目及考题,名词解释以及简答题汇总等等
  • 软件:是在计算机系统的支持下,能够完成特定功能...软件工程:将系统的、规范的方法应用于软件的开发、运行和维护的过程及上述方法的研究。 软件架构:是指一系列抽象模式,用于指导大型软件的各个方面的设计。...
  • 软件工程导论名词解释整理.pdf
  • 软件工程复习(第一部分填空选择和名词解释)L

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,893
精华内容 5,957
关键字:

软件工程名词解释