UML系统析与设计.ppt

实例——关联分析，建模，多重性分析，再建模 实例——职责分析 书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。 借阅记录类：借阅人（朋友）、借阅时间。 借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录 实例——限定与修改 约束：Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ；一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “{Xor}”约束 限定符：一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应 学生登录网站后，可以浏览课件、查找课件、下载课件、观看教学视频 教师登录网站后，可以上传课件、上传教学视频、发布教学心得、查看教学心得、修改教学心得 系统管理员负责对网站页面的维护、审核不合法课件和不合法教学信息、批准用户注册 ? 在 “远程网络教学系统”中： 学生登录网站要有登录名称和密码，还要有姓名、学号、性别、年龄、班级、专业、邮箱等属性 教师登录网站要有登录名称和密码，还要有姓名、性别、年龄、邮箱等属性 系统管理员有用户名、系统管理员密码、邮箱等信息 例如有人需要开发一套软件来模仿桌球游戏，问题可能用用例来表述表面的特征：“游戏者击中白球，它以一定的速度前进，并以特定的角度碰到红球，于是红球在某个特定的方向上前进一段距离”。可以拍下几百个这样的事件，测量不同的球速，角度和距离，但靠这些样例要写出好的仿真程序远远不够，因为除了这些表面现象，还必须了解背后的本质，那就是和质量有关的运动定律，速度，动量，等等。了解这些规律将更容易看到软件可以怎样建立。 这个例子可能很特别，因为这些定律已经成为公理；而在我们建造应用系统的时候，需要大量的了解和研究，才能接触到问题的本质。作为计算机软件开发人员，哪怕在哪一个领域工作了很多年，我们依然受到计算机思考方式的限制，因此，要建立合理的系统模型，要得到相对稳定的模式，都需要请问题域专家参与建模，我们需要教给他们一些用来表述的注记，引导他们把问题表述出来，然后，在可能的情况下，进行技术上的总结和提醒。系统的模型其实一直都存在，我们要做的，就是要和问题域专家们一起，把它们从纷繁复杂的问题表象中找出来。 在以往的系统建设经历中，曾经见过系统建模人员，将问题域人员的需求全部描述出来，然后把他们平常手工进行的业务过程，一一用软件实现，我们知道，这样其实不是很好的解决方案，每一次工具的变革都会对人们的活动产生影响，那么，我们有了计算机，硬件和软件以后，业务过程是否会受到影响，应该有所变革呢？如果需要的话，需要跟问题域专家进行协商，由他们来权衡，然后，这些变革和影响，首先就会体现在系统模型上。 这样，就已经有了一些软件过程重组的意义了，面向对象系统建模正好可以将系统分析和过程重组结合到一起，用来促进业务过程的变革。 分析模式更接近系统的概念模型，如果系统概念模型经过抽象，可以应用在多个相似的环境中，那么，它就变成了模式。在代码实现层面，我们很容易看到和理解重用的概念，从最开始的函数库，到类库，到设计模式，到应用框架，我们的对代码的重用程度越来越高，在业务领域的分析层面，重用的可能性依然存在，分析模式，就是这种重用的一部分，如果我们都可以利用以往的经验，得到业务领域的通用解决方案，它们将直接影响到应用系统的设计，因而这种重用的价值将更加显著。 我们需要把一组复杂的需求分解为基本元素和关系，解决方案就建立在这些元素和关系的基础上。分析是把真是世界建模为对象的第一个机会。 静态分析模型可以使用类图来描述。类图显示了系统要处理的对象和这些对象之间的相互关系。 读图过程 多重性：用来说明关联的两个类之间的数量关系 源类及多重性 目标类及多重性 分析 Customer(1) Order(0…n) 订单是属于某个客户的，网站的客户可以有0个或多个订单 Order(1) Consignee(1) 每个订单只能够有一个收货人 Order(1) OrderItem(1…n) 订单是由订单项组成的，至少要有一个订单项，最多可有n个 Order(1) DeliverOrder(1…n) 一个订单有一个或多个送货单 说明：系统根据订单项的产品所属的商户，将其分发给商户，拆成了多个送货单！ DeliverOrder(1) OrderItem(1…n) 一张送货单对应订单中的一到多个订单项 Deliver