鲁棒分析方法.pptVIP

附：鲁棒分析方法 附：鲁棒分析方法 Robustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具 在Robustness分析中，将应用边界类、控制类和实体类 从一个用例中抽取三类对象的方法： 边界类，实体类和控制类 UML中有3种主要的类版型： 边界类（boundary class） 实体类（entity class） 控制类（control class） 在进行OO分析和设计时，如何确定系统中的类是一个比较困难的工作，引入边界类，实体类和控制类的概念有助于分析和设计人员确定系统中的类。 实体类 （Entity class） 实体类 （Entity class）是应用领域中的核心类，一般是从现实世界中的实体对象归纳和抽象出来的，用于长期保存系统中的信息，以及提供针对这些信息的相关处理行为。一般情况下，实体类的对象实例和应用系统本身有着相同的生命周期。 实体类 （Entity class） 实体类通常指系统中需要持久化的类，代表系统中的核心概念。实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。 实体类和数据库中的表并不一定是一一对应的。有可能一个实体类对应多个表，也可能多个实体类对应一个表。这取决于数据库模式的设计。 实体类的表示方法 边界类 边界类（boundary class）：边界类是系统内的对象和系统外的参与者的联系媒体，外界的消息只能通过边界类的对象实例才能发送给系统 边界类 边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、 直接与外部系统交互的类等都是边界类。 通过用例图可以确定需要的边界类，每个Actor/Use Case对至少要一个边界类，但并非每个Actor/Use Case对应唯一的边界类。 边界类的表示方法： 控制类 控制类（control class）：实体类和边界类之间的润滑剂，是从控制对象中归纳和抽象出来的，用于协调系统内边界类和实体类之间的交互 控制类的表示方法 控制类 控制类是控制其他类工作的类。 控制类表示系统的动态行为，处理主要的任务和控制流。简单的说控制类指的就是业务逻辑，他通常独立于实体类和边界类，稳定性较好。 每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。 在什么情况下需要控制类 如果控制流比较简单，只处理象添加、修改和删除这样的功能，通常可以由边界类来处理。如果业务流程比较复杂，则需要单独设计控制类。 通常一个控制类只和一个角色进行交互，这是基于最小化变更对系统的影响来考虑的。 可视化建模与UML 鲁棒分析—从事件流开始 鲁棒分析—寻找边界对象 图书管理员向系统发出“新增书籍信息”请求——主窗口、“新增书籍信息”按钮 系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类——书籍类别列表框。 图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号——“新书信息录入”窗口及辅助的“提交”按钮 鲁棒分析—寻找控制对象和实体对象 根据事件流中的步骤5，以及扩展路径的描述，就可以在原图上增加相应的控制对象，得到更进一步的Robustness分析图 鲁棒分析—寻找控制对象和实体对象 新添两个逻辑：一是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；二是当书名重复性检查没有通过（有重名），则应返回要求其重输 构建交互模型 转换成通信图 交互模型的类型与演变 分析阶段的交互模型 工作方法：针对用例图中的每个用例，并结合领域模型中的类，寻找分析类，并通过Robustness分析来理清业务逻辑流程，再用交互模型将其确定下来 注意：主要关注于区分出边界对象、实体对象和控制对象，暂时不要考虑其具体的实现类 说明：对于较复杂的用例，可以按上述的流程逐渐地进行分析、设计、实施；但对于比较简单的用例而言，也是可以直接从用例描述中导出设计阶段交互模型 分析阶段的交互模型之后 引入基础类：包括基础框架、程序库等 质量评审：-- 低耦合：耦合性是指两个类之间的连接强度-- 高内聚：内聚性是指一个类的属性与方法高度集成-- 效率：解决方案的执行效率是否满足系统的需求-- 完整性：是指在任何环境下都可以重复使用-- 简单性：类越简单，出错的可能性越小，系统的灵活 性和可维护性也越好 优化类设计：设计模式与重构