一直以来,都是上来就设计数据库,然后直接写程序,最多仿照PetShop的架构做个三层的东西。
终于有一天觉得这样不好,于是就想要按照规范的开发流程尝试一次——
正好手头要写的东西里有一个简单的新闻发布程序,就拿它练手吧(难点儿的怕一下子驾驭不来,打击士气)
上网找UML工具(虽然有PD,但是不太习惯),听人家说EA不错,就下载了一份下来,是试用版的,只能用30天。
还好界面风格很适合我,很快就上手了,但是由于自己UML的基础太薄弱,画起来也是费了好一番工夫。
(在此希望有好心人能给偶推荐点好一点的UML教程、资料,在Google上找到的都是一鳞半爪的,沮丧……)
好了,说说基本的需求(很简单):
终于有一天觉得这样不好,于是就想要按照规范的开发流程尝试一次——
正好手头要写的东西里有一个简单的新闻发布程序,就拿它练手吧(难点儿的怕一下子驾驭不来,打击士气)
上网找UML工具(虽然有PD,但是不太习惯),听人家说EA不错,就下载了一份下来,是试用版的,只能用30天。
还好界面风格很适合我,很快就上手了,但是由于自己UML的基础太薄弱,画起来也是费了好一番工夫。
(在此希望有好心人能给偶推荐点好一点的UML教程、资料,在Google上找到的都是一鳞半爪的,沮丧……)
好了,说说基本的需求(很简单):
- 此系统有三种用户:管理员,信息发布者,访问者
管理员: 负责管理所有账号,同时在必要时可直接进行信息管理
信息发布者:负责日常的信息发布
访问者:访问系统来浏览信息
- 所有种类的用户都必须在登录账号后才能进行相应的操作
就这么多,可以说是非常简单,下面是我画的用例图
几点问题:
1.怎样体现需求中的第二点,我是用了Dependency关系(见图中指向“系统登录”的三条虚线箭头),但不知道对不对。
2.管理员、信息发布者同时也可能是“访问者”,这一点是否有必要在图中有所体现?如是,如何体现?
3.“浏览信息”有无必要在图上列出,似乎这不在系统边界内。
4.如何从中抽象出业务对象,哪怕是谈谈经验也好
改版(2008年6月2日9:20:26)
今天又修改了一下,发觉似乎舒服一点了...
却原来、姹紫嫣红开遍,似这般、都付与断井颓痕 ——《昆曲·游园惊梦》