软件工程及实践[窦万峰]第3章 软件需求分析.pptVIP

1．UML的组成 （1）UML的模型元素。 UML定义了两类模型元素的图形表示，一类模型元素用于表示模型中的某个概念，如类、对象、用例、节点、构件、包和接口等；另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖和聚集（表示整体与部分的关系）等。图3-13给出了部分UML定义的模型元素的图形表示。 （2）UML模型结构。 根据UML语义，UML模型结构可分为4个抽象层次，即元元模型、元模型、模型和用户模型。它们的层次结构如图3-14所示，下一层是上一层的基础，上一层是下一层的实例。 元元模型层定义了描述元模型的语言，是任何模型的基础，它的模型定义了元类、元属性和元操作等一些概念。例如，图3-15所示是一个“元类”的元元模型描述，“事物”概念可代表任何定义的对象。 元模型层定义了描述模型的语言，它组成了UML模型的基本元素，包括面向对象和构件的概念，如类、属性、操作和构件等。元模型是元元模型的一个实例，如图3-16所示是一个元模型示例，其中类、对象和关联等都是元元模型中事物概念的实例。 2．UML模型 UML主要是用于描述模型的，它可以从不同视角为系统建模，形成不同的视图（View）。每个视图都是系统完整描述中的一个抽象，代表该系统一个特定的方面。每个视图又由一组图（Diagram）构成，图中包含了强调系统某一方面的信息。 1．编写用例 【案例3.8】 POS机系统用例描述 POS机系统中，系统的参与者主要有收银员、经理、顾客和公司销售员等，本例主要考虑收银员和经理的用例图，如图3-17所示。 随着与用户更多的交谈，分析师为每个标记的功能开发用例。通常用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，而且有些格式更强调描述的直观性。用例场景详细描述的模板如表3-5（a）所示。 POS机系统中的“处理销售”场景描述如表3-5（b）所示。 用例不同部分 说 明 用例名称 以动词开始描述用例名称 范围 要设计的系统 级别 “用户目标”或者是“子功能” 主要参与者 调用系统，使之交付服务 涉众及其关注点 关注该用例的人及其需要 前置条件 开始前必须为真的条件 成功保证 成功完成必须满足的条件 主成功场景 典型、无条件和理想方式的成功场景 扩展 成功或失败的替代场景 特殊需求 相关的非功能性需求 技术和数据变元素 不同的I/O方法和数据格式 发生频率 影响对实现的调查、测试和时间安排 杂项 未决问题等 表3-5（a） 用例场景详细描述的模板 2．开发活动图 活动图通常能够既表示控制流，又表示数据流。UML活动图能够满足数据流建模，从而代替传统的数据流图表示法。图3-18给出了处理销售用例中的UML活动图的例子，图中的黑色圆点表示起点，外带一个圆代表终点。 3．泳道图 UML泳道图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。在为复杂业务过程建模时，可以利用耙子符号和活动图分层描述。图3-19所示为处理销售用例的UML泳道图。 1．识别分析类 （1）边界类。 边界类用于建立系统与其参与者之间交互的模型，经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端及API等的抽象。每个边界类至少应该与一个参与者有关，反之亦然，例如，收银员与“处理销售界面”的边界类交互用于支持输入商品和处理支付等交互，如图3-20所示。 （2）实体类。 实体类用于为长效持久的信息建模，大多数情况下，它是直接从业务对象模型中相应的业务实体类得到的。实体对象不一定是被动的，有时可能具有与它所表示的信息有关的复杂行为，能够将变化与其所表示的信息隔开。 （3）控制类。 控制类代表协调、排序、事务处理及其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可以用来表示复杂的派生与演算，如业务逻辑。 2．用例实现分析 UML包图通常用于描述系统的逻辑架构——层、子系统和包等，层可以建模为UML包，例如，UI（User Interface）层可以建模为名为UI层的包。UML包图分层组织元素的方式，也可以用嵌套形式。UML包是比Java包或.Net命名空间更为通用的概念，可以表示更为广泛的事物。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内；否则可以标在包内。UML包代表命名空间，假如Date定义在两个包中，可以用全限定的名称区分它们。如Java：：Util：：Date表示Java的包嵌套了名为Util的包，后者包含Date类。图3-21所示为一台POS机的部分UML包图。 3．识别属性和操作 操作可以分为以下4种类型。 （1）以某种方式操纵数据，例如，添加、删除、选择、更新等。 （2）执行计算的操纵，例如，销售中的计算总价。 （