功能分析

观察者模式上篇 观察者模式原理： 大家好，欢迎来到污污弹公司，最近啊，污污弹接到气象站的外包项目。 功能比较简单： 要对外提供天气接口(温度、气压、湿度)需要实时通知第三方； 还需要实时在市中心公告栏上发布天气情况。 司小司接到任务开始动手干了。根据Java面向对象特性分析后得到如下信息： 天气对象：WeatherData 公告板对象:CurrentConditions 天气更新时候，调用天气对象的dataChange方法，得到数据后，然后将数据通过display()方法展示出来。 根据上面信息，我们可以创建以下两个类： 天气对象： ​ 观察者模式上篇 观察者模式原理： 大家好，欢迎来到污污弹公司，最近啊，污污弹接到气象站的外包项目。 功能比较简单： 要对外提供天气接口(温度、气压、湿度)需要实时通知第三方； 还需要实时在市中心公告栏上发布天气情况。 司小司接到任务开始动手干了。根据Java面向对象特性分析后得到如下信息： 天气对象：WeatherData 公告板对象:CurrentConditions 天气更新时候，调用天气对象的dataChange方法，得到数据后，然后将数据通过display()方法展示出来。 根据上面信息，我们可以创建以下两个类： 天气对象： @Data public class WeatherDataOO { public WeatherDataOO ()

需求分析二 1.1编制目的 希望通过此文档来初步介绍这一微信小程序，并借此使得用户能够更加了解其大概功能和使用方法。 1.2适用范围 此文档只适用于基于微信小程序的食堂订餐送餐等功能的介绍与使用。适用于使用本程序的食堂工作人员和点餐的学生等。 1.3前提与约束 这项软件开发的时长为一个月，无具体经费限制。要求是使用Java、软件工程及数据库访问技术等知识进行开发。 系统概述 2.1用户特点 此小程序的用户类型主要分为两类，主要是食堂工作人员和学生。面对学生大数量的点餐送餐，软件需要及时更新发布数据，对于数据的快速响应和准确性有很大的要求。 2.2运行环境 手机客户端（安卓、iOS都行），使用者通过微信进入小程序页面进行操作，需要用户开通地理位置的权限等。 2.3设计和执行约束 软件使用可以在微信小程序中找到并使用，且必须符合微信小程序使用的相关规定，必须配备身份认证系统等。 外部需求接口 3.1用户界面 用户进入需要登录并且进行身份认证，需要配备其他帮助选项或者错误信息显示等。 3.2软件接口 由微信小程序提供各种软件接口，如数据库、操作系统等应用程序编程接口。 3.3通信接口 与本程序所使用的的通信功能相关的如电子邮件、Web浏览器、网络通信标准或协议等。 功能需求 4.1用户分类 一类为食堂的工作人员

http://hi.baidu.com/hieda/blog/item/627e9fdd2526e0ec76c638e3.html Synopsys工具简介 〓 LEDA 　　LEDA?是可编程的语法和设计规范检查工具，它能够对全芯片的VHDL和Verilog描述、或者两者混合描述进行检查，加速SoC的设计流程。 LEDA预先将IEEE可综合规范、可仿真规范、可测性规范和设计服用规范集成，提高设计者分析代码的能力 〓 VCSTM 　　VCS是编译型Verilog模拟器，它完全支持OVI标准的Verilog HDL语言、PLI和SDF。 VCS具有目前行业中最高的模拟性能，其出色的内存管理能力足以支持千万门级的ASIC设计，而其模拟精度也完全满足深亚微米ASIC Sign-Off的要求。VCS结合了节拍式算法和事件驱动算法，具有高性能、大规模和高精度的特点，适用于从行为级、RTL到Sign-Off等各个阶段。VCS已经将CoverMeter中所有的覆盖率测试功能集成，并提供VeraLite、CycleC等智能验证方法。VCS和Scirocco也支持混合语言仿真。VCS和Scirocco都集成了Virsim图形用户界面，它提供了对模拟结果的交互和后处理分析。 〓 SciroccoTM 　　Scirocco是迄今为止性能最好的VHDL模拟器，并且是市场上唯一为SoC验证度身定制的模拟工具

http://hi.baidu.com/hieda/blog/item/c1dc23ee505a25f8b2fb95e3.html Calibre物理验证系列 〓 Calibre DRC 　　作为工作在展平模式下的设计规则检查（DRC）工具，Calibre DRC先展平输入数据库，然后对展平的几何结果进行操作。 〓 Calibre DRC-H 　　作为Calibre DRC的选项，Calibre DRC-H确保层次化的DRC成为可能，层次化设计规则检查维持数据库的层次化结构，并且充分利用设计数据的层次化关系减少数据处理时间、内存使用和DRC检查结果数量。对于确定类型的芯片而言，DRC-H要比在展平模式下的Calibre快几个数量级。层次化处理对于0.35μm或以下工艺，规模达到或者超过百万晶体管的芯片设计优势更加明显。Calibre DRC-H通常可以和设计规则检查(DRC)以及光学工艺校正(OPC)配合使用。 〓 Calibre LVS 　　作为Mentor Graphics公司工作在展平模式下的版图与原理图对照（LVS）工具，Calibre LVS先展平输入数据库，然后对展平的几何结果进行操作。 〓 Calibre LVS-H 　　作为Calibre LVS的选项，Calibre LVS-H确保层次化的LVS成为可能，层次化版图与原理图对照维持数据库的层次化结构

团队作业10——事后分析（Beta版本） 目录 一、设想与目标 二、计划 三、资源 四、变更管理 五、设计与实现 六、测试与发布 七、总结 八、图片和贡献分分配 一、设想和目标 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 我们的软件要解决的问题是用户能够正常使用四则运算app，app可以出题，判断对错，显示结果，录入错题库的问题，同时在beta阶段加入注册登陆功能，设置简单版和复杂版。定义得也比较清楚，包括 出题，判断对错，显示结果，录入错题库 。 用户主要针对学生，老师，家长，场景主要是练习四则运算，做题。 2.是否有充足的时间来做计划? 时间上面还是不够充分，因为后期碰到了一些问题，一切都没有想象的那么顺利。 3.团队在计划阶段是如何解决同事们对于计划的不同意见的？ 小组通过微信，qq和电话等通讯工具一起协商讨论来解决意见冲突。 4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? 用户量并没有达到预期，但是就有使用过的用户来说，功能（重要）是符合他们的要求的。离我们最初的梦想还是有一些距离的。 5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进? Beta阶段我们由于模拟器和设备等问题，等于把所有的内容全部重做了一遍。这样时间就会显得很不充分。如果可以重来我们会制定更细的任务清单

1.今天完成：MockingBot企业版中创建项目，将小组成员加入同一项目中；开始参照墨刀中的产品需求模板写需求分析；用ProcessOn完成思维导图，对产品需求有进一步的认识。 2.明日计划：需求分析文档完善，写完功能介绍和产品逻辑，开始原型设计。有时间的话看看关于微信小程序开发的文档和网课。 来源： https://www.cnblogs.com/Jane165/p/11385428.html

基于微信小程序的食堂订餐送餐系统的需求分析 文档说明 1.1编制目的 希望通过此文档来初步介绍这一微信小程序，并借此使得用户能够更加了解其大概功能和使用方法。 1.2适用范围 此文档只适用于基于微信小程序的食堂订餐送餐等功能的介绍与使用。 1.3前提与约束 我们假设使用我们这一产品的用户已经了解到现在线上点餐等基本功能。 系统概述 2.1用户特点 此小程序的用户类型主要分为两类，主要是食堂工作人员和学生。面对学生大数量的点餐送餐，软件需要及时更新发布数据，对于数据的快速响应和准确性有很大的要求。 2.2运行环境 手机客户端（安卓、 iOS都行），使用者的网络必须保持良好，需要用户开通地理位置的权限等。 2.3设计和执行约束 软件使用可以在微信小程序中找到并使用，且必须符合微信小程序使用的相关规定，必须配备身份认证系统等。 外部需求接口 3.1用户界面 用户进入需要登录并且进行身份认证，需要配备其他帮助选项或者错误信息显示等。 3.2软件接口 3.3通信接口 功能需求 用户分为两类，一类为食堂的工作人员，食堂需要在此小程序上登录注册账户并将其菜品样式价格等上传到网上并及时更新其状态；另外一类便是使用该小程序点餐的学生，学生同样也是可以使用学号登录线上点餐。 今天我们小组就“饱了么”小程序的需求分析做了一个大概的叙述和分析

前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子，那么选择一款合适自己的消息中间件显得尤为重要。就算是前者，那么在自研出稳定且可靠的相关产品之前还是会经历这样一个选型过程。 在整体架构中引入消息中间件，势必要考虑很多因素，比如成本及收益问题，怎么样才能达到最优的性价比？虽然消息中间件种类繁多，但是各自都有各自的侧重点，选择合适自己、扬长避短无疑是最好的方式。如果你对此感到无所适从，本文或许可以参考一二。 各类消息队列简述 ActiveMQ是Apache出品的

原 消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局https://blog.csdn.net/u013256816/article/details/79838428版权声明：本文为博主原创文章，未经博主朱小厮允许不得转载。 https://blog.csdn.net/u013256816/article/details/79838428 本文收录于InfoQ，未经允许不得转载。 一、前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子

交付用户想要的软件 让客户做决定 在设计方面，做决定的时候好必须有开发者参与。可是，在一个项目中，它们不应该做所有决定，特别是业务方面的决定。 Decide what you shouldn’t decide. 开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不来的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟那不是你的事情。如果遇到了一个问题，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题，要委婉地劝说他们，这些问题最好还是和真正的业务负责人或客户商议。 当你和客户讨论问题的时候，准备好几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响，以及如何权衡。无论他们做出了什么决定，他们必须接受它，所以最好让他们了解一切之后再做这些决定。如果时候他们又想要其他的东西，可以公正地就成本和时间重新谈判。 毕竟，这是他们的决定。 具体技巧 记录客户做出的决定，并注明原因。好记性不如烂笔头，但你选择的记录方法不能太笨重或太繁琐。 不要用过于具体和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没有价值的。 不要随意假设具体的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题。