为什么要建模 建模是一项经过检验并被广泛接受的工程技术。一个成功的软件组织有很多成功的因素，其中共同的一点就是对建模的采用。建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来，并对系统的体系结构进行可视化和控制。建模时为了更好地理解正在构造的系统，并经常提供简化和复用的机会。同时建模还可以管理风险。 模型是对现实的简化。模型提供了系统的蓝图。模型既可以包括详细的计划，也可以包括从很高的层次考虑系统的总体计划。一个好的模型包括那些由广泛影响的主要元素，而忽略那些与给定的抽象水平不相关的次要元素。每个系统都可以从不同的方面用不同的模型来描述，因而每个模型都是一个在语义上闭合的系统抽象。模型可以是结构性的，强调系统的组织；它也可以是行为性的，强调系统的动态方面。 之所以要建模，一个基本的理由是：我们建模是为了能够更好地理解我们正在开发的系统。通过建模，要达到四个目的：
1． 模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。
2． 模型允许我们详细说明系统的结构或行为。
3． 模型给出了一个指导我们构造系统的模板。
4． 模型对我们作出的决策进行文档化。 建模并不之针对大的系统。然而，可以明确地讲，系统越大、越复杂，建模的重要性就越大，一个很简单的原因是：因为我们不能完整地理解一个复杂的系统，所以我们要对它建模。人对复杂问题的理解能力是有限的。通过建模，缩小研究问题的范围，一次之着重研究它的一个方面。 建模有四项基本原理：
1． 选择要创建什么模型度日动手解决问题和如何形成解决方案有着意义深远的影响。
2． 每一种模型可以在不同的精度级别上表示。
最好的模型是这样的：它可以让你根据观察的角色以及观察的原因选择它的详细程度。分析人员或最终用户主要考虑“做什么”的问题；开发人员主要考虑“怎样做”的问题。这两类人员都要在不同的时间以不同的详细程度对系统进行可视化。
3． 最好的模型是与现实相联系的。
所有的模型都对现实进行了简化，但是有一点，不能简化掉任何重要的细节。
4． 单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理。
为了理解系统的体系结构，需要及格互补和连锁的视图：用例视图（揭示系统的需求）、设计视图（捕获问题空间和解空间里的词汇）、进程视图（对系统的进程和线程的分布建模）、实现视图（描述系统的物理实现）和实施视图（着重于系统的工程方面的组织）。每一种视图都可能有结构方面和行为方面。这些视图一起从整体上描绘了软件蓝图。
UML软件建模
统一建模语言（Unified Modeling Language, UML）是一种绘制软件蓝图的标准语言。可以用UML对软件密集型系统的制品进行可视化、详述、构造和文档化。
UML是一种富有表达力的语言，可以描述开发所需要的各种视图，然后以此为基础装配系统。它仅仅是一种语言，并且是软件开发方法的一部分。UML是独立于过程的，但最好把它用于以用例驱动、以体系结构为中心、迭代及增量的过程中。
为了理解UML，需要形成一个语言的概念模型，这要求三个主要要素：UML的基本构造块、支配这些构造块如何放在一起的规则和一些运用于整个UML的公共机制。 1．构造块
UML的词汇表包含3种构造块：事物、关系和图。
事物
事物是对模型中最具代表性的成分的抽象。
UML中有4种事物：结构事物、行为事物、分组事物、注释事物。
结构事物 (structural thing)是模型的静态部分，描述概念或物理元素。共7种结构事物：类、接口、协作、用例、主动类、构件、节点。
行为事物（behavioral thing）是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。行为事物有两类：交互 、状态机。
分组事物（grouping thing）是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是：包。
注释事物 是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。主要的注释事物是：注解。 关系
UML中有4种关系：依赖、关联、泛化、实现。
依赖（dependency）是两个事物间的语义关系，其中一个事物发生变化会影响另一个事物的语义。依赖有一些变体，如精华、跟踪、包含和延伸。
关联（association）是一种结构关系，他描述了一组链，链是对象之间的连接。聚合是一种特殊的关联，它描述了整体合部分之间的结构关系。
泛化（generalization）是一种特殊/一般关系，子元素的对象可替代父元素的对象。用这种方法，子元素共享了父元素的结构合行为。
实现（realization）是类元之间的语义关系，其中的一个类元制定了另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在接口合实现它们的类或构件之间；另一种是在用矿合实现它们的协作之间。 图
图（diagram）是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。除了非常微笑的系统外，图是系统组成元素的省略视图。有的元素可以出现在所有图中，有的元素可以出现在一些图中（很常见），还有的元素不能出现在图中（很罕见）。在理论上，图可以包含任何事物及其关系的组合。然而，实际上仅存在着少量的常见组合，它们要与5种最有用的组成了软件密集型系统的体系结构的视图相一致。由于这个原因，UML包括9种这样的图：
类图：展现了一组对象、接口、协作和它们之间的关系。在对面向对象系统的建模中所建立的最常见的图是类图。类图给出了系统的静态设计视图。
对象图：展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。
用例图：展现了一组用例、参与者（一种特殊的类）及其它们之间的关系。用例图给出了系统的静态用例视图。这些图对于系统的行为进行组织和建模是非常重要的。
顺序图：是一种强调消息的时间顺序的交互图；
协作图：强调收发消息的对象的结构组织。
（顺序图和协作图都是交互图，它们是同构的，这意为着它们是可以相互转换的。交互图专注于系统的动态视图。交互图展现了一种交互，它由一组对象和它们之间的关系组成，包括在它们之间可能发送的消息。）
状态图：展现了一个状态机，它由状态、转换、事件和活动组成。状态图专注于系统的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调对象行为的事件顺序。
活动图：是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象控制流程。
构件图：展现了一组构件之间的组织和依赖。构件图专注于系统的静态实现视图。
实施图：展现了对运行时处理节点以及其中的构件的配置。实施图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构件。 2．UML规则
不能简单地把UML的构造块按随机的方式放在一起。像任何语言一样，UML有一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。一个结构良好的模型应该在语义上是前后一致的，并且与所有的相关模型协调一致。
UML有用于描述如下事物的语义规则：
命名 ――为事物、关系和图起名
范围 ――给一个名称以特定含义的语境
可见性――怎样让其他人使用或看见名称
完整性――事物如何正确、一致地相互联系
执行――运行或模拟动态模型的含义是什么
UML的规则鼓励（不是强迫）专注于最重要的分析、设计和实现问题，这些问题将促使模型随时间的推移而具有良好的结构。 3．UML的公共机制
UML有4种贯穿整个语言且一致应用的公共机制：规格说明、修饰、通用划分、扩展机制。
规格说明：提供了一个语义底版，它包含了一个系统的各模型的所有部分，并且各部分相互联系，并保持一致性。因此，UML的图只不过是对底版的简单视觉投影，每一个图展现了系统的一个特定的方面。
修饰：UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上。
通用划分：在对面向对象系统建模中，至少有两种划分方法。一种是对类和对象的划分，一种是接口和实现的分离。
扩展机制：包括构造型、标记值和约束。构造型扩展了UML的词汇，它允许创造新的构造块，这个新构造块既可从现有的构造块派生，又专门针对你要解决的问题；标记值扩展了UML构造块的特性，允许创建详述元素的新信息；约束扩展了UML构造块的语义，它允许增加新的规则或修改现有的规则。
UML软件设计中的应用
UML在很大程度上是独立于过程的，这意味着它不依赖任何特殊的软件开发生命周期。然而，为了从UML中得到最大的收益，应该考虑这样的过程：
1． 用例驱动
2． 以体系结构为中心的
3． 迭代的和增量的
用例驱动意味着，把用例作为一种基本的制品，用于建立所要求的系统行为、验证和确认系统的体系结构、测试以及在项目组成员间进行交流。
以体系结构为中心意味着，要以系统的体系结构作为一种基本制品，用于在开发中对系统进行概念化、构造、管理和演化。
迭代过程是这样一种过程：它涉及到一连串可执行发布的管理。增量过程是这样一个过程：它涉及到系统体系结构的持续集成，以产生各种发布，当然每个新的发布都比上一个发布有所改善。
游戏设计师只有精通建模原理,游戏才能真正从技术上进行开发.而要精通建模,必须亲手作过才行.这些和程序关系不大,所以即使没有程序基础的人也能很快学会.重点和难点在于如何运用规则做出新的东西.
| 
说的好!
[em01]xiexie!