OO系统分析员之路系列
文章平均质量分 91
coffeewoo
《大象——Thinking in UML》作者。关注企业数字化转型,正在研发企业数字化中台产品。
本人是经验丰富的IT从业者,曾经担任过项目经理、产品经理、系统分析师、架构师等职,拥有10多个项目分析、设计、管理经验,对软件领域有着全面和深刻的理解。精通UML及建模方法,在需求管理、分析方法、企业架构、软件架构建模以及面向对象的分析和设计方面具有十多年的实践经历,有着深刻的理解和独到的认识。精通软件工程和各种软件方法,如RUP、敏捷方法等。精通项目管理,PMP证书获得者。
展开
-
OO系统分析员之路--用例分析系列(1)--什么是用例
我发现,在OO和UML几乎一统天下的今天,仍有很多系统分析员对OO和UML一知半解,甚至包括很多已经使用了很久UML的系统分析员。于是打算写一个系列文章,将多年来的工作经验做一个总结。对初学者起个启蒙作用,也希望抛砖引喻,与各路大虾共同探讨,共同提高。这个系列文章将以我对OO和系统分析的理解为主,从UML基础开始,阐述面向对象的需求分析方法,过程,并以RUP为例,阐述如何将OO过程与原创 2008-10-13 15:13:00 · 20577 阅读 · 15 评论 -
OO系统分析员之路--用例分析系列(5)--用户、业务用例和业务场景[整理重发]
很久没有动笔了,这期间承蒙许多朋友的喜欢和鼓励,再不写点东西就对不住这些朋友了。写点什么呢?按照原先的设想,应该开始动手写如何从业务用例转化到概念用例和系统用例,不过老实说这一步需要的是经验居多,而很难找出一个普适的步骤来。先暂时放一放吧,以后一定会写到的。上一篇讲到用例分析的一般步骤和方法,也给出了一个实例,不过没有做更进一步的说明,所以这一篇,笔者决定先罗嗦罗嗦之前的内容,说说业务建模中各种原创 2008-12-23 01:04:00 · 9204 阅读 · 5 评论 -
OO系统分析员之路--用例分析系列(4)--业务建模一般步骤和方法[整理重发]
本篇开始之前先扯点闲话,商业应用系统开发经历了三个阶段:第一个阶段以计算为中心,分析设计围绕程序的运行效率,算法优劣,存贮优化来进行。90年代的大学课程讲的都是这些。第二阶段以数据为中心,分析设计围绕数据流进行,以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。第三阶段以人为中心,分析设计围绕人的业务需求,使用要求,感受要求进行。这也就是现在的面象对象分析模式。 使用OO方法建立商业模原创 2008-12-16 00:15:00 · 12076 阅读 · 16 评论 -
OO系统分析员之路--用例分析系列(3)--业务建模之涉众[整理重发]
从这一篇开始,笔者将借助一个虚拟的实例来阐述获取用例的方法,以及如何判断用例获取是否完备,粒度选择是否合适。事实上,在做这些工作时,我们正在进行需求分析的第一个阶段,即业务建模阶段。借助这个例子,笔者同样会阐述业务建模到底应该做什么,做到什么地步才能说明业务需求已经完整,可以称为一份完整的需求规格说明书了。一般来说,只有当以下工作都完成,才能说业务模型建立完成,它们是:发现和定义涉众画定业务边界原创 2008-12-08 21:12:00 · 8105 阅读 · 2 评论 -
OO系统分析员之路--用例分析系列(2)--用例的类型与粒度 [整理重发]
在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。 先说说用例类型的问题。 用例类型,有的资料翻译为版型,英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realizatio原创 2008-12-05 10:29:00 · 10858 阅读 · 12 评论 -
OO系统分析员之路--用例分析系列(6)--用例实现、用例场景和领域模型[整理重发]
上一篇说到我们经过初步的业务分析,得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架,并圈定了业务范围。这时应当做一份基线。当然,第一份基线所包括的内容是非常粗的,要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物,以及这些成果对需求的贡献。在开始之前,还是提醒读者下载实例,本文下面只会从实例中挑选很少一部分来说明,对照实例读者将能更好的理解。原创 2009-02-09 21:41:00 · 9148 阅读 · 12 评论 -
OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描述[整理重发]
先说说业务规则。笔者习惯将业务规则分为三种。一种是全局规则,这种规则一般与所有用例都相关而不是与特定用例相关,例如actor要操作用例必须获得相应的授权,用例的操作与授权级别相关,或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于,并且也建议将它们写到用例的补充规约里面去,因为它们一般与具体的业务功能性要求没有直接关系。有时候,这类规则也被写到软件架构文档中。关于用例补充规约原创 2009-04-14 17:29:00 · 16831 阅读 · 13 评论