一个软件设计的全过程

在我的工作和学习记忆里一直有一个东西——设计。业界提出了很好的设计规范，也有相关的工具和方法。早年间我也一直努力的去促进和使用规范。

用例图 概括性的对功能进行了描述

用例是什么？用例就是需求，就是你的软件应该具有的功能。
首先我们需要了解一下这个软件的需求，在一张白纸上以UML用例图的方式，记录下需求的功能。
在画用例图的时候，可发现了一些隐含的功能，每一个用例之前会使用连接表达基本关系
如果关系连接交接点很多的用例则很容易显示出它的重要性。
【如图】

类图 软件的数据模型

类图 反映了软件的数据模型，在设计数据模型，我们参考了界面设计图和用例.
找出一个个的类。然后参照用例图的一个个功能，设计出各类的属性和方法。
设计初始的类图当然不可能很详细，但至少可看个大概
有错误不要紧，后期可以慢慢慢修正，但大体关系就算定下来了。
一个软件的设计主要看两个类 类图和时序图。
类图确定的软件数据模型的静态关型，时序图则是数据模型的动态关系

时序图 数据模型的动态关系

时序图表明了用例图中各功能的实现方案，同时也反应了类图中各类的交互关系。以后程序的逻辑和时序图基本一致。不过，有些人会去画得很详细的时序图，详细到都快赶上伪代码级别了，我觉得这没必要。我把时序图看做反映自己思路的大概过程，所以也就画个大概。

我认为时序图要简洁易懂，这样以后你的后继维护者，拿到这个软件的时序图（当然也包括用例图、类图），就能明白你的大概设计思路。另外，画时序图也能整理自己的思路，同时还可以对类图的设计进行验证。在画这个时序图的过程中，我就纠正了在类图中的几处考虑不周的地方。

总结：时序图可以（１）整理思路（２）验证类的设计（３）是很好的软件文档，对维护者理解代码很有帮助。

状态图 不同状态不同反应

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。

CRUD图 软件=数据+算法 CRUD就是描述基本数据

CRUD是指在做计算处理时的增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete)几个单词的首字母简写。crud主要被用在描述软件系统中数据库或者[持久层]的基本操作功能。

所谓“持久层”，也就是在系统逻辑层面上，专著于实现数据持久化的一个相对独立的领域(Domain)，是把数据保存到可掉电式存储设备中。持久层是负责向（或者从）一个或者多个数据[存储器]中存储（或者获取）数据的一组类和组件。

这个层必须包括一个业务领域实体的模型（即使只是一个元数据模型）。

但在我们开始工作到工作几年我接触到设计和愿意谈设计的人是越来越少
综观所有的情况 我们的与之相关的软件行业莫不是在都在资本的操纵下，进行业务级别的混战
所追求的莫不是堆积着应用，谁还会在意什么优化 核心，演进....

即便前辈早就给出的这一套规范。而国内大环境下远没有达成设计的意识，还不足够形成使得我们规范起来土壤。
回想我们的软件之路，仍是浮在应用层上追逐，好比《小说三体》所描述的，当地球物理知识已被对手的”质子“封锁后。仅只能在应用层面上发应用物理，造就了外表看似强大的太空舰队，沉浸至幻想能与之相抗。
而实际上，在面对对手”水滴“的攻击下，太空舰队外表强大实则不堪一击。

其他

API接口规范完整版本
实现规范作业的流程
图

image.png

--