zoukankan      html  css  js  c++  java
  • 十年磨一剑,BloodyAngel!

     三个月没写日志了,比较懒散……下半年准备做OEA 的 B/S 版本,比较复杂,需要从架构设计开始认真入手。正好今天到了部门反思的时间,今天先把原来的一些设计经验总结一下,以方便将来回顾。

        直入主题,这篇日志主要用于总结一些框架级别的模块设计经验。

    总述


        一个大型的框架,必然由多个较独立的子系统/子模块构成。这些子模块如何交互,之间的接口如何定义,这是框架的架构设计的问题。而今天我主要要总结一下,针对其中的某一个子模块,应该如何进行设计。(例如,在 OEA 中有这些相对独立的模块:分布式框架、实体框架、界面生成框架、命令框架、产品线框架、分布式缓存框架、报表模块……)

        我在对一个模块进行设计时,大致经过以下流程:预设计阶段、逻辑设计阶段、设计评审、设计调整阶段、设计实现阶段、模块整合阶段。在一次单独的设计中,并不是必须要经过以上每一个阶段。例如,当模块比较简单时,就不需要设计评审、设计调整等阶段了。以下我逐一描述。

    预设计阶段


        设计开始之前,我们需要为设计做很多工作。其主要的目标是收集并整理模块的需求,力求结构化地描述需求。这些需求主要包括:场景需求、质量属性要求、环境约束。这个过程对于之后的设计过程相当重要,原因也很明显,不再赘述。

        场景需求包括:框架用户对模块的功能性需求、70%场景、20%场景、10%场景、API 需求。

        质量属性:参考国家标准。这里要分析出关键质量属性。

        环境约束:技术约束、系统环境等。比较常见的是对原有系统的兼容性。

        根据模块的复杂度不同,这个阶段的时间长短可能会有很大区别。例如,界面生成框架在 OEA 框架中是核心模块,在它的 2.0 版本的设计之前,我们平时会不断地收集前一版本的缺点及不足,做整理并使这些杂乱的需求结构化,这个工作“非正式”地做了一年,这些时间都可以算是在预设计阶段中。

        最后的交付物自然是:《模块需求规格说明书》。当然,文档这东西,主要用于沟通、传授。可以看情况而定,不一定有这个必要。但是,如果后面有正式的评审会议,这个文档最好还是准备一个正式的。

     

     

    逻辑设计阶段


        关键点:场景驱动设计、质量属性验证设计、环境约束验证设计。前者做加法,后两者做减法。

        设计师的经验越丰富,在这个阶段成功的机会也就越大。要满足一套关键质量属性,如果你之前没有遇到过类似问题的话,可能你觉得你的设计能实现,但是最后的事实往往不一定正确。而且设计不象数学那么严格,更象是艺术,艺术靠什么,灵感!所以这个阶段中,不同的设计师很可能会有不同的设计稿。(当然,如果这个模块比较简单的话,很可能设计就不会有什么区别了,毕竟,现有的软件设计的模式是很多的。)

        逻辑设计的方法主要还是画图。其中主要还是依据一些通用设计的原则进行设计。

        画什么?主要是 UML 中的两类图:静态结构图(包图、类图);动态结构图(序列图)。

        顺带说一句,很多设计人员可能会坐在电脑旁边直接拿 EA 等工具画图。但是我个人比较喜欢的方式是:

    1. 先用纸笔来画一些手稿。
      这个方式主要是比较方便,任何地点都可以画,例如开一些不重要的会议的时候,就可以随手画画。而且最后看着许多有用的手稿,感觉还是很有成就感的,跟画家似的~哈哈。
    2. 随时想、随时画:
      我觉得,一些复杂的设计不是简简单单就能想出来的,特别是我觉得自己的智商只是处于常人智商的范围中,要想出一些卓越的设计,不可能只是坐在办公室的那一点点时间。(我记得我曾在梦中想出了一些醒着的时候想不出来的东西……)
    3. 汇总成正式设计稿。

        交付物:UML 图!这是必须的!

        这个阶段中,主要考虑质量属性及关键需求。

        要提升该阶段的能力,个人再次推荐几本著名的书籍:《Pattern of Enterprise Application Architecture》,《Microsoft Application Architecture Guide》,《Enterprise Solution Patterns Using Microsoft .NET》。

    设计评审


        召开设计评审会议的原因:

    1. 人无完人,个人的想法很可能有问题。
    2. 听取更有经验的人的指点。
    3. 团队协作、团队沟通。
    4. 听取模块使用者的建议。

        所以,如果不是十万火急,都建议召开评审会议!

        我主持过的评审会议,曾经出现了许多的问题,大家可以看看我当时的反思:《反思 - 组内设计评审会议》,不要出现和我一样的错误。

     

    设计调整阶段


        没啥,看评审会议的结论。要么做些小的调整,要么大改动,甚至重新设计。如果改动较大,别忘了最后再召开一次评审会议。

     

    设计实现阶段


        这个阶段包含了设计的代码验证阶段。

        可能由于公司的组织结构不同,这个阶段并不一定由设计师自己去完成。但是我建议不要完全由他人完成,设计就象是自己的孩子一样,辛苦辛苦把他生下来,你让别人来把它抚养大,不觉得奇怪吗?如果你觉得你要设计的东西太多,没时间完成,我觉得你还是少做一些,做好一些会更好。

        建议实战能力弱甚至没有实战能力的设计人员不要再做设计了,先好好在底层磨炼磨炼吧。设计师从程序员成长而来,架构师从设计师成长而来,这才是务实的做法!

        这个阶段考验的是设计人员的代码实现能力,团队协作能力。代码的实现能力往往真正能看出一个人的设计能力。软件设计原则大家都会说,但是,要真正把这些原则应用到代码实现中,却需要时间的不断磨炼。如果开发组里能有几个为技术痴迷的人,那是最好不过的了。

        实现相对于设计稿,可以有一些更多的灵活性,并不一定要100%符合设计稿,这是因为代码实现本身就是一种微观的设计。但是必须要求80%以上是要符合设计稿的。如果实现过程中,不得已有过多的部分不符合当初的设计稿。请:召开讨论会议!重新画图描述当前设计!总结反思!

        值得一说的是,实现阶段需要着重对使用场景进行 721 分析,设计良好的 API 以应对这些场景,并配以相应的单元检测。关于框架设计中的场景驱动设计,大家可以看这篇文章推荐的书籍:《Framework Design Guidelines 2nd Edition》

    模块整合阶段


        其实这个阶段中的工作在上一阶段中需要准备好,也就是说,在进行编码时,需要不断考虑所设计的代码能否在大的环境中运行。所设计的接口是否能和当前系统正确的衔接上。如果之前的代码没有考虑足够,在这一整合阶段中,可能会发生一些集成的问题。不过这种情况我遇到的比较少,这里就不展开了。

        这阶段完成后,最好能配上集成测试。(不过我目前都没有做过。)

    演进模块的考虑点 


        在整个框架的架构设计完成之后,其中所涉及到的模块分两类:一类是在架构设计时已经考虑到并明确定义的模块;另一类是架构初始设计时并没有考虑到,但是随着系统逐渐演进,发现必须被添加进来的模块,我简称其为“演进模块”。两种模块的设计有许多相同之处,相对而言,设计演进模块时,相对要需要考虑更多的东西。

        针对演进模块,在预设计阶段,约束中需要重点写明历史系统对当前模块的兼容性约束。在设计阶段,需要分析当前系统,从中找到突破口。

        兼容性是很麻烦的一种约束,为了满足这种约束,常常会使简单的设计变得复杂。最后的代码也很可能写得不符合规范。在以后的新版本中,如果做出不再兼容这些历史代码的决定时,这些兼容性设计需要被删除。

    设计失败的常见原因 


    1. 预设计阶段工作做得不充足。
      未收集场景、早早地进入了逻辑设计阶段、甚至直接开始编码,导致最终设计了不需要的部分,或者根本满足不了需求。
    2. 过份自信,未召开评审会议。
    3. 设计经验不足。(逻辑设计要求经验、灵感)
      提升方案:多把现有系统画出来。架构模式、设计模式都熟了吗?平时有没有花非工作的时间多设计些东西?书看太少了?
    4. 编码能力不强。(代码实现要求实战家。)
      提升方案:天天写些无聊的代码?非工作时间有多少花在代码上?书看太多了?
    5. 逻辑设计、代码实现分两波人做。

     

    总结


        这篇文章是基于目前我的设计经验总结而成,将来可能会不断更新……

        同时,希望和园友们交流设计经验。更加希望平台开发人员能和我一起交流平台级别的开发。

        可以短信我,交换QQ和EMail。

    http://www.cnblogs.com/zgynhqf/archive/2011/07/15/2107593.html

    http://www.cnblogs.com/umlonline/archive/2011/07/15/2107207.html

    做一回软件架构师 - 视频分享第2弹!

    视频内容概述
    这是去年受海南软协的邀请,在海南省海口市所做的一场分享。课程集中火力在部署图、组件图、包图,体会如何利用这三种图做出“高性价比”的软件架构设计,让每位学员做一回软件架构师。将UML知识融入到具体的实例中,而不会单调地讲UML语法。案例一个接一个,贯穿整个课程,学员需分组讨论和思考。

    作者:张传波
    讲师:张传波

    课程目标
    通过本课程,学员能把握软件架构设计的关键点,学会“需求驱动”地设计,学会用例图,能综合应用部署图、组件图和包图,在实际工作中进行软件架构的工作。

    适合听众
    项目经理、系统分析师、设计人员、开发人员、测试人员、有一定编程经验并且对软件设计或UML感兴趣的人士。

    课程大纲
    1.什么是“漂亮”的设计?——高性价比的设计
    2.理解需求——优秀设计的开始
    3.描绘系统的骨架——部署图
    4.构造骨架及可重用设计——组件图
    5.组织你的设计——包图
    6.做一回软件架构师——综合应用部署图、组件图、包图

    浏览视频注意事项:
    1.本课程视频有6小段,总时间共130分钟。
    2.所有视频按顺序加起来才是本课程的完整视频,视频有逻辑上的先后关系,第一次观看请按顺序观看,这样才能达到最佳学习效果
    3.现场课程有很多提问、讨论等,请适时地按下暂停键,先自己思考和练习后再继续观看,这样学习效果更好!
    4.本课程UML图比较多,视频可能看不清楚,请全屏播放,或者下载本课程的教材,一边看教材一边看视频。
    5.我们使用优酷网发布视频,优酷网可能会插播广告,敬请留意。
    6.视频是高清精度的,需要比较大的带宽,但一般家庭的宽带是足够的,但如果在公司则要视乎公司的网络情况了。
    7.部分视频有播放密码,密码为:umlonline

    1.什么是“漂亮”的设计?——高性价比的设计 (15分钟)


    2.理解需求——优秀设计的开始 (29分钟) 播放密码:umlonline


    3.描绘系统的骨架——部署图(12分钟) 播放密码:umlonline


    4.构造骨架及可重用设计——组件图(26分钟) 播放密码:umlonline


    5.组织你的设计——包图(10分钟) 播放密码:umlonline


    6.做一回软件架构师——综合应用部署图、组件图、包图(38分钟) 播放密码:umlonline


    如果你觉得上述资料有用,欢迎你点击一下“推荐”,谢谢支持!

    张传波 软件知识原创基地 www.umlonline.org
  • 相关阅读:
    ***25 k个一组反转链表
    24 交换链表中相连的节点
    19 删除链表倒数第N个节点
    2 两数相加
    23 合并K个有序链表
    21 合并两个有序链表
    114 判断一个链表是否存在环并返回环起点
    141 链表是否存在环
    160 寻找链表交点
    92 指定区间链表逆置
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/2107871.html
Copyright © 2011-2022 走看看