江苏龙网

  1. 首页 > 生活 > >

一个开源项目，为了后续的使用与维护，怎样总结出它的流程与系统结构，并在文档中体现出来，工具和方法推荐

方法的话，推荐UML（统一建模语言），不过UML中我只会用类图，状态图，用例图和活动图。其他的都可耻地忘记了。需求定制的时候用用例图建立需求列表和测试用例，代码设计的时候使用活动图构建代码流程，用类图确立各种类之间的关系，用状态图来构建状态机，基本是这样了。工具的话，UML工具太多了，我习惯用StartUML，visio正在学习，我觉得visio很漂亮是怎么回事？一个开源项目，为了后续的使用与维护，怎样总结出它的流程与系统结构，并在文档中体现出来，工具和方法推荐

感谢@张恂 指出, 应张大叔的要求, 现做一幅visio做的用例图现丑 【一个开源项目，为了后续的使用与维护，怎样总结出它的流程与系统结构，并在文档中体现出来，工具和方法推荐】 一个开源项目，为了后续的使用与维护，怎样总结出它的流程与系统结构，并在文档中体现出来，工具和方法推荐

给几个参考网址：UML实践----用例图、顺序图、状态图、类图、包图、协作图统一建模语言
■网友
\u0026gt;\u0026gt;一个开源项目，为了后续的使用与维护，如何总结出它的流程与系统结构，并在文档中体现出来，工具和方法推荐？你说的是如何描述 Software Architecture（软件架构）吧，UML 当然是首选。这与开源还是闭源软件没啥关系，都能用。有些人说，软件架构用代码（加注释）来描述？不太可能吧，那是件很笨拙的事，因为软件架构与代码完全是两码事，描述抽象的架构当然画图来得更方便了。软件设计或软件架构文档全都是文字，没有一张图？在实践中，这也是比较少见的情况（尤其对于复杂软件），说明文档的作者不够专业，不知道“一图胜千言”、图文并茂的重要性和价值。图形符号常常比大段的文字描述更简单、更直观和形象，更易于读者的理解、记忆，抓住问题的焦点。一两张图就能说明白的事，还有必要编写大段冗余累赘的文字吗？所以，UML 图形常常能减少文字工作量，在精简文档的同时提高文档的质量。UML 架构建模比较简单，而且是通用的。建模方法主要参考 UP（统一过程）和敏捷建模，比较全面、系统地描述软件架构与执行流程主要是通过 n+1 视图（View）来建立软件架构的模型：需求视图（用例 + 非功能需求）逻辑视图（架构的层次、包，关键的类、接口，以及关键需求的动态实现）进程视图（进程、线程交互）实现视图（软构件的组成结构、依赖关系）部署视图（系统拓扑）数据视图（数据库设计、信息模型）等。（参考：4+1 architectural view model）架构模型中的每个视图都可能用到一个或多个 UML 静态图和/或动态图。网上关于 UML 工具的讨论已经很多了，到处都是。常用的有 EA、Visio、StarUML、PD 等等。
■网友
理解清楚一个项目，首先要理解业务逻辑，因为不理解业务逻辑，光看代码是不能理解代码为啥要这样做。
■网友
1. 划分目标读者，并根据他们的兴趣编写。比如，有些读者是项目使用者，他们可能并不十分关心内部设计或实现细节。而有些读者想出一份力，那么他会更关心如何在本地构建开发环境，在何处切入加入自己的功能等等。2. 保持文档精炼，不要搞成篇幅特别大的，读者看着就心生抵触。可以通过分章节，加入链接引导等方式组织文档，让读者易于在文档中寻找答案。3. 多写为什么这样做（做出设计的依据，对后续维护和演化有帮助），少写怎么做的（可以看代码）4.适当加一些图，来帮助读者理解你的文字
■网友
使用StarUml绘制时序图，跟着业务逻辑熟悉代码使用Markdown，及时将掌握的知识点总结记录下来
■网友
亲，这个没办法，开源文档的维护基本上是跟不上时代的。还是考虑两件事，1.整体的设计框架，或者说叫架构说明。2.整个系统的入口说明，有这两部分就足够让关心项目的人入门了。如果连这些都不成那只能说明，他对项目不关心。


推荐阅读


上一篇：医疗■江苏丹阳供电：“不停电”作业让鱼跃医疗“不掉线”

下一篇：环境■镇江新区全域提升农村人居环境 增“颜值”提“气质”