1,265
社区成员
发帖
与我相关
我的任务
分享UML好文章系列三
接（二）
二． 做些准备工作
别把建模当回事（当然说这个话是有目的），建模就是让别人知道如何操作自己而来实现别人对你的要求。模也就是一个Document（使用MFC的兄弟应该对此有很深的体会），但如何把Document叙述的详尽，完整和条理，为此我们（当然不包括我了）利用UML定义了一套标准来规范文档的写作。
为此，理解你要实现的东西是一件建模初期的事，在理解的基础上我们并不能忽略现实的简单性，所以，好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。 我在工程的实践中，遇到了一系列问题，但问题反映出来，其原因有如下几个大问题：
1． 设计者就是设计者
设计者如此费力地把模型搭建起来，然后再费力向各个程序员详细地说明该软件开发的具体步骤，若程序员的水平太差，再给他们写些原代码示例，如此以来，还不如自己写算了，设计者就是设计者，并不需要实际深入地参与软件原代码开发，但应参与其他文档地编制。习惯了好象我们成了幼儿园的老师。 2. 教育你的程序员
你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。
教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。其实该问题是如此地实际，但也正是该问题困扰着我目前的开发状况，例如：我用Playcase的开发工具做了一套流程，使得程序编写起来模块化，第一没有人看懂如此设计文档，我开始讲述如此建模知识；第二有些开发人员学习过其他的建模语言，对此开发工具指手划脚，其实工具并不重要，重要的是用它来实现东西。
另外，你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候，你的团队才能实现真正的合作。
3. 在现有任务中应用多个模型
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。
当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。
程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。
4. 证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。软件的设计最忌讳的就是使用不成熟的技术来开发软件产品，我的朋友和谈天的时候说：“我用最成熟技术开发最实用的软件”,“首先客户需要的是一个成熟的软件，稳定、可靠，如果采用最新的技术，由于没有经过时间的检测，不能保证其运行的稳定性”。
你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。
5. 管理接口和使用接口组件
你应该在开发阶段的早期就定义软件模块之间的接口。我是电子商务软件的，对于COM/DCOM组件的使用需要深入地研究下去，这个研究的目的就是使得软件模块的接口方便、简易、易于管理。
接口或接口型组件将有助于开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工一旦模块的接口确定之后，模块怎样实现就不是很重要了。从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。我想再说一次爱因斯坦的话：“外部的证实，内部的完备”。
6. 软件的移植性和封装
移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（当然广告的宣传是带有软件的商业性质）。
即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。记得从16 位Windows 移植到32 位windows 的“乐趣”吗 （微软公司又开始挣我们的钱了）？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程(DCOM/Istorage或其他策略)。你的软件和那个特定的产品结合度就已经很高了。
好的软件设计者把那些特有的实现细节打包隐藏起来—我比较随便把这种东西叫封装（也可能我是C++等OO技术的爱好者），所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。
7. 降低软件模块间的耦合度
高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动，其实这种变动在数据库领域内更让你有很深的体会，尤其是现在人们常用的关系数据库，修改起来很象株连九族一样。
你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。
耦合度低的软件可以很容易被重用、维护和扩充(那什么软件耦合度低—采用中间件，这么这些都是我喜欢的)。
8.最后的绝招
询问.学习.整理。
这个没有人教的，全是我悟出来的。但这是软件设计人员的过程：1、询问客户建立需求文档；2、学习研究需求文档，测试设计的可行性；3、整理文档，编写设计文档。
二． 做些准备工作
别把建模当回事（当然说这个话是有目的），建模就是让别人知道如何操作自己而来实现别人对你的要求。模也就是一个Document（使用MFC的兄弟应该对此有很深的体会），但如何把Document叙述的详尽，完整和条理，为此我们（当然不包括我了）利用UML定义了一套标准来规范文档的写作。
为此，理解你要实现的东西是一件建模初期的事，在理解的基础上我们并不能忽略现实的简单性，所以，好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。 我在工程的实践中，遇到了一系列问题，但问题反映出来，其原因有如下几个大问题：
1． 设计者就是设计者
设计者如此费力地把模型搭建起来，然后再费力向各个程序员详细地说明该软件开发的具体步骤，若程序员的水平太差，再给他们写些原代码示例，如此以来，还不如自己写算了，设计者就是设计者，并不需要实际深入地参与软件原代码开发，但应参与其他文档地编制。习惯了好象我们成了幼儿园的老师。 2. 教育你的程序员
你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。
教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。其实该问题是如此地实际，但也正是该问题困扰着我目前的开发状况，例如：我用Playcase的开发工具做了一套流程，使得程序编写起来模块化，第一没有人看懂如此设计文档，我开始讲述如此建模知识；第二有些开发人员学习过其他的建模语言，对此开发工具指手划脚，其实工具并不重要，重要的是用它来实现东西。
另外，你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候，你的团队才能实现真正的合作。
3. 在现有任务中应用多个模型
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。
当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。
程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。
4. 证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。软件的设计最忌讳的就是使用不成熟的技术来开发软件产品，我的朋友和谈天的时候说：“我用最成熟技术开发最实用的软件”,“首先客户需要的是一个成熟的软件，稳定、可靠，如果采用最新的技术，由于没有经过时间的检测，不能保证其运行的稳定性”。
你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。
5. 管理接口和使用接口组件
你应该在开发阶段的早期就定义软件模块之间的接口。我是电子商务软件的，对于COM/DCOM组件的使用需要深入地研究下去，这个研究的目的就是使得软件模块的接口方便、简易、易于管理。
接口或接口型组件将有助于开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工一旦模块的接口确定之后，模块怎样实现就不是很重要了。从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。我想再说一次爱因斯坦的话：“外部的证实，内部的完备”。
6. 软件的移植性和封装
移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（当然广告的宣传是带有软件的商业性质）。
即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。记得从16 位Windows 移植到32 位windows 的“乐趣”吗 （微软公司又开始挣我们的钱了）？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程(DCOM/Istorage或其他策略)。你的软件和那个特定的产品结合度就已经很高了。
好的软件设计者把那些特有的实现细节打包隐藏起来—我比较随便把这种东西叫封装（也可能我是C++等OO技术的爱好者），所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。
7. 降低软件模块间的耦合度
高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动，其实这种变动在数据库领域内更让你有很深的体会，尤其是现在人们常用的关系数据库，修改起来很象株连九族一样。
你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。
耦合度低的软件可以很容易被重用、维护和扩充(那什么软件耦合度低—采用中间件，这么这些都是我喜欢的)。
8.最后的绝招
询问.学习.整理。
这个没有人教的，全是我悟出来的。但这是软件设计人员的过程：1、询问客户建立需求文档；2、学习研究需求文档，测试设计的可行性；3、整理文档，编写设计文档。
...全文
请发表友善的回复…
发表回复
wltsui 2003-04-08
- 打赏
- 举报
good!
