和Google互补的搜索引擎Wolfram|Alpha
Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。
作者 邱郁惠 发布于 2008年6月20日 上午1时54分
使用UML如何能让我们做好系统分析的工作呢?就让我们通过基金模拟项目,先睹为快,抢先体验一番。其中可以分为以下几个步骤:
在系统分析员执行了前述的CIM与PIM步骤,并且获得高质量的生成之后,设计师会依据具体平台进一步生成PSM阶段的设计,并交由程序员按图编码,编写出适用于特定具体平台的代码。
详细内容,请阅读全文:用UML做好系统分析
本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。
《系统分析师UML实务手册》通过一个完整的仿真实例,介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等,一应俱全,过程细腻,步骤详细。主要内容包括:定义 业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。
与此同时,机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读:欢迎下载第10章《基金模拟项目》
我们知道,经济活动有审计,你这个系统分析如何审计。以上的例子适应领域应该是大型项目,但我担心如此复杂的业务模型是否能保证顺利执行。
deshi xiao 还有更好的方法么?我觉得文档成本比较高,在需求变化比较快的大型项目中,设计文档的维护是一个很头疼的问题.或者说有没有可能提供更好的工具可以降低文档的维护量?
通过上述分析过程与方法,可以使 经验/随意的 分析方法/过程 系统化/过程化、标准化/规范化、模式化/模型化,值得分析设计人员认真学习研究。
我是以我的技术经验来判断以上文章的,标准化,规范化肯定谁都希望,还有人希望过程自动化呢。可实现这样的系统,现在都在变化中,条件,需求,任务。像文中针对正式的业务系统这样分析,当然没得说,看上去很漂亮,但价值除了好看之外,他的通用性如何呢。所以就中国的软件开发业来说,UML的用处确实有用,但我们不能照搬别人的分析方式,应该用好UML这工具,但分析方式需要创新,并适合中国人的理解方式。
謝謝各位對這本書提出這麼多看法。 我想這本書的內容有它可取之處,也會有在實務上難以配合之處。在台灣,很多公司閱讀這本書,理解了之後,將書中的步驟修修改改,形成符合自己公司文化的程序,這是我最樂於見到的。 我從未希望各位完全按著這本書的方式進行,這絕對會有問題,因為每個公司、團隊的文化不同,不可能有一套統一的開發流程,我謹希望這本書可以有拋磚引玉之效,引出您們寶貴的開發流程。
deshi xiao:“他的通用性如何呢”
本书好像介绍的是一种 MDA 的建模方式,我感觉国内外 MDA 还没有普及,即便是 MDA 应用也未必只有一种标准方式,所以我不觉得本书的方法具有广泛的通用性。
当然,我们未必要追求广泛的通用性,有专用性也不错。那么本书介绍的方法是否“专门”适合国内的应用环境呢?我感觉也未必。
但作为一种观点和方法,我觉得作者的思路值得借鉴和参考。
deshi xiao:“所以就中国的软件开发业来说,UML的用处确实有用,但我们不能照搬别人的分析方式,应该用好UML这工具,但分析方式需要创新,并适合中国人的理解方式。
”
赞同,西方再成熟的技术在中国也有一个落地的问题,方式、方法的创新很重要。能否介绍一下你在这方面的经验?
张恂提出的 UML 太极建模 也是出于这个目的,欢迎有兴趣的朋友一起研究。
OOAD*UML 教练 张恂
www.zhangxun.com
作者说的很实在和诚恳,不错。
“我想這本書的內容有它可取之處,也會有在實務上難以配合之處。”
“很多公司閱讀這本書,理解了之後,將書中的步驟修修改改,形成符合自己公司文化的程序,這是我最樂於見到的。”
“我從未希望各位完全按著這本書的方式進行,這絕對會有問題,因為每個公司、團隊的文化不同,不可能有一套統一的開發流程,我謹希望這本書可以有拋磚引玉之效,引出您們寶貴的開發流程。”
OOAD*UML 教练 张恂
www.zhangxun.com
2008年6月21日 上午9时58分 发表人 deshi xiao
初看之下,本书的分析方法成本并不高,有些是必要的步骤,这样的业务模型还算简单,中小型项目估计也是可以尝试的。
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
我们知道,经济活动有审计,你这个系统分析如何审计。以上的例子适应领域应该是大型项目,但我担心如此复杂的业务模型是否能保证顺利执行。
缺点在于,只做到 PIM 就没下文了,好像没把 MDA 的完整流程走完。任何分析、设计模型,如果脱离实际代码,都可能带来风险。所以大家会有能否“顺利执行”的疑问。
你说的审计是不是 audit,自动审计还好,如果人工审计,往往也会增加成本。
估计你有很多话想说,能否介绍一下你的经验和思考,或者更好的、成本更低廉的让系统分析员可以保证质量的方法?
OOAD*UML 教练 张恂
www.zhangxun.com
实际上项目的文档其实就是这些uml图,但用户估计看不懂uml,他们需要的是文字性的word文档,我的经验是当用户需要提交文档的时候,通过uml工具输出一份文档就行了,而且这些文档用完了就扔,不必专人维护,如果用户对文档的格式不习惯,可以考虑花点功夫定制一下uml工具的报表模板来规范输出的格式,然后辅以专人进行修订,一般说来没什么问题
这样自上而下,由外到内,由粗到细的分析方式本身是没有问题的,甚至从哲学的观点上来看都是很科学的. 我感觉出问题的地方是我们抱着"为了保证留下文档","今后有人能够看明白","别人能接手"等等很"自然"的想法,我们企图去[记录整个问题的分析过程],希望每一步都完美的被记录. 1.开发的整个过程可能包括业务用例定义->业务用例分析->系统用例定义->系统用例分析->分析类图->分析序列图...在这个过程中出现的是成[金字塔状态的成本消耗]. 2.在现实开发中,企图一次就得到最终的答案是很难的.尽管定义的过程是线性的:CIM->PIM->PSM,事实上我们往往需要在几个过程之间进行反复, 分析->设计->Coding->修改分析->修改代码.由于抱着不肯抛弃过程产物,文档驱动等想法,我们甚至企图去记录整个反复的分析过程,这是需要花费大量成本的工作! 相当于把成本金字塔放大了N倍.到最后可能把自己陷入到一堆"过程垃圾"中. 因此,我认为:抛弃记录过程产物的想法,轻装上阵,以交流替代文档,用多种方式:图片\DV\文本等,只记录"必须的能帮助理解的资料",在迭代后期加入小的文档整理的过程(这个时候是效率最高的,屏蔽了很多分析中的杂质) 会是一个比较好的实践. 另:大型项目或行业项目中,以软件产品线为主导思想,在建立适当的库(规则库,业务流程库,组件库等)为基础上搭建特定领域的辅助分析设计工具,能在很大程度降低整个开发的成本.
晕了, 段落贴没了
可以用两个br来分段:)
可工作的软件,胜过面面俱到的文档
tobato说的有道理,大多数时候模型的维护要比代码的维护代价大的多。
Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。
Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。
罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。
Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。
中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。
HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。
14 条回复
关注此讨论 回复