软件需求、分析&设计的讨论（之四）
3 views
Skip to first unread message
Leo
Nov 8, 2008, 5:01:57 AM11/8/08
to 中国架构师联盟
【 节选自QQ群——架构师联盟论坛的讨论记录 2008年11月7日 】
风在吹(94524029)16:11:09
问大家一个问题啊
分析模型存在的价值是什么？为什么要建立分析模型？
红叶(Leo)(38800226)16:39:58
分析模型属于概念模型，是不依赖具体实现技术的业务和系统抽象。对于复杂的系统，通过分析模型可以简化、
方便从需求到设计模型的转化，但当设计模型一经建立之后，分析模型留下来的价值就不是很大了，并且分析模型
的存在反而增加与需求、设计模型一致性的维护成本（往往这种成本是相当高昂），所以一般都把分析模型当作抛
弃型模型来对待（个别巨复杂系统不同，要辩证对待）；另外，对于简单系统，建立分析模型的必要性就不大了，
往往这时候人类的思维可以把握从需求到设计的转换，从敏捷及成本考虑，从需求快速转化到设计甚至转化到代码
实现显得尤其重要。对于MDA（模型驱动架构，非模型驱动开发，很多人有这个错误认识）的规范定义是只要做好
需求和PIM（平台无关模型，也可以简单认为是“分析模型”）后，就让MDA工具自动转换PIM转化为PSM（平台相关模型），
但这时候很多人并不理解这其中还要定义相关的转换规则和映射(这对于一个技术领域或架构可能是一次性的)，这个
工作量一般是很巨大和很复杂，做这项工作的往往需要具备这方面的专业知识与技能，甚至可以称这方面的人才
为MDA映射架构师。
风在吹(94524029)16:47:14
，厉害
工程的确很大，要求的确很高
风在吹(94524029)16:47:16
为什么要用分析类而不是设计类去验证需求呢？这是由于抽象层次更高，分析类比设计类验证需求的工作量以及可能
的变化都要少很多。比如针对登录要求，如果用分析类来表达，我们只需要向登录control类发一条登录请求就OK了。
而设计类由于与实现方式相关，并且已经具化到了实现，所以根据安全验证方式不同，LDAP，CA，SSL，或应用服务
器不同，登录方式和方法都不同，并且可能是很多个步骤，例如
getUser(),getRole(),getGroup(),register()...
你愿意用这么多说明才能表示已经验证了一个简单的登录要求吗?慢着，如果更换了安全模式呢？更换了应用服务器
呢？这在现实情况中也很常见，对分析类来说，由于抽象层次高于实现方式，因此继续有效，而设计类却必须更改。
这就是为什么要用分析模型来验证需求的原因之一。
红叶(Leo)(38800226)16:52:29
我不这么认为。分析类太抽象，往往只能谈概念，不能明确是否能实现。需求是要用实现来满足的，不是靠说概念来
证明的，所以，仅仅（注意：我说的是仅仅）靠概念来验证需求，是不够的，比如性能或可用性或易用性等。其实，
这里有一个解决办法，就是架构验证，而不是分析验证。架构是可执行架构，不是抽象的概念架构，也就是说架构要
做到子系统的实现模拟，架构的实现肯定是通过具体的技术和编程语言来反映，但不会陷入无关的细节。
另外，说明一下，我这里谈到不是空洞的理论，而是我们已经实实在在这样做了。
风在吹(94524029)16:53:56
如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，
做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。在你的组织面对同行业不同客户时，可能无
法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。在设计模型的层次上，这必然导致很多
个不同的实现版本。面对这么多不同的版本，如何去维护一个“统一的行业解决方案”呢？正如上面所述，由于分析模
型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户们可能有的
用LDAP，有的用CA，将来可能还有新的模式，但对于分析模型来说，安全模块始终可以保持一致。这将非常有利于随
着各个项目的进行，对分析模型的逐步维护，而形成一个统一的，稳定的架构和行业解决方案，而针对不同的客户要
求，又可以提供不同的实现包。
风在吹(94524029)16:55:19
你那还是需要建立分析模型的
特别是你们这样的产品
有了稳定的分析模型
以后的维护扩展和行业应用会很方便
红叶(Leo)(38800226)16:56:57
“如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，
做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。”这点我赞同
红叶(Leo)(38800226)16:59:54
“在你的组织面对同行业不同客户时，可能无法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。
在设计模型的层次上，这必然导致很多个不同的实现版本。”这样就会导致我们思考做一个可复用的平台组件，而不能
仅仅停留在“分析类”的层面思考，否则我们复用的生产率会打很多折扣。复用有“概念复用”、“方法复用”、“方案复用”、
“设计复用”、“代码复用”等等。
红叶(Leo)(38800226)17:02:47
“由于分析模型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户
们可能有的用LDAP，有的用CA，将来可能还有新的模式，但对于分析模型来说，安全模块始终可以保持一致。”分析模
型只是从概念层面解决了安全的复用，或者说从概念模型。但如果能有具体的设计模型来体现复用，复用的效率将会很
高，比如，我可以设计一个安全子系统接口，然后实现可以运行任何安全策略，比如CA等。
风在吹(94524029)17:05:05
可以，分析模型是一个可选的过程
要具体权衡了
风在吹(94524029)17:08:52
不过，分析模型的确可以更好的理解
在多个项目组中运用还是不的
红叶(Leo)(38800226)17:09:14
这没错，关键看投入产出比
风在吹(94524029)17:09:24
嗯
风在吹(94524029)17:09:46
只有2个过程是必须的
需求和实现
风在吹(94524029)17:11:31
红叶是高手啊
风在吹(94524029)17:11:38
红叶可以做产品架构师
谢求智(66343483)17:11:56
问一个问题，这些知识你们是看什么书或者通过什么渠道获取到的
风在吹(94524029)17:12:40
学，想，做
谢求智(66343483)17:13:19
哪也得有渠道来了解呀，不然怎么想怎么做
红叶(Leo)(38800226)17:14:22
这些是学习、研究、思考、实践、总结、再实践、再总结的结果。符合毛主席的实践论
风在吹(94524029)17:14:52
我也是初学者哦
红叶(Leo)(38800226)17:15:05
看得出
风在吹(94524029)17:15:05
还要向红叶及各位学习讨论
风在吹(94524029)17:15:43
有很多书介绍的，大体概念差不多
然后真正去实施的时候会发现很多问题
就象练武功一样
明明照着书练，就是发现没有得到预期的效果
红叶(Leo)(38800226)17:16:37
看来“风在吹”悟到了一些东西
谢求智(66343483)17:16:40
我连这些概念都不知道怎么接触
风在吹(94524029)17:17:07
需要再揣摩思考，学习，就会发现概念很相似
风在吹(94524029)17:17:15
谢谢红叶，以后多指教啊
红叶(Leo)(38800226)17:17:36
"谢求智(66343483) 17:16:40我连这些概念都不知道怎么接触 "
加入我们这个团队就让你提升很快！不出半年，你的分析设计水平会有一个质的飞跃！
风在吹(94524029)17:17:37
胡子现在工作是哪个领域
红叶(Leo)(38800226)17:19:30
风在吹(94524029) 17:17:15谢谢红叶，以后多指教啊 呵呵～没问题。你也多多提供你的实践反馈，这对我来说也
是一个宝贵的间接经验，对完善我的体系会有帮助。
风在吹(94524029)17:20:20
你们现在专注于什么技术领域？
谢求智(66343483)17:20:37
老红，我不敢加入你们
红叶(Leo)(38800226)17:20:51
别这样，欢迎你呀
谢求智(66343483)17:21:23
"
风在吹(94524029) 17:17:37
胡子现在工作是哪个领域
"
我是同望的
风在吹(94524029)17:21:44
嘻嘻，你的老同事挖你了
谢求智(66343483)17:23:01
"
红叶(Leo)(38800226) 17:20:50
别这样，欢迎你呀
"
怕胜任不了，更让你们失望，你们说的那些分析，我都没有接触过，我去了，也是从零开始，那不是连累你们
风在吹(94524029)17:24:38
呵呵
风在吹(94524029)17:24:50
分析模型不是必须的，你可以直接跳过
红叶(Leo)(38800226)17:25:13
你可以先从实现入手，观察学习和逐步掌握这些分析设计技术及方法，然后先做一些子系统等详细设计，然后慢慢
体会架构的设计分析方法，逐步过渡到设计师角色。
风在吹(94524029)17:26:02
我跟你们完全相反
我现在是从商业，从价值的角度去考虑
到需要，到分析
红叶(Leo)(38800226)17:26:16
公司的关注点不同
风在吹(94524029)17:26:18
跟你们完全相反
风在吹(94524029)17:26:26
本质上，我是一个商人了
红叶(Leo)(38800226)17:26:27
也不是完全相反
红叶(Leo)(38800226)17:26:44
不同阶段或时期都有变化
红叶(Leo)(38800226)17:27:06
在同望，概念模型和需求也很重要
谢求智(66343483)17:27:40
可惜同望，这方面的人才在稀缺了
红叶(Leo)(38800226)17:28:26
正如老板以前说过，你们都是“超级程序员”
谢求智(66343483)17:28:58
呵呵，没错，就差老板没有给我们发红底裤穿在外面了
谢求智(66343483)17:31:10
需求分析，数据库设计，类设计，代码书写，页面布局，做报表，全部都做
红叶(Leo)(38800226)17:32:11
没有做用例分析吧？没有做子系统设计吧？
谢求智(66343483)17:32:37
但是都是很泛泛的，不会像你们一样那么具体，用那么多专业理论，得像你们学习讨教
谢求智(66343483)17:33:16
“
红叶(Leo)(38800226) 17:32:11
没有做用例分析吧？没有做子系统设计吧？
”
有用例，但是都是赶不上变化，到最后用例很多都和实现不一样了
红叶(Leo)(38800226)17:33:21
学习讨教不如来我这里亲自教你
风在吹(94524029)17:33:52
需求有效性的确是个问题
风在吹(94524029)17:34:18
不知道有什么对需要的有效的测试方法
红叶(Leo)(38800226)17:34:33
那是你们的用例分析根本就没有做对，没有围绕客户的核心价值来分析，如果围绕了客户的核心价值分析用例，
自然不容易出现你说的赶不上变化。
风在吹(94524029)17:34:54
嗯，对头
风在吹(94524029)17:35:00
商业价值才是根本
红叶(Leo)(38800226)17:35:16
同望有一个典型问题，就是项目人员经常不知道客户的核心价值在哪里。
风在吹(94524029)17:35:18
一切之源来源于用户的商业价值
风在吹(94524029)17:38:57
“
红叶(Leo)(38800226) 17:35:16
同望有一个典型问题，就是项目人员经常不知道客户的核心价值在哪里。
”
几乎所有的项目人员都是这样的吧
红叶(Leo)(38800226)17:39:59
但我现在对我的团队成员就要严格要求这点。原来不能在同望实现的理想，我将在现在这个平台实现！
风在吹(94524029)16:11:09
问大家一个问题啊
分析模型存在的价值是什么？为什么要建立分析模型？
红叶(Leo)(38800226)16:39:58
分析模型属于概念模型，是不依赖具体实现技术的业务和系统抽象。对于复杂的系统，通过分析模型可以简化、
方便从需求到设计模型的转化，但当设计模型一经建立之后，分析模型留下来的价值就不是很大了，并且分析模型
的存在反而增加与需求、设计模型一致性的维护成本（往往这种成本是相当高昂），所以一般都把分析模型当作抛
弃型模型来对待（个别巨复杂系统不同，要辩证对待）；另外，对于简单系统，建立分析模型的必要性就不大了，
往往这时候人类的思维可以把握从需求到设计的转换，从敏捷及成本考虑，从需求快速转化到设计甚至转化到代码
实现显得尤其重要。对于MDA（模型驱动架构，非模型驱动开发，很多人有这个错误认识）的规范定义是只要做好
需求和PIM（平台无关模型，也可以简单认为是“分析模型”）后，就让MDA工具自动转换PIM转化为PSM（平台相关模型），
但这时候很多人并不理解这其中还要定义相关的转换规则和映射(这对于一个技术领域或架构可能是一次性的)，这个
工作量一般是很巨大和很复杂，做这项工作的往往需要具备这方面的专业知识与技能，甚至可以称这方面的人才
为MDA映射架构师。
风在吹(94524029)16:47:14
，厉害
工程的确很大，要求的确很高
风在吹(94524029)16:47:16
为什么要用分析类而不是设计类去验证需求呢？这是由于抽象层次更高，分析类比设计类验证需求的工作量以及可能
的变化都要少很多。比如针对登录要求，如果用分析类来表达，我们只需要向登录control类发一条登录请求就OK了。
而设计类由于与实现方式相关，并且已经具化到了实现，所以根据安全验证方式不同，LDAP，CA，SSL，或应用服务
器不同，登录方式和方法都不同，并且可能是很多个步骤，例如
getUser(),getRole(),getGroup(),register()...
你愿意用这么多说明才能表示已经验证了一个简单的登录要求吗?慢着，如果更换了安全模式呢？更换了应用服务器
呢？这在现实情况中也很常见，对分析类来说，由于抽象层次高于实现方式，因此继续有效，而设计类却必须更改。
这就是为什么要用分析模型来验证需求的原因之一。
红叶(Leo)(38800226)16:52:29
我不这么认为。分析类太抽象，往往只能谈概念，不能明确是否能实现。需求是要用实现来满足的，不是靠说概念来
证明的，所以，仅仅（注意：我说的是仅仅）靠概念来验证需求，是不够的，比如性能或可用性或易用性等。其实，
这里有一个解决办法，就是架构验证，而不是分析验证。架构是可执行架构，不是抽象的概念架构，也就是说架构要
做到子系统的实现模拟，架构的实现肯定是通过具体的技术和编程语言来反映，但不会陷入无关的细节。
另外，说明一下，我这里谈到不是空洞的理论，而是我们已经实实在在这样做了。
风在吹(94524029)16:53:56
如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，
做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。在你的组织面对同行业不同客户时，可能无
法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。在设计模型的层次上，这必然导致很多
个不同的实现版本。面对这么多不同的版本，如何去维护一个“统一的行业解决方案”呢？正如上面所述，由于分析模
型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户们可能有的
用LDAP，有的用CA，将来可能还有新的模式，但对于分析模型来说，安全模块始终可以保持一致。这将非常有利于随
着各个项目的进行，对分析模型的逐步维护，而形成一个统一的，稳定的架构和行业解决方案，而针对不同的客户要
求，又可以提供不同的实现包。
风在吹(94524029)16:55:19
你那还是需要建立分析模型的
特别是你们这样的产品
有了稳定的分析模型
以后的维护扩展和行业应用会很方便
红叶(Leo)(38800226)16:56:57
“如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，
做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。”这点我赞同
红叶(Leo)(38800226)16:59:54
“在你的组织面对同行业不同客户时，可能无法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。
在设计模型的层次上，这必然导致很多个不同的实现版本。”这样就会导致我们思考做一个可复用的平台组件，而不能
仅仅停留在“分析类”的层面思考，否则我们复用的生产率会打很多折扣。复用有“概念复用”、“方法复用”、“方案复用”、
“设计复用”、“代码复用”等等。
红叶(Leo)(38800226)17:02:47
“由于分析模型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户
们可能有的用LDAP，有的用CA，将来可能还有新的模式，但对于分析模型来说，安全模块始终可以保持一致。”分析模
型只是从概念层面解决了安全的复用，或者说从概念模型。但如果能有具体的设计模型来体现复用，复用的效率将会很
高，比如，我可以设计一个安全子系统接口，然后实现可以运行任何安全策略，比如CA等。
风在吹(94524029)17:05:05
可以，分析模型是一个可选的过程
要具体权衡了
风在吹(94524029)17:08:52
不过，分析模型的确可以更好的理解
在多个项目组中运用还是不的
红叶(Leo)(38800226)17:09:14
这没错，关键看投入产出比
风在吹(94524029)17:09:24
嗯
风在吹(94524029)17:09:46
只有2个过程是必须的
需求和实现
风在吹(94524029)17:11:31
红叶是高手啊
风在吹(94524029)17:11:38
红叶可以做产品架构师
谢求智(66343483)17:11:56
问一个问题，这些知识你们是看什么书或者通过什么渠道获取到的
风在吹(94524029)17:12:40
学，想，做
谢求智(66343483)17:13:19
哪也得有渠道来了解呀，不然怎么想怎么做
红叶(Leo)(38800226)17:14:22
这些是学习、研究、思考、实践、总结、再实践、再总结的结果。符合毛主席的实践论
风在吹(94524029)17:14:52
我也是初学者哦
红叶(Leo)(38800226)17:15:05
看得出
风在吹(94524029)17:15:05
还要向红叶及各位学习讨论
风在吹(94524029)17:15:43
有很多书介绍的，大体概念差不多
然后真正去实施的时候会发现很多问题
就象练武功一样
明明照着书练，就是发现没有得到预期的效果
红叶(Leo)(38800226)17:16:37
看来“风在吹”悟到了一些东西
谢求智(66343483)17:16:40
我连这些概念都不知道怎么接触
风在吹(94524029)17:17:07
需要再揣摩思考，学习，就会发现概念很相似
风在吹(94524029)17:17:15
谢谢红叶，以后多指教啊
红叶(Leo)(38800226)17:17:36
"谢求智(66343483) 17:16:40我连这些概念都不知道怎么接触 "
加入我们这个团队就让你提升很快！不出半年，你的分析设计水平会有一个质的飞跃！
风在吹(94524029)17:17:37
胡子现在工作是哪个领域
红叶(Leo)(38800226)17:19:30
风在吹(94524029) 17:17:15谢谢红叶，以后多指教啊 呵呵～没问题。你也多多提供你的实践反馈，这对我来说也
是一个宝贵的间接经验，对完善我的体系会有帮助。
风在吹(94524029)17:20:20
你们现在专注于什么技术领域？
谢求智(66343483)17:20:37
老红，我不敢加入你们
红叶(Leo)(38800226)17:20:51
别这样，欢迎你呀
谢求智(66343483)17:21:23
"
风在吹(94524029) 17:17:37
胡子现在工作是哪个领域
"
我是同望的
风在吹(94524029)17:21:44
嘻嘻，你的老同事挖你了
谢求智(66343483)17:23:01
"
红叶(Leo)(38800226) 17:20:50
别这样，欢迎你呀
"
怕胜任不了，更让你们失望，你们说的那些分析，我都没有接触过，我去了，也是从零开始，那不是连累你们
风在吹(94524029)17:24:38
呵呵
风在吹(94524029)17:24:50
分析模型不是必须的，你可以直接跳过
红叶(Leo)(38800226)17:25:13
你可以先从实现入手，观察学习和逐步掌握这些分析设计技术及方法，然后先做一些子系统等详细设计，然后慢慢
体会架构的设计分析方法，逐步过渡到设计师角色。
风在吹(94524029)17:26:02
我跟你们完全相反
我现在是从商业，从价值的角度去考虑
到需要，到分析
红叶(Leo)(38800226)17:26:16
公司的关注点不同
风在吹(94524029)17:26:18
跟你们完全相反
风在吹(94524029)17:26:26
本质上，我是一个商人了
红叶(Leo)(38800226)17:26:27
也不是完全相反
红叶(Leo)(38800226)17:26:44
不同阶段或时期都有变化
红叶(Leo)(38800226)17:27:06
在同望，概念模型和需求也很重要
谢求智(66343483)17:27:40
可惜同望，这方面的人才在稀缺了
红叶(Leo)(38800226)17:28:26
正如老板以前说过，你们都是“超级程序员”
谢求智(66343483)17:28:58
呵呵，没错，就差老板没有给我们发红底裤穿在外面了
谢求智(66343483)17:31:10
需求分析，数据库设计，类设计，代码书写，页面布局，做报表，全部都做
红叶(Leo)(38800226)17:32:11
没有做用例分析吧？没有做子系统设计吧？
谢求智(66343483)17:32:37
但是都是很泛泛的，不会像你们一样那么具体，用那么多专业理论，得像你们学习讨教
谢求智(66343483)17:33:16
“
红叶(Leo)(38800226) 17:32:11
没有做用例分析吧？没有做子系统设计吧？
”
有用例，但是都是赶不上变化，到最后用例很多都和实现不一样了
红叶(Leo)(38800226)17:33:21
学习讨教不如来我这里亲自教你
风在吹(94524029)17:33:52
需求有效性的确是个问题
风在吹(94524029)17:34:18
不知道有什么对需要的有效的测试方法
红叶(Leo)(38800226)17:34:33
那是你们的用例分析根本就没有做对，没有围绕客户的核心价值来分析，如果围绕了客户的核心价值分析用例，
自然不容易出现你说的赶不上变化。
风在吹(94524029)17:34:54
嗯，对头
风在吹(94524029)17:35:00
商业价值才是根本
红叶(Leo)(38800226)17:35:16
同望有一个典型问题，就是项目人员经常不知道客户的核心价值在哪里。
风在吹(94524029)17:35:18
一切之源来源于用户的商业价值
风在吹(94524029)17:38:57
“
红叶(Leo)(38800226) 17:35:16
同望有一个典型问题，就是项目人员经常不知道客户的核心价值在哪里。
”
几乎所有的项目人员都是这样的吧
红叶(Leo)(38800226)17:39:59
但我现在对我的团队成员就要严格要求这点。原来不能在同望实现的理想，我将在现在这个平台实现！
Reply all
Reply to author
Forward
0 new messages