软件工程

原创已于 2024-12-18 20:21:51 修改 · 1k 阅读

15 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#软件工程

于 2024-12-12 00:06:21 首次发布

软件的定义

软件(Software)是由程序,程序的操作对象数据,文档和相关文件所组成的集合

程序(program)是一组指令集合

软件的分类

从不同角度出发,分类的方式亦不同,[如按软件规模分类为大中小型软件;按服务对象不同分为通用软件和定制软件;按工作方式分为实时软件,分时软件,交互式软件,批处理软件]

下面从功能的角度进行分类

应用软件

为用户提供特定服务的软件

如社交软件微信游戏软件英雄联盟办公软件Excel

系统软件

用以管理硬件资源并为应用程序提供运行环境的基础软件,例如操作系统Windows,Linux;设备驱动程序等

支撑软件(support software)

介于系统软件和应用软件之间,为应用软件的开发,运行,维护提供支持;对底层硬件及操作系统进行抽象封装,为上层开发提供接口,简化跨平台开发

比如:

中间件:

数据库中间件:如Oracle Middleware

消息中间件:如RabbitMQ Kafka

应用服务器:如Tomcat JBoss

数据库管理系统(DBMS):

如MySQL PostgreSQL MongoDB

软件开发工具:

比如:

集成开发环境(IDE):如Eclipse VS

版本控制工具:如Git SVN

编程语言运行时环境:

如Java运行环境JRE Python解释器

软件框架和库:

比如:

Web框架:如Spring Django

前端框架:如React Vue.js

系统管理工具(帮助管理和监控系统资源的软件):

如Zabbix Nagios

软件危机

生产力和人数不成正比

软件开发创造性很大,很接近于艺术,她介于艺术与工程之间的某一点,并逐步向工程一端漂移,但很难发展到完全的工程

产生原因

软件复杂性和规模的迅速增加

开发方法落后,缺乏系统化的工程方法,多依赖个人经验或临时解决方法

项目管理不足,缺乏科学的项目管理方法

缺乏模块化设计及复用机制,重复开发耗费大量资源

主要表现

软件开发需求难以精准定义,且需求可能频繁变化

随着项目复杂性的增加,开发成本及时间难以精准预测

软件存在缺陷,导致运行不稳定或难以满足用户需求

代码复杂,文档不全,开发者离职等原因使得软件维护困难

随着团队规模扩大,沟通管理成本增大,导致开发效率低下或分工不明确

软件适应性可扩展性差,难以适应技术环境及用户需求的快速变化

解决方法

引入前期的需求分析

引入工程学的系统化工程方法,强调规范化,模块化和过程控制

引入先进的开发模型,如瀑布模型,迭代模型,敏捷开发

引入组件化设计,模块化设计和复用机制

引入先进的自动化工具,如IDE,版本控制工具,自动化测试工具

采用科学的项目管理方法,如Scrum PMBOK,明确需求,分工,进度安排

引入软件测试,代码审查,质量管理机制提高软件可靠性

新的挑战

大型分布式系统开发的复杂性

人工智能和云计算系统的安全性与透明性问题

短开发周期和高质量要求之间的矛盾

软件工程

Bohm-Jacoponi提出:goto语句是有害的,并提出:所有程序都可以用顺序分支循环三种逻辑来实现,奠定了结构化编程的基础

定义

IEEE的定义:

将系统化,规范化,可量化的工程化方法应用于软件开发,运行,维护

软件生命周期(Software Life Cycle)

可行性分析(feasibility study)

通过对技术,经济,时间,资源等方面的评估,确定项目的可行性,避免在后续开发过程中遇到重大问题

需求分析阶段

收集分析定义用户需求,明确软件功能,性能和约束条件

系统设计阶段

根据需求分析的结果,设计软件架构和模块,并制定实现方案

分为

高层设计(架构设计):定义软件的总体架构,模块划分,接口和数据流

详细设计:详细描述各个模块的功能

编码阶段

根据设计文档,开发软件的各个模块

测试阶段

验证软件是否满足需求,是否存在缺陷

缺陷发现的越晚,修复成本越高

部署和交付阶段

将经测试的软件投入实际环境使用

运行和维护阶段

确保软件在实际运行中保持稳定,并维护软件

退役阶段

软件不符合需求或过时时,进行退役

软件开发模型(Software Development Models软件过程模型/软件生命周期模型)

软件开发的框架,用以指导软件开发过程中的各个阶段

瀑布模型(Waterfall Model)

顺序式线性开发,前一个阶段结束后才可进入下一个阶段,可回溯性较差,对需求变化的适应性差

(快速)原型模型(Prototyping Model)

通过快速构建原型获得用户反馈并不断改进,直至符合需求

增量模型(Incremental Model)

将软件系统模块化,各个模块(增量组件)独立开发并逐步交付,系统功能逐步增加

可对各模块进行优先级排序,优先开发核心组件

螺旋模型(Spiral Model)

结合瀑布模型和原型模型(增量模型),增添了风险评估

每个周期分为规划,风险评估,实施工程(渗透瀑布模型的各个阶段),用户评估四个阶段

喷泉模型(Fountain Model)

允许开发活动在各阶段并行执行,且允许返回之前的阶段进行修改,灵活性高,适用于需求和设计不断变化的项目

基于组件的开发模型(Component-Based Development Model,CBD)

组件(Component):

封装了内部实现细节,通过接口(Interface)与外部交互的独立的可复用可替换(组件可以被功能相似的另一个组件替换)的软件单元

组件可以是函数库,服务模块,类库,微服务等

组件库(Repository):存储大量可复用的,验证过的组件,供开发者直接调用,以实现基于组件的开发

开发流程(不全):

组件设计:

为组件定义接口(包括输入输出交互协议);设计实现组件内部逻辑,且保证与其他组件兼容

组件测试:

单独测试每个组件,验证接口是否符合规范,确保可以与其他组件集成,确保其满足需求

集成后进行系统级测试,确保组件间的兼容性和系统的整体性能

统一软件开发过程模型(Unified Process,UP)

一种基于面向对象思想的软件开发模型,Rational Unified Process,RUP是其最著名的实现版本

核心思想:

迭代和增量开发:软件通过多个迭代周期逐步开发,每个周期交付一个功能增强的系统版本

以架构为核心:强第哦啊建立稳定的软件架构,早期开发重点是设计和验证系统的核心架构

用例驱动:以用例(Use Case)作为需求分析和系统设计的核心

UP的四个阶段:

Inception(初始阶段)

成果:项目愿景文档(Vison Document) 初步的用例模型

Elaboration(细化阶段)

成果:稳定的用例模型

Construction(构建阶段):实现所有用例,并集成为一个完整的系统

Transition(移交阶段):系统交付用户,完成最终部署

用例(Use Case):

从用户视角出发,定义了用户为实现目标而与系统交互的一系列动作或行为

用例常用于需求分析阶段,以捕获系统的功能需求

亦为功能测试提供了直接参考,通过测试用例亦验证系统是否满足需求

用例的核心要素:

参与者(Actor):与系统进行交互的外部实体,可能是用户,设备,或其他系统

主要参与者:主动发起交互的实体,例如登录系统的用户

次要参与者:提供辅助功能的实体,例如认证服务器

用例名称:简洁明了地描述用例的功能,例如"用户登录"或"提交订单"

用例之间的关系:

包含关系(Include):一个用例中包含另一个用例,例如"用户注册"包含"验证电子邮箱"

扩展关系(Extend):扩展一个用例(父用例)的行为,例如"高级用户登录"是对"用户登录"的扩展

泛化关系(Generalization):例如"用户登录"是对"高级用户登录"的泛化/一般化,反之为特殊化

触发条件:描述触发用例执行的事件,例如"用户提交登录表单"(桐庐:事件监听)

用例的表达方式:

自然语言描述:适用于需求文档或非技术人员阅读

用例图(Use Case Diagram):

一种图形化的表示方法,用于展示参与者和用例之间的关系,用例和用例之间的关系

核心元素:

椭圆:表示用例

小人图标:表示参与者

线条:表示参与者和用例之间的交互

敏捷开发模型(Agile Model)

提倡灵活快速高效的开发方法,强调与用户的持续沟通与反馈

采用小的开发周期进行迭代

敏捷软件开发宣言(Manifesto for Agile Software Development)

四个核心价值观:

1:个体和交互高于流程和工具

2:可运行的软件高于详尽的文档:对用户而言,更多会通过直接运行软件来了解软件的功能,而非阅读文档,因此优先提供可运行的软件,并不断迭代

3:与客户的协作高于合同谈判

更重视与客户的持续沟通协作,而非僵化地执行合同条款,例如开发初期客户很难精确完整表达其需求,且需求会经常变更

4:响应变化高于遵循计划

敏捷软件开发联盟(Agile software development alliance),简称"敏捷联盟"定义了12敏捷原则:

1:客户满意是最优先事项,通过尽早持续交付有价值的软件来实现

2:需求变更可能发生在整个软件开发过程中,我们要欢迎需求的变化,并积极得适应

3:持续交付可用软件,交付周期越短越好

4:业务人员和开发人员在项目过程中必须持续合作

5:Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done

激励团队里的每一个个体,给予他们支持,并信任他们可以完成任务

6:面对面沟通是信息传递的最有效方式

7:可工作软件是衡量进度的主要标准

8:敏捷开发强调可持续性,因此开发团队应保持长期持续的开发速度

9:Continuous attention to technical excellence and good design enhances agility

对技术及设计优越性的持续关注有利于提升敏捷性

10:尽量减少工作量

11:最好的架构,需求,设计来自于组织团队

12:每隔一段时间,应该反思如何提高效率,并作出相应的调整

极限编程(Extreme Programing,XP)

敏捷模型包括多种实践方法,比如极限编程,自适应软件开发(Adaptive Software Development,ASD),动态系统开发方法(Dynamic System Development Method,DSDM),Scrum,Crystal,特征驱动开发(Feature Driven Development,FDD)

极限编程:通过高质量代码和持续的用户反馈快速始应变化的需求

极限编程中一个流程:Pair Programing:两名开发人员协作编写代码,一个负责编写,另一个负责审查,实时交流

软件开发方法论(Software Development Methodology)

结构化方法(Structured Methodology)

从系统的整体需求开始,自顶向下将系统分解为较小的功能模块

主要工具:

结构化图(Structured Chart):用以表示系统各模块间的关系

数据流图(DFD,Data Flow Diagram):

基本元素:

过程(Progress):即功能模块或曰处理模块,过程会接收数据,处理后再输出数据

通常用一个圆形或一个矩形框表示

数据流(Data Flow):用箭头表示数据在系统内的流动

数据存储(Data Store):指系统中任何形式的数据保存或数据库,通常用一对平行线表示

外部实体(External Entity):指系统之外与系统交互的人员组织或其他系统,通常用方框表示

DFD的层次结构:

层次越高,抽象程度越大

一级DFD(Level 0 DFD):表示整个系统的高级视图,主要描述系统的输入输出外部实体和主要处理过程

二级DFD(Level 1 DFD):在一级DFD的基础上,进一步细化每个处理过程

三级DFD及更高层次:继续分解过程,直至系统被详细描述为多个子过程

面向数据结构方法(Data Structure Oriented Methodology)

以数据结构为核心,系统的设计与实现紧密围绕数据的组织和操作展开,功能的设计是为了满足数据操作需求,这种方法使用于以数据存储,查询,处理为主要目的的系统,如数据库管理系统,信息管理系统

数据分析:分析系统的业务需求,确定系统中需要处理的主要数据类型和数据关系,构建数据字典,用以定义系统中所有数据的名称类型长度约束方式等,确保数据的规范化

数据结构设计:根据需求设计系统的核心数据结构(数据,链表,树,图等)以及复杂的关系型数据模型,确定数据的存储形式(如文件系统,数据库表等)和访问方式

优化:使用索引,缓存,事务等技术提升数据操作效率

工具:

实体关系图(ER图):描述系统中实体(数据)及其关系的图形化工具,实体(如用户,订单)对应系统中的数据表,关系(如一对多)决定数据的连接方式

面向对象方法(Object-Oriented Methodology)

将系统中的数据和功能紧密结合,模拟现实世界中的事物(对象)

对象具有属性(数据)和行为(方法),是系统功能和数据的统一体,系统中的每一个实体都被看作是一个对象,对象之间通过消息传递进行交互,完成系统的功能

类是对象的模板,定义了对象的属性和行为;对象是类的实例,通过类的定义以创建具体的对象

三大特性:

封装(Encapsulation):将数据和操作封装在对象内部,隐藏实现细节,只提供外部访问接口

继承(Inheritance):子类可以继承父类的属性和行为,支持代码复用

多态(Polymorphism):

面向对象方法的开发过程:

面向对象分析(OOA,Object-Oriented Analysis):

识别系统中的对象,属性二号行为

确定对象之间的关系和交互,建立用例图

输出:问题域模型,用例模型

面向对象设计(OOD,Object-Oriented Design):

定义类及其属性,方法,接口

设计类之间的交互和依赖关系,组织类的继承关系

输出结果:类图,交互图(如时序图和协作图)

面向对象实现(OOP,Object-Oriented Programming):
使用面向对象编程语言(如Python Java C++)实现设计中的类和对象

面向对象的模型:

静态模型:

描述系统的结构,如类之间的关系,对象的组成

常用工具:类图

动态模型:

描述系统的行为和对象之间的交互,如方法调用的顺序

常用工具:时序图,活动图

功能模型:

描述系统的功能和数据流动

常用工具:用例图

主要工具和技术:

UML(Unified Modeling Language)

UML是一种标准的面向对象建模语言,用于绘制系统的各种模型,包括类图,用例图,时序图

设计模式(Design Patterns)

面向对象设计中的常见解决方案,例如:单例模式,工厂模式,观察者模式

形式化方法(Formal Methods)

基于数学和逻辑对软件系统进行严谨分析

形式化方法的主要阶段:

形式化规范:

用形式化语言描述系统的需求和行为

常用语言包括:Z语言,VDM(Vienna Development Method),B方法等

形式化设计:

基于形式化规范,进行系统的分层设计和详细建模,描述系统各模块的逻辑和交互

验证和推理

使用逻辑推理或自动化工具验证系统,如安全性,死锁避免等,验证方法包括模型检查(Model Checking,通过枚举系统的所有可能状态,自动验证系统是否满足指定属性如安全性和活性,常用工具:SPIN,NuSMV),定理证明(Theorem Proving,基于数学推理,手动或使用工具如Coq,Isabelle验证系统正确性)等

实现与测试

将形式化设计实现为代码,通过测试验证实现是否满足需求

形式化方法的使用场景:

安全关键系统:如航空控制,核电站控制系统,医疗设备控制

高可靠性系统:如银行交易系统,通信协议,嵌入式系统

并发和分布式系统:对事件同步,数据一致性要求较高的系统

协议验证:如网络通信协议,加密协议正确性的验证

软件开发工具

按照功能划分:

可视化建模工具,程序开发工具,自动化测试工具,文档编辑工具,配置管理工具,项目管理工具

按照支持的范围划分:

窄支持工具支持特定任务,一般称为工具

较宽支持工具一般由多个工具集合而成,称为工作台

一般支持工具包含多个工作台,称为环境

常用的CASE(Computer-Aided Sofeware Engineering)工具:

需求分析与系统设计阶段

面向通用软件设计的Microsoft Visio

面向对象软件设计的Rational Rose

用于数据库设计的Power Designer

Enterprise Architect

作用:简化UML图绘制,模型转换功能等等

编码阶段

集成开发环境(IDE),例如IDEA

测试阶段

使用自动化测试工具进行测试

比如单元测试工具JUnit CUnit CppUnit

比如功能测试工具Win Runner 性能测试工具LoadRunner 测试管理工具TestDirector

Web服务测试工具QTester(QT)

配置管理:Microsoft VSS CVS SVN Git

项目管理:Microsoft Project

其他工具:

原型设计:Dreamweaver

在线协作办公系统:Microsoft Office Online

在线协作软件设计平台:ProcessOn

华丽的分割线

可行性研究

确保项目在技术,经济,操作等方面具备可行性,避免资源浪费

明确项目的范围和限制,为需求分析奠定基础

技术可行性

经济可行性:分析项目的成本和效益

投资回报率(ROI,Return on Investment) 成本效益分析(CBA,Cost-Benefit Analysis)

操作可行性/组织可行性:评估项目是否能融入现有的组织环境

法律和社会可行性

时间可行性

可行性研究的输出:

可行性研究报告

可行性研究报告的内容:

项目背景:项目的起因,目标和范围

现状分析:现有系统或解决方案的缺陷

需求概述:用户的核心需求

可行性分析:技术经济操作等方面的评估结果

风险分析:项目可能面临的主要风险及其应对措施

结论和建议:是否建议启动项目,并提出下一步工作建议

需求分析

明确用户需求,消除需求中的歧义,遗漏和矛盾,为设计提供可靠依据

明确系统边界,防止需求膨胀或范围模糊

为测试提供依据,确定测试用例和验收标准

需求分类

功能需求(Functional Requirements)

功能需求描述系统必须具备的功能和行为,通常直接来源于用户需求,与用户的直接操作相关

如用户通过用户名和密码登录,系统的增删改查功能

可通过测试验证其实现

非功能需求(Non-Functional Requirements)

非功能需求不涉及具体功能点,描述系统运行质量,包括系统的性能(如系统支持1000个并发用户,响应时间不得超过2秒),可靠性(如系统必须保证99.99%的在线时间),安全性(如密码必须加密存储,登录失败5次需锁定账户),可扩展性(如系统应支持未来增加的支付方式,如数字货币),兼容性(如系统必须兼容主流浏览器)

通常非功能需求很难测试,需要性能分析,压力测试等手段验证

约束条件(Constraints):

系统必须遵守的外部限制,可能源于客户要求,硬件,法律,预算等

如:

系统必须部署在客户提供的服务器上,操作系统为Linux

数据库必须使用MySQL