个人总结,仅供参考,欢迎加好友一起讨论
第二版架构新教材里对应第5章,相关概念和定义改动的比较多,尤其是对于软件工程阶段的划分,传统的软件设计的阶段划分等,新教材里都删除了,也缺少了测试用例设计、运行维护阶段内容,而且还将需求工程,软件测试,软件维护相关内容加入进来。
相关软件工程还可以参考:系分 - 软件工程
软件开发生命周期:
软件系统的文档可以分为用户文档和系统文档两类,用户文档主要描述系统功能和使用方法,并不关系这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容。
软件工程过程是指为获得软件产品包括以下4个方面活动:
软件系统工具通常可以按软件过程活动将软件工具分为:
软件设计四个活动:
软件能力成熟度模型(Capability Maturity Model for Software,CMM)
初始级 |
---|
特点: 软件过程的特点是杂乱无章,有时甚至很混乱,几乎没有明确定义的步骤,项目的成功完全依赖个人的努力和英雄式核心人物的作用。 |
可重复级 |
特点: 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性,有必要的过程准则来重复以前在同类项目中的成功。 过程域: 软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理 |
已定义级 |
特点: 管理和工程两方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件。 过程域: 同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点 |
已管理级 |
特点: 制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 过程域: 软件质量管理和定量过程管理 |
优化级 |
特点: 加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 过程域: 过程更改管理、技术改革管理和缺陷预防 |
软件能力成熟度模型集成(Capability Maturity Model Integration for Software,CMMI)
CMMI是在CMM的基础上发展而来的。
初始级 |
---|
特点: 过程不可预测且缺乏控制 |
已管理级 |
特点: 过程为项目服务 过程域: 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 |
已定义级 |
特点: 过程为组织服务 过程域: 需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 |
定量管理 |
特点: 过程已度量和控制 过程域: 组织过程性能、定量项目管理 |
优化级 |
特点: 集中于过程改进和优化 过程域: 组织级改革与实施、因果分析和解决方案 |
开发方法比开发模型要来得大一号。结构化开发方法对应V模型和瀑布模型;面向对象开发方法对应喷泉模型,统一方法模型,敏捷模型,面向服务的模型。 所有面向服务的模型都是以面向对象为基础的。
瀑布模型也称为生命周期法,是生命周期法中最常用的开发模型,一般将软件开发分为:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。如图:
瀑布模型特点:
瀑布模型有利于大型软件开发过程中人员的组织与管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下的,而是呈线性图示,因此,瀑布模型存在严重的缺陷:
原型化模型主要针对事先不能完整定义需求的软件开发,是在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。
原型法认为在很难一下子全面准确地提出用户需求的情况下,原型应当具备的特点如下:
有关原型化方法/模型的内容:
软件原型是所提出的新产品的部分实现,建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题,其目的是明确并完善需求、探索设计选择方案、发展为最终的产品。原型模型比较适合需求不够明确的项目。
原型有很多种分类方法。从原型是否实现功能来分,软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型,用来探索预期系统的一些特定行为,并达到细化需求的目的。水平原型通常只是功能的导航,但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型,实现了一部分功能。垂直原型主要用在复杂的算法实现上。
从原型的最终结果来分,软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型,是指达到预期目的后,原型本身被抛弃。抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础,是螺旋模型的一部分,也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的项目,适用于Web项目。
有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前,考核方案是否合适,规格说明是否可靠。进化型原型的目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。
原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求,建立一个原始模型,这是一个可以修改的模型(在生命周期法中,需求分析成文档后一般不再多修改)。
在软件开发的各个阶段都把有关信息相互反馈,直至模型的修改,使模型渐趋完善。在这个过程中,用户的参与和决策加强了,最终的结果是更适合用户的要求。
这种原型技术又可分为三类:抛弃式、演化式和递增式。这种原型法成败的关键及效率的高低在于模型的建立及建模的速度。
增量模型融合了瀑布模型的基本成分(重复的应用)和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的"增量“。当使用增量模型时,第一个增量往往是核心的产品,也就是说第一个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估,都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复,直到产生最终的完善产品。
增量模型强调每一个增量均发布一个可操作的产品。如图:
增量模型像原型实现模型和其他演化方法一样,本质上是迭代的。但与原型实现不同的是增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的"可拆卸"版本,但它们确实提供了为用户服务的功能,并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求,还需要更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。
采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源,如果核心产品很受欢迎,则可以增加人力实现下一个增量;当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径,这样就可以先发布部分功能给客户,对客户起到镇静剂的作用。此外,增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理,就必须做全盘的系统分析,不能很好的进行模块划分。增量模型将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。
螺旋模型将瀑布模型和原型化(演化)模型相结合,它综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动,并开发原型的一个新版本。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。经过若干次螺旋上升的过程,得到最终的系统,如图:(需求在项目刚开始的时候往往会比较模糊,而随着项目的进行会慢慢的明确下来,也就是需求有渐进明细的特点。)
喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持,主要支持面向对象的开发方法,是一种以用户需求为动力,以对象作为驱动的模型。"喷泉"一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次,相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中,分析、设计和编码之间不存在明显的边界,如图:
在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型,那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程,如图:
V模型是最具有代表意义的测试模型,它是瀑布模型的变种,它在瀑布模型的基础上加强了测试,反映了测试活动与分析和设计的关系。V模型中,左边下降的是开发过程阶段,右边上升部分是测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测试是为了使整个系统满足用户的需求。V模型存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。让测试工作贯穿于始终。
V模型强调软件幵发的协作和速度,将软件实现和验证有机地结合起来,在保证较高的软件质M情况下缩短开发周期。V模型适合企业级的软件幵发,它更淸楚地揭示了软件开发过程的特性及其本质。
V模型的价值在于它非常明确地表明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系:
构件(Component,组件)是一个具有可重用价值的、功能相对独立的软件单元。基于构件的软件开发(ComponentBased Software Development,CBSD)模型是利用模块化方法,将整个系统模块化,并在一定构件模型的支持下,复用构件库中的一个或多个软件构件,通过组合手段高效率、高质量地构造应用软件系统的过程。
基于构件的开发模型融合了螺旋模型的许多特征,本质上是演化型的,开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立(其中构件库包括了构件获取和构件管理)、应用软件构建、测试和发布5个阶段组成。如图:
CBSE的构件应该具备的特征:
CBSE的构件的组装顺序:
构件作为重要的软件技术和工具得到了极大的发展,这些新技术标准和工具有Microsoft的DCOM/COM,Sun的EJB,OMG的CORBA等。基于构件的开发活动从标识候选构件开始,通过搜索已有构件库,确认所需要的构件是否已经存在,如果已经存在,就从构件库中提取出来复用;如果不存在,就采用面向对象方法开发它。在提取出来的构件通过语法和语义检查后,将这些构件通过胶合代码组装到一起实现系统,这个过程是迭代的。
基于构件的开发方法使得软件开发不再一切从头开始,开发的过程就是构件组装的过程,维护的过程就是构件升级、替换和扩充的过程,其优点是构件组装模型导致了软件的复用,提高了软件开发的效率;构件可由一方定义其规格说明,被另一方实现,然后供给第三方使用;构件组装模型允许多个项目同时开发,降低了费用,提高了可维护性,可实现分步提交软件产品。缺点是由于采用自定义的组装结构标准,缺乏通用的组装结构标准,引入具有较大的风险;可重用性和软件高效性不易协调,需要精干的、有经验的分析人员和开发人员,一般的开发人员插不上手,客户的满意度低;过分依赖于构件,构件库的质量影响着产品质量。
快速应用开发(Rapid Application Development,RAD)模型是一个增量型的软件开发过程模型,强调极短的开发周期。RAD模型是瀑布模型的一个“高速”变种,通过大量使用可复用构件,采用基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围,利用这种模型可以很快地创建出功能完善的“信息系统“。其流程从业务建模开始,随后是数据建模、过程建模、应用生成、测试及反复。瀑布模型和CBSD(Component-Based Software Development基于构建的软件开发模型)的综合开发模型,如图:
RAD模型各个活动期所要完成的任务如下:
与瀑布模型相比,RAD模型不采用传统的第三代程序设计语言来创建软件,而是采用基于构件的开发方法,复用已有的程序结构(如果可能的话)或使用可复用构件,或创建可复用的构件(如果需要的话)。在所有情况下,均使用自动化工具辅助软件创造。很显然,加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成,那么它就是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现,最后再集成起来形成一个整体。
RAD模型通过大量使用可复用构件加快了开发速度,对信息系统的开发特别有效。但是像所有其他软件过程模型一样,RAD方法也有其缺陷:
RUP的特点
RUP中有4个阶段
统一软件开发过程定义了四种开发阶段,它们按照过程顺序分别是起始阶段,细化阶段,构建阶段和交付阶段,其中在构建阶段主要产生的文档有设计模型。
初始阶段:项目蓝图文档(核心需求,关键特征,主要约束),用例模型,项目计划
细化阶段:完成架构设计,淘汰高风险元素
构造阶段:UML模型,测试用例
交付阶段:可运行的软件产品,用户手册,用户支持计划。
RUP中有9个核心工作流
RUP的工作流程分为两部分:核心工作流程与核心支持工作流程。核心工作流程(在项目中的流程)包括业务需求建模、分析设计、实施、测试、部署;核心支持工作流程(在组织中的流程)包括环境、项目管理、配置与变更管理。
RUP软件开发生命周期是一个二维的软件开发模型,RUP中有9个核心工作流,如下:
XP极限编程
XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于:
四大价值观:
XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法,开发人员和客户可以非常清楚开发进度、变化待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。
XP提倡测试先行,为了将以后出现bug的几率降到最低。
XP一些对费用控制严格的公司中的使用,非常有效。
水晶方法
水晶系列方法与XP方法一样,都有以人为中心的理念,但在实践上有所不同。其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式、工作产品和实践。
水晶方法:探索了用最少纪律约束而仍能成功的方法,从而在产出效率与易于运作上达到一种平衡。
开放式源码
开放式源码:程序开发人员在地域上分布很广【其他方法强调集中办公】。
并列争求法
并列争球法(SCRUM)是一种迭代的增量化过程,把每段时间(如30天)一次的迭代称为一个“冲刺”(Sprint),并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。
并列争求法(SCRUM):明确定义了的可重复的方法过程,侧重于项目管理。。
特征驱动开发方法
特征驱动开发方法(FDD)是一个迭代的开发模型。认为有效的软件开发需要3个要素:人、过程和技术。有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。定义了6种关键的项目角色:项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。
功用驱动开发方法(FDD):编程开发人员分成两类:首席程序员和“类”程序员。
ASD方法
ASD方法:其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。
动态系统开发方法
动态系统开发方法(DSDM):倡导以业务为核心。
逆向工程的特点是从已有的程序中抽取数据结构,体系结构和程序设计信息。
它的流程为:现有系统 → 逆向工程 → 考虑新需求 → 正向工程 → 新系统。
软件的逆向工程是一个恢复设计的过程,从现有的程序中抽取数据,体系结构和过程设计信息。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述,在大多数情况下,抽象层次越高,完备性就越低。
领域级抽象级别最高,完备性最低,实现级抽象级别最低,完备性最高。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程:
逆向工程恢复信息的方法 | |
---|---|
方法 | 导出信息 |
用户指导下的搜索与变换方法 | 实现级、结构级 |
变换式方法 | 实现级、结构级、功能级 |
基于领域知识的方法 | 功能级、领域级 |
铅板恢复法 | 实现级、结构级 |
净室即无尘室,洁净室,也就是一个受控污染级别的环境。
使用盒结构规约(或形式化方法)进行分析和设计建模,并且强调将正确性验证而不是测试,作为发现和消除错误的主要机制。
使用统计的测试来获取认证被交付的软件的可靠性所必须的出错率信息。它是一种强调正确性的数学验证和软件可靠性的认证的软件工程模型,其目标和结果具有非常低的出错率。
技术手段:
统计过程控制下的增量式开发:控制迭代
基于函数的规范和设计:盒子结构
定义3种抽象层次:行为视图(黑盒)=>> 有限状态机视图(状态盒)=>> 过程视图(明盒)
正确性验证:净室工程的核心
统计测试和软件认证:使用统计学原理,总体太大时必须采用抽样方法
缺点:
相关需求工程还可以参考:系分 - 需求工程
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
需求分类
质量功能部署QFD
它是一种将用户要求转化成软件需求的技术,其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标,QFD将软件需求分为三类,分别是常规需求、期望需求和意外需求。
需求获取方法 | |
---|---|
方法 | 特点 |
收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 |
阅读历史文档 | 对收集数据性的信息较为有用。 |
用户访谈 | 1对1-3,有代表性的用户,了解主观想法,交互好。成本高,要有领域知识支撑。 |
问卷调查 | 用户多,无法—一访谈,成本低。 |
现场观摩 | 针对较为复杂的流程和操作。 |
参加业务实践 | 有效地发现问题的本质和寻找解决问题的办法。 |
联合需求计划(JRP) | 高度组织的群体会议,各方参与,了解想法,消除分歧,交互好,成本高。 |
情节串联板(原型法) | 一系列图片,通过这些图片来讲故事。 |
抽样调查/采样 | 基于数理统计,降低成本,快速获取。 样本大小=a*(可信度系数/可接受的错误)2注:a一般取0.25 |
用户访谈是最基本的一种需求获取手段,其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题,有针对地进行;而非结构化则是只列出一个粗略的想法,根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行,毕竟不可能把什么都一一计划清楚,应该保持良好的灵活性。
用户访谈具有良好的灵活性,有较宽广的应用范围。但是,也存在着许多困难,例如,用户经常较忙,难以安排时间;面谈时信息量大,记录较为困难;沟通需要很多技巧,同时需要系统分析师具有足够的领域知识等。另外,在访谈时,还可能会遇到一些对于企业来说比较机密和敏感的话题。因此,这看似简单的技术,也需要系统分析师具有丰富的经验和较强的沟通能力。
问卷调查与用户访谈相比,问卷调查可以在短时间内,以低廉的代价从大量的回答中收集数据;问卷调查允许回答者匿名填写,大多数用户可能会提供真实信息;问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性,其他缺点还有:
① 双方未见面,系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息,用户也没有机会立即澄清对问题有含糊或错误的回答。
② 用户有可能在心理上会不重视一张小小的表格,不认真对待,从而使得反馈的信息不全面。
③ 调查表不利于对问题进行展开的回答,无法了解一些细节问题。
④ 回答者的数量往往比预期的要少,无法保证用户会回答问题或进一步说明所有问题。
抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程,通过认真研究所选出的样本集,可以从整体上揭示种群的有用信息。对于信息系统的开发而言,现有系统的文档(文件)就是采样种群。当开始对一个系统做需求分析时,查看现有系统的文档是对系统有初步了解的最好方法。但是,系统分析师应该查看哪些类型的文档,当文档的数据庞大,无法一一研究时,就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据,还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时,上面介绍的采样技术同样适用。通过采样技术,选择部分而不是选择种群的全部,不仅加快了数据收集的过程,而且提高了效率,从而降低了开发成本。另外,采样技术使用了数理统计原理,能减少数据收集的偏差。
但是,由于采样技术基于统计学原理,样本规模的确定依赖于期望的可信度和已有的先验知识,很大程度上取决于系统分析师的主观因素,对系统分析师个人的经验和能力依赖性很强,要求系统分析师具有较高的水平和丰富的经验。
联合需求计划(JRP)
JRP是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。通常该会议的参与人数为6~18人,召开时间为1~5小时。
JRP的主要意图是收集需求,而不是对需求进行分析和验证。实施JRP时应把握以下主要原则:
① 在JRP实施之前,应制订详细的议程,并严格遵照议程进行。
②按照既定的时间安排进行。
③尽量完整地记录会议期间的内容。
④在讨论期间尽量避免使用专业术语。
⑤充分运用解决冲突的技能。
⑥会议期间应设置充分的间歇时间。
⑦鼓励团队取得一致意见。
⑧保证参加JRP的所有人员能够遵守事先约定的规则。
需求分析:一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性,因此,需要分析人员把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。
需求分析的任务:
结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型,分别是数据模型,功能模型,行为模型(状态模型)。
结构化分析的步骤如下:
结构化分析方法SA是数据流和控制流,常用手段是数据流图(DFD)和数据字典。
数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。
数据字典有4类条目:数据流、数据项、数据存储和基本加工。包括了数据元素,数据结构,数据流,加工逻辑和外部实体。如下图:
数据流图DFD是用数据流图表示功能模型,DFD说明系统所完成功能,从数据传递和加工的角度,利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况,来说明系统所完成的功能。如下图:
其中,DFD还会有“顶层DFD图”和“0层DFD图”。
如上图,有如下几种“图元”描述:
另附一个错误的DFD图,如下:
如上图错误:
用状态转换图表示行为模型,STD通过描述系统的状态和引起系统状态转换的事件,来表示系统的行为,指出做为特定事件的结果将执行哪些动作。如下图:
ER图主要描述实体属性,以及实体之间的关系。另外,ER模型是结构化时代的模型与产物,在面向对象和UML中是没有的。如下图:
什么是弱实体?
举例说明:在人事管理系统中,职工子女的信息就是以职工的存在为前提的,子女实体是弱实体,子女与职工的联系是一种依赖联系。所以,职工是实体,也可以成为强实体。
强实体与弱实体的联系只能是1:1或1:N。
相关的几个概念 | |
---|---|
对象 | 属性[数据] + 方法[操作] + 对象ID/标识ID |
类[详细见下] | 实体类/控制类/边界类 实体类:往往和数据库有对应的关系,是不是数据类型 控制类:衔接实体类和边界类的类 边界类:在一个系统的边界上和外部进行沟通的类 这三个类似于MVC模型之间的关系,它们的思想是一样的 |
继承与泛化 | 复用机制,它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例的特征稍作改变就生成其他的实例。 |
封装 | 隐藏对象的属性和实现细节仅对外公开接口 |
多态 | 不同对象收到同样的信息产生不同的结果 |
接口 | 一种特殊的类,它只有方法定义没有对方法的实现 |
重载 | 一个类可以有多个同名的参数类型不同的方法。函数同名但参数不一样是其特点 |
消息和消息通信 | 消息是异步通信的 |
覆盖与重写 | 子类的同名方法覆盖父类的同名方法 |
组合与聚合 | 聚合关系:汽车部件和整车的关系(整体与部分生命周期不同) 组合关系:部门与公司的关系。公司倒闭的话部门也完完(整体与部分生命周期相同) |
OOA大致上遵循如下5个基本步骤:
OOA需求分析的UML(统一建模语言,与平台和语言无关)由基本构造块,规则和公共机制构成。
UML基本构造块之事物【重要组成部分】 | |
---|---|
结构事物 | 最静态的部分,包括类,接口,协作用例,活动类,构件和节点 |
行为事物 | 代表时间和空间上的动作,包括消息,动作次序,连接 |
分组事物 | 看成是个盒子,如包和构件 |
注释事物 | UML模型的解释部分。描述,说明,和标注模型的元素 |
UML基本构造块之关系【把事物紧密联系在一起】 | |
---|---|
依赖关系 | 一个事物发生变化影响另一个事物,包含关系和扩展关系都属于依赖 |
泛化关系 | 特殊一般关系,特殊元素的对象可替换一般元素的对象 |
关联关系 | 描述了一个链,链是对象之间的连接 |
实现关系 | 接口与类之间的关系,一个类指定了由另一个类保证执行的契约 |
UML基本构造块之图【多个相互关联的事物的集合】 | |
---|---|
静态图(结构图) | |
类图 | 描述一组类,接口协作和它们之间的关系。 |
对象图 | 描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用,画出来的对象图往往不会只有一个对象。 |
构件图 | 也叫组件图,是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口,端口,以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。 |
部署图 | 表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统,内存,CPU等不在它范畴内,它只解决开发的系统如何去部署的问题。 |
制品图 | 描述计算机中一个系统的物理结构。制品包括文件,数据库,和类似的物理比特集合。 |
包图 | 将某些类放入“包”中,通过包图来组织业务概念图。 |
组合结构图 | 展示该部分内容“内部”参与者的配置情况。这个图不常用。 |
动态图(行为图) | |
用例图 | 系统与外部参与者的交互。描述一组用例,参与者及他们之间的关系的图。 |
顺序图 | 强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。 |
通信图 | 也叫协作图,它强调的是相互之间关系,是顺序图的另外一种表达。 |
定时图 | 消息跨越不同对象或角色的实际时间。交互图的一种。 |
交互概览图 | 活动图与顺序图的结合。这个图不常用。 |
活动图 | 类似程序流程图,表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流,它专注于系统的动态视图,它对系统功能建模和业务流程建模特别重要;并强调对象间的控制流程。 |
状态图 | 从某个物品的状态是如何变化的角度来展示流程。 |
UML规则 |
---|
是构造块如何放在一起的规定,包括为构造块命名;给一个名字以特定含义的语境,即范围;怎样使用或看见名字,即可见性;事物如何正确、一致地相互联系,即完整性;运行或模拟动态模型的含义是什么,即执行。 |
UML公共机制 |
---|
是指达到特定H标的公共UML方法,主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制4种。规格说明是事物语义的细节描述,它是模型真正的核心:UML为每个事物设置了一个简单的记号,还可以通过修饰来表达更多的信息;UML包括两组公共分类:类与对象(类表示概念,而对象表示具体的实体)、接门与实现(接口用来定义契约,而实现就是具体的内容);扩展机制包括约束(扩展了UML构造块的语义,允许增加新的规则或修改现有的规则)、构造型(扩展UML的词汇,用于定义新的构造块)和标记值(扩展了UML构造块的特性,允许创建新的特殊信息来扩展事物的规格说明)。 |
UML中的概念
现有的UML,再有的UML视图
UML采用4+1视图来描述软件和软件的开发过程,其中进程视图绘制了所设计的并发与同步结构;部署视图表示软件到硬件的映射和分布结构;UML中的类图可以用来表示4+1视图中逻辑视图;最终形成用例视图,用来得到需求分析模型。
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性,实践证明能在许多大型项目中成功运用。
在OOA的需求分析中,图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线,其中用例模型采用用例图来构建,分析模型用类型表示。其它细节情况,也可以建立其它交互图。
案例分析中,用例图和类图,经常考到
用例建模来源于面向对象建模技术,但该技术也在非对象开发环境中比较流行,用例建模技术对传统的系统分析和设计工具进行了补充,例如数据建模和过程建模, 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与,具有如下优点:
为了决定用例的重要性,项目经理或者系统分析员将填写用例分级和评估矩阵,并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵,决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是:
2、有些用例依赖于其他用例,其中一个用例使系统处于一种状态,该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点:
数据建模是一种为数据库定义业务需要的技术,因为数据模型最终要实现成数据库,所以数据建模有时称为数据库建模。下图是一个简单的数据模型,称为实体关系图。
数据建模的系统概念:
如何构造数据模型?
过程建模源自传统的软件工程方法,可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型,即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念:
如何构造过程模型:
面向对象分析涉及到定义信息系统的静态和动态行为模型,而非定义数据和过程模型(这是传统开发方法的特点)。对象的标识,对象的数据部分(属性),对象的行为。
需求定义的过程也就是形成需求规格说明书SRS的过程,通常有两种需求定义的方法,分别是严格定义方法和原型方法。
严格定义法的特点:所有需求都能够被严格定义;开发人员和用户之间能够准确而清晰的交流;采用图形文字能够充分体现最终系统。
原型法:并非所有的需求都能在开发前被准确的说明;项目参加者之间通常存在交流上的困难;需要实际的可供用户参与的系统模型;有合适的系统开发环境;反复是完全需要和值得提倡的,需求一旦确定就应该遵从严格的方法。
需求规格说明书SRS的需求验证也称为需求确认,其活动是为了确定以下几个方面的内容:
需求验证包括了需求评审和需求测试。
需求评审包括了:正式评审和非正式评审。需求验证是需要做用户签字确认,但往往实施起来比较困难,因为需求验证时签字就要负责任,它是验收的标准之一(此时的规格说明书SRS就是需求基线)。需求的评审需要用户的参与。
需求测试,不是运行类的测试而是设计测试用例进行测试,比如告诉你输入是什么输出是什么,所以更加接近于想像性测试,它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而,以功能需求为基础(SA方法)或者从用例派生出来(OO方法)的测试用例,可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例,但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例,即不是真正执行的测试用例,它们可以发现SRS中的错误、二义性和遗漏,还可以进行模型分析,以及作为用户验收测试的基础。在正式的系统测试中,还可以将它们细化成测试用例。
在软件需求工程中,需求管理贯穿于整个过程中,它的最基本的任务就是明确需求,并使项目团队和用户达成共识,即建立需求基线。另外,还要建立需求跟踪能力联系链,确保所有用户需求都被正确地应用,并且在需求发生变更时,能够完全地控制其影响范围,始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域,其目标是为软件需求建立一个基线,供软件开发及其管理使用,使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看,需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动,包括控制需求基线,保持项目计划与需求一致,控制单个需求和需求文档的版本情况,管理需求和联系链之间的联系,或管理单个需求和项目其他可交付物之间的依赖关系,跟踪基线中需求的状态。
需求开发的结果应该有项目视图和范围文档、用例文档和SRS,以及相关的分析模型。经评审批准,这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定,它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念,它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义,基线是指已经通过正式评审和批准的规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变更控制系统进行变化。在软件工程范围内,基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且已经经过正式技术评审而获得认可。例如,SRS文档通过评审,其中的错误已经被发现并纠正,则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》(GB/T 12505-1990)的规定,基线可以分为功能基线、指派基线和产品基线三种,通过评审后的SRS(软件需求规格说明书)属于指派基线。
在需求状态的变化中,项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求,如果不是通过有管理的处理过程,就有可能因为疏忽而被遗漏。同时,也应关注被交付的需求,因为可交付物是项目的成果体现,而可交付物的主要内容就是对需求的实现。
CCB,变更控制委员会,也成配置控制委员会
要让变更有序进行,首先需要有一个统一的单位来负责,这个单位一般叫变更控制委员会(Change
Control Board),也叫配置控制委员会(Configuration Control
Board)。CCB由项目干系人中有代表性的人员组成,人数没有限制,一个人也可以。CCB有能力在管理上做出承诺,对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构,一般不参与具体的变更执行工作。
常见的需求变更策略:
带有风险的做法有:①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。
变更产生的原因:①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。
SRS中的每个软件配置项的需求到其涉及的系统(或子系统)需求都要具有双向可追踪性。所谓双向跟踪,包括正向跟踪和反向跟踪,正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点;反向跟踪也称为逆向跟踪,是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
相关系统设计还可以参考:系分 - 系统设计
系统设计是系统分析的延伸与拓展。系统分析阶段解决“做什么”的问题,而系统设计阶段解决“怎么做”的问题。同时,它也是系统实施的基础,为系统实施工作做好铺垫。合理的系统设计方案既可以保证系统的质量,也可以提高开发效率,确保系统实施工作的顺利进行。
系统设计阶段又称为物理设计阶段,它是信息系统开发过程中一个非常重要的阶段。其任务是根据系统规格说明书中规定的功能要求,考虑实际条件,具体设计实现逻辑模型的技术方案,也就是设计新系统的物理模型,为下一阶段的系统实施工作奠定基础。
系统设计的主要内容包括概要设计和详细设计。概要设计又称为系统总体结构设计,它是系统开发过程中很关键的一步,其主要任务是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图。在概要设计中,将系统开发的总任务分解成许多个基本的、具体的任务,为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同,详细设计又可分为多种,例如,网络设计、代码设计、输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。
软件设计包括体系结构设计、接口设计、数据设计和过程设计。
软件架构 = 软件体系结构
架构设计就是需求分配,即将满足需求的职责分配到组件上。
相关架构设计还可以参考:软件架构设计
以上三条原则由著名用户界面设计专家Theo Mandel博士所创造,通常称之为人机交互的“黄金三原则”。另外,在设计用户界面时,还需要保证界面的合理性和独特性,有效进行组合,注重美观与协调;恰到好处地提供快捷方式,注意资源协调等。
结构化设计(Structured Design,SD)是一种面向数据流的方法,它以SRS和SA阶段所产生的数据流图和数据字典等文档为基础,是一个自顶向下、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构,分为概要设计和详细设计两个阶段,其中概要设计的主要任务是确定软件系统的结构,对系统进行模块划分,确定每个模块的功能、接口和模块之间的调用关系;详细设计的主要任务是为每个模块设计实现的细节。
概要设计又称为系统总体结构设计,它是系统开发过程中很关键的一步,其主要任务是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图。
系统结构图(Structure Chart,SC)又称为模块结构图,它是软件概要设计阶段的工具,反映系统的功能实现和模块之间的联系与通信,包括各模块之间的层次结构,即反映了系统的总体结构。
人们在解决复杂问题时使用的一个很重要的原则,就是将它分解成多个小问题分别处理,在处理过程中,需要根据系统总体要求,协调各业务部门的关系。在SD中,这种功能分解就是将系统划分为模块,模块是组成系统的基本单位,它的特点是可以自由组合、分解和变换,系统中任何一个处理功能都可以看成一个模块。
模块的四个要素:
前两个要素是模块的外部特性,即反映了模块的外貌;后两个要素是模块的内部特性。在结构化设计中,主要考虑的是模块的外部特性,其内部特性只做必要了解,具体的实现将在系统实施阶段完成。
在SD方法中,系统由多个逻辑上相对独立的模块组成,在模块划分时需要遵循如下原则:
面向对象的设计OOD是面向对象的分析OOA的延续,其基本思想包括抽象、封装和可扩展性,其中可扩展性主要通过继承和多态来实现。在OOD中,数据结构和在数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的集合,所以OOD方法是一种更接近现实世界、更自然的系统设计方法。
对象问的关系有:组合,聚合,继承等
Use-A依赖关系
IS-A继承关系
IS-PART-OF聚合(组合一种),聚合对应的语义是“is a member of”
在OOD中,可维护性的复用是以设计原则为基础的。常用的OOD中原则包括单一原则、幵闭原则、里氏替换原则、依赖倒置原则、组合/聚合复用原则、接口隔离原则和最少知识原则等。这些设计原则首先都是面向复用的原则,遵循这些设计原则可以有效地提高系统的复用性,同时提高系统的可维护性。
相关软件测试还可以参考:系分 - 系统测试与维护
测试是发现错误,调试是找出错误的代码和原因。
调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
调试的方法有:蛮力法、回溯法(从出错的地方开始,向回找)、原因排除法(找出所有可能的原因,逐一进行排除,具体包括演绎法、归纳法、二分法)。
软件的两种属性:外部属性指面向管理者和用户的属性,可直接测量,一般为性能指标。内部属性指软件产品本身的的属性,如可靠性等,只能间接测量。
McCabe度量法:又称为环路复杂度,假设有向图中有向边数为m,节点数为n,则此有向图的环路复杂度为m-n+2。
注意m和n代表的含义不能混淆,可以用一个最简单的环路来做特殊值记忆此公式,另外,针对一个程序流程图,每一个分支边(连线)就是一条有向边,每一条语句(语句框)就是一个顶点。
遗留系统(Legacy System)是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
对遗留系统评价的目的是为了获得对遗留系统的更好的理解,这是遗留系统演化的基础,是任何遗留系统演化项目的起点。主要评价方法包括度量系统技术水准、商业价值和与之关联的企业特征,其结果作为选择处理策略的基础。
在实施新旧系统转换时,转换的策略通常有三种:
数据迁移的主要方法大致有三种,分别是系统切换前通过工具迁移、系统切换前采用手工录入和系统切换后通过新系统生成。
数据迁移的实施可以分为三个阶段,分别是数据迁移前的准备、数据转换与迁移和数据迁移后的校验。其中准备工作要做好以下7个方面的工作:
在数据迁移完成后,需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查,同时数据校验的结果也是判断新系统能否正式启用的重要依据。可以通过以下两种方式对迁移后的数据进行校验:
【可理解性】是指通过阅读源代码和相关文档,了解软件的功能和如何运行的容易程度。
【可修改性】是指修改软件的难易程度。
【可测试性】是指验证软件程序正确的难易程度。
可测试性好的软件,通常意味着软件设计简单,复杂性低。因为软件的复杂性越大,测试的难度也就越大。
【可靠性】一个软件的可靠性越高,需要维护的概率就会越低。
【可移植性】是指将软件从一个环境移植到新的的环境下正确运行的难易程度。
软件运行环境的变化是软件维护的一种常见情形,可移植性好的软件会降低维护的概率
软件的维护并不只是修正错误,为了满足用户提出的增加新功能,修改现有功能以及一般性的改进要求和建议,需要进行完善性维护,他是软件维护的重要组成部分。