标签：泛化 完整 工作 实践 数据类型 添加 简化 结构 语言
1、领域建模Domain Modeling：开发团队获取领域知识的过程
2、进行业务领域建模原因：因为软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。比如，团队中的每个人都在说不同种类的语言。德语、法语、希伯来语等。每次有人发言，其他人完全错误的理解发言者真正想表达的话。系统在开发的过程中，每个人都会以不同的方式解释需求和设计。领域模型是一个灵活的，协作的”工做组件“。它对整个项目进行了细化和更新，从而反映了目前对需求空间的理解。领域建模，其目的是通过建立映射问题空间的常用词汇来解决项目沟通不畅的问题。
2）头脑风暴–列出重要的应用程序域概念，列出它们的属性/属性，列出它们之间的关系
3）使用UML类图记录结果，最终画出业务类图，并说明业务类图中每一个类、属性、方法的来源，对于有关联类情况要进一步给出关系数据库的模型。
6、以我的工程实践，手势识别为基础，进行领域建模的步骤如下：
1）发现类和对象：尽可能多的找出概念类（识别方法：概念类分类列表、名词性短语）
a.概念分类列表：人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构（对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等）
b.名词分析法：识别问题域和用例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是一种标识、状态和行为）
我的名词有：玩家用户、开发人员、手势库、手势识别、交互应用、手势
2）建立类之间的关联（关联、继承、依赖）
关联：类之间的某种语义关系包括聚合，组合
继承：一般到特殊
依赖：表明一个元素（源元素）的定义或实现依赖另一个元素（被依赖元素）的定义或实现
3）添加类的重要属性（类的语义完整性、类的作用、问题域相关特性等）
a.语法：可见性 属性名：类型 多重性=默认值{特性表} [可见性] 属性名 [：类型] [=初始值]
b.属性类型是简单的数据类型为佳，如果是复杂概念，考虑是否单独作为一个概念类
c.任何属性都不表示外键，即不应该用属性来联系概念类，区别于数据库设计中的外键
| 类 | 属性方法 | 备注 |
| 开发人员 | 建立手势库和交互应用方法 | 无特殊属性 |
| 玩家用户 | ID、Name、Age等属性，Login、Logout方法 | |
| 手势库 | 手势名称属性，增加删除等操作方法 | |
| 交互应用 | 应用名称属性，增加删除等操作方法 | |
| 音乐 | 音乐名称属性，是交互应用底下不同的应用，是组成一部分 | |
| 文件 | 文件名称属性，是交互应用底下不同的应用，是组成一部分 | |
| 照片 | 文件名称属性，是交互应用底下不同的应用，是组成一部分 |
最后的类图如下：
4）关联类数据库设计：玩家用户信息表、登录信息表、手势库模板信息表、交互应用内容信息
标签：泛化 完整 工作 实践 数据类型 添加 简化 结构 语言
原文地址：https://www.cnblogs.com/ylyangliu/p/11794194.html
