网站推广优化软件可以带锚文本的网站

当前位置： 首页 > news >正文

网站推广优化软件,可以带锚文本的网站,wordpress百度xml地图,家装设计图片面向对象方法分为面向对象分析#xff08;OOA#xff09;、面向对象设计#xff08;OOD#xff09;、面向对象编程#xff08;OOP#xff09;#xff0c;本文详细介绍面向对象分析 本文参考教材#xff1a;沈备军老师的《软件工程原理》大多图片来源其中 目录 面向对…面向对象方法分为面向对象分析OOA、面向对象设计OOD、面向对象编程OOP本文详细介绍面向对象分析 本文参考教材沈备军老师的《软件工程原理》大多图片来源其中 目录 面向对象基础 用例图 活动图 类图 时序图 通信图 包图 分析建模五大步骤 用例建模 执行者的识别 用例的识别 用例图设计 用例规约的设计 活动图的设计 建立概念模型 用例实现的识别 分析类的识别 识别边界类 识别控制类 识别实体类 用例分析 面向对象基础 抽象将事物的共性特征提取出来形成抽象类或接口以便让其他类通过继承或实现来共享这些特征 封装将对象特征的实现方式隐藏在一个公共接口后面的黑盒子中 模块化将一个大型系统划分为相互独立的小块或模块的过程。每个模块都负责一个明确定义的功能且与其他模块尽可能独立 层次化将系统的组成部分按照不同的层次或级别进行组织和划分的过程。通常一个系统可以分解为若干层每一层都有特定的责任和功能 对象是具有相同状态属性的一组操作的集合、是对问题域中某个东西的抽象对象的优点包括以数据为中心、实现了数据封装、具有并行性、模块独立性好 类类是对具有相同属性和行为的一个或多个对象的描述。类是支持继承的抽象数据类型而对象就是类的实例 实例由某个特定的类所描述的一个具体的对象当使用“对象”这个术语时既可以指一个具体的对象也可以泛指一般的对象但是当使用“实例”这个术语时必然是指一个具体的对象 方法是对象所能执行的操作也就是类中所定义的服务。方法描述了对象执行操作的算法响应消息的方法。在C语言中把方法称为成员函数 属性是类中所定义的数据类的每个实例都有自己特有的属性值 继承能够直接获得已有的性质和特征而不必重复定义它们。继承是子类自动地共享基类中定义的数据和方法的机制 多态性子类对象可以像父类对象那样使用同样的消息既可以发送给父类对象也可以发送给子类对象。根据该对象所属于的类动态选用在该类中定义的实现算法。在C语言中多态性是通过虚拟函数或者函数重载来实现的 重载共有两种函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字运算符重载是指同一个运算符可以施加于不同类型的操作数上面 用例图 UML中的用例图是一种描述待建软件系统的上下文范围以及它提供的功能的概览视图它从“黑盒”的角度描述了谁或什么与系统交互外部世界希望系统做些什么下面描述了4S系统中整车销售的功能 通过这个图看出用例图的组成要素如下 执行者是与系统交互的实体可以是人、其它外界的硬件设备或系统执行者应该位于系统外 用例代表了执行者希望系统为他们做什么用椭圆表示 关系包括执行者和用例间的关系、用例和用例间的关系以及执行者和执行者间的关系。执行者和用例的关系叫做关联用例和用例的关系有三种包含、扩展、泛化执行者和执行者的关系也只有一种叫做泛化 活动图 UML中的活动图用于刻画一个系统或子系统的工作流程也可用于描述用例内部的事件流提供了活动流程的可视化描述 通过这个图看出活动图的组成要素如下 动作是行为的基本单元一个活动可包含多个动作用圆角矩形表示 控制流用来表示从一个动作到另一个动作的控制用一条带箭头的直线表示 初始节点是活动开始的节点用一个实心圆表示 终止节点是活动结束的结点可细分为活动终止和流终止分别用带十字叉的圆和带边框的实心圆表示 分叉节点、汇合节点用于表示并发流用一条水平或垂直粗线来表示分叉节点表示并发流程的开始汇合节点表示并发流程的结束图中“财务经理审批”或者“销售经理审批”是两个并发活动 判断节点用菱形符号表示一个判断节点可以有一个进入流和多个离去流 合并节点用菱形符号表示一个合并节点可以有多个进入流和一个离去流如果一个合并节点接收到多个流它的离去流指向的动作会被执行多次 对象节点是动作处理的数据用矩形表示 泳道可以看作是活动图的分区它将活动图分为若干水平的区域每个区域代表一个参与者、角色或系统部分。泳道的目的是清晰地表示哪些元素由哪些参与者执行从而更好地理解系统中的活动流程用泳道实现分组使得每个参与者都明确了自己的责任 类图 在UML中类的表示为一个矩形分为三个区域从上到下分别是类名、属性和操作对于一个类的属性和操作有着不同的可见性类型 继承/泛化 在UML中类之间的泛化关系用带空心三角形的实现来表示比如下面这个图Car继承了车Vehicle为单重继承RV继承了Vehicle和House属于多重继承 关联 两个相对独立的类当一个类的实例与另外一个类的特定实例存在固定关系时这两个类之间就存在关联关系在UML中类之间的关联关系用实线箭头来表示比如下图中车和人之间存在关联即人是车的主人 关联的两个连接点称为关联端在关联端可以设置名字、可见性和基数等特性 基数表明这一段的类最多有几个实例其中人针对车的角色名是主人两端的基数是1对多这表明1个人可能有几辆车也可能没有车1辆车只能有1个主人 下面是一些基数的表示方法 聚合和组合 聚合和组合是一种特殊的关联表示部分和整体关系的关联。在UML中用带有空菱形的实线表示空菱形要和聚合类相连接。组合类似于聚合两者区别为 发生聚合关系的两个类独立存在组合中当整体消亡部分亦消亡 比如上面这个例子Trailer拖车和卡车是组合关系当卡车没有的时候推车失去了意义。但车和车队是聚合关系当某辆车离开车队的时候这辆车依然可以在街上行驶 上述几个关系综合起来 除此之外其实还有一些其它关系如依赖、接口、实现等但由于不太常用暂时就不叙述了如果有机会以后会直接在这里补充 时序图 时序图又称序列图它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作以二维图的形式刻画垂直维是时间水平维是角色表示参与交互的对象。 每个角色有一个名称和生命线生命线用垂直虚线表示表示整个交互过程中对象的声明期在对象发送或接受消息时生命线变成粗实线 在传递消息的过程中消息总共分为三种同步消息、异步消息和返回消息 同步消息用带实心箭头的实线表示发出一个同步消息之后就开始等待直到接收到返回消息返回消息用带空箭头的虚线表示 异步消息用带空箭头的实线表示对于异步消息而言发出去之后无需等待 下面是一个例子 我们可以看出一个个紫框圈住的就是一对对同步消息和返回消息对哪个角色发送信息就必须从哪个角色中接收到返回的信息 看到上面的图之后发现了一些奇怪的东西就是一个又一个带标签的方框像loop、alt、ref这种这是什么意思呢 实际上这叫做序列片段Fragment可以用来简化时序图分为四种 交互使用用于复用已定义的一个交互场景它表现为一个带有ref标签的框如图在对象order被创建后就执行在已定义的get existing customer status时序图中定义的消息序列 循环一个带有loop的框由条件[get next item]控制执行依次处理订单中的每一项内容 条件可以有两个或多个分支表现为一个带alt的框如图在发送同步消息reserve后会根据库存情况返回accept or reject 并发可以有两个或多个并发执行的序列片段表现为一个带有par标签的框 通信图 时序图主要用于描述对象之间的交互顺序和时间关系强调消息的发送时间和接收时间的顺序而通信图则主要用于描述对象之间的协作关系强调消息的发送和接收顺序强调每个参与者间的角色和职责 当两个对象对应的类存在关联关系时对象之间则存在一条通信路径称为链接Link信息的传递必须依附这种链接 上述时序图转换成通信图如下所示 这个内容暂时就说这么多如果想要扩充对于通信图的知识可以传送到下面这个大佬的文章 UML回顾-通信图csdn作者zhuojialin 包图 当一个软件系统的规模过大需要使用到一个叫做“包图”的东西 想象你在电脑上有一堆文件这些文件按照功能和类型分门别类放在不同的文件夹里。UML 包图就是用来展示软件系统中类似文件夹结构的设计。每个“包”就像一个文件夹里面装着相关联的软件元素。 这些包之间可以有不同的关系 依赖关系 一个包可以依赖于另一个包表示它需要使用那个包里的内容。 关联关系 两个包之间可能有关联意味着它们之间有某种连接或者合作关系。 包含关系 一个包可以包含其他包就像一个文件夹里可以有另一个文件夹一样。 以下是4S系统的包图 分析建模五大步骤 上面讲解的是面向对象分析建模的预备知识下面开始从前到后地讲解建模的每个步骤 注意第四步和第五步是需要针对每个用例循环实现 用例建模 分析建模的第一步是建立系统的用例模型其关键是通过对项目干系人需求的详细分析识别出待开发软件系统的执行者和用例画出用例图并针对每个用例写出详细的用例规约 执行者的识别 所谓执行者是为了完成一个事件而与系统交互的外部事物 识别执行者可以向自己提问以下问题 谁需要在系统的帮助下完成自己的任务 需要谁去执行系统的核心功能 需要谁去完成系统的管理和维护 系统是否需要和外界的硬件或软件系统进行交互 比如说对于4S系统通过上述方法可以识别的执行者如下总经理、店长、系统管理员、财务人员、销售经理、销售员、维修经理、维修员、采购经理、采购员、仓库管理员、运输员、质检员、人事管理系统 用例的识别 所谓用例是系统执行的一个动作序列这些动作必须对某个特定的执行者产生可观测的、有价值的结果 识别用例可以向自己提问以下问题 actor希望系统提供什么功能 actor 将创建、存取、修改和删除数据吗 actor是否要告诉系统外界的事件 actor 需要被告知系统中的发生事件吗? 例如4S系统的用例可能包括以下内容 用例图设计 用于4S系统的规模很大我们使用“包”来管理用例将用例分组到不同的包中画出包图如下 然后我们以“整车销售”这个包为例设计用例图如下 下面是我们用visio设计的“小米便签”系统的用例图 用例规约的设计 用例规约是一种文档它描述了系统中一个或多个用例用户场景或功能需求的详细行为和交互。它为开发团队提供了有关系统如何响应各种输入和情境的具体指导。 它主要由以下元素构成用例编号、用例名称、描述、执行者、前置条件、后置条件、基本流、备选流、扩展点、非功能需求、业务规划 下面对上面部分元素做出解释 前置条件在执行某个特定操作或场景之前系统或用户必须满足的条件或状态。 例子 在登录系统之前用户必须输入正确的用户名和密码。后置条件在执行操作或场景后系统或用户可以期望的状态或结果。 例子 在成功提交订单后用户应该收到一份确认电子邮件。基本流描述了正常情况下系统或用户如何执行特定用例的步骤。 例子 用户登录系统浏览产品将产品添加到购物车进行结账。备选流 描述了在执行用例时可能发生的非正常或例外情况下的步骤。 例子 用户尝试登录时输入了错误的密码系统显示错误消息。扩展点 描述了在执行用例时可能触发的其他功能或场景。 例子 在购物车中用户可以选择使用优惠券触发了一个扩展点。非功能需求不涉及具体功能而是描述系统性能、安全性、可用性等方面的需求。 例子 系统应该能够处理每秒1000个并发用户请求。业务规划描述了与用例相关的业务目标、战略或计划。 例子 提供在线客户支持是公司业务规划的一部分因此相关用例规约可能包括与在线聊天相关的行为。 下面是“提交购物订单”的用例规约 活动图的设计 “提交购物订单”的活动图设计如下 建立概念模型 分析建模的第二步是确定拟建系统必须处理的核心概念类并识别这些类之间的关系画出类图 概念类是那些能够始终贯穿分析和设计过程的类往往对应重要的实体信息识别概念类通常采用的方法是对相关的用例规约进行名词提取和过滤法对其事件流进行分析 比如对于上述那个用例规约的基本流 删除冗余名词、删除执行者和系统本身、删除属于边界类和界面的元素、删除类的属性最后得到六个概念类——订单Order、购车订单CarOrder、顾客Customer、订单CarOrderItem、品牌Brand、型号Model 找到上面概念类之间的关系画出类图 用例实现的识别 分析建模的第三步是识别“用例实现Use Case Realization”它有助于将系统的用例Use Cases转化为更具体的设计和实现。这一步骤主要集中在如何实现用例中定义的功能将用例转换为类、对象以及它们之间的关系 一个具体的“用例实现”提供了一个场所主要包括以用例事件为线索的动态视图和静态视图 动态视图是直接对应用例事件流的动态交互图通信图和时序图 静态视图是类图 用例与“用例实现”间的关系是实现Realize即依赖关系在4S系统的分析建模过程中采用一对一的用例实现识别策略即一个用例对应一个用例实现 在识别用例实现之后就要进入最后两步对于最后两步是对每个用例循环实现的 分析类的识别 作为分析建模的第四步分析类的识别是系统从纯粹说明所需行为向具体描述系统工作方式转换的过程中的关键一步 对分析类进行设计可以使用MVC设计模式分别对应了系统的3个维度 MModel系统要记录和维护的信息对应实体类 VView系统和外部环境之间交互的边界对应边界类 CControl系统在运行中的控制逻辑对应控制类 识别边界类 一个系统主要有三种边界类用户界面类、系统接口类比如ATM和银行会计系统的接口、设备接口类比如打印机接口、传感器接口 识别规则是执行者和用例之间的一条通信关联对应的一个边界类 若执行者是用户则所识别的边界类是用户界面类 若执行者是外界系统则所识别的边界类是系统接口类 若执行者是硬件设备则边界类是设备接口类 对于4S系统的“提交购车订单UCR”从用例图可以识别出一个用户界面类“CreateCarOrderForm” 还比如在图书馆管理系统中UIController用户界面控制器类可能是一个边界类处理用户输入和显示输出 识别控制类 控制类负责协调系统中的各个部分通常包含系统中的业务逻辑或流程控制不直接处理数据而是调度实体类和边界类之间的交互 例子在图书馆管理系统中LoanManager借书管理器类可能是一个控制类负责协调借书和还书的流程 对于4S系统的“提交购车订单UCR”从用例图可以识别出一个控制类“CreateCarOrderController” 识别实体类 实体类代表系统中的数据或信息通常与问题领域中的实际概念相对应包含属性这些属性描述了实体的特征实体类的对象通常具有唯一的标识符 通常可以从概念模型、术语表、业务领域模型、用例的文字描述中可以找到实体类 例如在图书馆管理系统中Book书籍类就是一个实体类它可能有属性如书名、作者、出版日期等 对于4S系统的“提交购车订单UCR”从用例图可以识别出6个实体类订单Order、购车订单CarOrder、顾客Customer、订单项CarOrderItem、品牌Brand、型号Model 找到上面三种分析类之后设计出分析类图如下 用例分析 分析建模的第五步是对拟建系统进行用例分析针对每个用例实现以用例作为研究对象用分析类的实例作为载体通过消息传递的方式实现对用例场景的分析构建出相应的时序图、通信图和类图 用例的事件流中包含多个事件序列其中有一个基本事件序列和若干备选事件序列通常先绘制时序图在对象之间用消息传递的方式把事件序列的内容复述出来。描述分析类实例之间的消息传递过程就是将职责分配到分析类的过程 通信图和时序图在本质内容上是等价的可以利用建模工具从时序图自动生成相应的通信图 交互图时序图、通信图表达了“用例实现”的动态行为而类图刻画了用例实现的静态特性。用例实现中的类图又称为VOPC类图即参与协作完成该用例实现的分析类所组成的视图根据用例实现中的时序图或通信图就可以获得全部或大部分VOPC的类 一个典型的动态向静态映射的过程可以通过通信图中对象间的连接关系向分析类之间的关联关系的映射实现 依然是在4S系统的“提交购车订单UCR”用例实现中根据其通信图对先前的分析类图进行完善建立分析类间的关联关系形成VOPC类图如下 最后的最后就是分别确定上述每个分析类的职责和属性其实就是一个类中的“函数”和“变量”比如CarOrder这个分析类完善之后的分析类如下所示