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

第一篇：石河子大学 信息学院 面向对象的设计与分析 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

第二篇：面向对象的设计与分析(网上商城的建模设计)

第4章江西师范大学“网上商城”建模实例

本文所要进行建模分析的系统是学校小型电子商务系统，以欲构建的江西师范大学的便利店和生活超市“网上商城”为例，是满足校园客户(主要在校学生)网购要求的综合性的应用系统，本文以Rational rose 2003为建模工具，并应用第三章提出的基于UML的电子商务系统建模过程，完成该系统的详细分析和设计。对系统进行需求分析，建立系统需求模型、静态结构视图、动态结构视图、数据库模型、物理模型。

4.1系统的需求分析 4.1.1系统的设计背景

江西师范大学瑶湖校区江西师范大学新校区，地处南昌市昌东镇，在校学生3万余人，由于学校占地面积很大，离市区比较远，周围设施还不是很齐全，该校区为解决师生日常生活需要，建设了商业街并且每个宿舍区都有便利超市，这些店是一个小型的生活用品采购区，在校学生平时的大部分消费都是在这些地方，包便利店和小型超市等生活服务的实体商店，满足了师生不出校门就能买到自己想要的东西。近些年，随着高校的扩招，该校区学生和老师的数量也不断增加，新的问题也随之而来，高校学生由于社会发展带来的的巨大压力，生活节奏也日益加快，空闲时间也越来越少。所以如果他们每次生活消费都要到实体店购买，就给他们的生活带来不便，因而如果能够网上购物就解决了这个矛盾。另外，据数据显示，该校学生80%是网民，该群体的素质较高，接受新事物速度快，而且他们的消费兴趣和倾向也有高度的相似性。该校区学生居住地也比较集中，大都住在学校统一安排的公寓或者学校周围的小区，使物流配送更加方便和及时。目前学校的实体商店很多，但是大多数商店还没有自己的电子商务系统，所以如果通过一个统一的网上购物平台，商店将这些商品都发布在网上商城上，师生就可以足不出户选购商品，非常方便。只要授予他们可以在平台上销售自己的商品，提高了商店的知名度，也提高了他们的服务能力和影响力。该网上商城具有一般网上购物系统的功能: 1.师生可以通过该网上商城注册为商城用户，浏览商品订购商品放入购物车;客户可以通过该商城发布评论信息;客户可以查看自己订单;客户可以支付商品货款。

2.商户可以通过该商城发布自己的商品信息、供师生购买;可以通过该商城管理自己的商品信息和员工信息;可以进行订单处理。3.系统管理员对商户申请信息进行审核;对评论信息管理:对系统日常的维护和数据备份;对用户信息管理。

除了以上三个一般购物系统的功能商城的系统管理员可以通过对历史订单信息进行数据挖掘，找出顾客购买商品间的关联关系，建议商户对其营销策略进行调整或者绑定销售一些商品，以提高商户的销售利润，达到在线交易和实体店双重赢利。该功能模块的设计将在第五章详细说明。4.1.2系统的模块设计

根据以上背景，本文欲构建一个具有上述功能的江西师范大学“网上商城”。该商城可以满足师生网上购物的要求，注册该商城用户都可以直接登录到该商城。该商城为校园的客户提供了一个统一的网上交易平台，该网上商城的业务流程图，如图4.1所示。

通过以上背景分析和业务流程的设计，根据一般网上购物系统的功能，并结合该“网上商城”的特殊功能需求，根据商城所涉及到的主要参与者将该商城主要功能描述如下: 1，商城维护:管理员可以对商城日常维护和数据备份。2.商户信息管理:管理员对申请加盟的商户等级管理和商户信息修改，添加等操作。

3.商城用户信息管理:对商城注册用户信息的管理，以及其应用权限

4.评论管理:管理员可以对评论信息进行处理，对于不符合要求的评论可以删除。

5.收集数据:系统管理员可以根据数据库中一段时间的订单历史记录查询分析，收集到分析数据。

6.订单分析:管理员可以对收集到的数据进行分析，得出商品之间的关联性。建议商户调整销售策略，从而提高商店利润。

7.商城注册:非家园网或非商城用户的客户可以注册为商城用户。8.修改个人资料:注册用户可以修改自己的注册资料。包括地址，电话等基本信息。

9.商城登录:系统管理员、用户、商户都可以登录商城相应的模块在相应权限内操作。

IO.查看商品信息:进入商城的师生都可以浏览商品信息，该商品信息包括商品的基本信息和商品的库存。

11.购物:如果商品有库存则客户可以购买，如果缺货则不能购买，客户将商品放入购物车，进行购物。客户可以对购物车里的商品随时修改，删除，添加和清空。

12.下订单:客户将商品加入购物车后，可以填写订单，对于订单，在未处理之前，客户也可以随时登录系统修改并提交。

13.支付:订单提交以后，客户可选择支付方式，如选择货到付款则订单完成，如选择网上支付，则客户要登录网上银行支付，支付完成则该订单完成。

14.订单查看:客户可以随时登录系统查看自己的历史订单信息，可以删除历史订单，可以查看订单状态，订单在未处理之前都可以修改然后再提交，也可以对取消未处理的订单。

15.评论:收到商品以后客户对商品和商户的服务是否满意可以对此订单进行评论。

16.申请加盟商城:商户申请加盟商城，资格审核通过后可以在商城建立自己的网上商店，拥有该商店的管理权限，可以进行网上交易。17.商品信息维护:商户可以随时添加、修改、删除商品的信息。18.配送员信息管理:商户可以对商店里的配送员信息进行添加、修改、删除，以更好的管理商店的配送工作。

19.订单处理:客户提交订单以后，商户接收订单并与客户确认订单以后对订单进行处理，根据订单所购买的商品，商户查询库存，确认库存中有该商品，对订单进行审批，审批完了后则打印配送订单，安排送货。

20.派遣配送员:商户点击相关功能，将输出配送员编号，商户把送货单和商品交予该配送员负责，配送员把商品送到客户指定的地点，如果无人收货，则在订单回执中填写“无人接货”，如果收货成功，则填写“收货成功”，如收货人推迟收货则填写“推迟收货”。并将订单回执交予商户。

21.库存管理:商户可以对商品库存进行定期清点，并修改商品信息中的库存信息。

22.配送订单管理:对已经处理的订单，商户打印出配送订单，并安排配送员配送，对配送订单的完成情况进行管理。

23.查看商品销售记录:商户可以对本商店的商品信息随时查看。24.查询分析结果:商户可以登录商城查询商品的关联分析结果，通过结果设置相应的销售捆绑包或交叉销售。

25.设置销售捆绑包:对分析到的关联商品，通过后台输入设置到捆绑包中。

满足上述需求的系统主要包括以下几个模块: 系统管理模块:该模块是系统提供给系统管理员的接口模块。主要包括对校园商户的加盟审核，对商店申请信息的管理，根据商户等级和信誉来决定删除和添加商户，另外对网站用户信息的管理。该模块可以对系统日常维护和数据备份，并且通过对订单信息进行数据分析，以帮助商户制定营销策略，赢得更大的利润。

用户接口模块:该模块为想购买该网站商品的学生提供的了入口，所有校园的师生都可以通过浏览器浏览该网站商品，可以注册为该系统用户并登录该系统订购自己喜爱的商品。

商户操作模块:该模块是“网上商城”的核心模块。主要包括接受客户完成的订单需求，指派特定的配送员，配送员根据订单所需提货，配送员送货上门，客户签收商品并生成回执单，商户可以查看最近一段时间某商品的销售记录，根据查看的商品订单分析结果制定相应的捆绑销售或者交叉销售策略。

4.2需求建模

该系统需求建模描述系统用户使用一个系统的方式，描述系统应该具备什么功能，是系统用户或者另一个系统与系统之间的一次交互过程，是系统分析和设一计的第一步，以系统全局的功能作为参考，把系统所涉及的参与者和他们从外部观察到的系统的功能描述出来，而并不描述这些功能在系统功能的实现形式。这个过程使用UML建立系统的用例图，分离出系统执行者和用例，以及用例之间的关系。4.2.1系统参与者

参与者是系统外部的一个实体，可以是系统用户、与所建造的系统交互的其他系统或者是一些可以运行的进程。第一，在每一个系统中，几乎都存在着最常用的参与者一真实的人(用户);第二，需要建立联系的其他外部应用程序，即其他系统;第三，一些可运行的进程，如时一间;通过上面对该系统的功能分析和系统功能模块的设计，系统参与者主要有:系统管理员、客户、商户和支付系统。4.2.2识别用例

确定用例最常用的方法是从分析系统参与者开始，把每个系统参与者如何使用系统的行为都考虑进来。根据上一节系统的需求分析功能模块，可以确定系统参与者有系统管理员、客户、商户和支付系统。根据上一小节的功能模块分析，得出系统的顶层用例图，如图4.2 0

下面分别对三个用例细化，系统管理所涉及到的用例有:商城登录，商户信息管理，用户信自、管理，评论管理，商城日常维护和订单分析。涉及到的参与者是系统管理员，系统管理的用例图如4.3所示。

用户接口用例细化有:商城注册，商城登录，查看商品信息，修改个人资料，购物，下订单，支付，评论，订单查看。用户接口的用例图如图4.4所示。

其中“购物”用例细化的用例有:清空购物车，修改购物车商品，添加商品到购物车，查看购物车信息，删除购物车中的商品。细化后的用例图如图4.5

“订单查看”用例细化的用例有:修改订单，提交订单.，删除订单，查看历史订单，订单状态查询，取消订单。细化后用例图如图4.6所示。

商户操作的细化用例有:申请加盟商城，商城登录，商品信息维护，配送信息管理，订单处理，配送订单管理，派遣配送员，查看商品销售记录，库存管理，查看订单分析结果，设置商品销售捆绑包。商户操作用例细化图，如图4.7所示。

商品信息维护的细化的用例有:增加商品信息，删除商品信息，修改商品信息。细化后的用例图如图4.8所示。

订单处理的细化用例有:确认订单，接收发货，查询商品库存。如图4.9

支付系统用例有:支付，网上支付，货到支付。支付系统的用例图，如图4.10所示。

根据以上对系统参与者的用例图分析与建模，得出系统的完整的用例图，如图4.11所示。

4.3静态结构建模

静态结构模型是对有关系统实现内部和应用领域的概念进行建模，本文通过分析上述需求建模中的用例和问题域，抽取相关的类，并将这些类之间的关系表示出来，以及类的内部结构，最后完成类图，反应了系统的一种静态关系。(1)抽取系统中的类

系统中存在三种类，一种是系统与外界的交界处，包括各种窗体和接口(与报表、打印机和扫描仪等硬件的接口或者与其他系统的接口);另一种是负责协调其他类工作的控制类，是控制使用事件的顺序的类;第三种是保存放入永久存储体的数据信息类，即实体类。本文将以“下订单”举例说明分析类的整个流程。

下订单用例的主要功能是:客户登录商品信息查看页面，系统验证客户注册信息，系统打开下订单页面，填写订单并提交订单信息，根据以上描述，该用例涉及到的类如下: 边界类:商品信息查看页面，填写订单页面。

控制类:下订单。

实体类:客户信息类，商品详细信息类，订单信息类。

据以上方法分析系统其它用例并经过整理合并，得出网上商城的类如下: 1.边界类:用户注册界面，用户登录界面，商品详细信息界面，商品查看界面，下订单界面，评论界面，支付界面，个人资料修改界面，订单查看界面，商品信息维护界面，查看订单分析结果界面，派遣配送员界面，设置商品销售捆绑包界面，订单处理界面，配送订单管理界面，配送员信息管理界面，库存管理界面，查看商品销售记录界面，商户信息管理界面，用户信息管理界面，商城维护界面，审核界面，评论管理界面，收集数据界面，订单分析界面。

2.控制类:用户注册，用户登录，浏览商品，下订单，评论，支付，个人资料修改，订单查看，商品管理，配送员管理，查看订单分析结果，派遣配送员，设置商品销售捆绑包，订单处理，配送订单管理，库存管理，查看商品销售记录，用户管理，商户管理，商城维护审核，评论管理，收集数据，订单分析。

3.实体类:用户信息类，商品信息，订单信息，配送员信息类，购物车信息类，配送订单信息类，商户信息类，商品销售记录信息类，评论信息类。管理员和客户都属于系统的非商业用户，所以将它们统称为用户信息类。电子商务配送系统在Internet中使用，所以为了安全起见，在分析实体类中，将经常使用的类所涉及操作和基本信息分别设计一个类。例如，客户信息类，客户涉及到的信息设计到客户信息类中，而客户所涉及到的方法操作则归为客户信息操作类。这样体现了而向对象的封装性和安全性，能更好的满足系统运作要求。

（2）生成类图

通过上述类的分析，要生成类图还需要弄清楚类与类之间的关系，并且要确定类的属性和方法。上文分析了与“下订单”用例相关的类，下面接着讨论类的属性和方法，并生成相关类图。

边界类:商品详细信息界面(GoodsDetailslnterface)填写订单页面(OrdersInterface)，主要是打开新的界面。

控制类:下订单C Order)。协作类之间的工作，起到“中介”的作用。

实体类:用户信息类(ClientInformations)，商品信息类(GoodsInformations)订单信息类(OrderInformations)，用户信息操作类(ClientOP)，商品信息操作类（GoodsOP），订单信息操作类(OrderOP)。ClientInfornlations类的重要属性有:用户ID号，用户名，注册日期，登录密码，电子邮件;ClientOP类的主要操作有:系统注册，系统登录，查看商品，订购商品，支付;GoodsInformations类主要属性有:商品ID号，商品名称，商品描述，商品价格，商品库存，商品类别;GoodsOP类的主要操作有:获取商品ID号、商品名称和价格;OrderInformations类主要属性有:订单ID号，商品ID号，商户ID号，用户ID号，客户姓名，订购日期，订购者地址，商品数量，商品价格;OrderOP类涉及的操作有:搜索订单，查看订单，处理订单，添加订单，删除订单。

根据以上分析，下订单的类图如图4.12。实线箭头表示的是关联关系，虚线箭头表示的是依赖关系。

由于电子商务配送系统涉及到类图比较庞大，而分析类图的过程可以通过上述方法一一得出用例的类图，本文只对系统中的实体类图进行建模。运用上文方法分析实体类所涉及到的信息类，实体类图4.13a

4.4动态结构建模

用例图和类图描述了系统的静态结构，接下来建立系统的动态行为模型，动态行为模型主要是建立系统的顺序图和活动图，川页序图主要来表示对一象之间的关系和对象之间传送消息的时间顺序。活动图则是描述活动的顺序的一种流程图，是从一个活动到另一个活动的控制流。

（1）顺序图

该商城系统涉及到的顺序图有很多，比如用户登录顺序图，下订单顺序图，删除订单顺序图，增加订单顺序图，订单处理顺序图。本文将通过“系统登录”顺序图和“下订单”顺序图建模为例来说明系统动态结构建模。

“商城登录”用例涉及到参与者是用户，包括管理员和其他用户，这里以客户登录系统为例，涉及到的对象有“登录界面”，“服务器”和“数据中心”，根据ROSE中的顺序图的建模方法，本文得到“商城登录”用例的顺序图如图4.14。

根据上文分析的“下订单”用例类图，“下订单”用例的顺序图参与者是客户，所涉及到的对象有“登录界面(login)”“商品信息查看界面(GoodsDetailsInterface)"“下订单界面(OrdersInterface“

“订单信息操作（OrderOP）”，用ROSE建模得出的“下订单”顺序图如图4.15所示。

(2)活动图

活动图表示一个事件正在运行的状态，事件是系统中某个对象的一个操作，主要表现一个活动到另一个活动控制流，是系统内部的驱动流程。一个系统涉及到的活动图很多，本文提到的系统活动图有:客户下订单的活动图，商城用户登录活动图，派遣配送员的活动图等，本文将以“下订单”活动图为例。根据活动图的组成元素，“下订单”包括很多活动状态，比如:查看商品，提交订单，订单处理等一系列状态，“下订单”就是从一个活动状态转换为另一个活动状态，直至完成该动作，活动图中涉及两个对象，客户和商户，根据以上描述，在ROSE中建模的“下订单”活动图如图4.16所示。

4.5数据库建模

在以上小节本文成功建立了江西师范大学网上商城的业务流程图、需求模型、静态模型和动态模型，接下来就要介绍如何通过已建立L1ML静态结构模型中的类图转换为数据库模型。在类图转换为数据库模型，控制类和边界类不需要转换为系统数据库模型，这些类是为了实现用例的流程而产生的类，所以只有那些持久存储信息的实体类需要转换为数据库模型。转换过程由于篇幅问题不再一一叙述，如图4.17系统实体类图转换的数据库模型图。

系统的数据库模型图建立之后，将模型图映射为数据表，此处数据库模型中的属性映射为数据表的列，系统的数据结构表如下表所示。4.6物理建模

完成系统的逻辑设计后，下一步要定义设计的物理实现，为了将逻辑设计图转化成实际的事物，面向对一象系统的物理建模有两种图:组件图和配置图。组件图是系统实现视图的图形表示，描述了系统的各种组件和组件之间的依赖关系。配置图是系统执行过程中资源元素的配置情况以及软件到这些资源元素的映射，描述了系统中硬件和软件的物理结构。(1)组件图

组件是表示将类、接口等打包而形成的物理模块。组件图是用来描述代码的物理模块之间的关系，显示了代码的结构。组件图能够帮助客户和系统开发人员理解最终的系统结构。根据上文对江西师范大学“网上商城”的逻辑视图的分析，在ROSE中得到系统的组件图，图4.18所示，组件图中只有用虚线表示的依赖关系。

2.配置图

配置图用来表示系统的运行结构或者系统软件和硬件组织之间的关系，由节点和节点之间的联系构成，配置建模就是将软件系统在互联网上的运作方式模式化，南昌大学“网上商城”是一个基于其数据库和校园网的应用系统，根据第三章中电子商务系统多层B/S体系结构，“网上商城”的系统配置图如图4.19。

4.7小结

电子商务系统是一个结构复杂、规模庞大的系统，根据本文提出的基于UML的系统建模过程，本章以江西师范大学“网上商城”为实例，对其进行了系统的需求分析，建立了系统的需求模型、系统的静态结构模型、系统的动态结构模型、系统的数据库模型、系统的物理模型。确立了系统的功能模块，分别建立了业务流程图、用例图、类图、顺序图和活动图、数据库模型和数据表、组件图和配置图。

第5章基于数据挖掘的商品订单分析

电子商务的迅速发展使其规模越来越复杂，客户获得有效商品信息的难度也在增加，因此如何增加商品信息的针对性，提高网站的可用性成为了现今电子商务研究的热点。国内对该热点的研究很少，但是也有了一些研究成果，比如王兆红((2005)利用关联规则提出了商品的最佳打包组合：金伟健，金文进(2010)从理论上提出了基于关联规则的商品推荐模型;章杰鑫，张烈平(2009)提出了时序关联规则挖掘算法，并通过模拟超市数据预测了顾客在时间单位内的商品关联规则，使企业更好的了解客户需求。本文应用数据挖掘的关联规则对商城的“订单分析”功能进行了分析和设计。首先对商城历史订单进行数据预处理，然后应用关联规则挖掘客户购买商品的关联关系，这样商户可以掌握客户的购物兴趣，设置相应的捆绑或交叉销售，使商户在降低成本的同时为广大师生提供更好的生活服务，增加现有客户的满意度。5.1数据挖掘技术 5.1.1数据挖掘的概念

1997年SAS研究所将数据挖掘定义为将大量相关数据进行探索，最后建立相关模型的方法;1999年Bhavani将数据挖掘定义为一个过程，即利用数学，统计和模式识别技术，在大量的数据中发现新的趋势、新关系和模式的过程;最后一种是最具有影响力且至今被广泛采用的Usama M.Fayyad等给出的，即数据挖掘(Data Mining)是从大量的、有噪声、模糊的、不完全的、随机的数据中挖掘出隐含的、未知的、用户可能感兴趣的但又有潜在价值的知识和信息的过程。5.1.2数据挖掘的功能一可以挖掘什么类型的模式

数据挖掘的目标从大量的数据中发现隐含的、有意义的知识并对现有数据记录进行分析，预测未来趋势和行为，做出基于知识的决策，主要有以下功能。

1.描述功能:将数据库中的对象通过数据分类、聚类分析、数据汇总与归纳、概括等过程最终获得数据简明、准确的描述。

第三篇：山东大学软件学院面向对象方法考试口述精简版

教务系统的用例图（UML+代码）

电梯运行状态图

门的（有把手/无把手）装潢模式（模式+类图+代码）时钟（钟表/数字）同上

网页下载（http/ftp）的两种下载方式用什么模式实现 同上

interator模式（迭代器模式）一个容器 作用是装载以及迭代的方式取出所有数据

第四篇：面向对象程序设计教学大纲-计算机科学与软件学院

面向对象技术

Technology of Object-Oriented Programming 课程编号：30420032 学分数：2 开课单位：计算机技术与自动化学院

课内总时数：40 任课教师姓名及职称：陈勇副教授、柯永振讲师、刘坤良讲师 开课学期：第2学期 教学方式：讲授

一、教学要求及目的：

理解面向对象的基本思想、基本概念；掌握面向对象程序设计语言的基本结构、各种语法成分的作用、语法结构及运用方式；掌握面向对象程序设计的方法和技巧；能比较熟练地用C#语言进行一般面向对象的程序分析、设计，提高编写和调试应用程序的能力。

二、课程的主要内容

1．面向对象方法的历史与现状

面向对象技术的发展历史，主要的面向对象语言介绍。

2．.Net Framework概述.Net Framework基本框架，.Net Framework的优点，以及开发平台。3．C#概述

C#的起源和特点，C#源程序的基本构成，C#中非面向对象方面的—些程序特性。4．C#中类和对象

类与对象的基本概念，构造函数，方法与属性，参数传递，静态成员。5．派生、继承、多态性

数据的抽象与封装，派生类的概念，派生类的构造函数，C#中多重继承的处理方法，虚方法的实现，抽象类，重载的实现，接口的实现，代理的实现。6． 基于Windows 与Web的应用程序开发

开发Windows，Web应用程序的基本框架。7．Web Service实现

使用XML的Web Service实现。8.面向对象技术实践

根据所掌握的面向对象技术，分析一个具体案例，利用C#实现其功能。

三、课程教材及主要参考书

1．C#面向对象程序设计，黄聪明，科学出版社，2004年 2.C#程序设计，田原，清华大学出版社，2005 3．C#高级编程，李敏波，清华大学出版社，2005（第3版）.4．C#程序设计教程，余安萍，电子工业出版社，2002 5．面向对象的分析与设计，（美）Grady Booch著，机械工业出版社，2005年

6．C#范例解析，朱沭红，电子工业出版社，2002 7．Visual C#程序设计基础教程，邵鹏鸣，清华大学出版社，2005.四、预修课程

C语言程序设计、数据结构、程序设计方法学

五、适用专业、范围

计算机应用技术专业、计算机软件与理论专业

第五篇：河南城建学院信息系统分析与设计考试总结

一．填空。（20）

1.项目人力资源管理包括项目团队组建和管理的各个过程，其作用是保证最有效的使用项目人力资源完成项目活动。

2.项目沟通管理是指对于项目过程中各种不同方式和不同内容的沟通活动的管理。

3.软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

4.模型是运用某种图标工具对系统特征（包括静态特征和动态特征）的一种表示。

5.业务流程是指一个组织在完成其使命、实现其目标的过程中必需的、逻辑上相关的一组活动。

6.可行性研究的目的是说明该IT项目的实现在技术上、经济上和运行条件上的可行性。

7.需求分析是系统开发的一个重要步骤，是整个系统开发的基础。

8.逻辑模型在系统分析中起着重要的作用，是新系统设计的基础和依据。

9.概念设计是把用户的信息要求统一到一个整体逻辑结构中。

10.系统设计的主要任务是依据系统需求规格说明书，全面地确定系统应具有的功能和性能要求。

11.面向对象设计是在面向对象分析的基础上，增加实现的细节来完成的。

12.结构化设计的优点之一是通过分解技术，使得软件结构易于理解。

二．名词解释。（20）

1.项目管理是以项目为对象的系统管理方法，通过一个临时性专门机构的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现项目全过程的动态管理和项目目标的综合协调和优化。项目管理需要通过一个专门的组织实施，通过规划资源，从时间、成本、质量、客户关系等方面满足项目目标。

2.企业信息化战略(BIS)也称为信息技术战略，是企业战略的有机组成部分，是关于信息功能的目标及其实现的总体规划。从功能划分的角度来讲，企业信息化战略是一类独立的战略；从信息功能实现的角度来看，企业信息化战略又必须与企业战略相融合。企业信息化战略描述了企业未来的信息化蓝图，并描绘了如何获取与整合这些蓝图的能力。

3.数据库设计是指在特定的DBMS环境下开发数据库应用系统，并非设计DBMS本身。数据库设计所涉及的内容包括“结构特性的设计”和“行为特性的设计”两个方面。结构特性设计是指数据库总体概念的设计，它是一个反应不同用户需求的、实现数据共享的系统。结构特性是静态的。行为特性设计是指数据库用户的业务活动。一般而言，用户的业务活动通过应用程序访问和操作数据库，与结构特性有关。

4.系统分析是指运用一定的方法，对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，并产生一个符合用户需求，能够直接反映问题域和系统责任的模型及其详细说明。系统分析的主要任务是需求开发和管理。

5.活动图是状态图的一个特例，其中所有的状态都是动作状态，且转换都是由源状态中的动作完成触发的。活动图与特定的类活用里相关，特描述某个方法的内部表现，使用活动图可以表示由内部生成的动作驱动的事件流。

三．问答。（30）

1.原型法的优点和缺点：

优点：1）减少了开发时间，大大提高了系统开发效率。这主要是由于最终用户更加积极地参与系统的开发，尤其是信息系统需求的确定。

2）由于用户在看到原型以前往往很难理解和详细陈述其需求，而且用户所看到的是实际的工作模型而不是单调的语言或图来描述的需求，因此，通过原型法使信息需求的定义工作更为直观、简单。

3）通过一系列对原型的修改和完善，大大增加了用户对设计的满意程度，进而提高了信息

系统的质量。

4）减少了系统开发费用。

缺点：1）分析和设计上的深度不够，从而可能造成在未能很好地理解用户需求的情况下就着手程序代码的编写。

2）快速原型法中的第一个工作原型可能并不是一个最优方案。

3）通过原型法所开发的系统不具备灵活性，难以适应用户需求的变化。

4）工作原型不容易修改。

2.IT规划的作用是

1）全局性。从企业战略发展的高度出发，纵览全局，目标明确，规划整个企业信息系统的全景远景图，确保信息架构能更好地应付业务流程和组织的变化。

2）预警性。通过考察、借鉴和学习，总结成功经验，吸取失败教训，能有效预防各种信息化建设中易出现的问题，知道系统选型和项目实施，从而有效地规避、降低企业信息化的各种风险。

3）有序性。根据企业各方面的资源约束，以及企业的预算，按照轻重缓急给出信息化建设的阶段性目标。

4）经济性。始终考虑成本投入与产出的关系问题，降低成本，科学地确定信息化建设的投资，用较少的资金做更多的事情。依据信息化建设的目标和全局架构，避免无效投资、重复投资等。

5）集成性。整合信息资源，解决“信息孤岛”问题，确保各应用系统的整体集成。

6）挖掘潜在的应用系统。

3.逻辑模型是与实施无关的模型。他描述了系统的本质，即系统必须做什么，而与系统是如何实施的无关。也就是说，逻辑模型是用来描述数据的内容及处理功能的，而不关心这些功能是如何实现的。其优点是：

1）逻辑模型不考虑系统具体的实施方式，因而可以最大程度地发挥系统分析师的创造性。

2）逻辑模型减少了遗漏用户功能需求的风险。系统一旦实施，修正这种错去的费用极大。通过将系统做什么与如何去做分离开来，有助于更好地保持需求的完整性、准确性、一致性。

3）逻辑模型可以使系统开发人员以非技术语言或尽可能少的技术语言与最终用户进行交流。

4.交互图包括协作图和顺序图。协作图和顺序图都表示出了对象间的交互作用，但是他们侧重点不同。顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。顺序图清楚地表示了交互作用中的时间顺序，但没有明确表示对象间的关系。协作图清楚地表示了对象间的关系，但时间顺序必须从顺序图中获得。顺序图常常用于表示方案，而协作图用于过程的详细设计。

5.三层结构由以下几部分组成：客户机、应用服务器和数据库服务器。实际上，B/S结构是将应用逻辑从客户机和数据库服务器中分离出来。三层结构的优点是：1）使客户端人机界面部分的程序开发工作得以简化。它不必关心业务逻辑是如何访问数据库的，只需把精力集中在人机界面上即可。

2）中间业务逻辑层包含了大量的供客户端程序调用的业务逻辑规则，以帮助其完成业务操作。它的优点就在于它所具有的可伸缩性，可使其随具体业务的变化而改变，但在客户层和数据服务层所做的改动较小，适合于快速开发。

3）数据服务层主要提供对数据库进行各种操作的方法。它主要由中间业务层来调用比昂完成业务逻辑，当数据库的结构确定后，对于它的改动也就比较小了。

4）系统的安全性得以提高。它可以对每个业务功能组件进行授权，限制了非法访问。

5）便于进行事务管理。