domain

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

业务领域建模 Domain Modeling 好的模型应该是建立在对业务深入理解的基础上，建模是一个不断迭代的过程，一开始可以简单点来。下面开始进行一个简单的业务领域建模。 领域建模共有4个步骤：收集领域信息，进行团队头脑风暴、分类和使用UML类图可视化领域知识。 1. 收集领域信息 收集领域信息包含两个方面的内容： - 聚焦在功能需求 focus on the functional requirements - 也要考虑其他的需求和文档 also consider other requirements and documents 我的项目是构建一个适用于PC端和移动端的专注于某一学科的智能题库，用户开始时，题库会对用户进行一次测评，可以根据测评结果智能的推算出用户在这门学科的知识水平，为用户的提供有针对性的题训练。 2.进行团队头脑风暴 头脑风暴包含三个方面的内容 - 列出重要的应用程序领域概念 - 列出类和属性 - 列出它们之间的关系：继承关系（IS-A）、聚合关系（part of)、关联关系。 团队成原在一起识别这些类型：名词/名词短语、 X of Y表达式、及物动词、形容词、数字、占有式表达、成分/组成部分、包含表达式、X是Y表达式等 3. 分类 类 - classes 属性/属性值 - attributes / attribute values 关系：继承关系、聚合关系

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

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

很好的一篇文章，不愧是reid大组中山大学Weishi-Zheng老师的工作 文章的基本出发点很有意思：用source domain的feature做作为参考，衡量target domain images是否相似，从而构成正负样本进行contrasive learning和domain adaption。这就为target images建立了一个可以比较的参考系。 假定souce domain set(文章里叫agents)有$N_p$个id(实际作者用的MSMT17数据集，则$N_p=1401$)，那么作者设置agents为$N_p, 2048$(2048为提取特征的维度)，记为$\{a_i\}_{i=1}^{N_p}$，每个$a_i$代表一个reference person的2048维feature。无论是souce domain input image还是target input image，经过网络提取得到的特征和agents里面的特征都是经过l2 normlized，那么input feature点乘agent feature就是余弦相似性，则每个input点乘整个agents就得到一个$N_p$维的相似向量，这个相似向量经过softmax归一化就是 Soft Multilabel 。（ 注意区分我写的agent和agent s ） 网络模型如下： 模型输入：source

工程实践介绍 本次工程实践主要是在Linux环境下对服务器板卡做温度控制。本项目的 处理卡的等效理论峰值运算能力 166.4 TOPS （ INT8 ），可通过双槽位的 PCIe Gen3 × 16 集成于现有的各类服务器机架和工作站中，支持被动或主动两种散热方式，典型功耗为 80W 。 处理卡支持最高 32GB 的 DDR4 内存容量，并具备 ECC 数据校验功能。在 75w 的功耗下， 理论峰值速度每秒 128 万亿次定点运算。 本项目旨在优化服务器内芯片 板卡在实际使用过程中出现板卡核心温度过高 导致的 降频问题 。实际过程中 板卡在一个板卡核心超过 87° 时自动保护降频 ， 而且风扇的降温过程中会出现一定的温度波动 。 本项目旨在 通过监视 板卡的功耗和温度 ，CPU 的功耗和温度 ， 以及服务器风扇的功耗等的关系 ，开发一个应用，编写出板卡温度读取函数库，风扇转速调控函数库，设计出高效的风扇控制算法。最终实现风扇智能控制算法，实现服务器风扇的风速平衡，整个系统低功耗，从而高效的控制服务器机箱内的系统风扇。 ♦ 1) 应用领域信息 ①能够实时读取各项传感器示数，并通过不同的接口传递给其他功能模块或在前端可视化传感器示数。 ②能够对传感器读数尤其是温度等读数进行存储分析，并采用不同的策略调整风扇参数。 ③能够根据不同用户具体的需求采用不同的温控策略

以您的工程实践项目为例，在深入理解需求的基础上进行业务领域建模Domain Modeling ♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents 　 　我的工程实践题目是基于VSLAM算法的室内地图三维重建系统设计， 使用ORBSLAM/MononSLAM等视觉SLAM算法，实现单目视觉里程计、地图构建和拼接，完成周边环境的3D点云地图实时重建。在此基础上进行定位与导航等功能。 ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other 客户： 使用手持或者机器地盘进行数据获取，调用功能； 发开人员： 更新优化系统算法，修改客户权限； 数据获取： 在视觉SLAM中主要为相机图像信息的读取和预处理，如果在机器人中还可能有码盘，惯性传感器等信息的读取和同步； 估计相机运动： 根据获得的数据，求出相机的运动轨迹，用于地图的构建； 地图构建：

我的工程实践是《基于情感词典的文本情感分析》，下面以我的工程实践为例，进行业务建模。 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 获取数据集。 本项目所针对的目标是京东电子商品评论，获取数据集的主要方式有通过网络爬虫技术进行获取、下载公开的数据集或者利用开源的API进行获取。 文本预处理。 包括对文本重复值的去除、缺失值的填充、分词、去除停用词以及词频统计和词性标注。并且进行特征提取，包括文本向量化和TF-IDF值的计算。 构建领域情感词典。

在IT项目的构建中，沟通是一切协作的基础。但在系统的开发过程中，每个人都会用自己的方式解释需求和设计，为此，项目需要提供一个标准的词汇表来反映目前对需求空间的理解。领域建模是构建项目词汇表或项目中使用的词典的任务，但领域模型比项目词汇表更好，因为它以图形方式显示了所有这些不同的术语如何相互关联。实际上，它是一个简化的类图，在不同的类（领域对象）之间使用线条进行描绘，以显示它们如何相互关联。领域模型显示领域类之间的聚合和泛化关系（has-a和is-a关系）。项目的领域模型定义了范围，并形成了构建用例的基础。域模型还提供了一个常见的词汇表，以便能够在项目团队成员之间进行明确的沟通。 1. Collect application domain information 我们小组的课题是实现一个面向主题的搜索引擎，它的功能性需求包括 爬取网页获取内容 文本处理，建立索引库 分析关键字进行查询 2.Brainstorming 爬虫部分：爬取下载与主题相关的网页 文本处理：过滤网页，提取网页文本，建立索引 查询：分析关键字，检索文档 3.Classifying the domain concepts into 爬虫：自动登录、网页抓取、网页解析、存储 文本预处理：过滤网页、提取网页文本、分词 索引：建立索引、索引维护 查询：分析关键字、相关文档打分、排序 用户界面：搜索框，搜索结果展示 4.

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