您的位置：软件研发->如何去设计一个系统
如何去设计一个系统2008-05-07 来自：java060515 [收藏到我的网摘]
想没有一个程序开发人员不把自己当成程序设计师在看（无论他现在是或者将来是），所以，我觉得良好的设计思路可以帮助我们慢慢走出属于自己路。上面四个步骤是前期设计工作的重要几步。我很理解一个程序员希望很快把自己的想法转换为具体的软件，但大多数时候，冲动是魔鬼。而且我也不反对，我们可以用XP思路的创建一个小模型，但我想说的是，如果我们站的高一点，思路开阔一些，是不是意味我们可以选择更好的路呢？
就像我们在程序中，设计接口（interface）一样，我们不急于完成实现，而是先定义抽象概念（程序依赖抽象而不要依赖实现 - 《Head First 设计模式》），再去完成实现。
这是我曾经给公司PDM/PLM 写了一个概念描述性文档,（12页，仍然觉得有需要修改的地方，限于保密条款不能给出全文）
目录
核心描述 2
物件（Item Base） 2
虚拟物件（virtual Item） 3
关联关系（relationship） 4
分类（Category Base） 4
物件模板（Item Template） 5
属性块（partBase） 5
属性定义（propertybase） 5
属性中的引用 6
属性表现（property presentation） 6
选择框selectBox 6
方面（aspect） 7
改动（ChangeBase） 7
状态点StateNode 7
用户组（UserGroup） 8
用户审核结果（AuditResult） 8
审核用户选择器（auditorSelector） 8
改动与表单填写内容的联系 9
用户、角色、权限的问题 10
用户（User） 10
角色组（RoleGroup） 10
权限（Access） 10
用户登录时序图 11
登录和权限控制 12
登录模块（login Provider） 12
业务表现层（Biz presentation） 12
模块定义（Module） 12
应用程序授权检查（license） 13
整篇文章就是讲述概念，就是讲述具体的系统抽象出来为什么样子。我想，只有深刻理解了这些东西才能把正确的它转化为要实现的系统，而且即使在设计或实现过程中，它仍然是被修改，被丰富的一个过程。
我觉得我们在设计时候必须要由一个好的模型，而模型不是几张图就搞定了（图是为了更好的理解），也要概念描述。理清这些概念，搞清楚之间的关系，建立一个合适的模型，我觉得很重要。
*注意
在设计讨论会上面的时候大家可以说说： 什么是这个系统的关键词？这些相似关键词之间由什么差别？关键词之间由什么样的联系，我们怎么来描述这些联系？什么是这个系统的关键行为，我们把它们归纳到哪一些关键词里面去？等等
因此，我觉得对于角色系统来说，当前重要的不是数据表，而去理清系统所涵盖的概念和模型。
引用评论 - 李涛
一点建议：可以再预备2到3种权限,以后扩展，这样更通用些。另外，排序也是一种权限，这个也可以考虑在内。
咋一听好像是加一个排序权限比较好。仔细一下，其实有点问题，首先，我们的系统开发出来是为了帮助客户来提高工作效率，那么，在此基础/前提，我们返回来看看“排序”是否能纳入到权限范围来？ 我个人认为不能。因为几乎没有一个系统会定义这个权限来限制用户。[仅做讨论无意打口水战]
既然谈到了权限系统，我也说说一个权限系统包括那些概念（See，Why don't I say Let's talk about systems?）
验证 - 在英语里面我们讲 Authentification， 容易跟Authorization（授权）搞混。不要一套系统一套验证系统，（我以前的公司有域验证，自定义验证，各种系统都拥有一套独立验证的模块，用户密码记一大推）请考虑一下，我们的设计前提，我们的系统是拿来提供用户工作效率，提升价值的。这么说，验证是否是独立开来？right！
再说说，用户信息（user profile），首先，部门信息和员工信息是不是在权限系统去掉后，没有什么影响？right！ 因此，拿掉它们。那么，我需要在系统使用这些信息怎么办？特别是授权的时候，总不能看一个用户Id授权吧？ OK！ 建立一个User Profile的实体类，而由Employee系统来实现IUserProfileProvider接口（罪过，罪过，怎么谈到实现了呢？）是的，我们的权限系统依赖的是接口，依赖的是抽像，而不是实现。
本文来自于 - ASTAR Coming Now - 博客园
就像我们在程序中，设计接口（interface）一样，我们不急于完成实现，而是先定义抽象概念（程序依赖抽象而不要依赖实现 - 《Head First 设计模式》），再去完成实现。
这是我曾经给公司PDM/PLM 写了一个概念描述性文档,（12页，仍然觉得有需要修改的地方，限于保密条款不能给出全文）
目录
核心描述 2
物件（Item Base） 2
虚拟物件（virtual Item） 3
关联关系（relationship） 4
分类（Category Base） 4
物件模板（Item Template） 5
属性块（partBase） 5
属性定义（propertybase） 5
属性中的引用 6
属性表现（property presentation） 6
选择框selectBox 6
方面（aspect） 7
改动（ChangeBase） 7
状态点StateNode 7
用户组（UserGroup） 8
用户审核结果（AuditResult） 8
审核用户选择器（auditorSelector） 8
改动与表单填写内容的联系 9
用户、角色、权限的问题 10
用户（User） 10
角色组（RoleGroup） 10
权限（Access） 10
用户登录时序图 11
登录和权限控制 12
登录模块（login Provider） 12
业务表现层（Biz presentation） 12
模块定义（Module） 12
应用程序授权检查（license） 13
整篇文章就是讲述概念，就是讲述具体的系统抽象出来为什么样子。我想，只有深刻理解了这些东西才能把正确的它转化为要实现的系统，而且即使在设计或实现过程中，它仍然是被修改，被丰富的一个过程。
我觉得我们在设计时候必须要由一个好的模型，而模型不是几张图就搞定了（图是为了更好的理解），也要概念描述。理清这些概念，搞清楚之间的关系，建立一个合适的模型，我觉得很重要。
*注意
在设计讨论会上面的时候大家可以说说： 什么是这个系统的关键词？这些相似关键词之间由什么差别？关键词之间由什么样的联系，我们怎么来描述这些联系？什么是这个系统的关键行为，我们把它们归纳到哪一些关键词里面去？等等
因此，我觉得对于角色系统来说，当前重要的不是数据表，而去理清系统所涵盖的概念和模型。
引用评论 - 李涛
一点建议：可以再预备2到3种权限,以后扩展，这样更通用些。另外，排序也是一种权限，这个也可以考虑在内。
咋一听好像是加一个排序权限比较好。仔细一下，其实有点问题，首先，我们的系统开发出来是为了帮助客户来提高工作效率，那么，在此基础/前提，我们返回来看看“排序”是否能纳入到权限范围来？ 我个人认为不能。因为几乎没有一个系统会定义这个权限来限制用户。[仅做讨论无意打口水战]
既然谈到了权限系统，我也说说一个权限系统包括那些概念（See，Why don't I say Let's talk about systems?）
验证 - 在英语里面我们讲 Authentification， 容易跟Authorization（授权）搞混。不要一套系统一套验证系统，（我以前的公司有域验证，自定义验证，各种系统都拥有一套独立验证的模块，用户密码记一大推）请考虑一下，我们的设计前提，我们的系统是拿来提供用户工作效率，提升价值的。这么说，验证是否是独立开来？right！
再说说，用户信息（user profile），首先，部门信息和员工信息是不是在权限系统去掉后，没有什么影响？right！ 因此，拿掉它们。那么，我需要在系统使用这些信息怎么办？特别是授权的时候，总不能看一个用户Id授权吧？ OK！ 建立一个User Profile的实体类，而由Employee系统来实现IUserProfileProvider接口（罪过，罪过，怎么谈到实现了呢？）是的，我们的权限系统依赖的是接口，依赖的是抽像，而不是实现。
本文来自于 - ASTAR Coming Now - 博客园
推荐人评论
想没有一个程序开发人员不把自己当成程序设计师在看（无论他现在是或者将来是），所以，我觉得良好的设计思路可以帮助我们慢慢走出属于自己路。上面四个步骤是前期设计工作的重要几步。
用户评论
正在载入评论列表...
是谁推荐了此篇文章
付江CSDN频道编辑
- 付江推荐的其他文章
