建模软件

一.领域建模Domain Modeling定义 领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。 二.业务领域建模原因 领域建模可以降低软件和现实世界之间的差异，用真实的业务概念划分职责，目的是实现一个可以高效低成本维护的可持续发展的软件系统。 从领域模型推导到系统实现是一套引导思考的方式，也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上，既可以用来同客户沟通验证需求，又可以避免模型因实现的考量而带偏（实现成本、遗留系统） 软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。 三.模型(Model)通常由2部分组成： 1.对象（Object） 2.对象间的关系(Relationship) 四. 领域建模（Domain Modeling）/业务分析的主要就是： 1.寻找业务对象（Business Object） 2.恰当建立这些对象间的关系 3.添加关联和属性 五.领域模型设计的步骤（如何进行领域建模）： 5.1用例分析法 用例分析法是进行领域建模最简单可行的方式。其步骤如下： 1.获取用例描述 既然我们的领域模型指的是问题域模型，那么建模也一定要从问题域入手

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型；所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

我的工程实践的题目是基于OpenGL ES 2.0的车载虚拟仪表软件的开发，是一个纯开发的项目，领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 1) Collect application domain information（收集应用程序域信息） 我的工程实践课题是实现房车的车载虚拟仪表，也是智能终端解决方案，它的功能性需求包括： 实现房车的实时状态的获取和更新，如电量，水位等 对于房车内部的电器，如冰箱、灯光等可以调节 界面美观，能够对应不同的房车厂商生产出不同的主题选择 语音识别和处理，网关、蓝牙的实现 2.Brainstorming（集思广益） 列出重要的应用程序域概念–列出它们的属性/属性–列出它们之间的关系 主题选择 语音控制 灯光控制 车内信息管理

一、什么是业务领域建模 　　 业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、为什么要进行领域建模 　　软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。实际上，CQRS就是对事务脚本和领域模型两种模式的综合，因为对于Query和报表的场景，使用领域模型往往会把简单的事情弄复杂，此时完全可以用奥卡姆剃刀把领域层剃掉，直接访问Infrastructure。我个人也是坚决反对过度设计的，因此对于简单业务场景，我强力建议还是使用事务脚本，其优点是简单、直观、易上手。但对于复杂的业务场景，你再这么玩就不行了，因为一旦业务变得复杂，事务脚本就很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。 　　目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达

一、领域模型 　　　　显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。（类：表示业务概念，通常只包含重要属性，少甚至不包含操作；关联、泛化：表达概念之间的关系）， 　　总而言之：领域模型是描述业务领域（业务实体）的静态结构。 　　　　理论派认为，领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 　　　　实战派认为，领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。是需求分析人员与用户交流的有力工具，是彼此交流的语言。 二、建模 　　　　我的工程实践项目是基于文本理解的的聊天机器人（汽车领域）。 　　　　1.应用域信息 　　　　　　用户通过输入name，开始一个对话，输入汽车相关问题，从聊天机器人处获得回答，根据回答进行评价。 　　　　　　聊天机器人从用户处提取问题，送入模型进行计算，输出预测回答，根据评价进行学习。 　　　　2.重要的程序域及其属性 　　　　　　用户：name， 　　　　　　对话：记录，评价 　　　　　　聊天机器人：name，满意度 　　　　3.UML类图 　　　　　　 　　　　　　 来源： https:

1.什么是业务建模？ 　　是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。其目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。而根据环境和需求的不同，业务建模工作会有不同的规模。领域建模就是其中一个。 　　如果构建应用程序的主要目的是管理和提供信息，那么可能选择在业务级别上构建该信息的模型，而不是考虑该业务的工作流程。这就称为领域建模。 　　我的工程实践是关于金融文本挖掘的，当普通用户输入实体名后出现与该实体有关的知识图谱，而后台管理员则是提供该知识图谱。因此，我的工程实践中有领域建模这一部分。下面，进入我的工程实践的领域建模。 2. 来源： https://www.cnblogs.com/ljj18/p/11908142.html

第十二章 信息系统 12.1 信息管理 1.信息系统(unformation system):帮助我们组织和分析数据的软件。 2.三种最流行的一般应用信息系统是电子表格、数据库管理系统和电子商务。 数据库管理系统是面向大量常常被搜索的数据，并将其组织成相应的小节。 12.2 电子制表软件 1.电子制表软件(spreadsheet):允许用户用单元格组织和分析数据的程序。 2.单元格(cell):电子数据表 3.可以用行列标号引用电子数据表的单元格，通常用字母指示列，用数字指示行。对于第26列之后的列，电子制表软件用两个字母作为列标号。 4.通常，电子数据表有一个合理的最大行数，如256。另外，大多数电子制表程序会把会把多个表格组合在一个大的交互系统中。 5.大多数电子制表软件允许用户控制单元格中的数据的外观和形式。用户可以设置数据的字体、样式、颜色和对齐方式。对于实数值，可以设置显示多少位小数。在大多数电子制表软件中，用户还能够设置是否显示网格线、背景颜色或单元格的图案。 12.2.1 电子数据表公式 1.电子数据表中的公式可以利用使用标准符号(+、-、* 和/)的基本数学计算，还可以利用软件内置的电子数据表函数。 电子数据表函数(spreadsheet function):电子制表软件提供的可用于公示的计算函数。 2.由于函数通常作用于一系列连续的单元格

说说概要设计 概要设计是一个设计师根据用户交互过程和用户需求来形成交互框架和视觉框架的过程，其结果往往以反映交互控件布置、界面元素分组以及界面整体板式的页面框架图的形式来呈现。这是一个在用户研究和设计之间架起桥梁，使用户研究和设计无缝结合，将对用户目标与需求转换成具体界面设计解决方案的重要阶段。 概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。 你如何划分领域边界 # 【领域驱动设计】浅谈聚合的划分与设计 聚合以及聚合根是领域驱动设计中的重要概念，根据定义，聚合是针对数据变化可以考虑成一个单元的一组相关的对象。聚合使用边界将内部和外部的对象划分开来。每个聚合有一个根。这个根是一个实体，并且它是外部可以访问的唯一的对象。根可以保持对任意聚合对象的引用，并且其他的对象可以持有任意其他的对象，但一个外部对象只能持有根对象的引用。如果边界内有其他的实体，那些实体的标识符是本地化的，只在聚合内有意义（参见《领域驱动设计-精简版》第42页）。从定义上看，貌似针对特定上下文的领域模型来讲，聚合的划分与设计并不那么困难

UML像一个工具箱，里面各种工具都有。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以，并不需要“完整地”使用UML。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。 各工作流可以选用的UML元素以及推荐用法如图所示。 不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲”。这样的做法有一个巨大的“优点”——怎么画都是对的，关于这个草图的解释权归“我”所有，同事不好批评我，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。 但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着作家可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。UML没有强调一定要用多么昂贵的工具来建模，但是，即使您在海边用手指在沙滩上建模，模型依然要概念清晰，而不是以此为理由遮掩脓包。 有的开发人员的

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。