526互联

逻辑视图模型建模会员关系管理

发布时间 2023-12-10 13:56:30作者: 艾鑫4646

一 实验目的

l 理解面向对象系统分析和对象类建模的概念；

l 了解和掌握面向对象系统分析的方法和步骤；

l 了解和掌握寻找待开发系统中类的方法和技巧；

l 了解和掌握分析类之间继承关系的方法；

l 了解和掌握分析类之间的关联关系的方法；

l 掌握使用Rational Rose建立类图模型的方法；

二 实验环境及实验准备

l 所需硬件环境为微机；

l 所需软件环境为Rational Rose、Miscrosoft Word等；

l 熟悉Rational Rose下类模型建模的方法和步骤；

l 完成系统用例模型建模；

三 实验内容 

（1）分析系统用例，确定对象类

 会员管理系统”包括“ 会员信息管理系统”“ 会员关系管理系统”、“ 会员积分管理系统”等。 下面先对会员信息管理系统进行详细描述。

[ 系统业务需求描述]"会员信息管理系统"作为企业综合信息管理系统的一部分，承载着管理会员信息和账户信息的重要任务。这个系统将提供给会员商铺店员、会员本人以及总管理人员对会员信息和账户信息进行查询、添加、删除和修改等操作的功能。其业务工作内容如下：

1会员信息查询：无论是会员本人还是商铺店员，都可以通过系统快速查找到会员的相关信息，包括姓名、性别、生日、联系方式、地址等基本信息，以及账户信息，如账户余额、积分等。

2会员信息添加：当新的会员加入时，商铺店员可以通过系统添加新会员的信息，包括基本信息和账户信息。同时，系统还应支持总管理人员对会员信息的审核和确认，确保信息的准确性和完整性。

3会员信息删除：因某些原因需要删除会员信息时，商铺店员和总管理人员都可以对会员的信息进行删除。在删除信息时，应遵循一定的操作流程和审核机制，避免误操作或者恶意操作。

4.会员信息修改：当会员的信息发生变更，商铺店员和总管理人员都可以对会员的信息进行修改。在修改信息时，应遵循一定的操作流程和审核机制，避免误操作或者恶意操作。

[抽象系统实体类]我们对会员信息管理系统的业务需求描述文本进行词法分析，得出实体类名词。如表(1)所示。

 

                       表 1 会员信息管理子系统待选类

会员

  商铺店员

总管理员

 账户信息

    账户余额

  会员信息

  操作流程

 审核机制

经过筛选，我将“总管理员”和“商铺店员”归为同一类别，将“账户信息”和“账户余额”合并为“账户信息” ，将“操作流程”和“审核机制”合并为“操作流程”，会员信息和会员合并为会员。因此，符合要求的对象类包括：“会员”、“商铺店员”、”总管理员”“账户信息”、“会员信息”和“操作流程”。以下是根据这个例子筛选后的结果如表(2)所示：

表 2 会员信息管理子系统中定义的类

序号

类名

中文含义

功能描述

1

Member

会员类

会员是系统的核心对象，每个会员都有唯一的ID和基本的会员信息，如姓名、性别、生日、联系方式和地址等。此外，每个会员都与一个账户关联，该账户存储了账户余额和积分等信息。

2

Shop Clerk

商铺店员类

商铺店员是会员信息管理系统的用户之一，他们可以查询和操作会员信息和账户信息。

3

Administrator

总管理员类

总管理员是具有最高权限的用户，可以审核和确认商铺店员提交的会员信息和账户信息的操作，也可以直接对会员信息和账户信息进行添加、删除和修改等操作。

4

Account

Information

账户信息类

账户信息是会员信息管理系统中的重要数据之一，每个账户都包含了余额和积分等信息。

5.

Operation Process

操作流程类

操作流程描述了在会员信息管理系统中进行添加、删除和修改操作的详细步骤和审核机制。

 

[系统边界类与系统控制类]系统边界类主要是指系统与用户交互界面有关的类。 在会员信息管理子系统中，与用户交互的窗口类通常包括以下几种：

登录窗口类（LoginWindow）：用于用户登录系统时输入用户名和密码的界面。

主窗口类（MainWindow）：是系统的主界面，通常包含菜单、工具栏、状态栏等。

会员信息管理窗口类（MemberInfoWindow）：用于管理会员信息的界面，包括添加、删除、修改会员信息的界面。

账户信息管理窗口类（AccountInfoWindow）：用于管理账户信息的界面，包括查看、修改账户信息的界面。

会员信息管理子系统（Member Information Management System）主要涉及与会员信息的交互和管理。这个子系统的用户界面由一系列窗口和对话框组成，用于会员信息的查询、添加、删除和修改等操作。在这个子系统中，主管理窗口类可以作为一个控制类，负责控制系统中事件发生的顺序和调用的类或类的操作。这个控制类可以由子系统主管理窗口类中的各个功能选项菜单、快捷键或按钮来触发和控制。会员信息管理子系统主管理窗口类作为控制类，可以与其他类进行消息传递和交互。其他类并不向这个控制类发送消息，而是由控制类向其他类发出消息，例如：当用户在主管理窗口中选择添加会员信息时，主管理窗口类可以向会员信息添加类发送消息，触发会员信息添加类的操作。

（2）采用 CRC 卡片标识对象类及其属性、操作

[ 类的属性与操作]关于“会员”、“商铺店员”、“总管理员”、“账户信息”、“会员信息”和“操作流程”的一般客户类的简单信息描述和状态描述：

1.会员（Member）类：

简单信息描述：会员是与销售合同签订者相关的客户，具有唯一的ID和基本会员信息，如姓名、性别、电话、电子邮箱等。

状态描述：会员的状态可以包括会员名称、法人代表姓名、地址、主要业务描述、采购数量、采购产品名称以及采购人的详细信息（姓名、性别、电话、电子邮箱）。

操作定义：增加（Add）、修改（Update）、删除（Delete）、查询（Query）、打印（Print）。

2.商铺店员（Shop Clerk）类：

简单信息描述：商铺店员是具有操作权限的用户，能够执行会员信息的查询和简单的操作，如增加、修改和删除等。

状态描述：商铺店员的状态可以包括用户名和密码等认证信息。

操作定义：增加（Add）、修改（Update）、删除（Delete）、查询（Query）。

3.总管理员（Administrator）类：

简单信息描述：总管理员是具有最高权限的用户，能够执行所有操作，包括审核和确认商铺店员提交的操作请求。

状态描述：总管理员的状态可以包括用户名和密码等认证信息。

操作定义：增加（Add）、修改（Update）、删除（Delete）、查询（Query）、审核（Review）。

4.账户信息（Account Information）类：

简单信息描述：账户信息是与会员关联的账户信息，包括账户余额和积分等信息。

状态描述：账户信息的状态可以包括账户余额和积分等。

操作定义：修改（Update）。

5.操作流程（Operation Process）类：

简单信息描述：操作流程描述了在会员信息管理系统中进行添加、删除和修改操作的详细步骤和审核机制。

状态描述：操作流程的状态可以包括各个功能选项菜单、快捷键或按钮的定义以及触发条件等。

操作定义：触发（Trigger）。

[ 类的 UML 图符表示]此处为会员信息管理管理系统案例中的会员类进行 UML 图符表示，如图 3所示：

              

               

                             图 3 会员类的图符表示

 

 

此处为会员信息管理管理系统案例中的商铺店员类进行 UML 图符表示，如图 4所示：

 

              

                             图 4 商铺店员类的图符表示

此处为会员信息管理管理系统案例中的总管理员类进行 UML 图符表示，如图 5所示：

                  

                       图 5 总管理员类的图符表示

此处为会员信息管理管理系统案例中的账户信息类进行 UML 图符表示，如图 6所示：

                

                        图 6 账户信息类的图符表示

 

此处为会员信息管理管理系统案例中的操作流程类进行 UML 图符表示，如图 7所示：

                 

                         图 7操作流程类的图符表示

 

（3）对象类间继承关系建模，绘制类图

我们可以发现一些公共属性和相似操作，例如增加会员信息、修改会员信息、删除会员信息和查询会员信息等。这些公共属性和相似操作可以抽象出来定义一个基类，例如“信息管理类”。原来的有公共内容的类如“会员”、“商铺店员”和“总管理员”可以由其派生，它们与基类之间存在继承关系。这样可以通过继承关系建模来减少代码重复和提高代码复用性。如图8所示

 

 

                      图 8 信息管理类的继承关系图

（4）对象类间语义关联关系建模，完善类图

1.会员类和账户信息类：会员类包含账户信息类的实例，因为每个会员都有一个账户信息。会员通过其账户信息来进行存款、取款等操作，如图（9）

                图 9 会员类和账户信息类之间的关联关系

 

                

  1. 商铺店员类和会员类：商铺店员类可以操作会员类的实例，例如查询、增加、修改或删除会员信息。因此，商铺店员类和会员类之间存在一种操作和被操作的关系。如图（10）所示

       

                 图10  商铺店员类和会员类之间的依赖关系

 

            

  1. 总管理员类和商铺店员类：总管理员类可以审核商铺店员提交的操作请求，例如审核会员的增加、修改或删除请求。因此，总管理员类和商铺店员类之间存在一种审核和被审核的关系。如图（11）所示.

   

             图11  商铺店员类和总管理员类之间的依赖关系

 

 

4.操作流程类和会员信息管理子系统其他对象类：操作流程类负责管理会员信息管理子系统中的所有操作流程，包括初始化操作环境、验证用户身份和权限、执行操作、审核操作、记录操作记录和清理操作环境等。因此，操作流程类和其他对象类之间存在一种流程管理和被管理的关系。

         

（1）分析系统用例，确定对象类

 企业综合信息管理系统”包括“ 会员信息管理系统”“ 会员关系管理系统”、“ 会员积分管理系统”等。 下面先对“ 会员关系管理系统” 进行详细描述。

[ 系统业务需求描述]会员关系管理系统中，对会员消费记录信息进行查询并计算会员消费频率的需求通常是非常重要的。这可以帮助商家更好地了解客户的购买行为和消费习惯，以便提供更个性化的服务和产品。以下是对这个业务需求的具体描述：

消费记录：首先，系统需要存储所有会员的消费记录。这些记录通常包括会员ID、交易时间、交易类型（如商品购买、服务消费等）、交易金额等信息。

数据查询：根据不同的需求，系统需要提供不同的查询方式。最基本的查询可能包括按照会员ID、交易时间、交易类型或交易金额进行查询。更复杂的查询可能包括按照特定的日期范围、商品类别、服务类型等进行查询。

消费频率计算：在获取到会员的消费记录后，系统需要计算每个会员的消费频率。这通常可以通过统计每个会员在特定时间范围内（例如一个月、一季度或一年）的消费次数或消费总额来实现。商家可以根据这些数据来分析会员的购买习惯和趋势，以便更好地制定销售策略。

数据可视化：为了更好地理解和展示数据，系统可能需要提供一些数据可视化工具，如柱状图、饼图或曲线图等，来展示会员消费频率的分布、变化趋势等。

报表生成：此外，系统可能需要提供一些预设或可定制的报表，以便商家快速了解会员的消费情况。这些报表可以包括每天、每周或每月的消费总额、每个会员的消费总额等。

[抽象系统实体类]我们对会员关系管理系统的业务需求描述文本进行词法分析，得出实体类名词。如表(12)所示。

 

                       表 12 会员信息管理子系统待选类

消费记录

消费频率

可视化数据

 报表

数据查询

 

 

 

经过筛选，报表和可视化数据可以合并成数据报告与可视化工具，简称“数据可视化报告”。 符合销售管理子系统要求的对象类包括：“ 消费记录”、“ 消费频率”、”数据可视化报告”。以下是根据这个例子筛选后的结果如表(13)所示：

表 13 会员信息管理子系统中定义的类

序号

类名

中文含义

功能描述

1

ConsumptionRecord

消费记录类

存储会员的消费信息，包括会员ID、交易时间、交易类型和交易金额等详细信息。

提供数据的增、删、改、查功能，确保数据的准确性和完整性。

 

2

ConsumptionFrequency

消费频率类

 根据消费记录计算会员的消费频率，如特定时间范围内的消费次数或消费总额。

提供统计和查询功能，允许商家按照不同的时间范围（如月、季度、年等）进行查询。

支持自定义时间范围，以便商家能够灵活查询和分析会员的消费行为。

 

3

 DataVisualizationReport

 数据可视化报告类

 根据消费记录和消费频率数据生成可视化的报告，如柱状图、饼图、曲线图等。

提供交互式的数据查询和筛选功能，允许商家根据特定的条件进行数据可视化。

支持自定义图表的类型和样式，以满足不同商家的数据展示需求。

提供报表导出功能，支持将数据可视化报告导出为常见的文件格式（如PDF、Excel等）。

 

 

[系统边界类与系统控制类] 

 在会员关系管理子系统中，与系统边界类和系统控制类相关的“消费记录”、“消费频率”、“数据可视化报告”和“数据查询”可以描述如下：

系统边界类：消费记录界面（ConsumptionRecordInterface）

该类是与用户交互的边界类，用于展示和管理会员的消费记录。它具备以下功能：

显示会员的消费记录列表，包括会员ID、交易时间、交易类型和交易金额等信息。

提供添加、编辑和删除消费记录的功能，确保数据的准确性和完整性。

与其他系统控制类（如消费频率计算类、数据查询类等）进行交互，实现数据的传递和更新。

系统控制类：消费记录管理控制器（ConsumptionRecordManagementController）

该类负责处理消费记录相关的业务逻辑和数据操作。它具备以下功能：

接收并解析来自消费记录界面的用户请求，如添加、编辑或删除消费记录等。

验证用户请求的合法性和权限，确保只有经过授权的用户才能进行操作。

调用消费记录存储类的相关方法，完成数据的增、删、改、查等操作，并返回操作结果给消费记录界面。

系统边界类：数据可视化报告界面（DataVisualizationReportInterface）

该类是与用户交互的边界类，用于展示数据可视化报告。它具备以下功能：

显示数据可视化报告，包括各种图表（如柱状图、饼图、曲线图等）和统计数据（如消费频率、消费总额等）。

提供交互式查询和筛选功能，允许用户根据特定条件进行数据可视化和查询。

支持自定义图表的类型和样式，以满足不同用户的可视化需求。

系统控制类：数据查询与可视化控制器（DataQueryAndVisualizationController）

该类负责处理数据查询和数据可视化的业务逻辑和数据操作。它具备以下功能：

接收并解析来自数据可视化报告界面的用户请求，如查询条件、筛选条件或自定义图表设置等。

调用数据查询类的相关方法，根据用户请求进行数据查询和筛选，获取相应的消费记录和消费频率数据。

调用数据可视化工具的相关方法，根据查询结果生成相应的图表和统计数据，并返回给数据可视化报告界面进行展示。

通过这些系统边界类和系统控制类的设计与实现，会员关系管理子系统可以有效地管理和展示会员的消费记录、消费频率和数据可视化报告，提供丰富的查询和可视化功能，帮助商家更好地了解和分析会员的消费行为，为制定销售策略和决策提供有力的支持。

（3）采用 CRC 卡片标识对象类及其属性、操作

[ 类的属性与操作]关于“消费记录”、“消费频率”、“数据可视化报告”和“数据查询” 的简单信息描述和状态描述：

1. 消费记录类（ConsumptionRecord）

状态描述：

memberID：特定会员的ID，用于标识消费记录的所有者。

transactionTime：交易时间，表示消费记录的创建时间或发生时间。

transactionType：交易类型，用于描述消费记录的类型或交易的类型。

transactionAmount：交易金额，表示消费记录的交易金额或消费金额。

recordID：记录ID，用于标识特定的消费记录。

 

 操作定义：增加()、修改()、删除()、查询()、取消（）

 2. 消费频率（ConsumptionFrequency）

状态描述：

 memberID：会员ID，用于标识特定会员的消费频率。

startDate：起始日期，用于指定特定时间段的起始时间。

endDate：结束日期，用于指定特定时间段的结束时间。

timePeriod：时间周期，用于指定特定时间段的时长。

 

操作定义：

calculateDailyFrequency(memberID)：计算会员的每日消费频率。

calculateWeeklyFrequency(memberID)：计算会员的每周消费频率。

calculateMonthlyFrequency(memberID)：计算会员的每月消费频率。

calculateCustomFrequency(memberID, startDate, endDate)：为特定时间段计算会员的消费频率。

getFrequencyStatus(memberID, timePeriod)：查询会员在特定时间段的消费频率状态。

3. 数据可视化报告（DataVisualizationReport）

状态描述：

memberID：会员ID，用于标识特定会员的数据可视化报告。

timePeriod：时间周期，用于指定特定时间段的数据可视化报告。

reportID：报告ID，用于标识特定的数据可视化报告。

 

 操作定义：增加()、修改()、删除()、查询()、打印()

  [ 类的 UML 图符表示]此处为会员关系管理管理系统案例中的消费记录类进行 UML 图符表示，如图14所示：

              

         

                             图 14  消费记录类的图符表示

 

 

此处为会员关系管理管理系统案例中的消费频率类进行 UML 图符表示，如图 15所示：

 

        

                             图 15 商铺店员类的图符表示

此处为会员关系管理管理系统案例中的数据可视化报告类进行 UML 图符表示，如图 16所示：

            

                       图 16 数据可视化报告类的图符表示

                   

（3）对象类间继承关系建模，绘制类图

我们可以发现一些公共属性和相似操作，可以创建一个基类（“Record”）来表示这些对象类的共同属性和方法。然后，其他类可以从这个基类中继承。如图17所示

 

 

                      图 17 信息管理类的继承关系图

（4）对象类间语义关联关系建模，完善类图

1.消费记录类和消费频率类：

 消费记录和消费频率都与会员的消费行为相关。消费记录是具体的消费交易记录，而消费频率是描述会员在特定时间段内消费的频率。通过会员ID，可以建立消费记录和消费频率之间的关联。例如，一个会员的消费记录中包含多个交易，这些交易的时间、类型和金额等信息可以用于计算该会员的消费频率。如图（18）。

 

 

                图 18  消费记录类和消费频率类之间的依赖关系

 

                

2. 消费记录类和数据可视化报告类：

消费记录是数据可视化报告的基础数据之一。通过将消费记录聚合和分析，可以生成针对特定会员或整个群体的数据可视化报告。例如，一个数据可视化报告可能包含某个会员的消费趋势、消费类型分布等统计信息，这些信息是基于该会员的消费记录进行计算的。此外，通过将消费记录与时间周期相关联，可以确定报告的时间范围和更新频率，如图（19）所示

       

                 图19   消费记录类和数据可视化报告类之间的依赖关系

3. 消费频率类和数据可视化报告类：

消费频率是数据可视化报告中的重要指标之一。通过计算消费频率，可以了解会员在特定时间段内的消费活跃度和趋势。数据可视化报告可以展示不同时间段的消费频率，例如日度、周度或月度的消费频率，以便更好地了解会员的消费习惯和需求。此外，针对不同消费频率的统计数据，可以进一步分析会员的消费行为和偏好。

如图（20）所示.

  

   

             图20    消费频率类和数据可视化报告类之间的依赖关系

 

（1）分析系统用例，确定对象类

 “会员管理系统”包括“ 会员信息管理系统”“ 会员关系管理系统”、“ 会员积分管理系统”等。 下面先对“ 会员积分管理系统”进行详细描述。

[ 系统业务需求描述] “会员积分管理系统”是“会员管理系统”的一个重要组成部分，用于管理会员的积分相关信息。下面是“会员积分管理系统”的业务需求描述：

1增加会员积分：

这部分功能允许系统管理员或特定权限的用户为会员增加积分。通常，增加积分的操作需要输入会员ID、积分数额和积分类型等信息。系统需要确保积分的增加是准确无误的，并且不会导致积分超出会员的可用限额。

2查询会员积分：

会员或系统管理员可以通过该功能查询会员的积分信息。查询条件可能包括会员ID、姓名、手机号等，以便快速找到对应的会员并查看其积分情况。系统需要提供一种方便快捷的查询方式，并返回准确的积分信息。

3.兑换积分：

会员可以通过此功能将他们的积分兑换成实物奖品、优惠券或其他形式的奖励。兑换过程可能需要输入会员ID、选择兑换的奖品、确认兑换等步骤。系统需要确保兑换过程的安全性和公平性，防止恶意兑换和滥用积分的情况发生。

4.积分规则管理：

系统管理员可以设置不同的积分规则，例如消费金额与积分的换算比例、不同等级的会员享受的积分政策等。这些规则可以基于不同的业务需求进行灵活调整，以满足不同阶段的需求变化。

 

[抽象系统实体类]我们对会员积分管理系统的业务需求描述文本进行词法分析，得出实体类名词。如表(21)所示。

 

                       表 21会员积分管理子系统待选类

 积分

   兑换

 实物奖品

 优惠券

   积分规则管理

   

   

  

经过筛选，我将“实物奖品”和“ 优惠券”还有”兑换”合并为“ 兑换优惠奖品”，会员信息和会员合并为会员。因此，符合子系统要求的对象类包括：“积分”、“兑换优惠奖励”和”积分规则管理”。以下是根据这个例子筛选后的结果如表(22)所示：

表 22 会员积分管理子系统中定义的类

序号

类名

中文含义

功能描述

1

 Integral

积分类

 积分查询：提供积分查询功能，允许用户或系统管理员根据会员ID查询会员的积分信息。

积分增加：提供积分增加功能，允许系统管理员或特定权限的用户为会员增加积分。在增加积分时，需要输入会员ID、积分数额和积分类型等信息，并确保积分的增加是准确无误的，且不会导致积分超出会员的可用限额。

积分兑换：提供积分兑换功能，允许会员将积分兑换成实物奖品、优惠券或其他形式的奖励。兑换过程需要输入会员ID，选择兑换的奖品，并确认兑换等步骤。系统需要确保兑换过程的安全性和公平性，防止恶意兑换和滥用积分的情况发生。

 

2

 RewardExchange

兑换优惠奖励类

 奖励查询：提供奖励查询功能，允许用户查询可用的奖励列表，包括实物奖品和优惠券等。

奖励兑换：提供奖励兑换功能，允许会员将积分兑换成可用的奖励。系统需要确保兑换过程的安全性和公平性，防止恶意兑换和滥用积分的情况发生。

兑换通知：在会员成功兑换奖励后，系统可以发送通知给会员，告知兑换结果和相关注意事项。

 

3

 IntegralRuleManagement

积分规则管理类

 规则查询：提供规则查询功能，允许系统管理员查询当前设置的积分规则列表。

规则设置：提供规则设置功能，允许系统管理员设置不同的积分规则，例如消费金额与积分的换算比例、不同等级的会员享受的积分政策等。这些规则可以根据不同的业务需求进行灵活调整，以满足不同阶段的需求变化。

规则更新：提供规则更新功能，允许系统管理员对现有的积分规则进行修改和更新。

 

 

[系统边界类与系统控制类]系统边界类主要是指系统与用户交互界面有关的类。 在会员信息管理子系统中，与用户交互的窗口类通常包括以下几种：

1.系统边界类：

 

1）会员积分管理系统边界类：该边界类将整个会员积分管理系统包裹起来，负责管理系统与外部环境的交互。它提供了一些接口，允许外部用户或系统进行交互，例如增加积分、查询积分、兑换奖励等操作。

2）积分规则管理系统边界类：该边界类将积分规则管理子系统包裹起来，负责管理积分规则的增加、查询和更新等操作。它提供了一些接口，允许系统管理员或其他有权限的用户进行积分规则的设置和修改。

3）兑换优惠奖励系统边界类：该边界类将兑换优惠奖励子系统包裹起来，负责管理兑换操作的整个流程。它提供了一些接口，允许会员进行奖励的查询和兑换等操作。

 

  1. 系统控制类：

 

1）会员积分管理控制器：该控制器负责协调整个会员积分管理子系统的工作流程。它接受外部用户的请求，并根据请求的类型和内容，调用相应的业务逻辑进行处理，然后返回处理结果。控制器还负责处理一些异常情况，例如积分增加失败、兑换失败等。

2）积分规则管理控制器：该控制器负责协调整个积分规则管理子系统的工作流程。它接受系统管理员或其他有权限用户的请求，并根据请求的类型和内容，调用相应的业务逻辑进行处理，然后返回处理结果。控制器还负责处理一些异常情况，例如规则设置失败、规则更新失败等。

3）兑换优惠奖励控制器：该控制器负责协调整个兑换优惠奖励子系统的工作流程。它接受会员的请求，并根据请求的类型和内容，调用相应的业务逻辑进行处理，然后返回处理结果。控制器还负责处理一些异常情况，例如兑换失败等。

 

（5） 采用 CRC 卡片标识对象类及其属性、操作

[ 类的属性与操作]关于“ 积分类”、“ 兑换优惠奖励类”、“ 积分规则管理类”、 的的简单信息描述和状态描述：

1.积分类（Integral Class）：
属性：积分（points）、会员ID（member ID）、积分类型（integral type）、积分状态（integral status）等。
操作：

积分查询：根据会员ID查询积分信息。

积分增加：根据会员ID和积分数额增加积分。

积分兑换：根据会员ID和兑换条件兑换积分。

2.兑换优惠奖励类（Reward Exchange Class）：
属性：奖励ID（reward ID）、奖励名称（reward name）、奖励类型（reward type）、奖励数量（reward quantity）等。
操作：

奖励查询：根据奖励ID查询奖励信息。

奖励兑换：根据会员ID和兑换条件兑换奖励。

奖励通知：在会员成功兑换奖励后，发送通知给会员。

3.积分规则管理类（Integral Rule Management Class）：
属性：积分规则ID（rule ID）、积分规则名称（rule name）、积分规则内容（rule content）、积分规则状态（rule status）等。
操作：

规则查询：根据积分规则ID查询规则信息。

规则设置：根据积分规则内容和状态设置新的规则。

规则更新：根据会员ID和积分规则内容更新现有规则。

 

 [ 类的 UML 图符表示]此处为会员积分管理管理系统案例中的积分类进行 UML 图符表示，如图 23所示：

              

                

                             图 23 积分类的图符表示

 

 

此处为会员积分管理管理系统案例中的兑换优惠奖励类进行 UML 图符表示，如图 24所示：

 

              

                           图 24 兑换优惠奖励类的图符表示

 此处为会员积分管理管理系统案例中的积分规则管理类进行 UML 图符表示，如图 25所示：

                  

                       图 25 积分规则管理类的图符表示

 

                   

（3）对象类间继承关系建模，绘制类图

我们可以发现一些公共属性和相似操作， 会员类（Member Class）是一个基础类，积分类（Integral Class）和兑换优惠奖励类（Reward Exchange Class）继承自会员类。积分规则管理类（Integral Rule Class）是一个独立类，不与会员类直接相关联。这样可以通过继承关系建模来减少代码重复和提高代码复用性。如图26所示

 

 

                      图 26 会员类的继承关系图

（4）对象类间语义关联关系建模，完善类图

 1.积分类与兑换优惠奖励类之间的关联关系：

积分类中的积分可以用于兑换奖励，因此积分类与兑换优惠奖励类之间存在关联关系。具体来说，积分类中的会员可以使用积分兑换奖励，而兑换优惠奖励类则提供了兑换奖励的功能。如图27

    

图27     积分类与兑换优惠奖励类之间的依赖关系

 

 

 2.积分类与积分规则管理类之间的关联关系：

积分类中的积分规则由积分规则管理类进行设置和管理，因此积分类与积分规则管理类之间存在关联关系。具体来说，积分规则管理类负责设置和管理积分规则，而积分类则根据设置的积分规则进行积分的增加、查询和兑换等操作。如图28

 

                 图 28积分类与积分规则管理类之间的组合关系

 

 

 3.兑换优惠奖励类与积分规则管理类之间的关联关系：

兑换优惠奖励类需要使用积分规则管理类中设置的积分规则进行兑换操作，因此兑换优惠奖励类与积分规则管理类之间存在关联关系。具体来说，积分规则管理类中的积分规则可以用于指导兑换优惠奖励类进行兑换操作。如图29

 

 

  图 29 兑换优惠奖励类与积分规则管理类之间的组合关系

 

  四 实验分析及问题思考

对于“会员管理系统”和“会员关系管理系统”中的各个对象类，以及实验分析及问题思考的要求，进行以下分析：

一、会员管理系统中的对象类

会员：包括会员的个人信息、注册信息、登录信息等。

商铺店员：负责管理和服务会员的商铺员工，具备对会员信息的增删查改等操作权限。

总管理员：负责整个系统的管理与维护，具备最高权限，可以设置商铺店员权限、管理会员信息等。

账户信息：包括会员的账户余额、交易记录等。

会员信息：包括会员的积分、等级、消费记录等。

操作流程：包括系统的操作流程、规则等。

二、会员关系管理系统销售管理子系统中的对象类

消费记录：记录会员的消费行为，包括消费时间、消费地点、消费金额等。

消费频率：统计会员的消费频率，以便进行后续营销活动。

数据可视化报告：将会员的消费行为、消费频率等数据进行可视化展示，便于分析和决策。

三、会员积分管理系统中的对象类

积分：记录会员的积分数量、来源、使用情况等。

兑换优惠奖励：记录会员使用积分兑换的优惠奖励情况，包括兑换时间、兑换物品、兑换积分数量等。

积分

规则管理：设置和管理积分规则，包括积分获取规则、兑换规则等。

 

思考：

 

系统功能的完整性：系统是否实现了预设的所有功能，如会员信息的增删查改、消费记录的统计与展示等。

系统操作的便捷性：系统的操作流程是否简洁明了，用户是否可以轻松上手使用系统。

数据的安全性：系统是否采取了必要的安全措施，如数据加密、权限管理等，以确保会员信息的安全性。

系统的可扩展性：系统是否具备良好的可扩展性，以便在未来添加更多功能和业务逻辑。

实验结果的准确性：对实验结果进行验证和分析，以确保实验结果的准确性和可信度。

通过以上分析，我们可以对“会员管理系统”、“会员关系管理系统”以及“会员积分管理系统”进行全面的实验和评估，以发现系统中的问题和不足，并采取相应措施进行改进和优化。

 
逻辑视图模型建模

班级: 信2205-2        学号: 20224082        姓名:艾鑫

实验自评

实验内容

自评结果（在对应格内打ü）

不熟练

一般

比较熟练

熟练

识别对象类及其属性、操作

 

 

 

ü

确定类间关系

 

 

 

ü

绘制类图，描述系统静态逻辑结构

 

 

 

ü

实验体会

会员管理系统实验体会

我最近参与了“会员管理系统”的开发实验，其中涉及到了“会员信息管理系统”、“会员关系管理系统”和“会员积分管理系统”等多个子系统的整合。通过这次实验，我深入了解了系统的逻辑视图，并体会到了系统设计与开发的复杂性。

1.系统整体性的重要性：

在实验之前，我对每个子系统都有一个大致的了解，但通过实验，我真正体会到了它们是如何相互连接、相互依赖的。任何一个子系统的变动都可能影响到其他部分，甚至整个系统的稳定性和效率。

2.逻辑视图的实际意义：

通过逻辑视图，我可以清晰地看到数据的流动、处理过程以及各个组件之间的交互。这为我在后续的开发和维护工作中提供了很大的便利。

3.会员关系管理的复杂性：

“会员关系管理系统”不仅仅是一个简单的CRM系统。它需要考虑如何与会员进行互动、如何分析会员的行为、如何制定合适的营销策略等。这需要对业务有深入的了解，并能够将业务需求转化为技术实现。

4.积分管理的策略与技术实现：

“会员积分管理系统”中，如何设定积分规则、如何计算积分以及如何与其他系统进行积分数据的交互都是需要仔细考虑的问题。在实验过程中，我体会到了业务需求与技术实现之间的微妙平衡。

虽然实验中遇到了很多技术难题和业务逻辑的挑战，但每一次解决问题都让我成长许多。我学会了如何将复杂的业务需求拆解成可执行的技术任务。总的来说，这次“会员管理系统”的实验让我深刻体会到了系统开发的复杂性和挑战性。但正是这种挑战，促使我不断成长和进步。我相信，通过不断地实践和积累经验，我会在系统开发这条道路上走得更加稳健和长远。