领域模型(概念类图)
- 格式:ppt
- 大小:1.17 MB
- 文档页数:49
领域模型、贫⾎模型、充⾎模型概念总结领域模型领域模型是对领域内的概念类或现实世界中对象的可视化表⽰。
⼜称概念模型、领域对象模型、分析对象模型。
它专注于分析问题领域本⾝,发掘重要的业务领域概念,并建⽴业务领域概念之间的关系。
业务对象模型(也叫领域模型 domain model)是描述业务⽤例实现的对象模型。
它是对业务⾓⾊和业务实体之间应该如何联系和协作以执⾏业务的⼀种抽象。
业务对象模型从业务⾓⾊内部的观点定义了业务⽤例。
该模型为产⽣预期效果确定了业务⼈员以及他们处理和使⽤的对象(“业务类和对象”)之间应该具有的静态和动态关系。
它注重业务中承担的⾓⾊及其当前职责。
这些模型类的对象组合在⼀起可以执⾏所有的业务⽤例。
贫⾎模型是指领域对象⾥只有get和set⽅法(POJO),所有的业务逻辑都不包含在内⽽是放在Business Logic层。
优点是系统的层次结构清楚,各层之间单向依赖,Client->(Business Facade)->Business Logic->Data Access Object。
可见,领域对象⼏乎只作传输介质之⽤,不会影响到层次的划分。
该模型的缺点是不够⾯向对象,领域对象只是作为保存状态或者传递状态使⽤,它是没有⽣命的,只有数据没有⾏为的对象不是真正的对象,在Business Logic⾥⾯处理所有的业务逻辑,对于细粒度的逻辑处理,通过增加⼀层Facade达到门⾯包装的效果。
在使⽤Spring的时候,通常暗⽰着你使⽤了贫⾎模型,我们把Domain类⽤来单纯地存储数据,Spring管不着这些类的注⼊和管理,Spring 关⼼的逻辑层(⽐如单例的被池化了的Business Logic层)可以被设计成singleton的bean。
假使我们这⾥逆天⽽⾏,硬要在Domain类中提供业务逻辑⽅法,那么我们在使⽤Spring构造这样的数据bean的时候就遇到许多⿇烦,⽐如:bean之间的引⽤,可能引起⼤范围的bean之间的嵌套构造器的调⽤。
领域概念模型领域概念模型概念领域概念模型(Domain Concept Model,DCM)是一种用于描述特定领域内对象、属性和关系的模型。
它是软件开发中的一个重要工具,用于帮助开发人员更好地理解和描述业务需求。
作用领域概念模型的主要作用是帮助开发人员更好地理解和描述业务需求。
通过对特定领域内对象、属性和关系进行建模,可以使开发人员更加清晰地了解业务需求,并且可以在后续的软件设计、编码和测试过程中提供指导。
特点1. 抽象性:领域概念模型是对特定领域内对象、属性和关系进行抽象描述的。
它不涉及具体实现细节,而是侧重于表达业务需求。
2. 精简性:领域概念模型应该尽可能地精简。
只有最核心、最重要的对象、属性和关系才应该被包含在其中。
3. 可读性:领域概念模型应该易于阅读和理解。
它应该使用通俗易懂的术语,并且应该避免使用过于复杂或专业化的术语。
4. 可维护性:领域概念模型应该易于维护。
它应该能够随着业务需求的变化而进行调整,以保持其准确性和有效性。
建模过程1. 收集需求:在开始建模之前,需要收集业务需求。
这包括与客户和业务专家的沟通,以确定应该包含哪些对象、属性和关系。
2. 确定对象:根据收集到的业务需求,确定应该包含哪些对象。
这些对象应该是领域内最核心、最重要的对象。
3. 确定属性:对于每个对象,确定应该包含哪些属性。
这些属性应该是与业务需求密切相关的,并且能够提供有用的信息。
4. 确定关系:确定不同对象之间的关系。
这些关系可以是一对一、一对多或多对多等类型。
5. 优化模型:在完成初步建模之后,需要对模型进行优化。
这包括删除不必要的对象、属性和关系,并且确保模型足够简洁和易于理解。
6. 验证模型:在完成优化之后,需要验证模型是否符合业务需求。
这可以通过与客户和业务专家进行沟通来实现。
7. 更新模型:如果在验证过程中发现模型存在问题,需要进行更新。
这包括添加、删除或修改对象、属性和关系等。
应用场景领域概念模型可以应用于各种软件开发项目中。
领域模型概念类描述文档领域模型:概念类的简要说明:Payment:(付款)amount 为了确定是否提供足够的支付金额,并且计算零头,所以必须记录总额(或“支付总额”)。
Custumer:(顾客)Product Description:(产品描述)description 显示在显示器或票据上的描述。
itemID 用于查询ProductDescription。
price 显示商品单价并计算销售总额。
Product Catalog:(产品目录)Ledger:(总账)Sale:(销售)dateTime 票据上一般要显示销售的日期和时间,同时可用于销售分析。
Item:(商品)Sales Line ltem:(销售商品项)quantity 当同一种商品售出多个时(例如,5包豆腐),需要记录收银员输入的该商品的数量。
Store:(商店)address, name 票据上需要有商店的名称和地址。
Register:(终端)id 终端的编号。
Cashier:(收银员)id 收银员的编号。
关系及关系描述:与其他交易相关的交易:Sale Paid-by Payment。
顾客发起的交易:Sale Is-for Customer。
交易在终端上被捕获:Sale Captured-on Register。
总账记录着交易:Sale Logs-completed Ledger。
交易中的项目:Sale Contains Sales Line Item。
交易(或项目)对应的商品:Sales Line ltem Records-sale-of Item。
每个商店有自己的总账记录收账:Ledger Records-accounts-for Store。
产品目录被商店使用:Product Catalog Used-by Store。
产品目录包含产品描述:Product Catalog Contains Product Description。
用例图(Use case)参与者,通过使用系统服务实现其目标的那些人或者事物用例,外部可见的系统功能,对系统提供的服务进行描述。
用椭圆表示。
用例是动词或者动名词。
可以从每一个界面的主要功能来析取用例。
关系:用例图中涉及的关系有:关联、泛化、包含、扩展。
如下表所示:泛化包含扩展扣分点:参与者,用例的词性(动名词),关联是实线还是虚线,关联是否有箭头活动图(Activity):每一个用例有一个活动图,活动图尽量简单开始节点:(只有一个)结束节点:(可以有多个)同步条:(必须成对出现),表示并行执行选择:(需要写明分支的判断条件)活动:(圆边矩形,必须与状态图进行区分,动名词,可以从一个用例的执行流程中分析出动词)扣分点:同步条必须成对出现,判定需列明条件,活动的框一定是圆边矩形状态图(statement):每一个用例有一个状态图,显示一个对象从创建到消亡的整个生命周期状态:表示对象具有的一个状况,条件(名词或者说是动名词格式)转移:事件名[监护条件]/动作名(如果前面出现“/”,说明是系统的动作,不加是使用者进行的操作)开始/结束状态:扣分点:状态是圆角矩形,状态不能是一个动作(动名词格式),而是一个状况(名词或者名词+动词的格式)必须要有状态发生变化的条件领域模型(domain model):一组没有定义操作(方法的特征标记)的类图,也称为概念类图步骤:(1)寻找概念类概念类:思想,事物或对象(也就是说找名词)描述类:描述其他事物的信息,如Flight和Airport之间最好添加一个FlightDescription这个描述类。
(2)将其绘制为UML类图的类(3)添加关联和属性关联:名称需要首字母大写,一般以类名-动词短语-类名的格式来命名。
但在领域模型中,避免加入太多关联,是否需要记录关联,要基于现实世界的需要,就是那些“需要记住”的关联关系。
多重性:类A有多少个实例可以和类B的一个实例关联0或更多1或更多1~40属性:对象的逻辑数据值。