建模软件

理解数据是控制任何企业的先决条件。但只有当这些知识能够被分享和传播时，理解才是有用的。有效的数据建模应该是任何企业架构师的首要关注点。 在我的上一篇文章中，我认为理解一个企业的数据是指导一个企业的核心。但理解只是问题的一半。另一半是能够记录这种理解并与他人分享。 如果没有对数据的共同理解，就谈不上跨系统或组织的共享数据。传统上，这是通过使用数据字典来完成的--这些文件旨在解释数据结构中每个字段的内容和格式。可悲的现实是，这些文档必须手动创建和更新，因此很少会进行更新。其结果是往往会出现过时的、无用的文档和沮丧的架构师和开发人员。但其实还有更好的办法。 正确完成建模 在过去的几十年里，数据建模的努力通常集中在关系数据建模或可扩展标记语言(XML)的建模上。只要数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其他的用途。而且XML也不能被可靠地称为建模语言。XML是序列化数据的规范--即定义了如何将数据写入文件。XML为构造数据的序列化提供了一种格式，但它不是一个真正的模型。 我所说的“模型”指的是以数学为基础的形式规范。实际上，这意味着是可以使用形式化方法进行验证的东西。通俗地说，这意味着我们可以用数学运算来证明它是正确的，并且我们可以使验证过程自动化。而在XML模式中捕获数据不符合此定义下的模型。但可以肯定的是，我们可以使用软件来验证该XML格式是否良好

对 jBPM 来说，今年最大的事件莫过于jBPM的创建者 Tom Baeyens 离开JBoss了。Tom Baeyens离开的具体原因尚不清楚，但他的离开产生了两个结果：一是jBPM的下一个版本jBPM5完全放弃了jBPM4的基础代码，基于 Drools Flow 重头来过；二是Tom Baeyens加入 Alfresco 后很快推出了新的基于jBPM4的开源工作流系统 Activiti 。由此不难推测Tom Baeyens离开的部分原因：JBoss内部对jBPM未来版本的架构实现产生了严重的意见分歧。更加巧合的是12月1日Activiti5刚发布，紧接着12月2日jBPM5就发布了第一个候选发布版本，jBPM与Activiti之间的微妙关系可见一般。 相关 厂商 内容 Flash Builder 4.5高级版试用版免费高速下载 百度技术沙龙第十七期：富客户端时代的JavaScript框架（8月20日 周六） Hadoop、HBase、MongoDB和Cassandra等技术在当前的企业中的应用 Sybase在线研讨会：云时代的列式数据库——Sybase IQ15.3新特性(8月22日 周一) InfoQ诚聘：策划编辑、项目经理、商务经理等 在这篇文章里，我们将一起回顾jBPM从jBPM3到jBPM5以及Activiti5的发展历程，我们可以清晰的看见jBPM

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 UML分类 （1）静态模型（系统结构）： 用例图、类图、对象图、构件图、部署图 （2）动态模型（系统行为）：状态图、活动图、顺序图、协作图 UML中有4种事务： （1）结构事务：名词、静态部分、物理元素。 （2）行为事务：动词、动态部分、行为。 （3）分组事务：包。 （4）注释事务：注解。 用例图： 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 用例之间的关系 （1）包含 (include) 关系 父用例包含子用例，父用例执行，子用例必然被执行 当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行

1.powerdesigner安装教程（很好用，内容很完善的一个教程！！！） https://blog.csdn.net/sinat_34104446/article/details/79885141 最后一步汉化不建议，汉化并不彻底，而且摸着石头过河也似乎可以 真的不要从软件园下载软件，捆绑安装太恶心，之后清了很久！！ 2.ER建模 建立概念模型：https://www.cnblogs.com/xingyukun/archive/2007/08/02/840293.html 生成物理模型：tools->generate physical model 生成SQL脚本：https://jingyan.baidu.com/article/6f2f55a14e61d8b5b93e6c93.html 居然没有IBM DB2，表示不服 运行SQL脚本生成表格：生成的SQL再在power designer上运行开始报错，可能要到数据库上运行吧 3.反思 再最开始ER建模的时候需要先找出实体，注意需要把实体和关系区分开，实体的属性是它本来就具有的属性，这个时候不需要考虑最后生成表的情况，把自己不是当作一个技术人员，这个时候是要完全站在业务的角度去画这个东西。 最开始的时候，考虑了各种主外键之类的，完全是在画表，就很乱。 来源： CSDN 作者： xueying_2017 链接： https:/

1.什么样的服务是好的微服务？ 它应该具备这 两个特点：松耦合、高内聚 松耦合 ： 如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另外一个服务了 。使用微服务最重要的一点是，能够独立修改和部署单个服务而不需要修改系统的其他部分，这一点非常重要。 那么相对的什么是紧耦合呢？使用紧耦合来做服务之间的集成，会使的一个服务的修改致使其消费者的修改。 一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。 高内聚 ： 我们希望 把相关的行为聚集在一起，把不相关的行为放在别处 。 因为如果你要改变某个行为的话，最好能够只在一个地方进行修改，然后就可以快速发布。如果你同时需要很多地方做修改，那么就可能同时发布多个微服务才能完成这个功能。这样的话，修改会变慢，部署服务的工作量和风险也会增大。 这就需要找到问题域的边界，从而确保相关的行为能放在同一个地方，并且它们会和其他边界以尽量松耦合的形式进行通信。 2.限界上下文 Eric Evans 的 《领域驱动设计》中，曾提到这个概念。 他认为， 任何一个给定的领域都包含多个限界上下文，每个限界上下文中的模型分成两部分，一部分不需要与外部通信，另一部分则需要 。 每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他上下文。 2.1 共享的隐私模型 例如，对于MusicCorp来说，财务部门和仓库就可以是两个独立的限界上下文

为什么需要数据仓库？ 传统的数据库中，存放的数据都是一些定制性数据较多，表是二维的，一张表可以有很多字段，字段一字排开，对应的数据就一行一行写入表中，特点就是利用二维表表现多维关系。 但这种表现关系的上限和下限就定死了，比如QQ的用户信息，直接通过查询info表，对应的username、introduce等信息即可，而此时我想知道这个用户在哪个时间段购买了什么？修改信息的次数？诸如此类的指标时，就要重新设计数据库的表结构，因此无法满足我们的分析需求。 在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致 数据库是根据业务需求进行设计 。 那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？ 首先数据仓库，从字面上理解就可以感受到这是一个很大的空间，而且存储的物品很杂，里面会存放酱油、沐浴露、洗发精等物品，而数据库是存放酱油、盐等厨房用品，洗浴又是一个数据库。 另外一个就是，国内互联网的发展，一开始大家都是做个软件出来，大家一起用，这个时候只要满足的了需求即可，现今不止是需求还有用户的体验等各种方面，需要根据这些分析指标做调整。 小结： 数据库是跟业务挂钩的，而数据库不可能装下一个公司的所有数据，因此数据库的设计通常是针对一个应用进行设计的。 数据仓库是依照分析需求、分析维度、分析指标进行设计的。 什么是数据仓库？ 数据仓库

一、什么是威胁建模 简单的来说，威胁建模就是通过结构化的方法，系统的识别、评估产品的安全风险和威胁，并针对这些风险、威胁制定消减措施的一个过程。 威胁建模是一个非常有用的工具，它的核心是“像攻击者一样思考”。威胁建模可以在产品设计阶段、架构评审阶段或者产品运行时开展，强迫我们站在攻击者的角度去评估产品的安全性，分析产品中每个组件是否可能被篡改、仿冒，是否可能会造成信息泄露、拒绝攻击。威胁建模的作用更偏向于确保产品架构、功能设计的安全，无法保证编码的安全，但是输出的威胁建模报告中包含了全面的安全需求，这些安全需求不仅包括大的方案设计，如要认证、鉴权、审计，也可以包括安全细节的实现，比如具体的认证方式、密码使用哪种安全算法存储，使用什么方法生成安全随机数等。所以，威胁建模虽不能保证编码的安全，但可以指导研发人员编写出安全的代码，同时也可以辅助渗透测试人员开展安全测试。 二、为什么要做威胁建模 1. 站在攻击者的角度通过识别威胁，尽可能多的发现产品架构和功能设计中的安全风险 2. 制定措施消减威胁，规避风险，确保产品的安全性 三、应该在什么时候做威胁建模 威胁建模应融入企业的软件开发安全生命周期（SDL）中。 1. 新产品或新功能的设计阶段应开展威胁建模，发现风险、制定消减措施，消减措施是安全需求的一部分，需落入产品需求跟踪，确保产品安全。 2. 系统运行过程中也可以开展威胁建模

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 UML分类 （1）静态模型（系统结构）： 用例图、类图、对象图、构件图、部署图 （2）动态模型（系统行为）：状态图、活动图、顺序图、协作图 UML中有4种事务： （1）结构事务：名词、静态部分、物理元素。 （2）行为事务：动词、动态部分、行为。 （3）分组事务：包。 （4）注释事务：注解。 用例图： 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 用例之间的关系 （1）包含 (include) 关系 父用例包含子用例，父用例执行，子用例必然被执行 当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行

注：科比今天要退役了，我是 60 亿分之一，满腹怀念～😭😭😭 前几天看了园友的一篇文章《 我眼中的领域驱动设计 》，文中有段话直击痛点： 有人误认为项目架构中加入 Repository，Domain，ValueObject 就变成了 DDD 架构 。没错，我就是这样，不过准确的来说，并不能称为 DDD 架构，而是我之前经常说的“ 伪 DDD ”设计，后来我还抽离出了一个伪 DDD 设计框架： DDD.Sample ，大家有兴趣的可以瞧瞧，在实际项目的开发中，我用它做过了几个不太大的项目，我个人觉得用起来很顺手，当然并没有真正的 DDD 设计，只不过用了一个空的架构而已，然后冠以”DDD 开发“的名号。 因为之前有过 DDD 设计的痛苦经历（短消息系统），具体表现就是，如果真正 DDD 设计，需要花费大量的时间和精力，可能几天都在思考一个问题或者考虑几行代码的编写，但最后也可能没什么结论或结果，并且这个过程是很艰难和痛苦的，所以我后来就变懒了，懒的去思考项目所表现的业务，也不再考虑如何去设计领域模型，只是在考虑如何让框架用起来更爽，DDD.Sample 前两个应用的实际项目，我都是在完善这个框架，比如 Repository 和 UnitOfWork 的设计等等，所以，关于领域模型的设计，就是一堆贫血模型。不过，后来应用的第三个项目，也就是上一个实际项目，我觉得不能再这样下去了

业务领域建模的概念 领域建模是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。（百度百科） 业务领域建模的原因 分析系统和设计系统不是同一个人，这种割裂导致需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD（领域驱动设计）则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。对于复杂的业务场景，事务脚本很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达，使得复杂性治理成为可能。 业务领域建模的步骤 初步建模： 建模也是一个不断迭代的过程，所以一开始可以简单点来，就采用两步建模法抓住一些核心概念：首先从User