让我们谈谈需求,说说设计

    今天闲来有空,让我们谈谈需求,说说设计。这一阵子又开始忙这个事情,感觉有一些感悟,分享一下。


      首先是需求,一直关注什么软件需求,什么是用户需求。两个需求会不会写成一样,实际上从文档的阅读者来看就知道不能写成一样。用户需求交付给用户的,需要让用户明白他们的胃口是否被满足了。“在一个地图上,显示餐馆的位置和口味排名。用户可以按照地域和名字查找餐馆”这是用户需求吗,是的,当然也可以再进一步挖掘,这个要看水平了。写出来的用户需求,如果用户看不懂,就完了。这个交流主要是在于用户层面的交流,需要从用户的需要上,工作行为习惯,性能要求,年龄,心理,目标甚至精神等各个层面上进行挖掘汇集,实际上这是一个市场需求挖掘的过程,最后交给用户说,这样行吗?偏偏我们聪明的计算机人员通常都是从C做出来的,对于机器的友好性认识远远高于对用户的友好性认识。呵呵!!现在时代变了行为心理学,用户体验中心,WEB2.0和长尾,都是内容为王。

      软件需求我理解是给方案做铺垫的,事给计算机职员准备的。是用户需求的软件化,计算计化体现,是给计算机人员开的,是给设计,开发,测试人员看的。说白了,是药方。是解决问题的药方和病历。用户需要的内容体现在功能分解上,形式体现在界面元素设计上,性能体现在整体约束上,流程体现在过程设计上。都有对应元素,但是不能混淆。包括异常的流程都是需要考虑起来的。说白了,这个时候是用专业的计算机元素来诠释用户的内容,其中也包含了一些设计元素。例如对于上段中的用户需求,可以这样说明

    “界面为右边一张表格,左边一张地图,上边一个工具栏。地图中为当前区域的所有餐馆,川味的采用红色表示,本帮菜使用黄色表示,利用星星的数量表示评价的高低,地图可以放大,缩小,通过左边的行政区域来进行扩充地图,右边的表格显示当前区域内的所有餐馆,包含餐馆名字,口味,评价,每一列都可以排序,排序按照时间顺序来进行主次之分,工具栏中有搜索栏,可以按照模糊匹配的方式搜索对应的餐馆,如果没有搜索到,则提示用户。。。。。。等等还有很多”

    可以看出这个需求中,包含了界面元素的设计,使用习惯的考虑,重点元素的设计,异常等。开发人员看了就知道做成什么样子。

 

      对于二者,系统工程师是需要关注用户需求和软件需求的。原则上任何人都需要关注全部。但是实际上也只有系统工程师重点关注全部,测试关注的是软件需求,开发关注的是详细设计。尽管这是错误的,但这是现实情况。


      设计主要分为这样几个层面,首先是软件需求上,这个包括了功能的分解和界面元素的设计。这个主要还是体现在用户需求的一个重新提炼过程,想弄出来的是结果设计。这个方面mac是专家,另外想说明大家都是很傻的,用windows的几个界面因素就能去搞定一切。主要还是在工作流上不能有偏差,这个偏差决定成败。这个在软件需求阶段可以结束。概括起来一句话,理解生活,然后用英文和英文语法描述生活。

      第二个层面,是整个系统的分层和统一约束。没有上帝,没有十全十美,没有永恒。这个谁都知道。这个层面的工作是架构师干的事情,架构师是魔鬼,其破坏十全十美,其摧残人性,限制你能做啥不能做啥。这就是约束和分层。其实就是想把整个问题进行优化选择,选择一个最好的方式,尽量但是不可避免会给系统带来约束,这个约束是必然的。每一种方案都有其缺点,这种缺点对于用户需求的影响只能由架构师自己去细细品味了。正如你治好了病人的肺癌然后告诉他以后不能抽烟,病人也是能接受的。

    然后就是分层,这个是为了以后的 变化而准备的,这个变化是因为两个原因,首先是自己的设计和用户需求就没有完全切合,顺便说一句多使用传统的经典的设计分层其内涵就能为你减少很多麻烦,经典就是经典,所以设计模式之类的书到处盛行;其次的确是用户的需求发生了非常大的进步,进步是合理的,我们也必须流行的跟上。

      最后这个层面,才是为每一个细节问题,需要来做代码或者子系统设计,包放在那里,对象如何设计,采用什么算法,交互流程怎样的,多线程是如何处理的,数据库是如何设计的,哪些消息是同步还是异步的,哪些可以成为API,生命周期是如何管理的,兼容性是如何保证的等等一切。这个设计是在上面这个的约束范围内。尽管此处经常突破上面的约束。一个仔细认真的编码人员能够完成功能,但是变化和异常依然希望有有经验的人员来保证。可是我们经常的主要精力还是放在方案上,毕竟进度对于项目来说是至高无上的。有时有经验的人员把问题归纳为几种计算机问题后,例如容器,排序,IO,应用框架,甚至功能类似的软件。导致我们最后最偷懒的方法就能够从功能类似的开源软件中去抄袭一下自己熟悉和不熟悉的代码完事,只要不突破分层和整体约束即可。


     呵呵,软件实际就是文学创作。艺术来源生活,也需要高于生活。我们国人还在做前者,依赖第一个因素把国外软件公司赶出国门,但也只能是生活经验丰富的应用软件,淘宝,讯雷,百度,Foxmail,FlashGet,金山词霸。可惜了,Office。对于操作系统,数据库此类高于生活甚高的软件,我们还差很远!!!!

### 1. 常见的算法时间复杂度有哪些?动态规划的设计步骤有哪些?最长公共子序列的实现思路是什么? #### 常见的算法时间复杂度 常见的算法时间复杂度包括:O(1)(常数时间)、O(log n)(对数时间)、O(n)(线性时间)、O(n log n)(线性对数时间)、O(n²)(平方时间)、O(2^n)(指数时间)以及O(n!)(阶乘时间)。这些复杂度描述了算法运行时间与输入规模之间的关系[^4]。 #### 动态规划的设计步骤 动态规划的设计通常包括以下几个步骤: 1. **定义状态**:明确问题中的“状态”是什么,如何用变量表示当前问题的中间结果。 2. **确定状态转移方程**:根据问题的最优子结构性质,推导出从子问题到当前问题的递推关系式。 3. **初始化和边界条件**:设定初始值或边界条件,确保递推能够正确开始。 4. **计算顺序**:以自底向上的方式逐步求解所有子问题,直到得到最终问题的解。 5. **存储结构设计**:选择合适的数据结构来保存中间结果,避免重复计算。例如,使用数组或哈希表存储子问题的结果[^2]。 #### 最长公共子序列的实现思路 最长公共子序列(LCS)问题的目标是找到两个字符串的最长公共子序列。其核心思想是利用动态规划解决。具体步骤如下: 1. 定义一个二维数组 `dp[i][j]`,表示字符串 `X[0:i]` 和 `Y[0:j]` 的最长公共子序列长度。 2. 状态转移方程为: - 如果 `X[i-1] == Y[j-1]`,则 `dp[i][j] = dp[i-1][j-1] + 1`; - 否则,`dp[i][j] = max(dp[i-1][j], dp[i][j-1])`。 3. 初始化边界条件:当其中一个字符串为空时,LCS 长度为 0,即 `dp[i][0] = dp[0][j] = 0`。 4. 按照上述规则填充整个 `dp` 表格,最终答案为 `dp[m][n]`,其中 `m` 和 `n` 分别是两个字符串的长度[^5]。 ```python def lcs(X, Y): m, n = len(X), len(Y) dp = [[0] * (n + 1) for _ in range(m + 1)] for i in range(1, m + 1): for j in range(1, n + 1): if X[i-1] == Y[j-1]: dp[i][j] = dp[i-1][j-1] + 1 else: dp[i][j] = max(dp[i-1][j], dp[i][j-1]) return dp[m][n] ``` --- ### 2. 在期末选题中,如何应用算法解决实际问题? 在期末选题中,可以通过以下方式应用算法解决实际问题: - **问题建模**:将实际问题抽象为数学模型或计算机科学问题,例如将资源分配问题建模为背包问题。 - **算法选择**:根据问题特性选择合适的算法,如动态规划、贪心算法或分治法等。 - **优化实现**:通过改进算法的时间复杂度或空间复杂度,提高程序效率。例如,使用备忘录方法减少重复计算[^2]。 - **验证与测试**:通过测试用例验证算法的正确性和性能,确保解决方案满足实际需求。 --- ### 3. 结合学过的算法,谈谈对分布式计算的理解 分布式计算是一种将任务分解并在多个计算节点上并行处理的计算模式。结合动态规划等算法,可以理解为: - **任务分解**:类似于动态规划中的子问题划分,分布式计算将大任务分解为多个小任务,分配给不同的计算节点。 - **数据共享与通信**:类似于动态规划中的状态转移,分布式计算需要在节点间传递中间结果,确保全局一致性。 - **负载均衡**:通过合理分配任务,避免某些节点过载而影响整体性能。 - **容错机制**:类似于动态规划中的边界条件处理,分布式系统需要设计容错机制以应对节点故障[^6]。 例如,在矩阵连乘问题中,可以将不同子矩阵的计算分配给不同节点,并通过消息传递机制整合最终结果。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值