成绩分析管理系统需求分析与建模

hobbyyyy 2021-12-27 14:19:04

工程实践题目是做一个学生成绩分析管理系统。本文以工程实践项目为需求场景，进行需求分析和建模，形成业务概念原型。

1.需求分析

对于本项目，用户主要有两类，一类为家长或学生，一类为管理员。家长或学生可以利用成绩分析系统来查看学生或自身情况，管理员负责系统数据的维护。

1.1 家长&学生

成绩展示：家长或学生可以查看学生所在班级平均分、年纪等级，平均分、优劣科目（离平均分差距最大的科目）、分数差距（差多少分到前一个等级）、成绩对比（不同学科+总分）、知识点掌握程度等。
画像展示：家长或学生可以查看学生画像，即通过学生平时消费、借书、学习等校园生活数据进行分析，将学生分成几类画像，家长或学生可以查看学生所属画像，并分析与学习成绩相关因素。
基本信息修改：家长或学生可修改学生基本信息。
登录：为了隐私保护，家长或学生经过登录验证后才可进入系统。

1.2 管理员

管理员：

对学生数据增删改查：主要包括对学生成绩的增删改查和对学生基本信息的增删改查。
画像管理：每隔一段时间对群体进行重新画像。

1.3 总结

成绩分析管理系统主要通过学生和家长线上查询学生成绩及了解学生平时学习生活的需求进行服务。而在此过程中，管理员可以保证学生数据的及时更新和维护不出错，提供数据保证。

系统参与者有学生家长和管理员，他们的操作都在成绩分析系统中完成。整个系统的功能分为两个模块，一个是学生家长对系统的操作，包括:成绩展示、画像展示、基本信息修改、登录。另一个是管理员对系统信息的维护,包括：对学生信息的增删改查、画像管理。

2.用例建模

2.1 用例的定义

　　用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。一个用例应该由业务领域内的某个参与者所触发，且必须能为特定的参与者完成一个特定的业务任务，它终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

2.2 用例建模步骤

　　第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；

　　第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；

　　第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；

　　第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

　　其中第一步到第三步是计划阶段，第四步是增量实现阶段。

2.3 提取用例原则和方法

由2.2可知用例建模的第一步是找到用例，下面是提取用例的步骤。

第一步，从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；

第二步，验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：

• 必要条件一：它是不是一个业务过程？

• 必要条件二：它是不是由某个参与者触发开始？

• 必要条件三：它是不是显式地或隐式地终止于某个参与者？

• 必要条件四：它是不是为某个参与者完成了有用的业务工作？

如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。

第三步：在需求中识别出参与者、系统或子系统。

• 参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者；

• 用例会属于系统或子系统。

2.4 根据项目进行用例建模

　　在成绩分析系统中，提取用例可以看有哪些动名词。

对于参与者是学生家长，用例有：

登录
修改信息
查看成绩：查看学生总分排名情况、查看学生各科情况、查看系统成绩分析。
查看画像：查看画像分类和画像描述

对于参与者是管理员，用例有：

管理学生基本信息：对学生基本信息增删改查
管理学生成绩：对学生成绩增删改查
维护学生画像：隔一段时间重新画像

基于以上，我们可以画出学生家长和管理员的用例图：

学生家长用例图：

管理员用例图：

3.业务领域建模

3.1业务领域建模定义　

　　业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

　　开发团队获取业务领域知识的过程一般包括收集业务领域相关信息，执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类将业务领域知识图形化展示。

3.2 业务领域建模步骤

• 第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

• 第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

• 第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

• 第四步，将结果用 UML 类图画出来。

3.3根据项目进行业务领域建模

　下面着重分析本工程实践中的业务领域概念和概念之间的关系。

（1）学生类

属性：学号，密码，年级、班级、画像类别，成绩单id

操作：登录、修改信息、查看成绩、查看画像

（2）成绩单

属性：成绩条id，科目、考试时间、总分、卷面小分id

（3）卷面小分

属性：卷面小分id，成绩条id，题号，得分

（4）画像

属性：画像类别、画像描述

（5）管理员类

属性：工号、密码

操作：管理学生基本信息、管理学生成绩、维护学生画像

　　下面是UML图

4.数据建模

4.1数据建模定义

数据建模其实就是在之前的步骤上引入关联类进行分析，关联关系是业务数据建模的关键。

4.2 根据项目进行数据建模

在本工程实践中，用户在进行成绩查询及成绩分析查看时，结果可能是从多表中的数据分析得来，结果复杂，需要查询多个结果来返回，所以需要设计一个中间结果类，用于保存查出的多种条件的信息。设计成绩分析类，表中表现为外键关联，与成绩单，卷面小分为聚合关系。

经过这样设计之后的数据模型如下：

4.3 表设计

关系数据的数据表如下：

学生表

学号	密码	年级	班级	画像类别	成绩单id

成绩单表

成绩单id	科目	考试时间	总分	卷面小分

卷面小分表

车票id	车次id	价格	剩余数量

成绩分析表

学号	科目	考试时间	总分	题号	得分	平均分

画像表

画像类别	画像描述

管理员表

工号	密码

5.概念原型

成绩分析管理系统概念原型由两个用例图和6个类构成。用例为学生家长用例图和管理员用例图，数据模型分为学生、成绩单、卷面小分、成绩分析、画像、管理员。

整个概念模型的工作过程为：用户进行登录验证后进入系统，可以查看自己各科分数与总分排名，查看每题得分与年级平均分对比，修改个人信息，查看个人画像分析。管理员对数据进行维护，可以对学生成绩进行增删改查、对学生信息进行增删改查，定期维护画像。

6.设计模式

6.1 设计模式概述

设计模式的本质是面向对象设计原则的实际运用总结出的经验模型。目的是包容变化,即通过使用设计模式和多态等特殊机制,将变化的部分和不变的部分进行适当隔离。设计模式是为了帮助我们应对需求的频繁变化而提出来的，它可以提高软件的重用性。

6.2 常用的设计模式

单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，典型的应用如数据库实例。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例，原型模式的应用场景非常多，几乎所有通过复制的方式创建新实例的场景都有原型模式。
建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。主要应用于复杂对象中的各部分的建造顺序相对固定或者创建复杂对象的算法独立于各组成部分。
代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。代理模式是不要和陌生人说话原则的体现，典型的应用如外部接口本地化将外部的输入和输出封装成本地接口，有效降低模块与外部的耦合度。
适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。继承和对象组合都可以实现适配器模式，但由于组合关系或聚合关系比继承关系耦合度低，所以对象组合方式的适配器模式比较常用。
装饰（Decorator）模式：在不改变现有对象结构的情况下，动态地给对象增加一些职责，即增加其额外的功能。装饰模式实质上是用对象组合的方式扩展功能，因为比继承的方式扩展功能耦合度低。
外观（Facade）模式：为复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。

享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。比如线程池、固定分配存储空间的消息队列等往往都是该模式的应用场景。
策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。策略模式是多态和对象组合的综合应用。
命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。

6.3 设计模式

　　由于项目采用了面向对象的思想，因此采用策略模式，为了保证类的封装性，我们采用代理模式来完成对类的访问，在前端上，采用外观模式，为复杂的子系统提供了一个统一的接口，采用适配器模式，来将普通用户接口转换为管理员接口。

7.设计架构

7.1 设计架构概述

常见的软件架构有三层架构、MVC架构、MVVM架构。

三层架构包括界面层、业务逻辑层、数据访问层。MVC架构包括model层、view层，control层。MVVM层比MVC多了一个modelview层。

MVC层中，控制器创建模型，控制器创建一个或多个视图，并将它们与模型相关联，且控制器负责改变模型的状态，当模型的状态发生改变时，模型会通知与之相关的视图进行更新。

MVVM是对MVC的改进，它的视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。且具有可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多View重用这段视图逻辑。使开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。