个人认为如果掌握软件工程相关知识,代码审计会更清晰,更具全局观
以下的英文内容均引用自 《软件工程》[罗杰] 的英文原版
1.Software Process:软件过程
强调的是整个软件开发过程;
软件过程是一种规范化和组织化的方法,用于管理和指导软件项目的全生命周期,包括需求分析,设计,编码,测试,部署,维护
1.1 过程模型
研究的是整个软件开发的流程
瀑布
快速原型
增量
....
2.Modeling:建模
以下才是分析软件的重点
建模的目的是为了更好的展示
2.1 需求分析
需求模型
数据模型 :用实体-联系图,UML类图表示
功能模型 :数据流图(基础),顺序图,
行为模型:状态图(responds to external events ) 活动图(responds to internal events)
不同阶段,可以用同种类型的模型,如体系结构设计(分析) 也可以用功能模型,行为模型
实际审计软件时,在“需求分析”阶段我关注的主要是官网的提供的功能展示
2.2 设计
Design Concept
Abstraction
Architecture :体系结构,架构
Patterns
目的:(1)模式是否适用于当前的工作;
(2)模式是否能够复用(因此节约设计时间);
(3)模式是否能够用于指导开发一个相似的但功能或结构不同的模式。
Separation of Concerns
Modularity
Information Hiding
Functional Independenc
Stepwise Refinement:逐步细化
Refactor
不改变 代码(或设计)的外部行为,但是改善内部的结构
Design Model
建模原型:
为了适配软件分析,我重新绘制了适用于软件分析的模型
设计阶段被划分成组件级别设计,和类级别设计
以后分析软件就可以用以上的两个维度去分析,且可以挑选几个(View,Abstraction) 坐标 去分析
Abstraction dimension
需求分析阶段(抽象的功能描述)
设计阶段 :Component-Based ; Class-Based;
实现阶段
Process dimension
体系结构(软件架构)
接口元素:用户接口(前端页面UI) ;外部接口(整个软件对外的接口,如作为第三方被其他系统调用);内部接口(体系机构内部构件之间的接口,构件内部类之间的接口)
接口元素非常重要,
接口是独立的,接口可以由调用方提供,也可以由实现方提供,前者相当于对外提供一种规范,如果想要被调用就必须实现调用方指定的规范,后者相当于对外提供功能的调用接口,如果想要调用我的功能必须调用我所提供的接口
软件由多个功能模块组成,模块有大有小,有主有次。
接口 是 “规范”的具体形式,且定义了功能
同时接口不是说一定是Interface类型才行,有时候抽象类,xxxUtils也是实际意义上的接口
在某个完整的系统中,一个组件(软件)既可以是接口的调用方,也可以是实现方,两者身份可以单独存在,也可以同时存在,
如此才能与其他软件 双向的交互”交互“,(适配器实现跨接口交互), 比如对于Servet 与Filter,Tomcat 是调用方(Servlet.service(),Filter.doFilter()),而Application是实现方,而对于Request: Application是调用方而Tomcat是实现方(HttpServletRequest)
构件级设计:具体的组件分布,联系(可以看作是体系结构的细化)
包结构
流程
- 其他:根据需要自行扩展
3. Architecture Design :Component-Based
体系机构的设计考虑了架构风格,构件的结构和属性以及系统内部构件的内部关系
It considers the architectural style that the system will take, the structure and properties of the components that constitute the system,and the interrelationships that occur among all architectural components of a system. --163
3.1 Architecture Style
体系结构风格 描述 系统类别,包括
-- p169
(1)一组执行系统所需功能的构件(例如,数据库、计算模块);
(2)一组实现构件间“通信、合作和协调”的连接件;
(3)定义构件如何集成为系统的约束;
(4)能够使设计者通过分析系统组成元素的已知属性来理解系统整体性质的语义模型
分类
Data-Centered
Data-flow
Main program/subprogram
Object-oriented
Layered
eg:MVC
3.2 视图模型
解决了如何表示软件架构,即如何对软件架构建模的问题
根据建模的侧重点不同分成了多重模型
界限不是很清晰,有时候不同类型的UML图有多种视图模型的影子
模型分类
结构模型
以构件(Component),连接件(Connector)和其他概念来刻画体系结构,上图的mvc就有描述Controller,Model,View的等组件动态模型 描述系统大颗粒行为性质,如上图mvc的描述了整个系统的行为,
过程模型
步骤,顺序,eg:时序图功能模型
功能模型认为体系机构由一组功能构件按照层次组成,下层向上层提供服务,如上面的层次结构图(9-5)就是一种功能模型
3.3 分析方法:
==分析整个软件的外部接口,+软件的内部接口(构件的外部接口)从而确定整体功能设计==
找到软件内部接口对应的组件 ,观察组件的分布
逐个分析组件,从而得出组件之间的关系
该方法在构件分析中同样适用,只是颗粒度不同而已
4. Component Design : Class-Based
构件是什么?
构件是相对概念,一个软件可以是一个构件,一个构件也可以是一个包含多个构件的软件
a sofware component can be something as simple as a program module or an object-oriented class,but it can also be extended to include databases and "middleware" that enable the configuration of a network of clients and servers
"a modular,deplyable,and replaceable part of a system that encapsulates implementation and exposes a set of interfaces"\
Component-level design defines the data structures,algorithms,interface characteritics,and communication mechanismsallocated to each software component
module == component
module是比较老的叫法
4.1 设计原则(Class-Based)
OCP:开闭原则
A module [component] should be open for extension but closed for modification
LSP:替换原则
Subclasses should be substitutable for their base classes
DIP:依赖倒置原则
Denpend on abstractions. Do not depend on concretions(具体实现)
比如spring :Ioc是DIP的实现
4. ISP:接口分离原则
Many client-specific interfaces are better than one general purpose interface
其他:P196
4.2 具体步骤:构件的视图建模(Class-Based)
==分析方法与Component-Based 的分析方法一致==,只是级别不同。
分析接口结构,确定整体功能设计
找到接口对应的实现模块
分析模块内类的关系
以下为具体分析某个模块中的类的方式,一般不用这么具体,可以先从继承结构图开始分析
详细描述操作(方法)的处理流 --- 活动图/伪代码
描述持久性的数据源(database/file) 确认处理它们的类
描述构件的行为 --状态图
描述部署图 (包结构,包在设备的分布
以上内容其实呼应着体系结构中多种视图模型,只是抽象级别不同,在构件设计中,也就是按照侧重点不同,对构件进行以类为单位的(Class-Based)的建模
4.3 设计模式
GoF(Gang of Four)设计模式主要是类级别的(Class-based)设计模式,通常被视为组件设计模式。包括创建模式、结构模式和行为模式,和视图建模中主要的侧重点(结构,行为)相对应,同时它非常接近编码实现阶段
==J2EE 设计模式主要被视为架构设计模式(component-based)==
Reference
软件工程【朴勇 周勇】
Software Engineering (A PRACTITIONER'S APPROACH) [美] 罗杰