每天积累一点，一年后你会发现，自己变化很大

1，描述业务用例的实现，即业务流程，然后改进它，推导出待开发系统的用例2，描述业务用例的实现，即业务流程，有几种可选的做法：选择一】文本例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下：1. 员工把报销单交给财务主管2. 财务主管确认报销单已经过员工领导审批3. 财务主管审批报销单4. 财务主管将审批好的报销单

系统用例图1,让我们把聚光灯从组织转到我们要研究的系统。有了业务建模的铺垫，系统的用例图实际上已经呼之欲出，但是我们还是要先来讲解一下系统执行者和系统用例的要点，再看看如何从业务序列图映射出系统用例图。执行者和用例的概念在业务建模的章节已经出现过。现在要研究的执行者和用例，与业务建模时研究的执行者和用例相比，不同之处是研究对象，之前研究组织，现在研究系统2,系统执行者的定义：在所研究系统外

1为什么要使用ngrok？作为一个Web开发者，我们有时候会需要临时地将一个本地的Web网站部署到外网，以供它人体验评价或协助调试等等，通常我们会这么做：找到一台运行于外网的Web服务器服务器上有网站所需要的环境，否则自行搭建将网站部署到服务器上调试结束后，再将网站从服务器上删除只不过是想向朋友展示一下网站而已，要不要这么麻烦，累感不爱╰（`□′）╯2有了ngr

sun.misc.BASE64Encoder和sun.misc.BASE64Encoder 找不到解决办法

1，利润＝需求－设计2，软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题3，用例是收益面，对象是成本面4，如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。5，拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳

1,业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去叫法的尊重，本书依然称为“业务建模”2,很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了.组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人肉系统，它由“父母公司

1,如何思考和建模得到需求模型，但需求模型的质量依赖于需求的素材。如果素材质量不高，需求的质量也高不到哪里去。就像做菜，如果食材是变质的，技艺再高妙的厨师也烹调不出美味的菜肴。厨师的技艺代替不了食材的质量。不过，厨师技艺越高，对食材的要求就会越挑剔。同样，建模技能虽然代替不了素材的质量，但会反向驱动素材质量的提高。从涉众处获取需求素材的工作叫做需求启发。2,许多时候，开发人员把需求启发想得太容

1.用例图只是表达了用例的目标，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约2,用例通过前置条件（precondition）、后置条件（postcondition）以契约的形式表达需求。用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径步骤走，系统就能到达后置条件。前置条件：用例开始