建模软件

Hadoop与Kubernetes就好像江湖里的两大绝世高手，一个是成名已久的长者，至今仍然名声远扬，一个则是初出茅庐的青涩少年，骨骼惊奇，不走寻常路，一出手便惊诧了整个武林。Hadoop与Kubernetes之间有很深的渊源，因为都出自IT豪门——Google，只不过，后者是亲儿子，正因为有大佬背书，所以Kubernetes一出山，江湖各路门派便都蜂拥而至，拥护称王。 不知道是因为Hadoop是干儿子的缘故还是因为“廉颇老矣”，总之，Hadoop朋友圈的后辈们如Spark、Storm等早都有了在Kubernetes上部署运行的各种资料和案例，但Hadoop却一直游离于Kubernetes体系之外，本文我们给出Hadoop在Kubernetes上的实践案例，以弥补这种缺憾。 Hadoop容器化的资料不少，但Hadoop部署在Kubernetes上的资料几乎没有，这主要是以下几个原因导致的： 第一， Hadoop集群重度依赖DNS机制，一些组件还使用了反向域名解析，以确定集群中的节点身份，这对Hadoop在Kubernetes上的建模和运行带来极大挑战，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解决这一难题。 第二， Hadoop新的Map-Reduce计算框架Yarn的模型出现的比较晚，它的集群机制要比HDFS复杂，资料也相对较少

♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other ♦ 3) Classifying the domain concepts into: – classes – attributes / attribute values – relationships • association, inheritance, aggregation ♦ 4) Document result using UML class diagram 　领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。领域模型是一种概念模型，也叫问题域模型。它表述的是某个领域的现实概念。上世纪80年代开始

1、Collect application domain information – focus on the functional requirements – also consider other requirements and documents 创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织您的软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，您将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。 2、Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other 随着时间的推移，您将会使用新的领域类别来识别您的领域模型。您还会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。 第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系

章节信息 Entity Framework 6 Recipes 第二版 第一章： Chapter 1: Getting Started with Entity Framework ------------------------------------------------------------------------- 阅读说明： 1 术语第一次出现时用中文（原文）表示，如EntityType将表示成 实体类型（EntityType） 2 菜单名用粗体表示，如File将表示成 文件 3 右击，即鼠标右键点击 第 1 章：EF入门 使用关系型数据库是根据表及其行列去考虑问题的。表是高度结构化并且擅长基于集合的处理。在面向对象编程思想广泛应用前，我们都是过程式思考问题并且通过编写结构化、自顶向下、一个接一个函数的方式解决这些问题。它们的世界都是排好的：表、行和列在我们的代码中紧密地匹配结构化和过程化模式。在相当长的时间内，这种方式工作的非常好…… 在代码的世界里已经发生了相当大的变革。现在我们从对象和领域模型方面考虑问题。我们对现在世界的事物如客户和订单做架构、设计和编程。我们在白板上描绘我们问题集中的词语。我们在它们之间连线、描述关系和交互。我们根据这些草图制订规范和指派任务给开发团队。总之，我们在一个概念水平上做架构、设计和编码