软件开发和运营的建模

铅笔小星

    模型是真实世界中对象和系统的"简化"抽象,可忽略大小、细节和外观(例如,一个关注成本或持久性,而忽略不相关系统因素的模型).在信息技术解决方案的开发中,模型被用来控制复杂度,并在客户、解决方案和系统架构师、开发者和运营人员之间传达系统需求.

　　以工程项目大量使用的模型为例:

    用例模型可表达系统的高级功能需求和需要被支持的角色;

    风险模型可通过尽早地在项目周期中规避风险来优化工作;

    实体关系模型捕捉被解决方案管理的基本信息,并且提供将其适当分解为表格、对象和服务的建议;

    逻辑系统模型组成了开发和运营之间的通信基础;逻辑系统模型可以进行需求和解决方案策略的早期确认,等等.

　　所有这些模型都使项目参与者能在最终系统的开发和管理中发挥其专长.所有这些模型都通过尽早避免误解和疏忽来减少项目的代价和风险.建模工具和框架通过在各个级别的方案设计中提供更高级别的追溯性、可视性和说明性促进了商业部门和信息技术团体的合作.

　　在整个的软件生命周期-从开发概念形成到运营和管理中,微软关注如何使模型更有使用价值.由于历史原因,在生命周期中通行的仅有的模型是含义模糊、冗余和很不完善的模型,而且是使用系统源代码所描述.系统模型之间的不协调经常在组织内部和其间造成理解和沟通错误,导致项目和系统的失败.

    微软的目标是让所有的项目参与者--技术人员,专家和管理者都能够获取公司组织系统最适时、精确和有效的描述,并表达为各自熟悉的语言;

    微软的意图是使所有的项目参与者--从商业分析员到数据架构师,还有安全专家和网络工程师,在解决方案的开发过程中尽可能的发挥他们的专长,尽量减少信息和知识的损失.

    某些模型力图在多个抽象层面上描述一个完全的系统,另外的模型则着重于系统的某些特定方面,诸如怎样保持安全性,或者从系统的各个方面跟踪性能表现.某些模型与解决的创建和开发过程有关,还有一些则预测并分析其在运营中的行为.

　　用例图有可能是软件工程中的最简单的"完全"模型:系统的用例集合建立了对系统功能的展望,为系统用户确定角色,并且提出了对运营的需求.用例可以发展成商务过程模型,派生出详尽的需求模型,数据模型,对象模型,和最终的可编辑模型.这些模型的层叠使人们联想起软件工程中熟悉的"瀑布"的概念.

    系统建模的一个更好的概念是一系列的锁定.不是随随便便的,被工具支持的系统化过程应该在良好的管理下从一个模型递交给下一个模型.递交过程应该是平滑可预见的.最重要的是,这些递交应该是双向的.用例应可以被转换成为商业过程模型,而商业过程模型也应该是能转换成用例的(虽然由于信息损失,你不能全保真的完成从客观到抽象再到客观的完整转换周期).理想情况下,这种映射的阶梯流要允许所有描述系统的模型之间的同步.

　　在项目中支持这些相互映射模型的集合,将产生模型驱动 (model-driven development MDD)的开发模式.在MDD中,模型成为开发过程中的最重要的原材料之一.当一个系统架构模型允许或禁止横跨企业数据中心安全区域的信息路径时,这个模型就指导和约束了服务模型,很有可能影响服务设计.当数据架构模型确定数据访问方法,工具就产生代理代码和语言捆绑.

    MDD并不是一种全新的想法,成功的实现了模型同步的例子包括:多视图数据建模工具,它可以使图例化模型;基于实体的模型,和相关的数据架构都保持同步;还有可以在开发中保持外观和代码模型一致性的集成开发环境设计器。我们可以从这些案例中汲取成功经验以大大扩宽MDD的应用范围。

    其中的挑战之一,就是开发一种可以被系统生命周期过程中的所有参与者都成功使用的建模工具,但语言经常成为障碍:安全分析师需要使用和安全相关的词汇和语法来表达要求.理想地,这种语言的图例将支持使用直观的符号和连接线来"画"出详细的要求.

    已经有了一些这样的工具来支持诸如数据库设计、用户接口设计和对象建模等工作.类似的领域描述语言(DSL)也可以被很容易的开发出来,用于加强从公司官员到金融分析人员等项目的不同参与者的工作能力.

　　软件开发和运营的建模

    除领域描述语言(DSL)和建模工具之外,我们必须严格地定义模型之间的关系.我们要彻底支持的整套模型是什么?记录系统各个方面的模型是什么?每个模型是如何映射到其他相关模型的?对模型的手动修改是如何同步到系统模型的其余部分?开发环境必须与这些"原模型"整合,并且加强模型之间的关系,特别是对记录系统各方面模型的修改约束.

　　有效的模型驱动开发能大大地增加软件生命周期中的自动化程度.各领域专家提供的明确模型将大大地减少在需求收集过程中的信息丢失.有明确工业内容的模型将帮助减少不一致或不适合的实施的风险,改进跨平台协作.开发和运营模型的同步将在部署阶段帮助避免问题.

    坚持建模框架将防止产生"被忽略"的需求.模型之间的自动转换将减少编码差错和开发时间.维护所有模型的可用和互通将有助于获得来自所有项目参与者的及时反馈,避免工程出现偏差的惨重损失.

　　微软通过其软件工厂启动计划,努力在其动态系统启动计划(Dynamic Systems Initiative DSI)和Visual Studio Team System中积极地追求并达到这个目标.

　　DSI使用系统定义模型(System Definition Model SDM)--一种描述分布式系统和他们运营平台的模型--来在开发和运营之间协调同步.SDM可以根据软件组件对工作所要求的资源（例如CPU周期）,以及对别的组件和服务的依赖性来对他们进行建模.同样地,SDM也可以对数据中心中的逻辑机器类型和安全区域建模,这依赖于他们可以提供给软件组件的资源.

    有了SDM,一旦解决方案被部署和运行,并行的解决方案模型和托管工作环境就被建立起来,而且可以进行有效模拟,确认设计,计划和资源的动态分配.Visual Studio .NET 2005建模工具支持SDM,Microsoft Operations Manager (MOM)和Microsoft Systems Management Server (SMS) 的未来版本也都将支持SDM.

　　软件工厂通过促进DSLs和领域描述框架的使用来提升开发过程的自动化,最终的目标是使微软自己的集成开发环境--Visual Studio .NET,可以被配置成为创建特定类型的软件组件和解决方案的"工厂".例如,有价证券交易应用的工厂将整合适用于金融服务组织结构、会计实践和贸易实践的模型.

    今天,大多数系统模型的有效生命周期很短,很快成为"漂亮的图画"—书面上的摆设.模型之间没有明确和平顺的映射,系统的非代码表示很快就失去了他的可靠性和准确性.有了正确的端到端的建模工具和框架,我们就能使软件的开发、部署和管理更一致,更负有责任,并且可以和商业目标更好的结合.

从不知

一楼的位置好啊..  

时光倒流

好困啊  

游手好闲

真的有么  

aizhijia

谢谢楼主啊！

bestquality

帮顶  

bestquality

支持你一下下。。  

c1532

哦...............  

titmc

挺好啊  

hasee

我在努力中