根据工程实践项目进行需求分析和概念原型建模

  • 2020 年 11 月 27 日
  • 筆記

1 前言

此篇博客主要是根据最近学习的软件工程建模方法,对笔者所参与的工程实践项目,进行建模与分析。主要是需求分析、业务领域建模以及数据建模,最终形成一个完整的概念原型。现在将建模的过程总结如下:

2 工程实践背景介绍


  工程实践是一个关于留学生信息管理与分析的平台。该系统是为用户提供有关留学服务信息的双边平台,管理人员定期维护系统,学生可以通过该系统搜索学校相关信息,并根据所提供的自身信息获得相应的留学建议。留学信息管理与分析系统可以针对不同用户,通过多种因素的综合分析,给出科学的建议,给用户合适的择校建议,让用户更好的选择心仪的海外高校。主要是为海外留学的人提供一些指导和推荐作用。

3 用例建模

  根据此系统和软件工程相关原理,我们可以进行用例分析,进行用例建模。首先我们要明确,用例是什么,基本要素是什么,抽象层级是什么,如何进行用例建模。

3.1 用例相关介绍

  用例是应用程序开发中的一个关键技术,主要用来捕获系统的高层次(High Level)用户功能性需求。用例是一个业务过程,经过逻辑整理抽象出来的业务过程。其中业务有三个基本要素:

  1 一个用例应该由业务内的某个参与者所触发

  2 用例必须能为特定的参与者完成一个特定的业务任务

  3 一个用例必须终止于某个特定参与者,也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

3.2 用例建模基本步骤

  了解了什么是用例,我们必须了解用例建模的基本步骤:

  1 从需求表述中找出用例,往往是动名词短语表示的抽象用例;
  2 描述用例开始和结束的状态,用TUCBW和TUCEW表示的高层用例;
  3 对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关系,并画出用例图;
  4 进- -步逐-分析用例与参与者的详细交互过程,完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

3.3 准确提取用例的基本方法

  为了准确地提取用例,我们必须遵循一些原则和方法:

  1 从需求中寻找业务领域相关的动名词和动名词短语,比如做什么事、什么事情必须被完成,或者执行某任务等;
  2 验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件:
  a必要条件一 :它是不是一个业务过程?
  b必要条件二:它是不是由某个参与者触发开始?
  c必要条件三:它是不是显式地或隐式地终止于某个参与者?
  d必要条件四: 它是不是为某个参与者完成了有用的业务工作?
  如果以上四个必要条件都满足的话,那么该业务领域相关的动名词或动名词短语就是一个用例。
  3 在需求中识别出参与者、系统或子系统。
  参与者会触发某个用例开始,用例也会显式地或隐式地终止于某个参与者; .
  用例会属于系统或子系统。

  其中四个必要条件尤为重要,是我们能否准确识别用例的关键所在。下面根据此原理和方法,针对留学生信息管理系统进行用例建模。

3.4 开始用例建模

  根据工程实践的背景,我们可以提取出相应的需求:

  首先系统分为两个角色,用户和管理员,是名词,因此显然系统有两个用例。用户主要有如下功能:

用户用例

在进入系统后,用户可以使用以下功能:

a)       注册登录

b)       浏览所感兴趣的学校信息和专业信息

c)       提交自己个人情况,获取系统提供的留学建议

d)       进入论坛发帖回帖

e)       管理个人信息

根据上述需求,我们可以找出相应的动名词,并且结合是否满足用例的四个必要条件,我们可以提取出用例,用例用下划线标出,并且基于此,我们可以画出基于用户的用例图:

 

 

 

 

 同样的,我们可以根据工程实践背景,抽取出相应的管理员需求:

管理员用例

在登录后,管理员可以使用以下功能:

a)管理学校、专业信息

b)管理用户信息

c)管理论坛信息

我们根据用例建模的原理,同样的可以提取出一些动名词,用下划线标出。此动名词即为管理员的相应用例。画出管理员的用例图如下:

 

 

 

 

 

 

4 业务领域建模

4.1 业务领域建模基本介绍

业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例 。

4.2 业务领域建模基本步骤

●第一步,收集应用业务领域的信息。聚焦在功能需求层面,也考虑其他类型的需求和资料;
●第二步,头脑风暴。列出重要的应用业务领域概念,给出这些概念的属性,以及这些概念之间的关系;
●第三步, 给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
●第四步, 将结果用UML类图画出来。

4.3 结合自己工程实践分析


1 collect application domain information

根据两种不同的用户,我们该工程要实现的是

(1)用户登录之后输入不同的条件,可以产生符合输入条件的留学信息和专业信息

(2)根据用户的个人材料,系统可以给用户推荐一些学校以参考

(3)用户和管理员有自己的个人中心,可以进行相应的管理

(4)用户可以在相应的学校论坛模块进行发帖、收藏,管理员可以进行帖子的管理、删除等等。

2 brainstorming

(1)列出重要的应用程序域概念:

信息检索:根据信息进行学校和专业的筛选

推荐算法:后台算法模块

用户管理:用户中心管理,管理用户的相应操作

后台管理:管理员模块,进行系统的相应管理

论坛:论坛管理,发帖、删帖、收藏

(2)列出他们的属性

-用户:用户ID,账号,密码,注册时间等
-管理员:ID,密码,权限,登录时间,登录IP等
-学校:ID,中英校名,地区,QS排名,介绍等
-专业:ID,名称,专业热度,介绍等
-文章:ID,作者,发布时间,热度,关键词,内容,留言等

(3)他们之间的关系

-管理员管理用户,用户搜索学校和专业信息,用户提供自己的材料,系统给出相应的建议,用户进行发帖、评论收藏,管理员进行管理违反社区的帖子

3.classifying the domain concepts into

根据上述,我们将分为5个类别:1 用户 2 管理员 3 学校 4 专业 5 文章 

4.document result using UML class design

5 数据建模

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

我们经过上述分析发现,用户在根据相应的条件进行查询时,结果可能是比较复杂的,返回的可能不是单一的结果,可能是匹配多个学校,多个专业,甚至包含特定论坛内容的结果,因此我们有必要设计一个中间结果类,用于匹配多种条件的信息。这就是所谓的中间关联类,我们设计一个这样的关联类,在表中其实表现为外键关联。与学校、专业和论坛为聚合关系。经过这样设计之后的数据模型如下:

 

相应的表设计如下:

 

A)用户信息表

用户信息表存放所有用户的账号和密码等重要信息,用于用户的注册和登录。其他信息则与论坛或其他个人信息关联,包括性别、头像、成绩、意向学校或收藏等,可为空,后续进行详细设计。使用拦截器,未登录不能访问论坛与院校详情。

Id

账号

密码

昵称

注册时间

其他……

 

 

 

 

 

 

 

B)管理员信息表

后台管理人员的信息。

Id

账号

密码

登录时间

登录ip

 

 

 

 

 

 

C)学校信息表

学校信息表主要记录学校的一些关键信息如名称、专业设置等。其他例如录取率、申请材料等在其他信息中进行详细设计。

Id

中英校名

国家地区

QS排名

学校介绍

专业设置

其他……

 

 

 

 

 

 

 

 

D)专业信息表

专业信息表包括全球主流专业的详细信息。后续进行详细设计以增强信息检索能力。

Id

名称

学校排名

详细信息……

 

 

 

 

 

E)文章信息表

论坛的首要的功能是实现文章的发布与留言,文章信息表中的热度包括浏览量、点赞数和转发数,留言列表将采用单独的表进行映射。

Id

作者

发布时间

热度

关键词

文章内容

留言列表

 

 

 

 

 

 

 

 

F)中间结果表

主要是起到缓存的作用,引入中间关联表。

Id

学校ID

专业ID

详细信息……

 

 

 

 

 


6 概念原型以及工作过程


概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论,概念原型是一种虚拟化的、理想化的软件产品形式。也就是说,概念原型 = 用例 + 数据模型。

因此基于以上分析和建模,我们就可以总结出此项目的概念原型,同时对此概念模型的工作过程进行分析。

留学信息管理与分析系统概念模型分为两个用例图和六个数据模型:
用例分为用户用例图、管理员用例图;
数据模型分为用户、管理员、学校、专业、文章和中间结果。

整个概念模型的工作过程为:

用户这个用例向系统输入条件和数据,系统进行分析和筛选为专业、学校和文章几种信息,学校和专业为聚合关系,文章和其他几类为多对多关系,专业学校文章中有个中间结果进行组合,系统进行处理之后,把中间结果转化为最终结果返回给用户,用户收到了满意的结果,这就是一次业务过程。
管理员这个用例登录之后,进入属于自己的界面,管理员进行增删改查等操作之后,系统进行处理这些数据,进行更新学校、专业、文章等表结构,并把操作之后的结果返回给管理员,完成了一次业务过程。

比如说用户搜索新加坡国立大学软件工程专业,系统搜索数据库之后进行数据处理,把精准的信息返回给页面,例如新加坡国立大学的介绍,Qs排名,专业排名,评价,以及有关方面的论坛介绍等等,如果用户输入的个人信息足够多,那么系统还可以智能推荐;
再比如管理员登录系统之后,可以进行学校信息的更新,专业的更新,对不符合的论坛或者用户进行删除操作等。

 

7 总结

此博客主要根据软件工程的概念原型建模原理,对工程实践项目进行了用例建模、业务领域建模和数据建模,最后总结出概念原型以及工作过程。

8 参考资料

1 ppt from Dr.David Kung University of Texas Arlington May 2010

 

//www.cnblogs.com/jundiy/category/194488.html

//www.cnblogs.com/zpfbuaa/p/5962613.html

//blog.csdn.net/u012785382/article/details/60586842