业务模型说明（商业模式的九大要素是什么 简要概述）

举例说明描绘软件现实业务存在的模型？为什么要建模
软件建模中的三个模型是指业务模型、功能模型和数据模型。
功能模型是描述系统能做什么什么，即对系统的功能、性能、接口和界面进行定义。
业务模型是描述系统在何时、何地、由何角色、按什么业务规则去做，以及做的步骤或流程，即对系统的操作流程进行定义((怎么做 ))。
数据模型是描述系统工作前的数据来自何处，工作中的数据暂存什么地方，工作后的数据放到何处；以及这些数据之间的关联，即对系统的数据结构进行定义(数据怎么组织 ) 。
三个模型建模思想的优点：简单、直观、通俗、易懂、易学、易用，非常适合于关系数据库管理系统RDBMS RDBMS支持的信息系统。缺点还入门容易，但想搞懂成为高手就难了。
业务建模的主要任务

项目涉众的共同愿景：要想项目成功，可离不开项目涉众的支持。在项目一开始，不论是项目涉众还是开发人员，对项目的任务、范围都是模糊不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必要在项目导入之前，先在项目涉众中竖立一个共同的愿景。
共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致的时候为止。在共同远景的竖立过程中，其实有两件事情也已经同时做了，项目范围（scope）和高阶（high-level）需求。
项目范围：项目该做什么，不该做什么，需要在一开始就有明确的定义。对于项目范围内的需求，一个也不要放过，而项目之外的，一个也不要去关心。虽然有的时候，范围的变化会有利于项目本身，例如客户的合理要求或是市场目标客户的变化，但是这种变化应该要在资源能够支持和得到审批的前提下进行。
项目范围的描述可以通过陈述和图示来进行。我建议大家使用图示。因为陈述语句比较含糊不清。例如常常听到有客户说。我要建立我公司的电子商务系统。这句话就是含糊不清的，你的电子商务系统是销售什么产品？面向什么客户？是否要支持在线支付？根据这些疑问，这个陈述句可以做进一步的修改，建立在线订货系统，针对当前的目标客户销售公司的目前产品。这样就清楚许多了。不过图示的方法会更好一些，在图的选择上，你可以使用DFD图或是用例图。根据经验，DFD图比较容易为客户所接受。
高阶需求：这个部分我们在下面会详细讨论。既然是高阶需求，就不能讨论过多的细节。在讨论高阶需求的时候，尽量保证快速的讨论出系统的概貌，建立需求模型，得到项目涉众的一致通过。
取得支持：为了保证需求计划的顺利进行，取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利和义务，以及开发人员的权利和义务。在这个方面，具体的我不想多说，大家可以参考『软件需求』的第二章。主要的就是涉众有改变需求的权利，同时要承担向开发人员讲解需求的义务。开发人员的权利和义务正好和涉众相反。
业务建模会议：所有的这一切都通过业务建模会议进行，和其它会议不同的是，这个会议需要所有的项目涉众参加，如果不能获取所有项目涉众的意见，那就不是完美的。会议中最重要的工具就是白板，一位出色的速记员也是必须的。

业务分析和业务建模用什么方法和工具
UML是面向对象的分析设计方法，DFD是面向数据流的设计方法。当然UML功能强,表述容易清晰,对将来采用面向对象的实现会省很多力气。UML是面向对象分析方法的表达工具,涉及的图包括用例图,活动图,类图,时序图,协作图,状态图等等;可以涵盖从需求分析到设计,编码整个开发过程用到的模型。DFD是面向过程分析方法的表达工具,功能大概等价于用例图,活动图,加上E-R模型,可以涵盖面向过程分析(业务建模,概念建模)中所用到的模型。