用议论文三要素，搞定需求分析（中）
副标题[/!--empirenews.page--]
先回顾一下上一篇文章的内容，主要讲业务模型这个“论点”的分析思路：以业务目标这个抽象角度作为分析的切入点，梳理需求；再引入用例，通过场景分析，对用例进行细化，最后得出分析业务模型的归纳公式：
讲完论点，此篇文章就来bb一下，需求分析的“论据”。需求分析的“论据”就是业务模型的整体结构，传达系统有什么？ 为了更好地理解这个问题，回答之前，首先我们思考一下这个生活问题：西红柿炒鸡蛋有什么？换言之西红柿炒鸡蛋的食材有什么？ 这点生活常识，我还是有的。 果断百度了一下，西红柿炒鸡蛋的食材：番茄3个，鸡蛋3个，油10g，盐5g， 鸡精3g。 so easy，但别小瞧这几个简单的数字与文字，它表示了各食材、佐料之间的数量关系（番茄与鸡蛋的数量关系、油、盐、鸡精之间的数量关系等），缺少某样食材或者各食材、辅料的数量关系不对，都会影响西红柿炒鸡蛋这盘菜的最后结果。 同样系统也是这个道理，而在软件中，这个物叫“类”，实际上就是一类事物的意思，一张桌子是一个对象，桌子就是一个类了，其实用户是很容易理解的，它就是“类型”的意思。很多商业系统只有1个、两个或三个核心的类，围绕着这几个类产生大量的处理流程，系统就是为产生和操纵这些东西开发的。 类的构成很简单，由类名、属性、操作组成。类名是类的名称、属性是类拥有的信息、操作是类提供的服务。 如图为类的表示方法：
回归正题，有没有发现，需求分析的“论据”就是用类映射现实世界，以类作为核心，描述系统的结构框架，来表示系统有什么？ 那如何用类来做结构框架分析呢？ 主要步骤包括这三个：
讲完思路，下面就来小实战一下。 发现类同样，还是以上篇文章中的“餐厅系统”为例。 就餐的大概流程：顾客在“真好吃”餐馆吃饭，通过手机扫描二维码进行点菜，翻阅菜单查看菜品，菜品种类有热菜、冷菜、小吃，点菜完成后，系统需要将小明点的菜品记录，生成订单，并生成送菜单发送给对应的厨师（负责热菜的、负责冷盘的、负责小吃的），厨师做完菜后，通知服务员端菜，服务员根据送菜单上的餐桌号，将菜端到顾客面前，顾客就餐完结账。 有一点不同的是现实生活的对象往往是具象的，类容易理解找出，系统的对象往往是抽象的，不容易找出与分辨，且具有十分多的属性需要分析，判断是否可以作为类。不过，也是有“名词动词法”去帮助我们去分辨。 “名词动词法”，其主要规则是从名词与名词短语中提取类与属性；从动词与动词短语中提取操作与关联；其实就是名词对应类或者类的属性，动词对应类的操作。而所有格短语通常表示属性（格式：xxx的xxx，例如：餐桌的号码牌，号码牌就是一个属性）。 名词有：顾客 “真好吃”餐馆 菜单 热菜 冷菜 小吃 菜品 订单送菜单 餐桌号 厨师 服务员。 很显然，并不是每一个名词都是可以作为类的，有些名词对于开发的系统来说是无关紧要的，甚至是系统之外的，而有些名词适合作为属性。 顾客，会对系统产生作用，会下订单，可以归类到“顾客”这个类中。 “真好吃”餐厅“厨师”“服务员”不对系统产生作用，是系统外的概念，不属于类。 热菜、冷菜、小吃都是菜品的类型，菜品是可以作为类的。 菜单作为统计菜品的主体，具有统计的操作方法，可以视为一个类。 订单包含了下单时间、餐桌号、顾客点的菜品与付款类型，是一个类。 送菜单包含了该菜的信息、餐桌号还有自身的编号，也是一个类。 餐桌号概念过小，只能作为订单的属性。 所以提炼出：菜单、菜品、顾客、订单、菜品单。 明确类之间的数量与逻辑关系类之间最常见的逻辑关系有三类：关联、泛化、聚合/组合。 关联：说明两物有联系，用一条直线连接。比如顾客与订单之间有联系。 泛化：子类从父类中继承，使用空心箭头的实现表示。就如图上述例子，菜品是父类，热菜、冷菜、小吃作为子类继承了菜的特性，同时具有自己独特的属性。 聚合与组合关系：整体与部分的关系。区别在于，聚合中的部分可以独立于“整体”存在，而组合中的部分“完全依赖于整体”。这里菜品与菜单就是聚合的关系，菜品可以独立于菜单而存在。
并根据以上的逻辑关系，对每个类进行分析，同时思考他们的数量关系，分析过程如下：
综上，可以得出初步的类图。
明确类的属性与方法当找出了系统的类，并厘清它们之间的数量关系与逻辑关系之后，就可以确定类的属性与操作了。根据目前的业务描述，可以找到以下的属性与操作：
接着使用“名词动词法”，来找出类的操作，动词有：吃点记录、发送做通知端、统计。 （编辑：广西网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
