面向对象分析和与设计

第一篇：面向对象分析和与设计

面向对象分析与设计实验报告

实 实

验

报

告

课程名称

面向东西阐发与设计

专业班级

_ _ ___

__ __

学

号

__

___

姓

名

___

__ __

同组成员

实验日期

_

成

绩

____________ ___________

人为治理系统 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 的那栏的输入/输出部分。

3 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

数据治理部分设计

类“人为”和“人为表”组成了组合干系，对他们分别设立两张表，并在与类“人为”对应的表中用外键隐含它与类“人为报表”的关联。对付类“员工”和类“人为治理员”也分别设立一张表，用于存储相应的东西。

下面给出了类“人为”和类“人为表”所对应的数据库表的结构。

表 表

类“人为”所对应的数据库表的结构

本表的主要害字为事情证号

表 表

类“人为表”所对应的数据库 表的结构

本表的主要害字为事情证号+时间，外键为事情证号。

表 表

类“销售奖金”所对应的数据库表的结构

本表的主要害字为事情证号+时间，外键为事情证号

表 表

类“保险用度”所对应的数据库表的结构

本表的主要害字为事情证号+时间，外键为事情证号

第二篇：面向对象系统分析与设计试卷与答案1

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

面向对象分析与设计试题B卷

一、单项选择题 ( 在每小题的四个备选答案中，选出一个正确答案，并将正确答案的序号填在题干的括号内。每小题 1 分，共 20 分 ) 3.下列不属于面向对象技术的基本特征的是(

)。

A. 封装性

B. 模块性

C. 多态性

D. 继承性

4. 面向对象程序设计将描述事物的数据与 ( ) 封装在一起,作为一个相互依存、不可分割的整体来处理。

A. 信息

B. 数据隐藏

C. 对数据的操作

D. 数据抽象

5. 关于面向对象方法的优点，下列不正确的叙述是 (

)。

A. 与人类习惯的思维方法比较一致

B. 可重用性好

C. 以数据操作为中心

D.可维护性好 8. 下列不属于类的成员函数的是 ( )。

A. 构造函数

B. 析构函数

C. 友元函数

D. 拷贝构造函数

9. 继承机制的作用是 ( )。

A. 信息隐藏

B. 数据封装

C. 派生新类

D. 数据抽象

14. (

)是从用户使用系统的角度描述系统功能的图形表达方法。

A. 类图

B. 对象图

C. 序列图

D. 用例图

15. ( ) 是表达系统类及其相互联系的图示,它是面向对象设计的核心，建立状态图、协作图和其他图的基础。

A.对象图

B. 组件图

C. 类图

D. 配置图

16.(

)描述了一组交互对象间的动态协作关系，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。

A.对象图

B. 协作图

C. 状态图

D. 序列图

17.(

)就是用于表示构成分布式系统的节点集和节点之间的联系的图示，它可以表示系统中软件和硬件的物理架构。

A. 组件图

B. 协作图

C. 状态图

D. 配置图

18. 在用UML进行数据库的分析与设计过程中，( ) 就是进行数据库的需求分析，使用用例图、类图、顺序图、活动图等建立业务模型。

A. 逻辑数据模型设计

B 业务Use Case模型设计

C. 物理数据模型设计

D. 物理实现设计

19. 使用UML进行关系数据库的(

)时，需要设计出表达持久数据的实体类及其联系，并把它们映射成为关系数据库表(Table)、视图(View)等。

第 1 页 共 7 页

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品” 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

A. 业务Use Case模型设计

B. 逻辑数据模型设计 C. 物理数据模型设计

C. 物理实现设计 20. UML的动态建模表示包含(

)种图。

A. 9

B. 5

C. 4

D. 2

二、填空题 ( 每空 1 分，共 20 分 ) 1. 面向对象开发方法一改过去传统的以_______________为基础的______________的结构化分析与设计方法，它模拟人们理解和处理客观世界的方式来分析问题，把系统视为一系列_______的集合，其______________又将分析的结果映射到某种面向对象实现工具的结构上，使映射过程有着比较直接的对应关系，使分析者、设计者和编程者都可使用相同的______，从而使面向对象的软件开发能比较自然地模拟客观世界的活动，使问题描述空间与____________在结构上尽可能一致。因此，采用面向对象方法可以更有效地开发大型软件系统。面向对象方法的________、________、_________等机制不仅支持软件复用，而且使软件维护工作可靠有效，可实现软件系统的柔性制造，更好地克服____________。因此，它已成为成熟的广为采用的软件开发方法。

2. 对象是客观实体的抽象表示，是由__________________________和________________________两部分组成。而______是对具有相同属性和行为的一组对象的抽象描述。因此，它可作为一种用户自定义类型和创建对象的样板，而按照这种样板所创建的一个个具体对象就是类的___________。通过________关系又可形成一种类层次结构。

3. UML中用于描述系统的静态建模的视图称为静态视图，包括________、 _________、_________、__________和__________。

四. 简答题(每空4分，共 20 分) 1. 简述面向对象软件开发方法的优点。 2. 简述面向对象技术的三大机制。 3. 简述OOA模型的层次结构。

4. 简述OOD模型的总体结构，并画图表示。

5. 应用UML进行系统分析和设计所需建立视图有那几种?

第 2 页 共 7 页 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品” 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

五. 试用UML对教学管理系统及相关的数据库系统进行分析和设计。学生选课系统一般包括(1)选课管理功能;(2) 成绩管理功能。试完成下列工作： (1)建立系统静态结构模型—画出系统用例图和类图;(10分) (2) 建立系统动态结构模型—画出系统序列图和协作图;(10分) (3)建立关系数据库逻辑模型。(10分)

面向对象分析与设计试题参考答案

一、单项选择题 ( 每小题 1 分，共 20 分 )

1.D

2.C

3.B

4.C

5.C 6.D

7.D

8.C

9.C

10.D 11.B 12.B 13.B

14.D

15.C 16.D 17.D 18.B

19.B

20.C

二、填空题 ( 每空 1 分，共 20 分 )

1.功能分析, 面向过程, 对象,面向对象的设计, 概念,解空间,封装, 继承, 多态, 软件危机 2.描述对象属性的数据,

四. 简答题

1. 简述面向对象技术发展的动因。

答：为了超越程序复杂性障碍，克服软件危机,人们提出了面向对象软件开发方法。面向对象开发方法一改过去传统的以功能分析为基础的面向过程的结构化分析与设计方法，面向对象开发方法模拟人们理解和处理客观世界的方式来分析问题，把系统视为一系列对象的集合，其面向对象的设计又将分析的结果映射到某种面向对象实现工具的结构上，使映射过程有着比较直接的对应关系，使分析者、设计者和编程者都可使用相同的概念，从而使面向对象的软件开发能比较自然地模拟客观世界的活动，使问题描述空间与解空间在结构上尽可能一致。因此，采用面向对象方法可以更有效地开发大型软件系统。面向对象方法的封装、继承、多态等机制不仅支持软件复用，而且使软件维护工作可靠有效，可实现软件系统的柔性制造，更好地克服软件危机。因此，它已成为成熟的广为采用的软件开发方法。请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

2. 简述面向对象技术的三大机制。 答：(1)封装性(encapsulation)

第 3 页 共 7 页

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

, 类， 实例，继承

3.用例图、类图、对象图、包图、构件图、配置图 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

所谓封装就是把对象的属性和行为结合成一个独立的单位，使外界不能直接访问或修改这些数据和代码，外界只能通过对象提供的接口函数来改变或获取对象的属性数据，这就实现了消息隐蔽。 (2)继承性

如果在一个已定义的类上，增加一些特殊属性或操作，可以形成一个新的类，这个类不仅继承了前一个类的全部特征，而且具有新的特性，因此可看作前一个类的特例，是对前一个类的继承。前一个类称为父类，新产生的类叫做子类。通过继承关系可形成一种类层次结构，叫做继承结构。 (3)多态性

在类层次结构的不同类中，可用相同的函数名实现功能不同的函数。 3. 简述OOA模型的层次结构。

答：OOA模型采用五层次结构，它们分别是： (1)对象-类层

划分待开发系统及其环境信息的基本构造单位，标出反映问题域的对象和类，并用符号进行规范的描述，用信息提供者熟悉的术语为对象和类命名。 (2)属性层

定义对象和某些结构中的数据单元，继承结构中所有类的公共属性可放于通用类中。标识对象类必需的属性并放在合适的继承层次上，属性的特殊限制和实例连接关系也应标识出来。 (3)服务层

表示对象的服务或行为，即是要定义类上的操作。 (4)结构层

标识现实世界中对象之间的关系。当一个对象是另一个对象的一部分时，用"整体-部分"关系表示;当一个类属于另一个类时，用类之间继承关系表示。 (5)主题层

可将相关类或对象划分为一个主题。 4. 简述OOD模型的总体结构，并画图表示。 OOD体系结构的各个部分内容: (1)问题论域部分,在OOA模型的基础上,细化分析结果,设计一组构成底层应用模型的类和对象。

(2)人机交互部分：设计用户界面模型,该用户界面模型中的类和对象提供实现人机交互操作的接口函数。用户界面设计包括 菜单设计、窗口设计、输入/输出界面设计等等。 第 4 页 共 7 页

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品” 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

(3)任务管理部分：建立一些类，用以负责处理操作系统级的并发问题、中断、调度以及其它与特定平台有关的问题。

(4)数据管理部分：提供数据管理系统中存储和检索对象的基本结构，包括对永久性数据的访问和管理。数据管理设计包括：

— 数据存放设计：数据存放设计选择数据存放的方式(文件存放、关系数据库表格存放或面向对象的数据库存放)。

— 设计相应的操作。为每个需要存储的对象和类增加用于存储管理的属性和操作，在类和对象的定义中加以描述。

class & object layer(类及对象层)attribute layer(类及对象层)service layer(服务层)问题论域部分人机交互部分任务管理部分数据管理部分类边界实例边界实例连接属性消息服务struct layer(结构层)subject layer(主题层)主题图1.5 OOD模型的总体结构5.(1) 系统用例图如下

第 5 页 共 7 页

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品” 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

查询课程信息老师老师查询学生成绩选课注册学生学生查询课程成绩管理老师信息学生成绩管理管理学生信息管理员管理课程信息管理开设课程管理员成绩统计(b)成绩管理的用例图(a)选课管理的用例图

对象类图如下：

教师编号姓名地址电话1..*0..*课程课程名描述学时加入课程()1..*0..*学生编号姓名地址电话开设课程课程名授课日期授课时间地点指定老师()学生满否()选修课程学生名课程名学期增加记录()选课统计()(a)选课对象类图开设课程课程名授课日期授课时间地点指定老师()学生满否()学生成绩登记学生名学期课程名成绩加入成绩()打印()(b)成绩管理对象类图成绩统计学期课程名成绩按课程统计()按学生统计()打印()

第 6 页 共 7 页

请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品” 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

(2)把需要持久存储的数据实体类及其联系，映射成为如下关系数据库表：

学生(学生号、姓名、出生日期、性别、籍贯、地址、电话、入学时间、专业、班级备注) 教师(教师号、姓名、出生日期、性别、籍贯、地址、电话、职称、专长、备注) 课程(课程号、课程名、描述、学分、学时、性质、备注)

开设课程(课程号、学期、授课日期、授课时间、地点、选修人数、备注)

第 7 页 共 7 页 请大家帮忙把这句话设为QQ签名，“淘热门 http:// , 精选淘宝热门商品”

第三篇：面向对象分析与设计-牙科诊所管理系统

牙科诊所管理系统

王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。

当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。

系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。

1、建立牙科诊所管理系统的对象模型。

2、建立牙科诊所管理系统的用例模型。

3、用数据流图建立所述牙科诊所管理系统的功能模型。

4、画出牙科诊所管理系统的状态图。

1、建立牙科诊所管理系统的对象模型

(1)词法分析，找出(名词)作为对象的候选者;

王大夫在小镇上开了一家牙科诊所。他有一个牙科助手、一个牙科保健员和一个接待员。王大夫需要一个软件系统来管理预约。

当病人打电话预约时，接待员将查阅预约登记表，如果病人申请的就诊时间与已定下的预约时间冲突，则接待员建议一个就诊时间以安排病人尽早得到诊治。如果病人同意建议的就诊时间，接待员将输入约定时间和病人的名字。系统将核实病人的名字并提供记录的病人数据，数据包括病人的病历号等。在每次治疗或清洗后，助手或保健员将标记相应的预约诊治已经完成，如果必要的话会安排病人下一次再来。

系统能够按病人姓名和按日期进行查询，能够显示记录的病人数据和预约信息。接待员可以取消预约，可以打印出前两天预约尚未接诊的病人清单。系统可以从病人记录中获知病人的电话号码。接待员还可以打印出关系所有病人的每天和每周工作安排。

(2)找出问题域中对象，对候选对象进行严格筛选，从中删除不正确的或不必要的，只保留确实应该记录其信息或需要提供服务的那些对象。

王大夫(牙医的实例)

小镇(牙科诊所的地址属性)

牙科诊所

牙科助手 牙科保健员 接待员(外部角色，不是问题域内的对象)

软件系统(与“系统”同义，指将来开发的软件产品)

预约

病人

预约登记表 就诊时间(与“预约时间”，“约定时间”同义，都是“预约登记表”的属性)

预约时间 约定时间 系统

名字(与“姓名”同义，是病人记录的属性)

记录的病人数据(即“病人记录”)

病历号(病人记录的属性)

姓名

日期(“预约登记表”的属性)

预约信息(与“病人清单”包含的信息基本相同)

病人清单

病人记录

电话号码(病人记录的属性)

每天工作安排 每周工作安排

(3)确定问题域中对象彼此之间的关系。

1牙科诊所11..*病人清单1..*1预约登记表111..*工作安排1..**预约11病人记录1病人1..*每天工作安排每周工作安排

2、建立牙科诊所管理系统的用例模型。

牙科诊所管理系统<>完成预约*1111*查询预约*职员*更新预约<><>取消预约<>1*牙医1打印工作安排访问预约登记表<><>访问病人记录*

3、用数据流图建立所述牙科诊所管理系统的功能模型。

1查询病人数据病人数据病人数据D1病人记录姓名病人日期2查询预约日期有效日期3完成预约预约信息7打印工作安排每天和每周工作安排牙医4取消预约姓名/日期预约信息预约信息预约信息预约信息职员姓名5更新预约D2预约登记表预约信息姓名/日期6查询预约预约信息职员

4、画出牙科诊所管理系统的状态图。

牙科诊所管理系统的主要功能是实现病人预约，状态图如下，图中把除了完成病人预约之外的事务笼统地称为日常事务。

查找病人记录及可能的预约输入有效名字开始返回确认信息处理日常事务退出进行预约确认预约输入非法名字、按姓名或日期查询，打印工作安排，取消预约

第四篇：石河子大学 信息学院 面向对象的设计与分析 OOAD考试总结

OOAD总复习

第一章

1、什么是分析与设计?

1、分析强调对问题和需求的调查研究

2、设计强调的是满足需求的概念上的解决方案

2、什么是面向对象分析与设计?

1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象(或概念)

2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。

3、简单示例：

1、定义用例(use case)

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型(domain model)

面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。(也被称为概念领域模型—conceptual object model)

3、定义交互图

关注的是软件对象的定义—它们的职责和协作。顺序图(sequence diagram)是描述协作的常见方法。它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图

除了在交互图中显示对象协作的动态视图外，还可以用设计类图(design class diagram)来有效的表示类定义的静态视图。这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类

要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章

1、什么是UML?

统一建模语言(UML)是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构(Model Driven Architecture, MDA)CASE工具供应商具有影响。开发者并不需要对其进行学习。

2、三种UML应用方式

1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。用于：①逆向工程;②代码生成。

3、UML作为编程语言—用UML完成软件系统可执行规格说明。

3、什么是UP?

软件开发过程(software development process)描述了构造、部署以及维护软件的方式。统一过程(UP)已经成为一种流行的构造面向对象系统的迭代软件开发过程。

4、迭代(iterative)、进化(evolutionary)和敏捷(agile)

1、迭代开发是UP和大多数其他现代方法中的关键实践。每次迭代都具有各自的需求分析、设计、实现和测试活动。

2、迭代进化开发

小步骤、快速反馈和调整是迭代开发的重要思想。短时迭代为上。迭代的一个关键时光可见

第 1 页

2013-3-31 OOAD总复习

思想是时间定量，或者时长固定。

3、瀑布生命周期

在瀑布(或顺序)生命周期过程中，试图在编程之前(详细)定义所有或大部分需求。而且通常于编程之前创建出完整的设计(或模型集)。

4、什么是敏捷模型?

1、采用敏捷方法并不意味着不进行任何建模，这是错误理解。

2、建模和模型的目的主要用于理解和沟通，而不是构建文档

3、不要对所有或大多数软件建模或者应用UML。

4、尽可能使用最简单的工具。

5、UP所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。

6、UP的四个阶段：初始(inc)、细化(elaboration)、构造(construction)、移交(transition)

第五章

1、进化式需求

1、需求就是系统(广义的说法是项目)必须提供的能力和必须遵从的条件。

2、需求分析的最大挑战是寻找、沟通和记住(通常是指记录)什么事真正需要的，并能够清楚的讲解给客户和开发团队的成员。

3、需求变更是不可避免的，因此有效的管理和关键

4、进化式需求VS瀑布式需求：„„

5、需求按照“FURPS+”模型进行分类：

1、功能性：特性、功能、安全

2、可用性：人性化因素、帮助、文档

3、可靠性：故障频率、可恢复性、可预测性

4、性能：响应时间、吞吐量、准确性、有效性、资源利用率

5、可支持性：适应性、可维护性、国际化、可配置性

6、一些次要因素：实现、接口、操作、包装、授权

6、UP制品如何组织需求：

1、用例模型：一组使用系统的典型场景。

2、补充性规格说明：基本上是用例之外的所有内容。

3、词汇表：词汇表以最简单的形式定义重要的术语。

4、设想：概括了高阶需求，项目的业务案例。

5、业务规划(领域规划)：通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或者业务所要求的，并且许多应用应该遵从这些规则。

第六章

1、用例是文本文档，而非图形;用例建模主要是编写文本的活动，而非制图。

2、用例常用的三种形式：

1、摘要(brief)：简洁的一段式概要，主要用于主成功场景。

2、非正式(casual)：非正式的段落格式。

3、详述(fully-dressed)：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和保证成功。

3、参与者(actor)、场景(scenario)、用例(use-case)

1、参与者是某些具有行为的事物，可以是人、计算机系统或者组织。

2、场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例

时光可见

第 2 页

2013-3-31 OOAD总复习

3、用例是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

4、准则：如何发现用例?

1、选择系统边界

2、辨别主要参与者

3、辨别每个参与者的目标

4、定义用例以满足目标

5、准则：什么样的测试有助于发现有用的用例?

1、老板测试(the boss test)：老板的一问一答

2、EBP测试(the ERP test)基本业务过程

3、规模测试(the size test)

6、示范：应用上述测试

1、就供应者合同进行协商：

比ERP更广泛，用时更长。更适合作为业务用例，而非系统用例。

2、处理退货

能够通过老板测试。看上去与ERP类似。规模适合

3、登陆

如果你一整天都在登陆，老板不会满意

4、在游戏板上移动棋子

单一步骤，不能通过规模测试

第八章

1、迭代1的需求和重点：OOA/D技术的核心

2、过程：初始(inception)和细化(elaboration)

初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。

细化是一般项目中最初的一些列迭代，其中包括：

1、对核心、有风险的软件架构进行编程和测试

2、发现并稳定需求的主要成分

3、规避主要风险

第九章

1、领域模型是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念膜性能高、领域对象模型和分析对象模型。

2、应用UML表示法，领域模型被描述为一组没有定义操作(方法的特征标记)的类图(class diagram)：

1、领域对象或者概念类

2、概念类之间的关联

3、概念类的属性

3、准则：如何创建领域模型?

1、寻找概念类

2、将其绘制成UML类图中的类

3、添加关联和属性

4、准则：如何找到概念类?

时光可见

第 3 页

2013-3-31 OOAD总复习

1、重用和修改现有的模型

2、使用分类列表

3、确定名词短语

5、准则：何时需要描述类?

1、需要有关商品或者服务的描述，独立于任何商品或服务的现有实例

2、删除其所描述事物的实例后，导致信息丢失，而这些信息也是需要维护的，但是被错误地与所删除的事物关联起来

3、减少冗余或重复信息

6、关联(association)是类(更精确的说，是这些类之间的实例)之间的关系，表示有意义和值得关注的连接

7、准则：在UML中如何对关联命名?

以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读和有意义的顺序。

8、准则：任何属性都不表示外键

第十章

1、系统顺序图(SSD)是为阐述与讨论系统相关的输入和输出事件而快速、简单地创建制品。它们是操作契约和(最重要的)对象设计的输入

2、SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。

3、对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统(作为黑盒)以及由参与者发起的系统事件。

4、什么是系统顺序图?

系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之间的事件，所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。

第十一章

1、操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。

2、定义：契约有哪些部分?

1、操作：操作的名称和参数

2、交叉引用：会发生此操作的用例

3、前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。

4、后置条件：最重要的部分。完成操作后，领域模型对象的状态。

3、什么是系统操作?

系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。

4、后置条件描述了领域模型内对象状态变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。

5、准则：契约在何时有效?

在UP中，用例是项目需求的主要知识库。用例可以为设计提供大部分或全部所需细节。这中情况下，契约就没什么用处。

6、准则：如何创建和编写契约?

1、从SSD图中确定系统操作

时光可见

第 4 页

2013-3-31 OOAD总复习

2、如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约

3、使用以下几种类表来描述后置条件：

1、创建或删除实例

2、属性值的变化

3、形成或消除关联(UML连接)

第十三章

1、什么是逻辑架构和层?

逻辑架构是软件类的宏观组织结构，它将软件类组织为包(或命名空间)、子系统和层等。之所以称之为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理计算机上对这些元素进行部署。

层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。

OO系统中通常包括的层有：

1、用户界面

2、应用逻辑和领域对象

3、技术服务

2、什么是软件架构?

架构是一组重要的决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。

第十五章

1、交互图这一术语是对以下两种更为特化的UML图的统称

1、顺序图：以一种栅栏格式描述交互，其中在右侧添加新创建的对象。

2、通信图：以图或者网络格式描述对象交互，其中对象可以置于图中的任何位置。

2、顺序图的基本表示法：

1、消息：实心箭头

2、应答或返回：在活动条末端使用应答(或返回)消息线

3、异步调用：虚线

3、通信图的基本表示法：

1、链是连接两个对象的路径，它指明了对象间某种可能的导航和可见性。链是关联的实例。

2、消息：对象间的每个消息都可以使用消息表达式和指明消息方向的小箭头表示。

3、消息的顺序编号：

1、不为第一个消息编号

2、使用合法编号方案来表示后续消息的顺序和嵌套，其中的嵌套消息要使用附加的数字

4、可以在顺序编号后使用带有方括号[]的条件句子来表示有条件消息。为真时发送消息

5、互斥的有条件路径：在顺序编号后面加上字母，第一个字母是a

6、迭代或循环：在顺序编号后面加*

第十六章

时光可见

第 5 页

2013-3-31 OOAD总复习

1、表示UML属性的方法：属性文本和关联线

2、在DCD中使用关联表示属性时的风格：导航性箭头、角色名、

3、对于领域模型使用类图的时候，需要表示关联名称，但是要避免使用导航箭头，因为领域模型不是软件透视图。

3、对数据类型对象使用属性文本表示法，对其他对象使用关联线。

4、依赖用从客户到提供者的虚线箭头表示(AB，B发生变化会影响A)

5、比较常见的依赖类型：

1、拥有提供者类型的属性

2、向提供者发送消息

3、接收提供者类型的参数

4、提供者是超类或者接口

6、依赖标签

7、插座法表示接口

8、限定关联

第十七章

1、GRASP：基本OO设计的系统方法

2、GRASP：使用职责进行OO设计的学习工具

3、RDD(responsibility-driven design)：职责驱动设计。

4、UML把职责定义为“类元的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：行为和认知。

1、行为职责：

1、自身执行一些行为，如创建对象或计算。

2、初始化其他对象中的动作

3、控制和协调其他对象中的活动

2、认知职责：

1、对私有封装数据的认知

2、对相关对象的认知

3、对其能够导出或计算的事物的认知

5、对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。

6、职责的粒度会影响职责到类和方法的转换。

7、什么是模式?

如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。

在OO设计中，模式是对问题和解决方案的已命名描述，它可以用于新的语境。

8、使用GRASP进行对象设计的简短示例

1、创建者

2、信息专家

3、低耦合

4、控制器

5、高内聚

9、创建者：谁创建了A?

解决方案：(有一个为真即可)

时光可见

第 6 页

2013-3-31 OOAD总复习

1、B“包含”或组成聚集了A

2、B记录A

3、B紧密地使用A

4、B具有A的初始化数据

10、信息专家：如果给定键值，谁知道Square对象的信息?

解决方案：把职责分配给具有完成该职责所需信息的那个类

11、低耦合：为什么是Board而不是Dog?如何减少变化产生的影响?

解决方案：分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估

12、控制器：在UI层之上首先接受和协调系统操作的对象是什么?

解决方案：把职责分配给能代表下列选择之一的对象：

1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统

2、代表发生系统操作的用例场景(用例或会话)

13、高内聚：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用?

解决方案：职责分配应保持高内聚，依此来评估备选方案

第十八章

1、用例实现描述某个用例基于协作对象如何在设计模型中实现。更精确的说，设计者能够描述用例的一个或多个场景的设计，其中的每一个设计都称为用例实现。

2、下面说明了一些制品之间的关系：

1、用例指出了SSD中所示的系统操作

2、系统操作可以称为输入到领域层交互图的控制器中的起始消息

3、领域层交互图阐述了对象如何交互完成所需任务—用例实现

第十九章

1、可见性是一个对象看见其他对象或引用其他对象的能力

2、实现对象A到对象B的可见性通常有四种方式：

1、属性可见性—B是A的属性

2、参数可见性—B是A中方法的参数

3、局部可见性—B是A中方法的局部对象(不是参数)

4、全局可见性—B具有某种方法的全局可见性

第二十章

1、用OO语言(java或者C#)创建代码并不是OOA/D的一部分，它是最重的目标

2、在UP中具有实现模型。源代码、数据库定义、JSP/XML/HTML页面等都是实现制品

3、面向对象语言中的实现需要以下元素编写源代码：

1、类和接口的定义

2、方法的定义

第二十三章

1、在迭代1结束的时候，应该已经完成以下任务：

1、所有软件都已经被充分地测试

2、客户定期地参与对已完成部分的评估

3、已经对系统进行了完成的集成和固化，使其成为基线化的内部版本

2、迭代2的需求和重点：对象设计和模式

时光可见

第 7 页

2013-3-31 OOAD总复习

1、支持第三方外部服务的变化

2、复杂的定价规则

3、需要进行设计，使得在销售总额变化时刷新GUI窗口

第二十五章

1、之前介绍了5个GRASP模式：信息专家、创建者、高内聚、低耦合、控制器

2、下面介绍最后4个GRASP模式：多态、间接性、纯虚构、防止变异

3、多态：如何处理基于类型的选择?如何创建可插拔的软件构件?

解决方案：当相关选择或行为随类型(类)有所不同时，使用多态操作作为变化的行为类型分配职责。推论：不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择

4、纯虚构：当你并不想违背高内聚和低耦合或者其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责?

解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念—虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的。

5、间接性：为了避免两个或多个事物之间直接耦合，应该如何分配职责?如何使用对象解耦合，以支持低耦合并提高复用性潜力?

解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性

6、防止变异：如何设计对象、子系统和系统，使其内部的变化或不稳定不会对其他元素产生不良影响?

解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口

第二十六章

1、适配器(GoF)：如何解决不相容的借口问题，或者如何为具有不同接口的类似构件提供稳定的借口?

解决方案：通过中介适配器对象，将构件的原有接口转换为其他接口。增加一层间接性对象，通过这些对象将不同的外部接口调整为在应用程序内使用的一致接口

2、工厂：当有特殊考虑(例如存在复杂创建逻辑，为了改良内聚而分离创建职责等)时，应该由谁来负责创建对象?

解决方案：创建称为工厂的纯虚构对象来处理这些创建职责

3、单实例类：只有唯一实例的类即为“单实例类”。对象需要全局可见性和单点访问

解决方案：对类定义静态方法用以返回单实例

4、策略：如何设计变化但相关的算法或政策?如何设计才能使这些算法或政策具有可变更能力?

解决方案：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同接口

5、组合：如何能够像处理非组织(原子)对象一样，(多态地)处理一组对象或具有组合解耦股的对象呢?

解决方案：定义组合和原子对象的类，使它们实现相同的接口

6、外观：对一组完全不同的实现或接口需要公共、统一的接口。可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变，怎么办?

解决方案：对子系统定义惟一的接触点—使用外观对象封装子系统。该外观对象提供了惟一和统一的接口，并负责与子系统构件进行协作

7、观察者(发布—订阅)：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并时光可见

第 8 页

2013-3-31 OOAD总复习

且想要在发布者产生事件时以自己独特的方式作出反应。此外，发布者想要保持与订阅者的低耦合。如何对此进行设计呢?

解决方案：定义“订阅者”和“监听器”接口。订阅者实现此接口。发布者可以动态注册关注某事件的订阅者，并在事件发生时通知它们

第三十章

1、包含关系：多个用例中存在部分相同的行为，这是常见的现象

2、如下情形可以分解出子功能用例并使用包含关系：

1、用例在其他用例中重复使用

2、用例非常复杂并冗长，将其分解为子单元便于理解

3、具体用例是由参与者发起，完成了参与者所期望的完整行为。它们通常是基本业务过程用例

4、抽象用例永远不能被自己实例化，它是其他用例的子功能用例

5、包含其他用例的用例，或者是被其他用例扩展或者泛化的用例被称为基础用例

6、被其他用例包含的用例，或者扩展、泛化其他用例的用例被称为附加用例

7、扩展关系的思路是，创建扩展或附加用例，并且在其中描述：在何处何何种条件下该用例扩展某基础用例的行为

8、事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系

9、扩展关系的UML表示法：

1、扩展用例指向基础用例

2、在线上可以表示条件和扩展点

第三十一章

1、泛化是在多个概念中识别共性和定义超类(普通概念)与子类(具体概念)关系的活动

2、概念超类与子类之间是什么关系?

3、概念超类的定义较子类的定义更为概括或包含范围更广

4、泛化和类集的关系：概念子类集合的所有成员都是其超类集合的成员

5、100%规则：概念超类的定义必须100%适用于子类，子类必须100%与超类一致：属性、关联

6、Is-a规则：子类集合的所有成员必须是其超类集合的成员

7、什么是正确的概念子类?

潜在的子类应该遵守下述规则：

1、100%规则(定义的一致性)

2、Is-a规则(集合成员关系的一致性)

8、在下述几种情形下创建概念类的子类

1、子类有额外的有意义的属性

2、子类有额外的有意义的关联

3、子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方式是我们所关注的

4、子类概念表示了一个活动体(例如动物、机器人等)，其行为与超类或者其他子类不同，而这些行为是我们所关注的

9、在下述情形下可以创建与子类具有泛化关系的超类

1、潜在的概念子类表示的是相似概念的不同变体

2、子类满足100%和Is-a规则

时光可见

第 9 页

2013-3-31 OOAD总复习

3、所有子类都具有相同的属性，可以将其解析出来并在超类中表达

4、所有子类都具有相同的关联，可以将其解析出来并与超类关联

10、在领域模型中，如果类C可能同时有多个相同的属性A，则不要将属性A置于C至中，应该将属性A放在另一个类中，并且将其与C关联

11、在领域模型中增加关联类的可能线索有：

1、有某个属性与关联有关

2、关联类的实例具有依赖于关联的生命期

3、两个概念之间有多对多关联，并且存在于关联自身相关的信息

12、在下述情况下，可以考虑组合关系：

1、部分的生命期在组成生命期界限之内，部分的创建和删除依赖于整体

2、在物理或逻辑组装上，整体—部分关系很明确

3、组成的某些属性会传递给部分

4、对组成的操作可能传递给部分

13、在关联中可能会

时光可见 第 10 页 2013-3-31

第五篇：C#面向对象程序设计感想

本课程主要讲解了控件，资源管理器，文件流，线程等等，通过这门课的学习，我学到了一些应用性的知识，比如如何设计控件，对文件流进行程序的代码编写，还有就是多线程编程技术，在此我想主要谈谈基本控件的学习和感想

学习控件，使我了解了基本控件的使用方法。在原先学习过c#的基础上，通过将窗体和控件联系起来，使得编写代码不再枯燥，反而能编写出更好玩的东西，比如《贪吃蛇》《拼图》这样的小游戏(界面有点死板哈，但是基本可以看出来的，还有待改善)，在这其中确实增加了学习的兴趣，更深刻得理解了程序的编写，提高了编程的能力。

当然，到现在仍然有一些问题，比如timer，picturebox之类的，老师在教的时候，听课是没有一点困难的，难的是课堂上记住操作步骤，即使上课记下一点，但是只要有一处漏记了就有可能出现问题，课后自己再去搞，难免会出现一些差错，尤其是自己设计的控件的软件嵌入，以及下次想使用的调用，这里都有一定的空白…,我希望老师在教的时候，每讲完一个知识点，就停下来，让我们好再理解一下

还有就是有时候遇到的问题，很难用语言向老师表达，想直接带电脑又不方便，这也是一个纠结的事情啊…所以，我觉得上机的时间要是多点该多好，可以直接问老师呢。 C#的学习是我们学习计算机课程的一部分，在这门课动手能力要求较高的客观需求上，我认识到对计算机课程的学习，不仅要背诵一些基本的原理和方法，更重要的是理论基于实践，在实践中感受理论，从而提高自己对计算机编程的认识。