系统分析和设计方法之使用UML进行面向对象设计和建模

使用UML完成系统建模是一件不错的事，不过在权衡进度、成本之后，大体上会知道能不能做。并不是对系统好的事情我们都要完成，重点在于资源约束。此处只是在资源约束满足时，应该怎么处理UML设计的通用流程，在实际工作场景中要根据要求做取舍。这是一篇科普文。

1. 设计面向对象系统
2. 面向对象设计过程
3. 对象复用和设计模式
4. 设计模式
5. 其他UML设计图和实现图

 

1.设计面向对象系统

面向对象设计（OOD）的目标是说明系统的对象和消息。实体类通常对应现实生活中的实体。接口类是实现用户界面与系统之间通信，也包括系统与系统之间、系统与部件之间等等的通信。控制类实现业务逻辑和业务规则。一般系统具有实体类、接口类、控制类就基本够用了。 持续类的属性是持续的，这些属性会超越系统运行而继续存在，例如数据库某张表的映射类就是持续类。系统类将其他对象从操作系统相关的功能独立开来，当系统被移植时，只有这些系统类和接口需要修改。系统类一般会让我们想到面向对象语言的虚拟机，虚拟机就是为了解决系统兼容问题的。

对象之间的关系有：关联关系、聚合关系、泛化特化关系。

对象的责任是通过对象的方法来体现的。

2.面向对象设计过程

面向对象设计包括以下活动：

1).对用例模型加以精炼以反映实现环境

2).建模支持用例情境的对象交互、行为、状态

3).修改对象模型以反映实现环境

精炼用例模型，主要包含两个步骤，第一步：将分析用例转换成设计用例，希望可以完成将设计用例变得相对独立，以获得更好的物理实现复用的灵活性；第二步：修改用例模型图和其他文档以反映新用例。做完这些之后，每个用例都会高度精炼地细化，并且描述了用户和系统的交互。

建模支持用例情境的对象交互、行为、状态，主要包含了四个步骤，第一步：确定并分类用例设计类，将设计用例需要用到的类进行分类；第二步：确定类属性，包括从分析设计期间确定的属性、用例文本中的属性、附加属性等等；第三步：确定类行为和责任，它的任务有分析用例以确定系统行为、关联行为和责任到类、建模具有复杂行为的类、检查类模型附加行为、验证分类，这些活动看上去很冗余，需要认真考虑一下要不要这么做；第四步：建模对象的状态，并不是所有的用例和场景都需要，不过针对状态区别比较明显而且比较多的情况下，还是需要状态机图来描述一下的。

修改对象模型以反映实现环境，主要内容是精炼活动2)的各种类图和设计图。

 

3.对象复用和设计模式

面向对象设计的两个决定性目标是低耦合和高内聚。低耦合和高内聚是为了达成对象复用，这是在代码层面的复用。想想现在多少项目因为工期的原因不得不放弃良好的设计进行强行赶工，虽然项目完成但是质量和对象复用就处于比较尴尬的地位，这个时候设计模式、对象框架、组件的复用就慢慢兴起。更高层次的复用是经验的复用，设计思想的复用。

 

4.设计模式

设计模式是从过去成功的经验中抽取应对某些问题的处理套路，并记录下来。一旦在实际应用中遇到跟这些问题类似的情况时优先考虑对应的设计模式，如果适合将降低很多的成本，提高很大的处理效率。从另个侧面来说，根据问题判断并选用合适设计模式需要经验积累，而且处理问题也不一定就必须使用设计模式，合理最重要。

 

5.使用其他UML设计图和实现图

组件图是一种实现类型的模型图，用于以图形化方式描述软件系统的物理架构。部署图是实现类型的模型图，描述了系统中硬件和软件的物理架构，即描述构成系统架构的软件组件、处理器和设备。这两种图也是比较常见的用于UML设计的图形。