国外优秀论文网站,怎么在百度发广告,网站开发前端和后端哪个费时间,是不是该填写完整目录
什么是分析和设计#xff1f;
什么是面向对象的分析和设计#xff1f;
迭代开发
UML
用例图
交互图
基于职责驱动设计
GRASP
常见设计原则 什么是分析和设计#xff1f;
分析#xff0c;强调是对问题和需求的调查研究#xff0c;不是解决方案。例如#x…目录
什么是分析和设计
什么是面向对象的分析和设计
迭代开发
UML
用例图
交互图
基于职责驱动设计
GRASP
常见设计原则 什么是分析和设计
分析强调是对问题和需求的调查研究不是解决方案。例如需要设计一个交易系统那么如何使用他他有什么功能 设计强调满足需求概念上的解决方案。而不是实现。例如数据库解决方案和软件对象描述。
什么是面向对象的分析和设计
面向对象分析(object-oriented analysis)强调的是在问题领域内发现和描述对象或者概念。例如在学生信息管理系统里包含学生班级课程等概念。 面向对象的设计(object-oriented design)强调是定义软件对象以及他们如何协作以实现需求。例如软件对象学生可以有姓名学号属性和获取成绩单的的方法。 最后在实现或者面向对象程序设计过程里会实现设计出来的对象例如Student类。 设计对象的交互和职责分配是对象设计的核心。
在oo开发中至关重要的能力是熟练地为软件对象分配职责。 如何为对象类分配职责对象之间如何协作什么样的类应该做什么事情我们可以使用职责驱动设计他是一种经典的oo设计。 迭代开发是OOA/D的最佳实践。
迭代开发
迭代开发是指开发被组织成一系列固定的短期的小项目每次迭代的产品都经过测试集成并且是可执行局部系统。每次迭代都具有各自的需求分析设计实现和测试活动。 迭代的生命周期是经过多次迭代的系统进行持续扩展和精化并且循环反馈和调整为核心驱动力最终成为适当的系统。 每次迭代的产品都是最终系统产品的子集。 在迭代的方法里所有的分析和设计制品(用例文档uml图)都不是完善的要根据新发现进行对其进行改进。 保持设计的轻量化和简短快速进入编码和测试不要试图在UML模型里细化所有事物。对设计中有创造性和困难的部分进行建模。 在实现过程中的创造和变数在编程和测试过程中会出现很多变化并且要发现和解决无数系统问题。只有从软件构造过程中才可以真正发现原本并不知道的需求信息。如果做得好那么可以将面向对象的设计建模过程中形成的思想和理解作为良好的基础提高编程的优雅性和健壮性从而应对编程过程中遇到的新问题。但是要对编程过程中的变化和偏差有所预测和计划这是在迭代开发的关键。
UML
统一建模语言用来描述构造和文档化系统产品的可视化语言。UML是图形化表示的标准用来绘制和展示与软件相关的图形或者文字。他可以便利的帮助我们观察全景发现软件或者分析之间的联系同时允许我们忽略细枝末节。 我们不需要为所有的场景绘制UML图形只需要为在架构上重要的或者有风险的场景创建。 我们可以使用IDE提供的逆向工程从代码生成图形。这样可以作为可视化学习的辅助工具从而有助于理解现有代码。
用例图
什么是用例 用例是文本形式的情景描述用来说明参与者使用系统以实现某些目标。用例就是需求主要用来说明系统如何工作的功能性或行为性需求。 用例
21点游戏规则
游戏的目标是获得点数最接近或等于21点的手牌。 胜利者需要赢过庄家的手牌并且不能超过21点。 无论桌上有几名玩家总是和庄家论输赢。 在21点游戏里2~10的牌的点数就是牌面的数值A的点数根据玩家的需要可以取1或11点JQK的点数都是10。 游戏开始时玩家首先下注下注的额度是有上限的。 如果你是唯一的玩家下注后庄家给你发2张牌牌面向上双方都能看到。 庄家给自己发两张牌一张向上叫明牌一张向下的叫底牌。 如果有多个玩家则庄家给每位玩家都是先发一张明牌庄家给自己发一张底牌再给每一位玩家和庄家各发一张明牌。 发完两张牌之后每位玩家自己决定是否要跟多的牌当对手的牌数满意之后就停手等待。 停手等待之后庄家开始加牌但是不能超过21点。 当你的手牌超过庄家时你赢当你的手牌点数不及庄家时庄家赢。 玩家赢你的手牌超过庄家并且不能超过21点或者庄家超过21点。 玩家输玩家超过21点。 场景 庄家 玩家 庄家洗牌 玩家下注 庄家给自己发牌 玩家拿牌到手里 手牌返回庄家手牌点数 手牌返回玩家手牌点数 庄家发第二张牌 玩家继续要牌 庄家问玩家是否继续要牌 玩家拿牌到手里 庄家询问玩家手牌点数 手牌返回玩家手牌点数 庄家亮牌 玩家增加或减少赌注 庄家分配赌金 玩家亮牌
使用21游戏作为例子使用CRC分拣方法得到游戏相关卡片 21点游戏CRC卡 CRC分拣法参考CRC卡片分拣法CRC建模CRC模型https://mp.csdn.net/mp_blog/creation/editor/144721896使用CRC卡片分拣法把用例文档分析一遍之后我们可以很容易绘制用例图类图然后把注意力放在序列图上在绘制序列图时决定类的职责分配。
什么是用例图 用来描述用例名称和参与者之间的关系为系统提供简洁可视化的语境图或环境图。用例图能够表示系统边界和边界之外的事物以及系统如何使用。可以用作沟通工具用以概况系统和参与者的行为。 什么是参与者 参与者是在我们讨论的系统里调用其他系统服务的时候任何具有行为的事物。可以是人组织软件和计算机。例如玩家和庄家。 领域模型
领域模型是对领域内的概念类或者真实世界中对象的可视化表示。在UML里领域模型是一组没有定义操作的类图。他可以展示1.领域对象或者概念类2.概念类之间的关系3.概念类的属性。 领域模型不是软件对象不包含对象的职责。 为什么使用领域模型 使用领域模型可以帮助我们理解需求中的概念的和词汇。软件类的名词要源于领域模型中的名称方便使对象具有领域的信息和职责。这样做可以减小我们的思维和软件对象之间的表示差异。
如何创建领域模型 1.寻找概念类。 2.把概念类绘制成UML类图。 3.添加关联关系和属性。
怎么寻找概念类 使用CRC模型。
什么是关联 关联是类的实例之间的关系表示有意义和值的关注的连接。是否需要关联基于现实世界的需要。添加关联是为了突出我们对于重要关系的大致理解而不是记录对象或者数据。 关联的命名规则 以类名-动词短语-类名的格式为管理命名其中的动词短语构成了可读的和用意义的顺序。 角色 关联的每一端称为角色角色具有以下可选项 多重性表达式定义了类A有多少个实例可以和类B的一个实例关联。例如一个手牌实例和多个牌实例关联。 属性 属性是对象的逻辑数组。例如牌含有点数牌面数值。 在领域模型里的属性应该是简单的数据类型通过关联来表示概念类之间的关系而不是属性。 导出属性 例如Hand的value可以从Card的信息里推导处来。在属性名加/来表示 属性的表示方法 可见性符号 属性名称属性类型[默认值]可选 可见性符号 公共属性 -私有属性 #保护属性 ~包属性 21点游戏概念图
系统序列图 系统序列图是用来表示外部参与者到系统相关的io事件。他是操作契约和对象设计的输入。对于用例的一个特定场景外部参与者产生的事件其顺序和系统之内的事件。所以系统被视为黑盒系统序列图强调的是从参与者到系统的跨越系统边界的事件。 为什么使用系统序列图 系统需要处理和响应来自参与者的外部事件时间事件错误和异常因此需要准确的知道什么是外部输入的事件即系统事件。这些事件是系统分析的重要部分。在对软件应该将如何工作进行详细设计之前我们系统的行为作为黑盒来调查和定义。将用例隐含的交互可视化。 系统行为描述系统做什么而不是解释如何去做。 交互图
交互图可以用来动态对象建模他有2种类型序列图和通信图。在画交互图的时候考虑和决定职责的分配。 什么是动态对象建模 在设计对象的过程里需要哪些对象他们如何通过消息和方法进行协作在画交互图的过程中把对象之间的协作方式确定下来。动态对象建模有助于设计逻辑和代码的行为。 序列图以一种栅栏格式描述交互在右侧添加新创建的对象。使用序列图可以方便的表达调用流的顺序只需要从上到下阅读即可。 使用生命线表示参与者。 消息在垂直的生命线之间用带实心箭头的实线并附加消息表达式的方式表示对象之间的每个消息。 消息表达式的语法return message(parameter:parameterType:returnType),没有参数时可以省略括号。例如size getDeckSize() 在序列图里的图形框图形框包含下列操作符 alt 选择性片段表示有互斥条件的消息 loop 表示消息为真时的循环片段 opt 当消息为真时执行的片段 par 并行执行的消息片段 通信图以图或者网络格式描述对象的交互其中对象可以置于图中的任何位置。
类图
类图表示类接口及其关联。类图用于静态对象建模。与领域模型相比类图增加了属性的类型和方法。setget方法通常省略不表。 常见类之间的关系如下所示 泛化(继承)关系用由子类到超类的实线和空心三角箭头表示。 依赖关系用从客户到提供者的虚线箭头表示。 什么时候表示依赖关系 使用依赖线描述对象之间的参数变量局部变量和静态方法的依赖。 组合关系表示整体和部分的组成关系。例如房间必须有门和窗户组成。用带有实心菱形箭头的关联线来表示。 基于职责驱动设计
基于职责驱动设计(RDD)的内在含义是考虑怎样给协作中的对象分配职责、角色和协作。在RDD里认为对象具有职责即对其所作所为的抽象。 职责分为2种类型行为和认知 对象的行为职责 自身执行一些行为例如创建对象或者计算。 初始化其他对象中的操作。 控制和协调其他对象中的活动。 例如庄家负责有洗牌的职责。 对象的认知职责 对私有封装数据的认知。 对相关对象的认知 对其能够导出或计算的事物的认知。 手牌负责认知牌的总点数。 职责的粒度大粒度职责具有数百个类和方法。例如DataSource的职责可能涉及系统中几百个类和几千方法。小粒度职责可能只是一个方法。例如创建牌的职责可能只涉及一个类中的一个方法。 职责是一种抽象方法实现职责。职责借助与方法实现这个方法可以独立完成也可以与其他方法和对象协作完成。例如庄家类定义方法来洗牌也可以将洗牌操作通知一幅牌来完成。 RDD把软件对象想成具有某种职责的人他可以自己独立完成工作也可以和同事分工合作一起完成工作。RDD使我们把面向对象的设计看作是有职责对象进行协作的共同体。
GRASP
GRASP是通用职责分配软件模式General Responsibility Assignment Software Patterns。他是一种学习工具能够帮助开发人员理解基本对象的设计并且以一种系统的合理的可以解释的方式运用设计推理。 GRASP有9个模式 创建者 控制器 纯虚构 信息专家 高内聚 低耦合 间接性 多态性 保护变化 创建者 谁负责创建类的新实例 如果以下的条件为真(越多越好)则将创建类A的实例的职责分配给类B B包含或者组成A B记录A B使用A B具有A的初始化数据并且在创建A时会将这些数据传递给A。 例如在21点游戏里一副牌负责创建牌对象。
信息专家 给对象分配职责的基本原则是什么 把职责分配给具有完成这个职责所需要信息的那个类。 信息专家是最基本的职责分配原则之一。履行职责需要满足完成职责所需要信息即关于其他对象的信息对象自身的状态对象周围的环境对象能够推导出的信息等。信息专家支持低耦合信息专家使我们寻找到的对象具有职责所需要的大部分信息并且把职责分配给这个对象。如果我们职责分配给其他对象那么总体的耦合度就会增高因为存在更多的信息被某些事物所分享而且这些事物远离信息源。例如玩家需要知道手牌的点数是多少那么把计算总点数的职责交给手牌因为手牌拥有牌的集合信息。 如果有多个局部信息对象有待选择的时候将职责赋予具有支配作用的信息专家即持有主要信息的对象这样有助于保持低耦合。 当存在多个选择时考虑每个选择对耦合和内聚的影响由此选择最佳方案。 如果还是无法选出则要考虑软件对象在未来可能的进化以及信息专家耦合和内聚的影响。
低耦合 如何减少因为变化产生的影响降低依赖和提高可重用性 分配职责使耦合保持在较低水平。低耦合是一个需要不断考虑的基本原则。我们使用低耦合来评价现有设计和新的可选方案之间作出选择应该首选耦合度更低的方案。 什么是耦合 耦合是元素与其他元素的连接感知以及依赖的程度的度量。具有低耦合的类不会过度的依赖其他的类。如果存在耦合关系那么当被依赖的元素发生变化时则依赖者也会受到影响。对象之间适当的耦合对系统来说正常和必要的其中的任务是通过被连接对象之间的协作来完成。例如子类和父类就是强耦合关系。高耦合对于稳定和普遍使用的元素不是问题例如Java程序可以安全和Java类库耦合因为Java库是稳定普遍使用的。高耦合本身不是问题问题是与某些不稳定的元素之间的耦合例如不稳定接口和实现。我们需要关注实际当中极其不稳定或需求经常发生变化的地方。 为什么要使用低耦合 因为低耦合能够减少修改软件所需要的时间工作量和缺陷。
高内聚 怎样保持对象是有重点或者聚焦可以理解可管理的并且能够支持低耦合 内聚是指功能内聚是对元素职责的相关性和集中度的度量。分配职责时保持较高的内聚性。内聚性较低的类需要做许多不相关的工作或者需要完成大量工作。这样的类是不合理的他们是难以理解难以复用难以维护的也是脆弱的经常会收到变化的影响。低内聚表示了大粒度的抽象或者承担了本应该委托给其他对象的职责。高内聚是一个需要不断考虑的基本原则。例如一个人承担了太多的不相关的工作特别是应该委托给别人的工作那么这个人一定没有很高的工作效率。
控制器 在UI层之上首先接收和控制系统的操作对象是什么 把职责分配给下列对象 代表全部系统根对象运行软件设备或者主要子系统。例如外观模式。 代表发生系统操作的用例场景。例如springMVC里controller用来接收请求和返回响应。从请求里获取信息封装成pojo,然后把工作委托给业务层再把业务层的处理结果放入响应里。 控制器自己不完成工作把系统操作的职责委托给应用层或者领域层中的对象。控制器增加可复用和可插拔的能力。UI层不处理系统操作只是把事件委托给其他层处理。
多态性 如何处理基于类型的选择如何创建可插拔的软件组件 基于类型的选择条件变化是程序的一个基本主题。如果使用if-else或者case语句的条件逻辑来设计程序那么当出现新的变化时就需要修改这些条件逻辑。这种方法很难扩展新变化的程序因为需要修改多个地方。 可插拔软件构件客户-服务器关系里的可视化组件如何才能替换服务组件而不会对客户端产生影响 当选择或者行为随着类型有所不同时使用多态操作为变化的行为的类分配职责。不要测试对象的类型也不要使用条件逻辑来执行基于类型的不同选择。这样可以易于增加新变化所需的扩展无需影响客户便能够引入新的实现。
纯虚构 当你并不想违背高内聚和低耦合或者其他目标但是基于信息专家所提供的方案又不合适时哪些对象应该承担这样的职责 面向对象设计有时被描述为实现软件类使其表示真实世界问题领域的概念以降低表示差异例如玩家和庄家然而在很多情况下只对领域对象分配职责会导致不良内聚或者耦合或者降低复用能力。 用人为制造出来的类给他分配一组高内聚的职责该类并不表示问题领域的概念他是虚构的事物用来支持高内聚低耦合和复用。例如userDao对象用来和数据库交互查询和保存对象。这样的对象是无法再领域模型里找到这个名称或者持久性存储的概念。他是为了软件开发而创造出来的概念。 纯虚构通常基于相关功能性进行划分因为这是一种以功能或者行为为中心的对象。例如适配器命令策略等模式。
间接性 为了避免多个事务之间的直接耦合应该如何分配职责如何使对象解耦以支持低耦合并且提高复用潜力 将职责分配给中介对象使其作为其他构建或服务之间的媒介以避免他们之间的直接耦合。中介实现了其他构件之间的间接性。计算机科学里的大多数问题都可以通过增加一层间接性来解决。例如适配器外观观察者模式。
保护变化(protected variations) 怎么样设计对象、系统和子系统使他的内部的变化不会对其他元素产生不良影响 找出或识别出预期的变化然后在这些变化之外通过分配职责来创建稳定的接口。也就是说把程序中不稳定部分的程序包裹在接口内利用多态来产生此一接口的不同实现。 例如数据封装接口多态间接性模型视图分离原则观察者模式这些技巧都是用来保护变化。
常见设计原则
模型-视图分离原则 模型对象不应该直接与视图对象交互。
模块化设计 模块化是将系统分解为一组内聚的松耦合的模块的特性也就是说通过创建高内聚低耦合的的方法和类来实现模块化。
命令-查询分离原则 一个方法不能同时属于以下2种类型 执行动作的命令方法具有改变对象状态的副作用并且是没有返回值的。 查询数据的方法没有副作用不会改变任何对象的状态。
面向对象的设计涉及一系列柔性原则自由度很大这反应了设计工作的复杂性。在设计过程里并行和互补地创建动态和静态对象模型也就是说同时绘制序列图和类图来反应设计决策。并且在绘制过过程中运用GRASP模式和设计模式。所有的设计工具和模式都是可选的根据需要自行选择。最好的软件开发工具是受过良好设计原则训练的思维。
