基于工程实践的需求分析与概念原型
1.前言
本次课题的主题是根据本人工程实践的项目,进行用例建模、业务领域建模、数据建模,并最终形成概念原型。可以把概念原型看作用例+数据模型,本次课题目的是掌握这种思想方法,通过这种方法去分析和理解项目。
2.项目背景
我的工程实践是留学信息管理与分析系统的设计与开发。该系统是为用户提供有关留学服务信息的双边平台,管理人员定期维护系统,学生可以通过该系统搜索学校相关信息,并根据所提供的自身信息获得相应的留学建议。用户可以在此平台上填写自己的基本信息、偏好等,系统会通过分析用户的需求、自身的条件、留学地的社会环境和安全问题、留学学校信息、留学专业信息等给用户一个合理的选择区间,给用户提供参考和指导。
3.需求分析
3.1什么是需求分析?
需求就是对用户期望的软件行为的表述。获取需求就是需求分析师通过关注用户的期望和需要,从而获得用户期望的软件行为,然后对其进行表述的工作。而需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。
3.2需求分析的类型
- 功能需求:根据需要的活动描述需要的行为
- 非功能需求:描述软件必须具有的一些质量特征
- 设计约束:设计决策,如平台或接口组件的选择
- 过程约束:对可用于构建系统的技术或资源的限制
3.3高质量需求
-
Making Requirements Testable
- 用定量描述每个副词和形容词
- 不要用代词,尽量用实体的具体名称
- 确保在需求文档中对每个名词都有定义
-
Resolving Conflicts
不同的stakeholder对需求的想法,可能有潜在的冲突,所以要对需求进行优先级划分:
- essential:必须实现的
- desirable:可取但不是必须实现
- optional:可选的
-
Characteristics of Requirements
-
正确性
-
一致性
-
无二义性
-
完整性
-
可行性
-
相关性
-
可测试性
-
可追踪性
-
3.4需求分析的方法
-
原型化方法(Prototyping)
可以很好地整理出用户接口方式(UI,User Interface),比如界面布局和交互操作过程。
-
建模的方法(Modeling)
可以快速给出有关事件发生顺序或活动同步约束的问题,能够在逻辑上形成模型来整顿繁杂的需求细节。这也是本次我们主要使用的方式。
4.用例建模
4.1什么是用例?
用例(Use Case)的实质是它是一个业务过程(business process),经过逻辑整理抽象出来的一个业务过程。
业务过程:在待开发软件所处的业务领域内完成特定业务任务(business task)的一系列活动。
用例的基本要素:
- 一个用例应该由业务领域内的某个参与者(Actor)所触发。
- 用例必须能为特定的参与者完成一个特定的业务任务。
- 一个用例必须终止于某个特定参与者,也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
参与者(Actor)
参与者是业务领域内的参与者或者业务实体。参与者不是待开发软件系统的一部分,但需要和待开发软件系统交互。参与者常常是人,某个参与者触发某个用例为相应的参与者完成一个业务任务。
用例的三个抽象层级
-
抽象用例
只要用一个干什么、做什么或完成什么业务任务的动名词短语,就可以非常精简地指明一个用例。
-
高层用例
需要给用例的范围划定一个边界,也就是用例在什么时候什么地方开始,以及在什么时候什么地方结束。
-
扩展用例
需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来,一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。
用三个抽象层级分析“用户登录系统”用例:
这里面涉及到需要登录的用户这一参与者和登录系统所需的一系列业务活动。
-
抽象用例:“登录系统”这一动名词短语;
-
高层用例:“登录系统”这一用例的开始状态就是用户使用键盘输入账号密码,终止状态就是用户收到“登录成功”的信息提示反馈。这样就描述了一个高层用例;
-
扩展用例:进一步扩展“登录系统”这一用例,大致可以得出如下扩展用例的两列表格
Actor: 用户 | System: 网站 |
---|---|
1. TUCBW: 用户点击登录 | 2. 弹出登录方式选择框 |
3. 用户点击账号密码登录 | 4. 弹出账号密码登录页面 |
5. 用户通过输入账号密码 | 6. 系统格式校验、信息校验,并返回结果给用户 |
7. TUCEW: 用户完成登录系统 |
4.2用例建模的基本步骤
- 从需求表述中找出用例,往往是动名词短语表示的抽象用例
- 描述用例开始和结束的状态,用TUCBW和TUCEW表示的高层用例
- 对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关系,并画出用例图
- 进一步逐一分析用例与参与者的详细交互过程,完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例
4.3提取用例的基本方法
-
从需求中寻找业务领域相关的动名词和动名词短语,比如做什么事、什么事情必须被完成,或者执行某任务等;
-
验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件:
-
它是不是一个业务过程?
-
它是不是由某个参与者触发开始?
-
它是不是显式地或隐式地终止于某个参与者?
-
它是不是为某个参与者完成了有用的业务工作?
如果以上四个必要条件都满足的话,那么该业务领域相关的动名词或动名词短语就是一个用例。
-
-
在需求中识别出参与者、系统或子系统。
- 参与者会触发某个用例开始,用例也会显式地或隐式地终止于某个参与者;
- 用例会属于系统或子系统。
4.4用例图中的基本关系
4.5用例建模
现在对留学管理与分析系统进行用例分析,整个系统有用户和管理员两个角色.
用户的主要功能:
-
注册系统
-
登录系统
-
浏览信息
-
获取留学建议
-
使用论坛
-
管理个人信息
上述需求都是动名词或者动名词短语,满足用例的四个必要条件,并对动名词短语用下划线标出,根据上述需求画出用例图:
管理员的主要功能
-
管理学校、专业信息
-
管理论坛信息
-
管理用户信息
5.业务领域建模
业务领域建模是开发团队用于获取业务领域知识的过程,有助于开发团队获取业务领域知识形成统一的业务认知。
基本步骤
-
收集应用业务领域的信息。聚焦在功能需求层面,也考虑其他类型的需求和资料;
-
头脑风暴。列出重要的应用业务领域概念,给出这些概念的属性,以及这些概念之间的关系;
-
给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
-
将结果用 UML 类图画出来。
根据以上步骤,对留学管理与分析系统进行业务领域建模。
-
获取需求:已经完成并画出了用例图。
-
头脑风暴并归纳出类和属性:
-
应用业务领域:
- 信息检索:根据信息进行学校和专业的筛选
- 论坛:论坛管理,发帖、删帖、收藏
- 后台管理:管理员模块,对系统所有信息包括用户信息进行管理
- 用户管理:用户管理自己信息
-
列出相关的类和属性
- 用户:uid、账号、密码、权限、个人信息、注册时间、登录记录
- 管理员:id、账号、密码、权限、登录记录
- 学校:sid、中英文校名、专业、所在地、QS排名、介绍
- 专业:mid、名称、热度、介绍
- 文章:aid、作者、发布时间、关键词、内容、热度、留言
- Merge(关联类):uid、sid、mid、aid
-
类之间的关系
-
一个管理员管理多个用户、学校、专业和多篇文章
-
多个用户搜索和浏览多个学校、专业,提交自己的信息,得到专业的建议;多个用户发表或评论多篇文章。
-
多个学校包含多个专业
-
-
-
画出UML类图
6.数据建模
根据上述UML类图,得出如下的关系数据表:
用户表
字段名 | uid | account | password | permission | infomation | register_time | login_time |
---|---|---|---|---|---|---|---|
字段类型 | int(8) | varchar(50) | varchar(50) | int(8) | varchar(255) | datetime(0) | datetime(0) |
字段描述 | 用户ID | 用户账号 | 密码 | 权限 | 个人信息 | 注册时间 | 上次登录时间 |
备注 | 主键,默认生成 |
管理员表
字段名 | id | account | password | permission | login_information | login_history |
---|---|---|---|---|---|---|
字段类型 | int(8) | varchar(50) | varchar(50) | int(8) | varchar(255) | varchar(255) |
字段描述 | 管理员ID | 管理员账号 | 密码 | 权限 | 登录信息 | 登录记录 |
备注 | 主键,默认生成 |
学校表
字段名 | sid | college_name | college_e_name | area | qs_rank | information |
---|---|---|---|---|---|---|
字段类型 | int(8) | varchar(50) | varchar(50) | varchar(50) | int(8) | varchar(255) |
字段描述 | 学校ID | 学校中文名 | 学校英文名 | 地区 | QS排名 | 学校简介 |
备注 | 主键,默认生成 |
专业表
字段名 | mid | major_name | hot | information |
---|---|---|---|---|
字段类型 | int(8) | varchar(50) | int(8) | varchar(255) |
字段描述 | 专业ID | 专业名称 | 热度 | 专业介绍 |
备注 | 主键,默认生成 |
学校-专业表
字段名 | s_m_id | sid | mid |
---|---|---|---|
字段类型 | int(8) | int(8) | int(8) |
字段描述 | 学校_专业ID | 学校ID | 专业ID |
备注 | 主键,默认生成 | 外键 | 外键 |
论坛文章表
字段名 | aid | author | publish_time | hot | tag | content | leave_note |
---|---|---|---|---|---|---|---|
字段类型 | int(8) | varchar(50) | datetime(0) | int(8) | varchar(50) | varchar(255) | varchar(255) |
字段描述 | 作者ID | 作者名 | 发布时间 | 热度 | 标签 | 内容 | 留言 |
备注 | 主键,默认生成 |
Merge关联表
字段名 | uid | sid | mid | aid |
---|---|---|---|---|
字段类型 | int(8) | varchar(50) | varchar(50) | int(8) |
字段描述 | 用户ID | 学校ID | 专业ID | 作者ID |
备注 | 主键,默认生成 | 外键 | 外键 | 外键 |
7.概念原型及其工作工程
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。
概念原型=用例+数据模型。
基于上面已经完成的用例和数据模型,我们可以得出本系统工作的概念原型,本概念原型包括2个用例和6个数据模型
用例:用户用例、管理员用例
数据模型:用户、管理员、学校、专业、文章、Merge
概念原型的工作过程举例如下:
eg1:用户注册系统时,输入手机号码,提交给系统,系统通过网络接口通信服务,发送验证码给手机,用户接收到验证码并输入、提交,系统核验后通过注册,并把手机号码作为账号插入用户表,用户完成注册。
eg2:用户搜索某某学校的某专业情况时,系统搜索数据库中的学校表以及专业表,经过一定的数据处理后,将信息返回给用户。
eg3:管理员登录系统,进入管理员页面,修改某某学校的简介时,系统查找到学校表的具体行,把管理员提交的简介内容与原简介内容进行合并修改。
8.总结
本次课题我们以面向对象的分析和设计为思想方法的主线,提供了一种从需求分析到软件设计的基本建模方法,通过完整学习了这种从需求分析到软件设计的基本建模方法之后,我对面向对象的概念有了切身体会。从需求分析到用例建模,从业务领域建模再到数据建模,都是紧密联系的,有一定的迭代关系。概念原型是一种虚拟的、理想化的软件产品形式,它等于用例加上数据模型,有了用例和数据模型,就能够得到概念原型的工作过程。