本人以“铁路公安派出所业务管理系统”项目的开发为背景，着重论述了需求分析方法中的面向对象分析的整个过程。
该项目的建设目标是：（1）建立枪支弹药管理数据中心，存储枪支弹药的信息和出入库的记录数据。（2）合理安排和管理派出所值班备勤警力。（3）建立执法场所管理数据中心，对执法场所的监管更加合理化、及时化。（4）显示屏显示统计信息。系统需要考虑到推广到其子管辖区的派出所，并于将来对接智能枪弹管理系统，系统需具有良好的扩展性和松耦合性。

在项目开展期间，我担任了系统分析、系统设计与数据库管理等大量工作。在项目需求分析和设计阶段，我着重考虑好系统的框架和原型，为项目组及其他分析员进行下一步的细化分析奠定了坚实的基础。

需求分析的工作通常包括以下几个方面：

1. 绘制系统上下文范围关系图
   用于定义系统与系统外部实体间的界限和接口的简单模型，它可以需求确定一个范围。项目需要对接公安局现有的警钟系统，并对在执法场所拘留时间到的嫌疑人予以释放，所以系统外部实体包括警钟系统和系统时钟。
2. 创建系统原型
   通过快速开发工具开发一个抛弃式原型，将帮助用户更好理解所要解决的问题，更好理解系统。我是使用axure 9.0快速进行页面的简单跳转。
3. 分析需求的可行性。
   对所有获得的需求进行成本、性能和技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
4. 确定需求的优先级
   对于需求优先级的描述，可以采用满意度和不满意度指标进行说明。其中满意度表示当需求被实现时用户的满意程度。不满意度表示当需求未被实现时用户的不满意程度。
5. 为需求建立模型
   即建立分析模型，这些模型的表现形式主要是图表加上少量的文字描述。根据采用的分析方法不同，采用的图也将不同。需求分析模型主要描述系统的数据、功能、用户界面和运行的外部行为，它是系统的一种逻辑表示技术，并不涉及软件的具体实现细需求分析模型可以帮助系统分析师理解系统，使需求分析任务更加容易实 。同 时它也是以后进行软件设计的基础 为软件设计提供了系统的表示视图。
6. 创建数据
   数据字典是对系统用到的所有数据项和结构进行定义， 确保开发人员使用了统一的数据定义。因为涉及到枪支信息，我特意参考了下《枪支管理信息规范》标准来定义枪支代号等字段。
7. 使用QFD（Quality Function Deployment，质量功能展开）方法
   将产品特性、属性与对用户的重要性联系起来。

考虑到用户要求系统将来可以拓展到管理子派出所，我们采用多租户的ABP（ASP.NET Boilerplate）框架。ABP是一个开源的基于DDD（Domain-Driven Design，领域驱动设计）的强大架构模型。为了系统的可用性，我们选择跨平台的.net core，并前后端分离的angular版本的ABP。因为ABP本身是使用面向对象设计的，为了接下来在整个系统生命周期中更好地与系统设计、系统实施衔接，所以在需求分析阶段，我采用OOA方法对系统进行分析。

OOA主要使用UML（Unified Modeling Languge）进行建模。在项目中，我使用Microsoft Office Visio 2013 来绘制分析中所需的UML图。OOA过程主要分为用例模型、领域模型和分析模型。

1. 用例模型
   用户模型主要是从用户的角度去建模。
   （1）识别参与者
   参与者是与系统交互的所有事物。这里有用户（警员、后勤人员）、警钟系统、提醒关押嫌疑人时间到的时钟
   （2）合并需求获得用例
   将参与者找到之后，需要为每一个参与者确定用例。将需求分配给相关参与者，如警力排班分配给大队队长；枪支出入库分配给仓库管理员。其次，进行合并操作。将识别到的参与者与合并生成的用例通过用例图的形式整理出来，获得用例模型的框架。需注意业务用例（Business Use Case）和系统用例（System Use Case）。比如告警是系统用例，而审核是业务用例。
   （3）细化用例描述
   用例模型的主要工作是形成用例规约（Use Case Specification）。用例模板定义了用例规约的结果。
   （4）调整用例模型
   建立初步用例后，还需要用用例之间的关系（主要是关联、依赖（包含、拓展）和泛化）来调整用例模型。把一些公共信息抽取出来，使系统松耦合，更易维护。比如权限管理用例，只有审核人员才具有枪支申请审核功能、导出警力排班信息为拓展用例。

2. 分析模型
   （1）定义概念类
   OOA的中心任务是找到系统中的对象或类。在命名上，因为ABP的实体需映射到数据库表的实体集DbSet（一般使用复数），所以在实体类命名中，我们采用名词单数。例如枪支Gun，我们可命名对应的DbSet为Guns，那么枪支的数据库表就为Guns。ABP可以在实体类中使用数据标注修改表名或者重载DbContext的OnModelCreating方法统一为所有的表添加表名前缀，所以我们定义在定义类名时尽量简洁。
   （2）确定类之间的关系
   类之间的关系可分为关联、依赖、泛化、实现、聚合、组合等。因为DDD的类都继承自实体类Entity或者Entity的子类（FullAuditedEntity、AuditedEntity），所以，类之间泛化少，以关联为主。枪支类中包含了弹药信息，属于组合关系。类图组合在一起可形成领域模型。
   （3）为类添加职能
   类的职能包括：类的成员变量或属性、类的成员方法。一个实体类对应定领域层的Entity（实体），DDD中的实体定义中，实体并不是通过它们的属性定义的，而是通过一连串的连续性事件和标识定义的。因此我们每个实体都赋予一个唯一标识的Id，对属性并未很严格，反而在成员方法上多做丰富。
   （4）建立交互图
   多个对象的行为通常采用对象交互来表示。UML2.0提供的交互图有顺序图、交互概览图、通信图和定时图。我用visio画出参与对象（警员用户、申请审核者、仓库管理员）在枪支申请信息、申请审核信息、枪支出库信息、枪支入库信息的顺序图等。

将面向对象的分析方法与基于DDD的ABP框架结合起来，使整个开发过程都很清晰流畅。但是因为ABP本身高集成的，灵活化用难度高，我们在开发中也遇到了各种难题。比如为了跨平台使用的entityframework core，数据库映射策略只支持TPH(table per Hierarchy)不像ef 6支持TPC和TPT。不过，在整个过程中，我们也体会到了DDD的优越性。