《Thinking in UML》 笔记——2、建模基础

建模基础

建模

建模(Modeling)，是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，内部结构和工作原理的便于理解的表达。

 

注：其实就是考察抽像能力。

 

建模工式

 

用例驱动

用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。用例驱动软件生产过程是非常有道理的。让我们再次回顾建模公式，很容易得出一个推论，要解决问题领域就要归纳出所有必要的抽象角度(用例)，为这些用例描述出可能的特定场景，并找到实现这些场景的事物、规则和行为.再换个说法，如果我们找到的那些事物、规则和行为实现了所有必要的用例，那么问题领域就被解决了。总之，实现用例是必须做的工作，一且用例实现了，问题领域就解决了。这就是用例驱动方法的原理。

 

在实际的软件项目中，一个软件要实现的功能通过用例来捕获，接下来的所有分析、设计、实现、测试都由用例来驱动，即以实现用例为目标。在统一过程中，一个用例就是一个分析单元、设计单元、开发单元、测试单元甚至部署单元。在统一过程中用例能够驱动的不仅仅是分析设计，请看下图的用例驱动视图，它来自统一过程。

 

·    逻辑视图：系统只有一个逻辑视图，该视图以图形方式说明关键的用例实现、子系统、包和类，它们包含在构架方面具有重要意义的行为，即建模公式中的那些“人”、“事”、“物”、“规则”、是如何分类组织的。

·    进程视图：为了便于理解系统的进程组织，在“分析设计”工作流程中使用了名为进程视图的构架视图。系统只有一个进程视图，它以图形方式说明了系统中进程的详细组织结构，其中包括类和子系统到进程和线程的映射，即建模公式中的那些“人”、“事”、“物”、“规则”是如何交互的，它们的关系如何。这个视图便是我们常说的分析设计视图。

·    部署视图：系统只有一个部署视图，它以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即建模公式中的那些“人”、“事”、“物”、“规则”是如何部署在物理节点(主机、网络环境)上的。

·    实施视图：实施视图的作用是获取为实施制定的构架决策。实施视图通常包括以下内容:

·    列举实施模型中的所有子系统。

·    描述子系统如何组织为层次和分层结构的构件图。

·    描述子系统间的导入依赖关系的图解。

    实施视图用于：

·    为个人、团队或分包商分配实施工作。

·    估算要开发、修改或删除的代码数量。

·    阐明大规模复用的理由。

·    考虑发布策略。

 

抽象层次

抽象层次是面向对象方法中极其重要，但是又非常难以掌握的技巧。学会站在不同的抽象层次考虑问题是建立好模型的基础，所以笔者不能不在这里说一些与技术无关的“废话"。

 

首先，抽象层次越高，具体信息越少，但是概括能力越强;反之，具体信息越丰富，结果越确定，但相应的概括能力越弱。从信息的表达能力上说，抽象层次越高表达能力越丰富，越容易理解。可能有人会对这个提出疑问，因为在人们的印象里，越是抽象的东西越难理解，相反越具体的事物越容易认识，难道不是吗?

 

视图

视图用于组织UML元素，表达出模型某一方面的含义。视图的准确应用是建立好模型的一个重要组成部分。视图的应用看上去似乎并不太复杂，但是在实际工作中很多人并不知道应该在什么地方应用视图、应用哪一种视图、部共需要哪些视图。

 

对象分析方法

要使用UML，面向对象的思想和方法是不可回避的。使用好UML的前提条件就是掌握了面向对象的思想和方法。

 

一切都是对象

在面向对象的眼里，一切有名字的东西都是对象，都应当使用对象的观点来看待它、分析它。哪怕这个东西的名字叫某某业务流程，它也仍然应当看作是一个对象，而不是一个过程。这意味着，无论什么时候都应当采用接下来讲述的一些观点和方法来看待和分析事物。

 

对象都是独立的

独立性是面向对象的一大特点，承认对象的同时就接纳了这一观点。对象与对象之间是天然独立的，只是在某个特定的场景下，它们的某一个特定的实例才相互联系在一起。

 

我们获取和分析对象的手段经常是通过分析某个场景，但是需要知道，对象是离散的，它不是因为该场景而存在的。场景中的对象只是对象“映射”到该场景中的一个侧面，我们称之为对象实例。换言之，通过一个场景，我们仅能得到对象的一个侧面的信息，如图所示。

 

对象都具有原子性

无论在什么时候，在分析过程中都应当将对象视为一个不可分割的原子，哪怕这个对象的规模很大。例如在分析一个商业过程的时候，对象的规模(粒度)大到如银行、工厂、商场的程度，不论它有多么巨大，只要我们认为它是对象，它与其他对象交互时就是一个整体，不能分割。

 

在分析过程中，对象总有一个边界，永远也不应该打破边界去窥探对象的内部。形象一些说，对象看上去就像是一个个的鸡蛋，蛋壳就是对象的边界。在分析对象的过程中，我们对它的所有理解都是来自蛋壳。如果因为我们好奇心太重试图了解壳以内的世界，冲动地打破了边界，嗯，的确看到了，好奇心得到了满足，不过很快就后悔了。因为鸡蛋被破坏了，一滩粘粘乎乎的蛋清弄脏了手，很难收拾。糟糕的设计就像一堆破了壳的鸡蛋，一片混乱。

 

我们应当将分析过程中得到的所有对于对象的认识附加在对象边界上，在实现这个对象之前不理会其内部的细节。这称之为面向接口编程。

 

对象都是可抽象的

对象有着很多个不同的方面。一般来说，对象参与一个场景时会展现出某一个方面。总可以将对象的某一个方面抽象出来，让其作为对象的一个代表来参与场景交互。通常这种抽象会以接口来命名。在分析过程中，得到的任何一个对象都有特定的方面可作为抽象。因为对象总是从场景分析中得到的，它在场景中肯定展现了一个方面。

 

对象所具有的方面，或者说对象所参与的场景越多，对象越有抽象价值，反之则越没有抽象价值。因此在分析过程中，应当关注于那些参与了很多场景的对象，它们往往是分析设计中的重点以及成败关键。

 

对象都有层次性

对象是有着抽象层次的。层次越高，其描述越粗略但适应能力越广。层次越低则描述越精确但适应能力越下降。在分析过程中，应当根据问题领域的复杂程度设定多个抽象层次，在每个层次上使用适合的抽象程度的对象描述.这将有助于显著地减少分析的难度和工作量。

 

不论是在需求、分析还是设计过程中，都应当具备抽象层次的观点。从需求到设计的过程已经是几个不同的抽象层次，笔者要说的是，在其中的一个阶段，例如需求阶段，仍然可以再多分几个抽象层次来说明。具体分多少抽象层次应视问题领域的复杂程度而定。

 

对象分析方法总结

独立性、原子性、抽象性和层次性是面向对象分析时应当遵循的一些原则和方法。在实际工作中，下图的几个方面是需要考虑的，如果该对象是一个关键对象，则应当尽量说明图中所示方面的内容。