个人认为如果掌握软件工程相关知识，代码审计会更清晰，更具全局观
以下的英文内容均引用自 《软件工程》[罗杰] 的英文原版
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
以后分析软件就可以用以下的两个维度去分析
Abstraction dimension
需求分析模型----->设计模型
Process dimension
-
体系结构（软件架构）
-
接口设计(用户接口（前端页面UI) ；外部接口（整个软件对外的接口，如作为第三方被其他系统调用）；内部接口（体系机构内部构件之间的接口，构件内部类之间的接口）
-
构件级设计
-
部署级设计: 也被称作物理级
【注意】==过程维度可以应用在不同抽象级别，如图中”设计模型“还可以再细分为 Component-Based和Class-Based两个抽象级别==，不同级别都有对应的体系结构，接口设计，构件（模块），部署维度，后文的”分析方法“可以体现
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) [美] 罗杰
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
