1. 面向对象基本思想: 分析、设计、编程
程序员
OO方法认为,客观世界是由各类各样的对象组成的,每种对象都有各自的内部状态和运动规律,不一样的对象之间的相互做用和联系就构成了各类不一样的系统。当咱们设计和实现一个客观系统时,如能在知足需求的条件下,把系统设计成由一些不可变的(相对固定)部分组成的最小集合,这个设计就是最好的。而这些不可变的部分就是所谓的对象。数据库
面向对象中的三种模型编程
面向对象分析方法:安全
手法架构 |
Shlaer &Mellor 法框架 |
Coad& Yourdon法分布式 |
OMT法模块化 |
Booch法函数 |
概述工具 |
(S&M方法)将意义模型做为基础 |
组合E-R图、S&M方法、OOP及知识库系统的概念而发展而来 |
从结构化分析继承数据流和状态转换图,对象、建摸受E-R图等的影响 |
扩充了Ada方法论的Booch 法(HOOD, OOSD),也受E-R,JSD法的影响 |
对象的静态关系 |
信息模型(information Model) |
对象图 (Object Diagram) |
对象模型(Object Model) |
静态模型(Static Model) |
对象的动态关系 |
状态模型 (State Model) |
对象状态图 (Object State Diagram) |
动态模型 (Dynamic Model) |
动态模型 (Dynamic Model) |
功能 |
过程模型 (Process Model) |
服务图 (Service Chart) |
功能模型 (Functional Model) |
-------- |
面向对象设计原则:
把分析阶段获得的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程
开-闭原则(The Open-Closed Principle, OCP):软件实体(类、模块、函数等)能够扩展(扩展是开放),可是不能够修改(更改是封闭的)
单一职责原则(Single Responsibility Principle,SRP):仅有一个引发它变化的缘由
里氏代换原则(Liskov Substitution Principle,LSP):子类必须可以替换掉其父类。 LSP是继承复用的基石,只有当衍生类能够替换其基类,软件功能或行为不受影响时,基类才能真正被复用
依赖倒转原则(Dependence Inversion Principle ,DIP):高层模块不该该依赖低层模块,即抽象不该该依赖细节,细节依赖抽象。强调接口编程,不要对实现编程
接口隔离原则 ( interface separate principle, ISP ):使用多个专门的接口比使用单一的总接口要好。
合成/聚合复用原则(Composition/Aggregation Reuse Principle,CARP):尽可能使用合成/聚合( “has a”的关系),尽可能不使用类继承(“is a”的关系),有助于保持每一个类的封装
迪米特法则(Law of Demeter,LoD):若是两个类没必要彼此直接通讯,那么这两个类就不该当发生直接的相互做用。类之间的耦合越弱,就越有利于复用。
面向对象系统的构造
面向对象分析
分析是提取和整理用户需求,并创建问题域精确模型的过程。
面向对象分析通常须要创建3个模型(功能模型、对象模型和动态模型)并定义相应的服务
对象是OO方法的主体,对象至少应有如下特征:
l)模块性。即对象是一个独立存在的实体,从外部能够了解它的功能,但其内部细节是“隐蔽”的,它不受外界干扰。对象之间的相互依赖性很小,于是能够独立地被其它各个系统所选用。
2)继承和类比性。事物之间都有必定的相互联系,事物在总体结构中都会占有它自身的位置。在对象之间有属性关系的共同性,在OO方法学中称之为继承性次结构是靠继承关系维系着的。
3)对象是一个被严格模块化了的实体,称之为封装(encapsulation)。这种封装了的对象知足软件工程的一切要求,并且能够直接被面向对象的程序设计语言所接受。
对象的行为经过操做展现,外界不能够直接访问其内部属性(封装性),操做的实现对用户透明
类是对具备相同内部状态和外部行为对象结构的描述,它定义了表示对象状态的实例变量集和表示对象行为的方法集。子类能够继承父类的实例变量和方法、重载父类的某个行为(虚函数),同时还能够定义新的变量和方法。
消息传递是对象间唯一的交互方式
2. 软件需求:业务需求,用户需求,功能需求
业务需求:反映组织机构或客户对系统、产品的归纳性要求,包括所要达到的业务目标,由项目视图与范围文档说明。
用户需求:描述用户使用系统而要完成的各类任务,由用例(use case)文档或方案脚本说明 。
功能需求:定义开发人员必须实现的软件功能,它源于用户需求,是软件需求说明书中重要的组成部分。
3. 软件工程定义: 是什么样的学科。
软件工程是从计算机科学中的一个学科方向发展成为与之并重的一门独立学科,重点研究如何以系统的、可控的、高效的方式开发和维护高质量软件的问题。
4. 软件的可维护性
软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。
决定可维护性的因素:
1).系统的大小
2).系统的年龄
3).结构合理性
可维护性可经过7个质量特性来衡量:
1).可理解性
2).可测试性
3).可修改性
4).可靠性
5).可移植性
6).可以使用性
7).效率
5. 软件过程
软件过程(Software Procedure) 是指软件整个生命周期,从需求获取,需求分析,设计,实现,测试,发布和维护一个过程模型。 一个软件过程定义了软件开发中采用的方法,但软件工程还包含该过程当中应用的技术——技术方法和自动化工具。过程定义一个框架,为有效交付软件工程技术,这个框架必须建立。软件过程构成了软件项目管理控制的基础,而且建立了一个环境以便于技术方法的采用、工做产品(模型、文档、报告、表格等)的产生、里程碑的建立、质量的保证、正常变动的正确管理。
软件过程可归纳为三类:基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运做过程,维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过程以及培训过程。
6.软件的风险管理
风险识别、风险分析和评估 、风险管理策略、风险解决和风险监控五部分,它能让风险管理者主动“攻击”风险,进行有效的风险管理。 在项目管理中,创建风险管理策略和在项目的生命周期中不断控制风险是很是重要的。
7.软件测试用例有那2大类
经常使用的软件测试方法有两大类:静态测试方法和动态测试方法。
静态测试就是静态分析,对模块的源代码进行研读,查找错误或收集一些度量数据,并不须要对代码进行编译和仿真运行。静态测试采用人工检测和计算机辅助静态分析手段进行检测。
动态测试是经过观察代码运行时的动做,来提供执行跟踪、时间分析,以及测试覆盖度方面的信息。动态测试经过真正运行程序发现错误。经过有效的测试用例,对应的输入/输出关系来分析被测程序的运行状况。
八、软件中遗留的错误数量和已经发现的错误数量之间是成“正比”的。
九、3种过程模型中: 敏捷过程模型和传统模型的区别
敏捷开发是近些年兴起的一种软件开发与管理的思想,以其灵活性、操做性获得软件行业的普遍关注。敏捷开发方法是一组开发方法的统称,包括极限编程、Scrum、精益开发和动态系统开发方法(DS-DM)、 特征驱动开发(FDD)等。它的基本原则有迭代式开发、增量交付、互动式开发、持续集成等。在软件开发 过程当中,敏捷开发具备开发精确、高质量、高速度、高投资回报、高效率等优势,所以敏捷开发方法愈来愈受到 广大程序员的青睐。敏捷开发是一种以人为核心、迭代、按部就班的开发方法。在敏捷开发中, 软件项目的构建被切分红多个子项目,各个子项目的成果都通过测试,具有集成和可运行的特征.换言之, 就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程当中软件一直处于可以使用状态。
敏捷开发路线图以下 :
1. Test-Driven Development,测试驱动开发。
2. Continuous Integration,持续集成。
3. Refactoring,重构。
4. Pair-Programming:结对编程。
5. Stand up,站立会议。
6. Frequent Releases,小版本发布.
7.MinimalDocumentation,较少的文档。
8.CollaborativeFocus,以合做为中心,表现为代
码共享。
9.CustomerEngagement,现场客户。
10。AutomatedTesting,自动化测试。
11.AdaptivePlanning,可调整计划。
敏捷软件开发宣言:
个体和交互赛过过程和工具;
能够工做的软件赛过面面俱到的文档;
客户合做赛过合同谈判;
响应变化赛过遵循计划
10.软件工程定义,集合实际谈谈软件工程的理解
(1)软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把通过时间考验而证实正确的管理技术和当前可以获得的最好的技术方法结合起来。它是从计算机科学中的一个学科方向发展成为与之并重的一门独立学科,重点研究如何以系统的、可控的、高效的方式开发和维护高质量软件的问题。
(2)当技术尚未发展到必定程度时,软件的开发就彻底是我的英雄主义的或是手工做坊式的开发。一个好的编程人员,能够独立制做出软件。但技术的日益完善,所处理的问题日益复杂对软件的开发提出了更高的要求,单一的做战方式不能知足软件开发的复杂度。这也就是60年代的软件危机。必须改变手工做坊式的开发方法,采起工程化的开发方法和工业化的生产技术。这是软件工程应运而生。简单的逻辑上讲,软件工程就是将现实世界中复杂无序的高层问题,经过人的做用,转化为计算机(机器)能够解决的简单有序的底层问题。因为有了“现实复杂”到“机器简单”的过程,软件工程就不只仅是单一的编程过程了。它包括系统分析->建模->概要设计->详细设计->编码->测试->维护。编码能够理解为编程,这个只占总时间的20%。编程只是一小部分。若是说把软件工程比做建筑业的话,是讲的是怎么进行有效组织顺利完成目标,那么编程只是工程设计到的一项技能,如同建筑中砌砖,讲究如何把砖砌的好。
11.软件有哪些质量特性如何在软件开发是保持这些质量特性
(1)功能性:是指当软件在指定条件下使用,软件产品知足明确和隐含要求功能的能力。
适合性:是指软件产品与指定的任务和用户目标提供一组合适的功能的能力。
准确性:是指软件产品具备所需精确度的正确或相符的结果及效果的能力。
互操做性:是指软件产品与一个或多个规定系统进行交互的能力。
保密安全性:是指软件产品保护信息和数据的能力,以使未受权的人员或系统不能阅读或修改这些信息和数据,但不拒绝受权人员或系统对其的访问。
功能依从性:是指软件产品依附与同功能性相关的标准、约定或法规以及相似规定的能力。
(2)可靠性:在指定条件下使用时,软件产品维持规定的性能级别的能力。
成熟性:是指软件产品避免因软件中错误发生而致使失效的能力。
容错性:是指在软件发生故障或违反指定接口的状况下,软件产品维持规定的性能级别的能力。
易恢复性:是指在失效发生的状况下,软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
可靠性依从性:是指软件产品依附与同可靠性相关的标准、约定或法规以及相似规定的能力。
创建以可靠性为核心的质量标准。选择适应的开发方法。最大限度地重用现有的成熟软件。使用开发管理工具。增强测试。容错设计。
(3)易用性:是指在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力。
易理解性:是指软件产品使用户能理解软件产品是否合适以及如何能将软件用于特定的任务和使用环境的能力。
易学性:是指软件产品使用户能学习它的能力。
易操做性:是指软件产品使用户能操做和控制它的能力。
吸引性:是指软件产品吸引用户的能力。
易用性依从性:是指软件产品依附与同易用性相关的标准、约定、风格指南或法规以及相似规定的能力。
(4)效率:是指在规定条件下,相对于所用资源的数量,软件产品可提供适当的性能的能力。
时间特性:是指在规定条件下,软件产品执行其功能时,提供适当的响应时间和处理时间以及吞吐率的能力。
资源利用性:是指在规定条件下,软件产品执行其功能时,提供合适的数量和类型的资源的能力。
效率依从性:是指软件产品依附与同效率相关的标准或约定的能力。
(5)维护性:是指软件产品可被修改的能力,修改可能包括修正,改进或软件适应环境、需求和功能规格说明中的变化。
易分析性:是指软件产品诊断软件中的缺陷或失效缘由,以及断定待修改的部分的能力。
易改变性:是指软件产品使指定的修改能够被实现的能力。
稳定性:是指软件产品避免因为软件修改而形成意外结果的能力。
易测试性:是指软件产品使已修改软件能被确认的能力。
维护性依从性:是指软件产品依附与同维护性相关的标准或约定的能力。
在需求分析、软件设计、软件代码、软件系统交付、软件维护等每一个阶段作好的审查和复审工做,以提升软件的可维护性。
(6)可移植性:是指软件产品从一种环境迁移到另外一种环境的能力。
适应性:是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段,就可能适应不一样的指定环境的能力。
易安装性:是指软件产品在指定环境中被安装的能力。
共存性:是指软件产品在公共环境中同与其分享公共资源的其余独立软件共存的能力。
易替换性:是指软件产品在环境相同、目的相同的状况下替代另外一个指定软件产品的能力。
可移植性依从性:是指软件产品依附与同可移植性相关的标准或约定的能力。
尽可能用高级语言编写系统中对效率要求不高的部分,统一高级语言,采用系列机,模拟与仿真、写跨平台代码、多用开源库。
12. 软件测试有哪些阶段? 每一个阶段有哪些目标? 采用哪些技术?
按照开发阶段划分,软件测试可分为单元测试、集成测试,系统测试和验收测试.
(1)单元测试:目标针对每一个单元的测试,以确保每一个模块能正常工做为目标。可使用junit等一些工具,或其余一些代码覆盖率工具帮助分析测试用例的覆盖程度。
(2)集成测试:对已测试过的模块进行组装,进行集成测试。目的在于检验与软件设计相关的程序结构问题。功能性测试。使用黑盒测试技术针对被测模块的接口规格说明进行测试。非功能性测试。对模块的性能或可靠性进行测试。
(3)系统测试:检验软件产品可否与系统的其余部分(好比,硬件、数据库及操做人员)协调工做。
a、 为项目指定一个测试工程师负责贯彻和执行系统测试活动;
b、 测试组向各事业部总经理/项目经理报告系统测试的执行情况;
c、 系统测试活动遵循文档化的标准和过程;
d、 向外部用户提供经系统测试验收经过的预部署及技术支持;
e、 创建相应项目的(BUG)缺陷库,用于系统测试阶段项目不一样生命周期的缺陷记录和缺陷状态跟踪;
f、 按期的对系统测试活动及结果进行评估,向各事业部经理/项目办总监/项目经理汇报/提供项目的产品质量信息及数据;
(4)验收(用户)测试:检验软件产品质量的最后一道工序。主要突出用户的做用,同时软件开发人员也应有必定程度的参与。
经过文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试等来实现。
13.什么是面向服务的方法? SOA 面向服务的架构分为那几个层次?
(1)它将应用程序功能做为服务发送给最终用户或者其余服务,采用表示的标准方式实现。它是一个组件模型,它将应用程序的不一样功能单元(称为服务)经过这些服务之间定义良好的接口和契约联系起来。
(2)WSDL,UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP,做为传输层,用来在消费者和服务提供者之间传送消息。
1四、软件过程的评估有哪些内容? 有哪些评估方式和类型?
软件过程评估的内容有:软件需求获取、分析、开发等能力;项目计划能力..项目监督和控制能力..合同管理能力..软件度量指标设定、度量工具和方法..软件质量保证和管理流程、手段和方法等..技术开发、革新、创新.产品的定义、设计、实现..产品集成,项目集成管理..组织过程定义、调整和改进的能力。配置管理、维护、风险识别、控制和管理。
评估方式: 自我评估包括“ 以团队为基础的评估”和“持续型评估”.
评估类型:
A类评估。全面综合的评估方法,要求在评估中全面覆盖评估中所使用的模型,而且在评估结果中提供对组织的成熟度等级的评定结果。
B类评估。在开始时作部分自我评估,并集中于须要关注的过程域。不评定组织的成熟度等级。
C类评估,也称为快估。主要是检查特定的风险域,找出过程当中的问题所在。
15.微软解决方案框架是什么? MSF 有哪些子过程(阶段内容)?
微软解决方案框架结构(MSF)是“一组创建、开发和实现分布式企业系统应用的工做模型、开发准则和应用指南”。它帮助企业融合商业和技术的目标,下降采用新技术后系统总体的费用,以及成功的应用微软技术整合商业过程的方法。
构思阶段(Envisioning):
一、目标:建立一个关于项目的目标、限定条件和解决方案的架构
二、团队的工做重点
a)肯定业务问题和机会
b)肯定所需的团队技能
c)收集初始需求
d) 建立解决问题的方法
e)肯定目标、假设和限定条件
f) 创建配置与变动管理
三、交付成果
a) 远景/范围文档
b) 项目结构文档
c) 初始风险评估文档
计划阶段(Planning):
一、目标:建立解决方案的体系结构和设计方案、项目计划和进度表
二、团队重点
a) 尽量早地发现尽量多的问题
b) 知道项目什么时候收集到足够的信息以向前推动
三、交付成果
a) 功能规格说明书
b)主项目计划
c)主项目进度表
开发阶段(Development):
一、目标:完成功能规格说明书中所描述的功能、组件和其余要素
二、团队主要工做
a) 编写代码
b)开发基础架构
c)建立培训课程和文档
d)开发市场和销售渠道
三、交付成果
a)解决方案代码
b)构造版本
c) 培训材料
d) 文档(包括部署过程、运营过程、技术支持、疑难解答等文档)
e)营销材料
f) 更新的主项目计划、进度表和风险文档
稳定阶段:
一、目标:提升解决方案的质量,知足发布到生产环境的质量标准。
二、团队的工做重点
a) 提升解决方案的质量
b)解决准备发布时遇到的突出问题
c) 实现从构造功能到提升质量的转变
d)使解决方案稳定运行
e)准备发布
3.交付成果
a)试运行评审
b)可发布版本(包括源代码、可执行文件、脚本、安装文档、最终用户帮助、培训材料、运营文档、发布说明等)
c)测试和缺陷报告
d)项目文档
部署阶段(Deploying):
1.目标:把解决方案实施到生产环境之中
2.团队的工做重点
a) 促进解决方案从项目团队到运营团队的顺利过渡
b)确保客户承认项目完成
3.交付成果
a)运营及支持信息系统
b)全部版本的文档、装载设置、配置、脚本和代码
c)项目收尾报告
微软模式适合于大企业,由于微软有无可比拟的人力资源优点。