本节向大家介绍一下有关UML和模式应用方面的知识，主要包括领域建模，顺序图，高类聚和架构分析等内容，相信通过本节的介绍大家对UML和模式应用一定有所了解。下面是有关UML和模式应用中常用术语。
领域建模
如果采用敏捷建模方法,创建领域模型的目的是为了快速理解和沟通大致的关键概念,***不是目的.
如果我们认为某概念类X不是现实世界中的数字或文本,那么X可能是概念类而不是属性.
例如Store应该是Sale的属性还是单独的概念类
在现实世界中,商店不会被认为是数字或文本,这一术语表示的是合法的实体,组织和占据空间的事物,因此Store应该是概念类.
关联(关系)的大部分将作为导航和可见性路径在软件中加以实现,但是,领域模型不是数据模型,添加关联是为了突出我们对重要关系的大致理解,而非记录对象或数据结构.
以"类名-动词短语-类名"的格式为关联命名,其中的动词短语构成了可读的和有意义的顺序.
诸如"拥有"或"使用"这样简单关联名称通常是拙劣的,因为这种名称不会增强我们对领域的理解.
通俗的说,大部分属性类型应该是简单数据类型,比如数字和布尔.通常属性的类型不应该是复杂的领域概念.
应该通过关联而不是属性来表示概念类之间的关系.
顺序图
UML和模式应用的顺序图应该为每个用例的主成功场景,以及频繁发生的或复杂的替代常见绘制顺序图.
在对软件应用将如何工作进行详细设计之前,***将其行为作为"黑盒"来调查和定义,系统行为描述的是系统做什么,而无需解释如何做.
系统时间应该在意图的抽象级别而非物理的输入输出设备级别来描述,比如enterItem要优于scan,因为前者即捕获了操作的意图,又保留了抽象性,而无需涉及到使用什么样的接口来捕获系统事件.系统事件的名称以动词开始,这样可以提高清晰程度,因为这样可以强调这些事件是命令或请求.
GRASP
RDD是思考OO软件设计的一般性隐喻.把软件对象想象成具有某种职责的人,他要与其他人协作以完成工作.RDD使我们把OO设计看作是有职责对象进行协作的共同体.
控制器
在正常情况,控制器应该把需要完成的工作委派给其他的对象.控制器只是协调或控制这些活动,本身不完成大量工作.
高类聚
UML和模式应用中高类聚模式是对现实世界的类比,显而易见,如果一个人承担了过多不相关的工作,特别是本应该委派给别人的工作,那么此人一定没有很高的工作效率.
"不要和陌生人说话"
该约束限制了你应该在方法里给哪些对象发送消息,它要求在方法里只应该给以下对象发送消息:
this对象
方法的参数
this的属性
作为this属性的集合中的元素
在方法中创建的对象
其意图是避免客户与间接对象和对象之间的对象连接产生耦合
直接对象是客户的熟人,间接对象是陌生人,客户应该和熟人讲话,而避免和陌生人讲话.
架构分析
变化点和进化点
变化点:当前现有系统或需求中的变化之处
进化点:现有需求中不存在,但可能在将来发生,推测性的变化点.
决定在何处花费精力进行必要的设计,预防将来可能的变化,这是架构设计师的艺术
架构分析关注的四个方面:
1)特别关注非惯性的需求,包括对应用的业务或者市场环境的熟悉.同时,功能性需求也不能忽略;它提供了处理这些架构因素的上下文,更进一步,识别功能性需求的可变性对架构分析也至关重要
2)涉及系统级别的,大尺度的,涉及面广的问题.解决这些问题通常涉及到大尺度或者基础的设计决策.
3)对相互依赖的关联的权衡,例如改善安全性可能会影响到实行效率和可用性,这些决策大都会影响成本.
4)对可选方案的规划和评估.一个熟练的架构师既可以提供构建新系统的解决方案,也可以对中备选方案进行评估.
架构分析指的是在功能需求的上下文中识别和解决非功能性需求.
异常
给一个异常命名,这个名字要能够描述这个异常为什么被抛出,而不是要描述抛出者.这样做,能够使程序员更容易理解问题,并且突出了众多异常的相似之处的本质.本节关于UML和模式应用方面的内容介绍到这里，谢谢关注。
【编辑推荐】
