设计批评的对象范文

第一篇：设计批评的对象范文

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

第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.描述功能:将数据库中的对象通过数据分类、聚类分析、数据汇总与归纳、概括等过程最终获得数据简明、准确的描述。

第二篇：PHP中面向对象设计的经验总结

你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起 。 ----- Arthur J.Riel

1. 所有数据都应该隐藏在所在的类的内部。

2. 类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 3. 尽量减少类的协议中的消息。

4. 实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。

5. 不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 6. 不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。

7. 类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。

8. 类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响。 9. 把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

10. 把不相关的信息放在另一个类中(也即：互不沟通的行为)。朝着稳定的方向进行依赖。 11. 确保你为之建模的抽象概念是类，而不只是对象扮演的角色。

12. 在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。 13. 在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。

14. 对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。

15. 对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

16.在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。

17. 尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则)。

18. 从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。 19. 去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

20. 不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是

否应当迁移到已经存在或者尚未发现的某个类中。

21. 我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。

22. 尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。 23. 尽量减少类和协作者之间传递的消息的数量。

24. 尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。 25. 尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。 26. 如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。

27. 类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

28. 类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

29. 让系统功能在窄而深的继承体系中垂直分布。

30. 在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在

构造函数中实现，但不是必须如此。 31. 在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。

32. 约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。 33. 约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。 34. 类必须知道它包含什么，但是不能知道谁包含它。

35. 共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。 36. 继承只应被用来为特化层次结构建模。

37. 派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。

38. 基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

39. 在理论上，继承层次体系应当深一点，越深越好。

40. 在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

41. 所有的抽象类都应当是基类。 42. 所有的基类都应当是抽象类。

43. 把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。

44. 如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。

45. 如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。

46. 如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。

47. 对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。

48. 对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。

49. 不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。

50. 不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

51. 如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。

52. 在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。 53. 不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。 54. 在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。

55. 如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。 56. 只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型?(2)基类是不是派生类的一部分?

57. 如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。

58. 在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。 59. 不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。 60. 面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 61. 不要绕开公共接口去修改对象的状态。

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

第四篇：《面向对象程序设计》课程设计教学大纲

《面向对象程序设计》课程设计教学大纲

中文名称：《面向对象程序设计》课程设计

英文名称：Course Project of Object-Oriented Programming 课程编码：09003410

设计周数：1周 (18学时) 学

分：1学分

开课学期：第2学期

开课单位：软件学院

一、课程设计的教学目的和任务

通过本课程设计教学所要达到的目的是培养学生理论联系实际的思想，让学生综合运用面向对象程序设计课程中的理论知识，特别是面向对象程序设计与面向对象编程的方法，进行实际的程序设计与编程项目实践。

本课程设计的任务是设计和编写完成一个简单的游戏程序。

二、课程设计的主要内容

学生采用面向对象程序设计课程教材《C++ Program Design》中提供的图形库ezWindow，参考教材第15章中的程序片段，设计编写完成一个游戏程序 ― 终结者(Terminator)。鼓励学生自主创新，脱离教材的内容，编写其它游戏程序。

三、课程设计的基本教学要求

该课程设计需要在安装了Microsoft Windows 2000操作系统、Microsoft Visual C++ 6.0和ezWindow 库的计算机实验室中进行。为了方便学生撰写设计报告，还要求计算机中安装Microsoft Office。软件学院教学实验中心满足这些条件，因此该课程设计可在软件学院教学实验中心进行。

四、参考资料

面向对象程序设计课程教材《C++ Program Design》。

五、成绩评定标准

课程设计成绩分为优、良、中、及格和不及格5个等级。分别从以下几个方面考擦：

1、工作学习态度：

10%;

2、程序设计与代码质量：40%;

3、设计报告质量：

30%;

4、创新：

20%。

大纲执笔人：雷跃明

大纲审定人：陈林

时间：2008年2 月4 日

第五篇：面向对象分析与设计课程总结

面向对象分析与设计

课程总结

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的喜爱，老师上课很生动，不光在学习上教导我，在生活和做人理念上也对我有所帮助。这篇学习总结写得比较乱，但我都有用心，在以后的学习过程中我会继续努力，再次多谢庄老师的教诲。