分析类分析类侧重于处理功能性需求通过较高的、非形式化层次的职责类定义某行为分析类三种基本构造型：边界类：边界类用于建立系统与其参与者之间交互的模型，每个边界类至少应该与一个参与者有关，反之亦然。控制类：控制类代表协调、排序、事务处理以及其他对象的控制。实体类：实体类用于对长效持久的信息建模。第30页，共68页，星期日，2025年，2月5日分析类举例第31页，共68页，星期日，2025年，2月5日控制类控制类类似于设计模型中的控制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。事件响应。业务逻辑流程控制第32页，共68页，星期日，2025年，2月5日控制类举例第33页，共68页，星期日，2025年，2月5日课堂练习POS系统的边界类和实体类第34页，共68页，星期日，2025年，2月5日用例实现分析用例实现分析是分析模型内部的一种协作，主要描述了如何根据分析类及其交互的分析对象来实现和执行一个具体的用例。用例实现事件流的文本描述反映参与者用例实现的分析的类图按照分析对象交互作用的交互图。用例实现侧重于功能性需求。第35页，共68页，星期日，2025年，2月5日处理销售类图第36页，共68页，星期日，2025年，2月5日交互图当参与者向系统发送某种形式的消息而激活用例时，开始执行该用例中的动作序列。边界类对象将接收来自参与者的消息。交互对象向其他对象发送一个消息，并使有关对象与之交互从而实现该用例。第37页，共68页，星期日，2025年，2月5日第38页，共68页，星期日，2025年，2月5日处理销售协作流的事件-分析流收银员通过处理销售商品界面发起一次销售，控制类创建一个销售类，收银员逐个输入商品，销售类创建商品，并放入销售列表中。控制类要求计算商品总价，收银员请求顾客付款，控制类委派销售类创建一个支付。第39页，共68页，星期日，2025年，2月5日分析包分析包描述了对分析模型的制品进行组织的方式，它可以包括分析类、用例实现及其他分析。分析包应是有强内聚性与低耦合性，具有以下特点：分析包可以表示对分析内容的分割。在统一过程中，服务的概念是由服务包支持的。服务包在按照系统提供的服务而组织的分析包层次结构中处于较低层。服务包包含了一组活动相关的类，服务包不可分割。在实现用例时，可能会有一个或多个服务包参与其实现。服务包相对独立，可以复用。UML包图用于描述系统的逻辑架构——层、子系统、包等。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内，否则，可以标在包内。第40页，共68页，星期日，2025年，2月5日UML包图第41页，共68页，星期日，2025年，2月5日逻辑架构逻辑架构是类的宏观组织结构，它将类组织为包、子系统和层等。层是对类、包或子系统的甚为粗粒度的分组，是有对系统主要方面加以内聚的职责。第42页，共68页，星期日，2025年，2月5日分层逻辑架构第43页，共68页，星期日，2025年，2月5日关联与依赖两个分析类以某种方式相互联系，这些联系被称作关联。关联可进一步指出多样性，也称为基数。两个分析类之间存在客户——服务器联系，客户类在某些方面依赖于服务器类并且建立了依赖关系。第44页，共68页，星期日，2025年，2月5日识别属性和操作属性描述类的性质，可以通过分析该类存在的一些信息类构建。操作定义了某个对象的行为。操作可以分为四种类型：以某种方式操纵数据，例如：添加、删除、选择、更新等。执行计算的操纵，例如：销售中的计算总价。请求某个对象状态的操作。监视某个对象发生某个控制事件的操作。操作的构造需要交互图和场景描述等手段多次反复分析才能获取。在研究语法分析并分离动词作为候选的操作。推荐的一个方法是使用CRC技术。第45页，共68页，星期日，2025年，2月5日CRC技术CRC(Class-Responsibility-Collaborator,类-职责-协作者)建模提供识别和组织与产品相关的类。一旦系统的基本使用场景（用例）确定后，则要标识侯选类，指明它们的责任和协作，即类-责任-协作者建模：责任是与类相关的属性和操作，即责任是类知道要做的事情。协作者是为某类提供完成责任所需要的信息的类，即协作类。CRC模型是一组表示类标准的索引卡——CRC卡的集合。CRC卡的内容分成三个部分：类的名字类的责任协作类第46页，共68页，星期日，2025年，2月5日销售类CRC卡Class：销售类说明：完成一次销售职责：协作类：创建商品商品类计算总价商品列表类创建支付支付类计算找零