组件应该对外延具有开放性，对修改具有封闭性
例如：类类型的扩充（增加动作传感器）
例：接口污染：有太多的不必要的接口方法
例：接口分离的设计
子系统之间的关系：
根据分析阶段产生的高层类图和交互图，由用例设计师研究已有的类，将它们分配到相应的用例中。检查每个用例功能，依靠当前的类能否实现，同时检查每个用例的特殊需求是否有合适的类来实现。细化每个用例的类图，描述实现用例的类及其类之间的相互关系，其中的通用类和关键类可用粗线框区分，这些类将作为项目经理检查项目时的重点。
类是包含信息和影响信息行为的逻辑元素。类的符号是由三个格子的长方形组成，有时下面两个格子可以省略。最顶部的格子包含类的名字，类的命名应尽量用应用领域中的术语，有明确的含义，以利于开发人员与用户的理解和交流。中间的格子说明类的属性。最下面的格子是类的操作行为。
实体类源于业务模型中的业务实体，但出于对系统结构的优化，可以在后续的过程中被分拆、合并
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。用于描述外部参与者与系统之间的交互，对系统中依赖于环境的那些部分进行建模。
由构件工程师详细设计每个类的属性、方法和关系。
用所选择的编程语言定义每个类的属性。类的属性反映类的特性，通常属性是被封装在类的内部，不允许外部对象访问。
分析阶段和概要设计阶段定义的一个类属性在详细设计时可能要被分解为多个，减小属性的表示粒度有利于实现和重用。但是一个类的属性如果太多，则应该检查一下，看能否分离出一个新的类。
如果一个类因为其属性的原因变得复杂而难于理解，那么就将一些属性分离出来形成一个新的类。
通常不同的编程语言提供的数据类型有很大差别，确定类的属性时要用编程语言来约束可用的属性类型。定义属性类型时尽可能使用已有的类型，太多的自定义类型会降低系统的可维护性和可理解性等性能指标。
类的属性结构要坚持简单的原则，尽可能不使用复杂的数据结构。
由构件工程师为每个类的方法设计必须实现的操作，并用自然语言或伪代码描述操作的实现算法。一个类可能被应用在多个用例中，由于它在不同用例中担当的角色不同，所以设计时要求详细周到。
注意事项：
分析类的每个职责的具体含义，从中找出类应该具备的操作。
阅读类的非功能需求说明，添加一些必须的操作。
确定类的接口应该提供的操作。这关系到设计的质量，特别是系统的稳定性，所以确定类接口操作要特别小心。
逐个检查类在每个用例实现中是否合适，补充一些必须的操作。
设计时不仅要考虑到系统正常运行的情况，还要考虑一些特殊情况，如中断/错误处理等。
设置基数：一个类的实例与另一个类的实例之间的联系。在图书馆信息管理系统中，“图书”类和“读者”类关联，如果需求说明中有“一位读者可借图书的数量为0至10本”，那么它们之间的基数为1：0..10。
对象（Object）
生命线（Lifeline）
消息（Message）
激活（Activation）
顺序图中对象的符号和对象图中对象所用的符号一样。
将对象置于顺序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。
参与者和对象按照从左到右的顺序排列一般最多两个参与者，他们分列两端。启动这个用例的参与者往往排在最左边；接收消息的参与者则排在最右端；对象从左到右按照重要性排列或按照消息先后顺序排列。
激活表示该对象被占用以完成某个任务，去激活指的则是对象处于空闲状态、在等待消息。
在UML中，为了表示对象是激活的，可以将该对象的生命线拓宽成为矩形。其中的矩形称为激活条(期)或控制期，对象就是在激活条的顶部被激活的，对象在完成自己的工作后被去激活。
返回消息是顺序图的一个可选择部分，它表示控制流从过程调用的返回。
返回消息一般可以缺省，隐含表示每一个调用都有一个配对的调用返回。
是否使用返回消息依赖于建模的具体/抽象程度。如果需要较好的具体化，返回消息是有用的；否则，主动消息就足够了。