第一篇：面向对象分析与设计实验报告
实 实
验
报
告
课程名称
面向东西阐发与设计
专业班级
_ _ ___
__ __
学
号
__
___
姓
名
___
__ __
同组成员
实验日期
_
成绩
____________ ___________
人为治理系统 1.1 系统的成果需求
人为治理系统包罗员工治理、人为治理、销售奖金治理、保险用度治理等。
1.人为治理 在取得授权的情况下，有关人员要进行如下事情。
（1)人为录入
人为治理员录入员工的人为，修改录入的堕落（维护），形成人为表。
（2）销售奖金录入 人为治理员录入员工的销售奖金，修改录入的堕落（维护），形成销售奖金表。
（3）保险用度的录入 人为治理员录入员工的若干保险用度，修改录入的堕落（维护），形成保险用度统计表。
（4）盘算人为 人为治理员按事情证号码来进行人为的盘算统计，然后生成报表再上报给财务部。
（5）盘算销售奖金 人为治理员凭据事情证号码进行人为销售奖金的盘算统计，然后生成报表上报给财务部。
(6)盘算若干保险的扣除用度 人为治理员凭据事情证号码进行若干保险的盘算统计，然后生成报表上报给财务部、(7)人为或销售奖金、保险用度查询 公司员工可以凭据自己的事情证号码查询自己的人为或销售奖金及保险用度。
人为治理的主要业务流程：
此处给出以上 7 个业务之间的流程图（用运动图描述）
1.2 创建需求模型
对人为治理系统先分别子系统，然后再通过创建用况模型，对需求进行捕获与描述。
1.2.1
分别子系统
限定人为治理系统的成果为：人为治理、统计部分、财务系统、员工治理。对上述的每个成果，用一个子系统来实现。下图给出了这些子系统以及它们之间的依赖。
人为治理系统中子系统以及它们之间的依赖：
此处给出子系统的摆设图如下
上图中的子系“财务系统”要分别使用子系统“员工治理”、“人为治理”中的员工号码、员工姓名、员工人为。子系统“人为治理”要分别使用子系统“统计部分”和“员工治理”中的员工信息和统计的人为信息。子系统“统计部分”要使用子系统“员工治理”中的员工信息。
1.2.2 识别 参加者
子系统“人为治理”的人员用户有人为治理员和员工。与子系统“人为治理”有关的子系统有“统计部分”、“员工治理”和“财务系统”，这些子系统是“人为治理”的参加者。
1.2.3 识别用况
对 1.1 节的中的用况需求，现归纳整理如下。
1.人为治理
（1）录入与维护人为、销售奖金及保险用度 人为治理员需录入员工的人为、销售奖金及若干保险用度信息做出人为表、销售奖金表及保险用度表。
（2）盘算人为或销售奖金及保险用度 人为治理员按事情证号码进行盘算做出人为报表、销售奖金报表及保
险用度表。
（3）查询人为、销售奖金或保险用度
员工查询自己的人为、销售奖金及保险用度。
（4）登录 人为治理员和员工进入该子系统都需要登录。
1.2.4 对需求进行捕获与描述
通过到目前为止掌握的需求，开端了解了系统所要完成的成果。下面进一步创建参加者与用况之间的干系，并对用况进行详细的描述。
图 1.3 为子系统“人为治理”的用况图。
首先，使用系统的员工和人为治理员都先要进行登录。参加者“人为治理员”通过用况“录入与维护人为、销售奖金及保险用度”来录入、修改，形成人为表、销售奖金表及保险用度表；再通过用况“盘算人为、销售奖金及保险用度”生成人为报表、销售奖金报表及保险用度表并予以宣布。所宣布的人为报表、销售奖金报表及保险用度表供参加者“员工”、“财务系统”和“人为治理员”使用。员工要通过用况“查询人为、销售奖金及保险用度”来得知自己的人为、销售奖金及保险用度。
此处要求给出各个用况的相关运动图 如下是对上述各用况的描述。
用况：录入与维护人为、销售奖金及保险用度 【前置条件：人为治理员已经登录乐成】
人为治理员选择人为录入与维护、销售奖金录入与维护、保险用度的录入与维护。
系统出现出供录入和修改人为、销售奖金及保险用度的界面 人为治理员处理惩罚完数据（录入、修改）后，发控制命令
若为生存，系统进行存储，并通知结果治理员是否乐成 若为取消，退出本成果
用况：盘算人为、销售奖金及保险用度 【前置条件：人为治理员已经登录乐成】
人为治理员发出进行人为、销售奖金及保险用度盘算的请求
按事情证号生成人为、销售奖金及保险用度报表，并发送到子系统“财务系统”中 用况：查询人为、销售奖金及保险用度 【前置条件：员工已经登录乐成】
交互内容见表 1.1 中编号为 1 的那栏的输入/输出部分。1.3 系统阐发
在掌握了上述的需求后，下面开始使用面向东西要领进行系统阐发。
1.3.1 寻找类
人为治理 在子系统“人为治理”中，也要设立两个类“员工”和“人为治理员”，用它们分别模拟相应的参加者。
人为治理中的东西是人为和销售奖金及保险用度，因而设立类“人为组成”、“销售奖金表”及“保险用度表”。种种人为组成许多，需要设立类“人为表”，它与类“人为组成”形成组合干系。
子系统“人为治理”需要从人为治理部分获取信息，需要设立需接口“人为治理”。子系统“人为治理”要向财务系统提供数据，需要设立供接口“财务系统”。
1.3.2 创建状态机图
对付上述所找到的类，现在凭据上述的阐发能理解它们的职责了。现针对子系统“人为治理”中的类“人为表”绘制一个状态机图。
凭据问题域，可为类“人为表”的东西设立了 5 个状态，分别为：初始、初始化、查询、封闭和终止。
施加在人为表上的时间有：宣布、查询和封闭。这些事情都是针对人为表所发消息的响应。
下图展示的是针对人为表的状态机图。
图 人为表的状态机图 1.3.3
创建类图
对在 1.3.1 节中找到的各个类进行考察，分别界说它们的属性和操纵，考虑它们之间的干系，绘制出类图。
（1）类“员工”
该类中属性有“姓名”、“事情证号”、“密码”和“职务”，操纵有“登入”、“查询”、“修改密码”、“查询人为”和“查询年终奖金”。
（2）类“人为” 该类中有属性“事情证号”和“人为”。
（3）类“人为表”
该类中有属性“姓名”、“事情证号”、“时间”和“人为额”。它与类“人为”组成组合干系，在其中要设立操纵“生成人为组成”、“查询人为组成”。它另有一个操纵“查询人为”，供员工查询人为之用。
（4）类“销售奖金表” 该类中有属性“姓名”、“事情证号”、“时间”和“销售奖金额”。它与类“人为”组成组合干系，在其中要设立操纵“生成销售奖金组成”、“查询销售奖金组成”。它另有一个操纵“查询销售奖金额”，供员工查询销售奖金之用。
（5）类“保险用度表” 该类中有属性“姓名”、“事情证号”、“时间”和“保险用度”。它与类“人为”组成组合干系，在其中要设立操纵“生成年保险用度组成”、“查询保险用度组成”。它另有一个操纵“查询保险用度”，供员工查询保险用度。
（6）类“人为治理员” 该类中有属性“姓名”、“事情证号”和“密码”；属性有“登入”、“录入与维护人为”、“修改密码”、“生成人为表”、“生成销售奖金表”、“生成保险用度表”、“盘算人为”、“盘算销售奖金”、“盘算保险用度”、“向财务部发人为表”、“向财务部发销售奖金表”及“向财务部发保险用度表”。
上述的六个类及其间的干系如下图所示。
图 人为治理部分分类图 人为治理员按事情证号输入与维护人为组成，为此在类“人为治理员”与类“人为表”之间设立一个关联“录入与维护人为表”。人为治理员还要生成人为报表，因此在类”人为治理员与类“人为表”间设立一个关联“盘算”。
员工要查询人为情况，因而在类“员工”和“人为表”间设立关联“查询人为”。
类“销售奖金表”及类“保险用度表”和类“人为治理员”、类“员工”之间的关联创建与上述类似。
1.3.4
创建顺序图
在上一节中，以文字的形式说明了类之间的关联作用。这种说明往往不能清楚的描述事物间的交互情况，这就需要使用交互图来予以准确的表达。对付员工查询人为来讲，下图给出针对员工以及员工人为查询有关的东西创建的顺序图
图
员工以及与员工查询人为有关的东西之间的交互情况（一）
图
员工以及与员工查询人为有关的东西之间的交互情况（二）
1.4
系统设计
1.4.1
问题域部分设计
人为查询子系统通过数据库与其他子系统互换数据，即，通过需接口从数据库中获取数据，通过供接口向数据库写入数据。故需要凭据供需双方配合约定的借口规约设计相应的数据库表的结构，并在接口相关的类操纵中结构 SQL 语句即可。
1.4.2
界面部分设计
应该针对表 1-1 中的内容进行界面设计，凭据第 8 章的要求设计出全部界面。
下图 所示的是用户登入界面，该界面也适用于员工。
下二图 是在登入乐成后，系统给出的选择时间界面。
图 登入界面
图 选择时间界面
在选择时间并确定后，出现下图所示的界面。
图 1-10
人为
1.4.3
数据治理部分设计
类“人为”和“人为表”组成了组合干系，对他们分别设立两张表，并在与类“人为”对应的表中用外键隐含它与类“人为报表”的关联。对付类“员工”和类“人为治理员”也分别设立一张表，用于存储相应的东西。
下面给出了类“人为”和类“人为表”所对应的数据库表的结构。
表 表
类“人为”所对应的数据库表的结构
本表的主要害字为事情证号
表 表
类“人为表”所对应的数据库 表的结构
本表的主要害字为事情证号+时间，外键为事情证号。
表 表
类“销售奖金”所对应的数据库表的结构
本表的主要害字为事情证号+时间，外键为事情证号
表 表
类“保险用度”所对应的数据库表的结构
本表的主要害字为事情证号+时间，外键为事情证号
第二篇：面向对象分析与设计课程总结
面向对象分析与设计
课程总结
0923010208 指导老师：庄育飞
这学期学院开设了面向对象分析与设计（UML）这门课，通过老师的讲解，自己一些相关书籍的阅读和实践作业的完成，逐步对课程有了由浅及深的认识。我觉得学习这门课还是受益匪浅的。
面向对象(Object Oriented,OO)是一门以实践为主课程，课程中可以分开两块OOA（面向对象系统分析)和OOD（面向对象系统设计）。
OOA（面向对象系统分析)主要内容: 研究问题域和用户需求,运用面向对象的观点和原则发现问题域中与系统责任有关的对象,以及对象的特征和相互关系.OOA不涉及针对具体实现采取的设计决策和有关细节,独立于具体实现的系统模型。是一个完整确切反映问题域和用户需求的系统模型。OOA的优势：复
用、可扩展、可维护性、弹性。
OOD（面向对象系统设计）：以OOA模型为基础，按照实现的要求进行设计决策，包括全局性的决策和局部细节的设计，与具体的实现条件相关。OOD的步骤：细化重组类→细化和实现类之间的关系，明确其可见性→增加属性,指定属性的类型和可见性→分配职责,定义执行每个职责的方法→对消息驱动的系统,明确消息传递的方式→利用设计模式进行局部设计→画出详细的类图和时序图。
面向对象的分析与设计方法将致力于解决传统软件研发过程中由于软件模块化结构化程度不高带来的软件重用性差、软件可维护性差、开发出的软件不能满足用户需要等方面问题。面向对象的概念包括：对象、对象的状态和行为、类、类的结构、消息和方法。对象概念将包含对象唯一性、抽象性、继承性、多态性的重要特征。面向对象的要素包含：抽象、封装性、共享性三方面。
在设计模式的研究过程中，我们组选择的是迭代器（Iterator）的设计模式研究。完成设计研究后，我对迭代器的设计模式有了更为深刻的理解。迭代器（Iterator）提供一个方法顺序访问一个聚合对象的各个元素，而又不暴露该对象的内部表示。并了解到迭代器设计模式一般在以下三类场合使用较多。
访问一个聚合对象的内容而无需暴露它的内部表示。
支持对聚合对象的多种遍历。因为遍历状态是保存在每一个迭代器对象中的。
为遍历不同的聚合结构提供一个统一的接口。根据实现方式的不同，效果上会有差别。同时还简化了容器的接口。但是在java Collection中为了提高可扩展性，容器还是提供了遍历的接口。
在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的：一是集合内部的数据存储结构，二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则，所以我们要尽可能的去分解这些职责，用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。
在Java Collection的应用中，提供的具体迭代器角色是定义在容器角色中的内部类。这样便保护了容器的封装。但是同时容器也提供了遍历算法接口，你可以扩展自己的迭代器。至于迭代器模式的使用。客户程序要先得到具体容器角色，然后再通过具体容器角色得到具体迭代器角色。这样便可以使用具体迭代器角色来遍历容器了。
OOA和OOD之间没有明显的界限。OOA与OOD的不可分割性正好说明了OO思想的强大，即软件过程阶段的无缝连接，在交流与沟通中不会产生鸿沟，这是相对结构化思想的好处，因为从功能模块到某块详细控制逻辑设计两者之间的联系不是十分紧密，需要分析人员与设计人员的再沟通。
通过课程的学习与实践，对面向对象的理念，以及相关方法，设计模式有了更为深刻的理解与掌握。针对面向对象的分析与设计课程的授课内容及方法，我个人觉得对我还是有不少的帮助和 提高。结合自己的工作，虽然与开发接触的比较少，但是在运维过程中，如果能了解开发原理，结合实际的工作，会对一些源代码的分析能力以及工作效率的提高起到明显的帮助作用。
庄老师上课经常说一些与课程无关的内容，我已开始并不理解他的作法，后来我慢慢认识到面向对象分析设计的学习就是培养思想的一种过程，这种思维方式还是需要大量的实践才能灵活的运用。目前的阶段，只能说是知道有这样一种设计思想、这种解决问题的方案，至于在何时应该使用、如何去使用，就需要在今后的经验中去累积了。
下面是一些我掌握的基础知识
9种UML图：
类 图：描述类的结构（包括属性以及类之间的相互关系）
对象图：对象以及对象之间的相互关系
构件图：构件及其相互依赖关系
部署图：构件在各节点上的部署
顺（时）序图：强调时间顺序的交互图，用于将系统行为分配给类。一般包含了边界、控制、实体对象
协作图：强调对象协作的交互图，与时序图同构
状态图：类所经历的各种状态，包括状态之间的转换以及触发转变的事件
活动图：对工作流程建模
用例图：与用例文档结合进行需求捕获，测试依据
面向对象设计七个原则：
开-闭 原则、里氏转换原则、依赖倒转原则、接口隔离原则、组合/聚合复用原则、迪米特法则、单一职责
ICONIX开发过程：域模型——用例文档——健壮性分析——健壮图——时序图
设计模式：
1)创建模式: 涉及对象的创建
单例模式, 工厂模式, 建造者模式，原型模式
2)结构模式:涉及类和对象的组合
Facede外观模式, 代理模式, 适配器模式, 装饰模式
3)行为模式: 刻画了类和对象交换及分配职责的方式.主要目标是解耦
观察者模式, 命令模式, 模板模式
本学期学了《面向对象系统分析与设计》课程，本课程我们主要是学习了面向对象的统一建模语言UML,了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在IBM RSA软件环境下用UML进行分析和设计的技术。在《面向对象系统分析与设计》 的上级课程上，我们的实践能力方面着重设计构思和设计技能的得到基本训练，熟练的上机操作能力和分析能力，加深理解、验证、巩固课堂教学内容。
数据库是以信息处理为核心的任何应用系统的基础，数据库设计的质量直接关系到系统开发的成败和优劣。数据库设计的方法与系统使用的开发方法有着密切的关系，同时还与所应用的数据库模型(层次模型、网状模型、关系模型、对象模型)有关。目前经常采用E—R(Entity—Relationship)图的方法设计数据库。但E—R图设计数据库存在的主要问题是只能对资料建模，而不能对行为建模。而UML类图的描述能力更强，UML类图是E—R图的扩充。对于关系模型来说，可以用类图描述数据库模式，用类描述数据库表。
UML是应用面向对象方法进行系统开发的全程建模语言，可用于业务分析、需求分析、系统设计、系统实现与测试等系统开发的各个环节。UML概念设计的基本工作分为两个方面：
· 一是从系统分析和系统设计所建立的各种类图中抽取持久型类。
· 二是确定持久型类之间的关系，并用类图描述这种关系，从而把类图作为数据
库概念设计的结果。
1．抽取持久型类
持久型类是指类的完整信息需要在数据库中存储的类。在UML中，类可以分为
边界类、实体类和控制类三种类型。
· 接口类和控制类的信息一般不需要长久存储。
· 持久型类只可能是实体类，但并不是所有实体类的信息都需要长久地存储，持久型类只需要从那些信息需要长久存储的实体类中抽取。
2．确定类关系
在比较复杂的系统分析和设计中，并没有建立立足于整个系统的整体类图，而只是建立了一个个针对具体用例的类图。也就是说，所提取的持久型类被分散到各个用例类图当中了。因此，需要对抽取的持久型类进行分析，以确定它们之间的相互关系，建立起反映这些类关系的类图。
UML数据建模与E—R图有着本质的区别。在E—R图中，应用型数据库系统的重点是数据库结构。概念设计是应用型数据库系统开发的重点和难点。而UML是用于面向对象系统开发的全程建模语言，可用于需求分析、系统分析与设计、系统实现、系统测试等系统开发的所有环节。由于UML基于面向对象技术，而要保持方法的一致性，最好选择面向对象数据库。但是，目前的面向对象数据库在实现技术上还不十分成熟，即使应用面向对象技术和环境开发应用系统，通常的做法是使用UML进行建模，用关系型数据库储存和管理数据。
通过一学期的学习和实践，我了解到uml具有以下特点[1]：
(1)面向对象。uml支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。
(2)可视化，表示能力强。通过uml的模型图能清晰地表示系统的逻辑模型和实现模型。可用于各种复杂系统的建模。
(3)独立于过程。uml是系统建模语言，独立于开发过程。
(4)独立于程序设计语言。用uml建立的软件系统模型可以用Java、vc++、smalltaik等任何一种面向对象的程序设计来实现。
(5)易于掌握使用。uml图形结构清晰，建模简洁明了，容易掌握使用。使用uml进行系统分析和设计，可以加速开发进程，提高代码质量，支持动态 的业务需求。uml适用于各种规模的系统开发。能促进软件复用，方便地集成已有的系统，并能有效处理开发中的各种风险。
而且uml是一种功能强大的、面向对象的可视化系统分析的建模语言，它采用一整套成熟的建模技术，广泛地适用于各个应用领域。它的各个模型可以帮助开发人员更好地理解业务流程，建立更可靠、更完善的系统模型。从而使用户和开发人员对问题的描述达到相同的理解，以减少语义差异，保障分析的正确性。
通过对学籍管理系统的开发可以看到，uml作为软件工程中的建模语言，代表了面向对象方法的软件开发技术的发展方向，具有重大的经济价值和国防价值，并获得了国际上的广泛支持，具有非常好的应用前景。
由于明年需要参加考研，复习很紧张，所以这学期面向对象分析与设计这门课程我并没有深入地去学习，但这无法影响我对UML的喜爱，老师上课很生动，不光在学习上教导我，在生活和做人理念上也对我有所帮助。这篇学习总结写得比较乱，但我都有用心，在以后的学习过程中我会继续努力，再次多谢庄老师的教诲。
第三篇：UML与面向对象分析与设计
UML与面向对象分析与设计
实验实践训练体系
适用专业: 计算机科学技术、软件工程
第一部分 课程与实验综述
一．课程简介及实践要求：
《UML与面向对象分析与设计》是以介绍面向对象的统一建模语言UML为主,使学生了解面向对象技术的基本概念,掌握面向对象的分析和设计方法,以及与面向对象技术相关的一些软件开发技术,同时掌握在Rational Rose环境下用UML进行分析和设计的技术。本课程在教学内容方面着重基本理论、基本知识和基本方法，在培养实践能力方面着重设计构思和设计技能的基本训练，熟练的上机操作能力和分析能力。
实验实践训练是UML与面向对象分析与设计教学的重要技能环节。通过实验，使学生加深理解、验证、巩固课堂教学内容，特别是通过设计和综合实验，发挥学生的想象力和创新能力。
二．课程实验目的要求：
通过UML的实验,学生应该: 1．学会用面向对象的思想去分析和设计相关系统;2．学会用Rose建模工具进行软件建模。三．课程实验参考资料
1.(美)Joseph Schmuller著.UML基础、案例与应用.人民邮电出版社,2004 2.(美)Hans-Erik Eriksson.UML 2工具箱.电子工业出版社,2004 3.吴际,金茂忠.UML面向对象分析.北京航空航天大学出版社,2002 4.赵从军.UML设计及应用.机械工业出版社,2004 5.Grady Booch,James Rumbaugh,Ivar Jacobson.UML用户指南.机械工业出版社,2001 6.吴建,郑潮,汪杰.UML基础与Rose建模案例.人民邮电出版社,2004 第二部分 实验实践指导
实验一
用例图
一、实验目的
1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
画出ATM系统的用例图
四、实验步骤
1.分析
ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。通过分析可找出如下几个参与者： 1．ATM 2．客户
通过分析得到如下用例：
（1）存款（2）取款（3）查询余额（4）转帐（5）修改密码（6）打印收据 2．绘图步骤：
下面介绍在Rose2003中创建用例图的过程：
（1）在“Use Case View“中双击Main图，或者右击“Use Case View“，弹出在快捷菜单中选择“New”－>“UseCase Diagram”，双击图标，出现图1，为编辑用例图做好准备。
（2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。
图2（3）同样的方法添加参与者“ATM”,如图3所示。
图3(4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。
图4（5）添加参与者和用例间的关联关系，如图5所示。
图5
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验二
交互图
一、实验目的
1.学会用协作图实现用例
2.掌握顺序图的绘制方法以及顺序图和协作图的相互转换。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
画出ATM取款的顺序图，并转换为协作图。
四、实验步骤
1.分析
ATM取款的场景：
（1）通过读卡机，用户插入ATM卡；
（2）ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号；
（3）用户输入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证；（4）用户输入取款数量；
（5）ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息；（6）ATM系统输出先进、ATM卡和显示帐户余额的收据；（7）ATM系统记录事务到日志文件。寻找场景中的对象：ATM、客户和帐户。2．绘图步骤：
下面介绍在Rose2003中创建顺序图的过程：
（1）在“Logical View”中新建“Sequence Diagram“，双击图标，出现图1，为编辑顺序图做好准备。
（2）在顺序图编辑窗口中，从工具栏中选择Object图标，在右边的绘图区中添加一个新元素，并取名Customer表明新增一个对象，如图2所示。
图2
（3）同样的方法，添加ATM对象和Account对象，如图3所示。
图3（4）根据ATM取款的场景，获得第一条消息为“客户向ATM机提交取款需求”，向图中添加消息，如图4所示。
图4
（5）同样的方法添加其它消息，如图5所示。
图5（6）根据顺序图生成协作图，步骤如下：“Browse”－>“Create Collaboration Diagram”，生成的协作图，如图6所示。
图6
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
实验三 类图
一、实验目的
1.理解类的基本概念 2.理解类间的关系 3.掌握类图的绘制方法
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
分析选课系统中的类及关系，然后画出它们的类图。
四、实验步骤
1.分析
在选课系统中，通过分析可抽象出如下几个类： 1．学生类 2．管理员类 3．课程类
学生类和管理员类的属性较容易分析，这里只列出课程类的属性和方法：（1）课程名称（2）开课教室（3）课程号（4）授课教师（5）选课的学生（6）开课起始时间（7）允许选课的学生人数（8）设置课程号（9）设置课程名称（10）查询课程号
（11）查询允许选课的学生人数 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中双击Main图，或者右击“Logical View“，弹出在快捷菜单中选择“New”－>“Class Diagram”，双击图标，出现图1，为编辑类图做好准备。
图1
（2）在逻辑视图中，从工具栏中选择class图标，在右边的绘图区中添加一个新元素，并取名Student表明新增一个类。
图2
（3）选择新创建的元素，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图3对话框。
（4）在对话框中，可以修改元素的名称，这里新元素的名称定为“Student”，如图4所示。
图3
图4（5）点击“Attributes”选项卡，添加属性，如图5所示。
图5（6）点击“operations”选项卡，添加方法如图6所示。
图6（7）同样的方法添加Course类，如图7所示。
图7（8）创建两个类之间的关系，通过分析得出：学生类和课程类之间为单向关联。选择图标栏的“关联”，由学生类指向课程类。如图8所示。
图8（9）创建关联名。右击关联，选择“open specification“，键入关联名，如图9所示。
图9（10）分别在“Role A Detail“和“Role B Detail“选项卡中键入名称和多重性，如图10所示。
图10（11）重复（2）－（10）中的步骤完成选课系统整个类图的创建。
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。实验四 状态图和活动图
一、实验目的
1． 熟悉状态图和活动图的基本功能和使用方法。2． 掌握如何使用建模工具绘制状态图和活动图方法。
二、实验器材
1.计算机一台；
2.Rational Rose 工具软件；
三、实验内容
（1）分析图书管理系统中的书和借书证的状态，画出它们的状态图；（2）分析管理员的活动状态，画出管理员的活动图。
四、实验步骤
1.分析
在图书管理系统中，分析书的状态如下： 1．可借 2．被借 3．被预约 4．删除
借书证的状态如下： 1．可用 2．不可用 3．删除
管理员的活动如下： 1． 处理还书 2． 处理借书 3． 处理罚款 读者的活动如下： 1．登录 2．找书 3．预约 4．浏览 2．绘图步骤：
下面介绍在Rose2003中创建类和它们之间关系的过程：
（1）在“Logical View“中信件“StateChart Diagram”，双击图标，出现图1，为编辑状态图做好准备。
图1（2）在工具栏中选择“Start State”图标添加到编辑窗口中，如图2所示。
图2（3）在工具栏中选择“State”图标，添加一个元素，命名为“New book”，如图3所示。
图3
（4）同样的方法添加其它状态，如图4所示。
图4
（5）书的各个状态之间添加转移及相应的事件，如图5所示。
图5
（6）同样的方法得借书证的状态图，如图6所示。
图6
（7）在Rose2003中，绘制图书管理员的活动图，新建“Activity Diagram”，如图7所示：
图7
（8）读者的活动图如图8所示：
图8
五、实验报告要求
1． 整理实验结果。2． 小结实验心得体会。
第四篇：面向对象分析与设计-牙科诊所管理系统
牙科诊所管理系统
王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。
当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。
系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。
1、建立牙科诊所管理系统的对象模型。
2、建立牙科诊所管理系统的用例模型。
3、用数据流图建立所述牙科诊所管理系统的功能模型。
4、画出牙科诊所管理系统的状态图。
1、建立牙科诊所管理系统的对象模型
（1）词法分析，找出（名词）作为对象的候选者；
王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。
当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。
系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。
（2）找出问题域中对象，对候选对象进行严格筛选，从中删除不正确的或不必要的，只保留确实应该记录其信息或需要提供服务的那些对象。
王大夫（牙医的实例）
小镇（牙科诊所的地址属性）
牙科诊所
牙科助手 牙科保健员 接待员（外部角色，不是问题域内的对象）
软件系统（与“系统”同义，指将来开发的软件产品）
预约
病人
预约登记表 就诊时间（与“预约时间”，“约定时间”同义，都是“预约登记表”的属性）
预约时间 约定时间 系统
名字（与“姓名”同义，是病人记录的属性）
记录的病人数据（即“病人记录”）
病历号（病人记录的属性）
姓名
日期（“预约登记表”的属性）
预约信息（与“病人清单”包含的信息基本相同）
病人清单
病人记录
电话号码（病人记录的属性）
每天工作安排 每周工作安排
（3）确定问题域中对象彼此之间的关系。
1牙科诊所11..*病人清单1..*1预约登记表111..*工作安排1..**预约11病人记录1病人1..*每天工作安排每周工作安排
2、建立牙科诊所管理系统的用例模型。
牙科诊所管理系统<
3、用数据流图建立所述牙科诊所管理系统的功能模型。
1查询病人数据病人数据病人数据D1病人记录姓名病人日期2查询预约日期有效日期3完成预约预约信息7打印工作安排每天和每周工作安排牙医4取消预约姓名/日期预约信息预约信息预约信息预约信息职员姓名5更新预约D2预约登记表预约信息姓名/日期6查询预约预约信息职员
4、画出牙科诊所管理系统的状态图。
牙科诊所管理系统的主要功能是实现病人预约，状态图如下，图中把除了完成病人预约之外的事务笼统地称为日常事务。
查找病人记录及可能的预约输入有效名字开始返回确认信息处理日常事务退出进行预约确认预约输入非法名字、按姓名或日期查询，打印工作安排，取消预约
第五篇：面向对象分析与设计,uml应用实例步骤详解（范文模版）
《面向对象分析与设
计》
实验参考资料
目 录
一、课程编号...................................................................................................................................2
二、课程类型...................................................................................................................................2
三、本课程的地位、作用与任务...................................................................................................2
四、课程基本要求...........................................................................................................................2
五、实验安排...................................................................................................................................2
实验1：实验准备............................................................................................................2 1．实验器材....................................................................................................................2 2．rational rose安装步骤.............................................................................................3 实验2：用例分析与设计................................................................................................3
1、实验目的....................................................................................................................3
2、实验内容....................................................................................................................3
3、实验步骤....................................................................................................................3
4、实验报告要求............................................................................................................8 实验3：类图的设计........................................................................................................8 1．实验目的....................................................................................................................8 2．实验内容....................................................................................................................8 3．实验步骤....................................................................................................................8 实验4：状态图................................................................................................................9 1．实验目的....................................................................................................................9 2．实验内容....................................................................................................................9 3．实验步骤....................................................................................................................9 实验5：时序图..............................................................................................................15 1．实验目的..................................................................................................................15 2．实验内容..................................................................................................................15 3．实验步骤..................................................................................................................15 实验6：协作图..............................................................................................................21 1．实验目的..................................................................................................................21 2．实验内容..................................................................................................................21 3．实验步骤..................................................................................................................21 实验7，8：综合设计实验............................................................................................24 1．实验目的..................................................................................................................24 2．实验内容..................................................................................................................24 3．实验步骤..................................................................................................................24
六、教材.........................................................................................................................................25
七、成绩考核办法.........................................................................................................................25
八、附A：完整UML建模过程例子..........................................................................................25 面向对象分析与设计
一、课程编号
本科软件工程
二、课程类型
课程类型：必修课。
适用专业：软件工程 试验学时：10～24学时
三、本课程的地位、作用与任务
计算机软件建模技术现在越来越广泛的应用于软件工程中。《面向对象系统分析设计》课程实验的目的是为了使学生在课程理论学习的同时，通过在一个实践的环境下，实际学习软件统一建模语言，对软件建模技术有一个初步的了解及认识。通过本指导书中的各个实验，学习掌握对一般面向对象系统建模的方法与技术。总之，通过上述实验环节，使学生加深了解和更好地掌握课程教学大纲要求的内容。
四、课程基本要求
1、学生应根据每个上机试验的任务和教师所提的要求，上机前准备好上机内容。
2、上机时要针对一个实际的案例进行分析，画出不同的阶段UML图。
3、上机结束后应按时提交试验报告，对于上机未完成部分，应该下机后利用课余时间完成。
五、实验安排
实验1：实验准备
1．实验器材
1．计算机一台。2．建模工具软件。2．rational rose安装步骤
（1）运行安装软件；
（2）单击下一步，选择rational rose enterprise edition；
（3）单击下一步，选择desktop installation from cd image，表示创建一个本地的应用程序而不是网络的；
（4）随后根据提示进一步操作，完成安装，注册；
（5）运行rational rose，进入主界面，new表示新建模型，existing表示打开现有，recent表示最近打开模型；
（6）熟悉模型的创建，保存，发布。
实验2：用例分析与设计
1、实验目的
1．熟悉用例图的基本功能和使用方法。2．掌握如何使用建模工具绘制活动图方法。
2、实验内容
1.根据某图书馆的图书管理系统开发进度，在完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。要求：
2.对其中主要功能的用例书写书面用例。
3、实验步骤
书写“删除读者信息”用例的书面用例。一般应包含以下信息：（1）管理员在录入界面，输入待删除的读者名；
（2）“业务逻辑”组件在数据库中，查找待删除的读者名；
（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；（6）在数据库中，删除相关信息；（7）显示删除成功信息；（8）结束。分析: 在图书管理系统中,管理员首先登录系统,系统验证通过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。
绘图步骤:(1)在用例图上双击main,出现如图2.1所示,为绘制用例图做好准备。
图2.1(2)在图中的工具栏选取Actor图标，在右边的图中添加一个Actor，并输入名称:administrator,如图2.2所示。
(3)在左边的工具栏中，选取用例的图标，在右边的图中画出一个用例，并输入用例的名称：login。
图2.2（4）按照步骤（3），绘制出如图2.4和图2.5的两个用例。
图2.3
图2.4
图2.5（5）在绘出了用例后，接下来的是绘制参与者与用例实现，如图2.6所示。
图2.6
（6）根据步骤（5），同时完成如图2.7和图2.8。此时，删除读者用例图就到此完成。其系统查询读者信息等其他的功能会在时序图和活动图中描绘。
（7）根据分析情况，进一步添加或细化用例图。
图2.7
图2.8
4、实验报告要求
1．可以细化、完善或者修改给出的例子，分析和设计用例图，写出实验步骤，整理实验结果。实验操作和步骤尽量详尽，并且按照指导书给出的范例，适当进行需求和系统分析，做出的各种框图需要在实验报告中画出来，可以打印。
2． 小结实验心得体会，对于遇到的问题给予分析。
实验3：类图的设计
1．实验目的
1.掌握使用rose画类图的步骤。2.掌握类图的基本语法。2．实验内容
1.根据图书管理系统的需要分析，用例图，交互图，对系统进行静态建模，寻找和发现类，分析类之间的关系； 3．实验步骤
1．打开前面初步构建的UML模型文件;2．打开Rose中的逻辑视图（Logical View），选择分析模型（analysis model）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。
3．用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Class diagram”项，创建类图。
4．双击新建的类图，并点右边控件集中选中的类并用鼠标在图中分别拖出上述类图。5．设定上述抽象出来各类的属性和操作。6．分析、设定以上各类之间的关系。
7．请根据教材中示例部分在Rational Rose中绘制类间的关系。
注意：这里没有具体的相关的例子；
实验4：状态图
1．实验目的
1．熟悉状态图的基本功能和使用方法。2．掌握如何使用建模工具绘制状态图方法。2．实验内容
1.通过某图书馆的图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态。通过这两类图我们可以初步了解系统的业务处理过程，但对业务处理过程的处理状态间转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态图能从对象的动态行为的角度去描述系统的业务活动。因此，指派你运用本节所学的状态图，完成如下任务：
2.完成图书业务模块中还书用例的状态图。3．实验步骤
1．业务分析：对图书馆管理系统中的还书主要业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Success）5种状态及激活相互转换的事件。
2．绘制状态图：请您根据分析运用UML绘制还书用例的状态图。分析：
还书的状态图，还书的主要业务都是由管理员来完成，首先管理员必须先登录系统，并通过验证后，便可以进行下一步的操作，查找该书的相关信息，如存在，则进行还书操作，如不存在该信息，则给出提示信息；
绘图步骤：
（1）在用例图中的还书（revesion）用例，单击右键，如图3.15所示，新建一个状态图，命名为revesion状态图，图3.16所示。
图3.15
图3.16（2）双击“receivesion”状态图，展开后，在左边的工具栏上选取一个实心圆点，此结点为开始结点，图3.17所示；当还书的时候，操作者先要询问系统的状态，如果系统忙，操 10 作者则必需等待，因此，得到系统的两种状态，如图3.19所示。
图3.17
图3.18
图3.19（3）操作者在询问系统和状态后，得到的图3.20所示两种状态，如果系统忙，操作者必需要等待、结束，如图3.21和图3.22所示，重返步骤（1）。
图3.20 12
图3.21
图3.22（4）如系统空闲，则进行对还书的信息进行查询操作，图3.23所示；查询也有两种结果，一是查询得到该书的相关信息，二查询不到该书的相关信息；则此时有两种状态，需要 13 建立两种状态，如图3.25所示。
图3.23
图3.24（5）最后，操作者进行了操作后，系统会给出操作的结果给操作者；操作成功或失败，都会有提示信息给出。整个的还书的过程便完成；
实验5：时序图
1．实验目的
1．理解时序（顺序）图的基本概念。
2．掌握在Rational Rose中绘制时序图的操作方法。2．实验内容
1.对图书的相关操作完成时序图； 3．实验步骤
1．分析：根据对图书业务功能模块中的时序图操作进行动态建模的操作步骤和方法，请你对书籍管理模块中的交互操作进行动态建模。该模块中主要存在新增书籍、修改书籍信息和删除书籍三种交互操作。
2．请根据教材中示例部分在Rational Rose中绘制上述的交互图。绘图步骤：
（1）在Rose软件的左边栏目上的Logicl View单击右键，新建一个时序图，时序图是交互图一种表示，可以用时序来表示，如图4.1；在此，先单间介绍一下用法：图中的直线箭头是发送消息；虚线箭头是返回消息；曲折线是对象自己给自己发送消息并调用。
（2）接下来的是添加类，系统中的类是其他的方法的边界，在上面做好的类找到可以直接拖拉来图中，见图4.2 和图4.3所示。
图4.1
图4.2
图4.3（3）添加类后，便可以添加方法了，开始是必需是外面的实体向系统发送消息，如图4.4所示，是管理员登录时向系统发送的消息；
图4.4（5）可以按上一步的方法来完成其他的方法，如viladate（验证）,返回验证结果，当用户收到结果后，可以正常登录后便能进行增加图书见图4.5到图4.9。最后得到的时序图如图4.10所示。
图4.5 : administrator1: login : ActionFormSystem2: login3: validate
图4.6 18 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result
图4.7 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add
图4.8
: administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook
图4.9
: administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook9: addruselt10: addresult
图4.10 20
实验6：协作图
1．实验目的
1．理解协作图的基本概念。
2．掌握在Rational Rose中绘制协作图的操作方法。2．实验内容
1.通过对教学内容的学习，使我们完成了某图书馆的管理系统的需求分析，并从业务对象中抽象出了类。现在需要对前面所给出的用例进行实现，主要是对书籍管理功能画协作图。3．实验步骤
1．分析：根据上面的时序图，我们也可以图出协作图。2．请根据上面时序图部分在Rational Rose中绘制协作图。绘图步骤：
(1)完成了时序图后，可以按F5键便得到增加图书的协作图，也可以画出图4.11这样的协作图。
1: login6: add : administrator5: result10: addresult : ActionForm3: validate8: addbook4: result9: addruselt2: login7: addSystem
图4.11
（7）剩下的更新图书信息和删除图书信息的交互图在此不再一一详细的介绍，其绘图方法跟绘制增加图书的方法一样，最后得到见图4.12 到图4.15 21 : administrator : ActionForm1: login2: loginupdate : System3: validate4: result5: result6: updatebook7: updatebook8: updatebook9: updateresult10: updateresult
图4.12
1: login6: updatebook : administrator5: result10: updateresult4: result9: updateresult2: login7: updatebook : ActionForm3: validate8: updatebookupdate : System
图4.13
: administrator : ActionForm : System1: login2: login3: viladate4: viladateresult5: viladateresult6: delete7: delete8: delete9: deleteresult10: deleteresult
图4.14
1: login6: delete : administrator5: viladateresult10: deleteresult : ActionForm3: viladate8: delete4: viladateresult9: deleteresult2: login7: delete : System
图4.15
实验7，8：综合设计实验
1．实验目的
1．掌握用Rational Rose进行软件建模。2．实验内容
1.对一个系统进行建模。3．实验步骤
1.对系统进行完整的建模。生成其用例图，状态图，活动图，时序图以及协作图。鼓励创新。
2.可以选择的系统有：本科生教务系统，图书管理系统，编译器，博客，即时通信软件等等。24
六、教材
实验教材以本实验指导书为参考；
七、成绩考核办法
采用综合实验与撰写报告综合评分
八、附A：完整UML建模过程例子
基于UML的面向对象分析与设计案例
介绍
本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。
经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。所以，想用好UML，扎实的OO思想基础是必不可少的。然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。
1.从需求到业务用例图
OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。
通过以上需求描述，我们画出如下的业务用例图：
这里要注意三点：
1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。2.业务用例仅包含客户“感兴趣”的内容。3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
2.从业务用例图到活动图
完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。例如，下面是“新闻管理”的活动图：
可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。
这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。
3.从活动图到系统用例图
找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。
一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。
最终我们得出的系统用例图如下：
4.从系统用例图到用例规约
得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。
下面给出“登录”这个系统用例的一个规约：
5.绘制业务领域类图
完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点：
1.系统中有哪些实体。2.这些实体能做什么操作。3.实体间的关系。
这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。
理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。
6.绘制实现类图
以上这几步，就是分析的过程。而下面的步骤就是设计了。
设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。
实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。
我们假设这个系统建构于.NET 3.5平台上，并且使用ASP.NET MVC作为表示层，整体使用三层架构。那么，用户模块体系的实现类图大体是这样子（不准确）：
7.绘制序列图
有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。
上图给出的是用户登录的序列图。首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。
要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。
8.后面的步骤
在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。
总结
本文简要给出了使用UML进行OOA&D的过程。当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。
点击咨询 