我已经编程了几年,现在正在大学学习计算机科学.每次我编写一些东西,我都会通过启动编辑器和即兴创作来实现.写作方法,我去的课程.当然,我事先考虑过,我拿出草图纸并写下我的想法,做一些事情要做的事情等等.这可以用于编写一些代码或简单而相对较小的软件,但是如何复杂的？
当你想制作一个复杂的软件时,你如何绘制蓝图？建筑师在开始任何实际工作之前对建筑物进行蓝图,并遵循标准.我希望程序员能做到,但我从来没有听说过.有哪些方法,工具和步骤可以用来做到这一点.
我不想要意见.
我想要一些具体的东西:图表？地图？工具？技术？分步流程？...
现在的标准答案很简单:绘制UML图.
多年来,答案应该是:"绘制流程图","绘制Nassi-Shneiderman图","绘制Warnier/Orr图","绘制数据流图"等等
他们在同一时间都会得到很好的答案和糟糕的答案.现实是这个问题没有单一的正确答案,原因很简单,没有人真正知道软件究竟是什么.
在人们跳到我的喉咙之前,让我解释一下我的意思.
当建筑师创建建筑物的蓝图时,最终产品是清晰的:它将是具有墙壁,门,窗等的物理结构.我们的建筑师将画一条线并说:"这是一堵墙"; 将绘制另一条线并说:"这是从屋顶到地下室的电视天线电缆".使用一些关于尺寸(比例),颜色和线条类型的惯例,他将能够与其他人沟通需要构建的东西以及如何将它们组合在一起.
可能会对细节产生一些误解,但没有人怀疑他们正在看的2D模型实际上代表了一个建筑物.即使需要多个图表(例如每层一个图表),也很容易将它们联系起来.
对于软件系统,我们尚未达到这个水平!第一个问题是"你将如何建模软件"？
如果使用面向对象的方法,您将把软件描述为属于"类"的一组"对象",这些对象彼此相关(如"类图"中所述),具有给定的行为("状态"图")并以某种方式进行交互(如一组"协作图"中所述).
没有单一的图表可以显示软件系统的所有方面.这就是为什么UML包含许多不同类型的图表.
如果使用结构化方法,则会将系统描述为一组处理组件,将输入转换为输出(DFD)和设置数据实体(作为ER图).
任何图表都有效,只要其含义对所有相关方都清楚.实际上,通过在白板上绘制两个框以及它们之间的一条线来开始设计会话是很常见的:"好的,这是连接到我们的Web服务器的浏览器......".
问题恰恰在于每个图表的含义.
实际上,我们有一个很好的通用方式来表示系统的数据部分:实体关系图(或类图的"静态部分")可以直接转换为实时数据库.我将此归结为关系数据库在关系代数中有充分根据的事实,同时,它们使用了任何人都可以掌握的简单概念(表,外键,连接......).所有其他数据表示都已被删除(不再有更多的数据库!).
我们缺乏的是对软件动态方面的共同认可观点; 一些统一的观点既理论上合理又不难以使用.
这就是我的建议.