• 自动秒收录
  • 软件:1973
  • 资讯:58004|
  • 收录网站:278291|

IT精英团

打开需求之门3354用例图绘制指南

打开需求之门3354用例图绘制指南

浏览次数:
评论次数:
编辑: 温瑜
信息来源: ITPUB
更新日期: 2022-09-24 01:09:37
摘要

1.前言1.1.简介使用UML绘制用例图是表现系统需求的一种方式,是分析获取需求的一种有效手段。用例图是了解系统的第一个关口,通过用例图可以知道系统有哪些角色,这角色通过系统能做什么事情。在用例图中,

  • 正文开始
  • 相关阅读
  • 推荐作品

00-1010-

1.前言

用UML绘制用例图是表达系统需求的一种方式,也是分析获取需求.的有效手段用例图是理解系统的第一道关口。在用例图中,通过用例图可以知道系统有哪些角色,这角色通过系统能做什么事情。将展示参与者、功能模块和系统的基本流程。从客户的角度来看,用例图是他们业务领域的逻辑表达;从软件供应商的角度来看,用例图是系统蓝图和开发的基础,说明用例图在软件生产过程中起到了很好的承上启下的作用。虽然它通常不会显示细节,但它是沟通复杂想法的好方法。

1.1.简介

1.2.主要元素

1.3.元素符号

本文有望成为实用指南,其目的是帮助初学者,快速掌握用例图的基础知识和绘制方法,以便于用于实践中,在实践中不断的感悟.另一个目的是做一个查阅手册.如果你在实际工作中遇到一些模糊的地方,可以通过本文快速查阅和复习知识点,以便解决实际问题。接下来,本文将逐一解释用例图的主要元素。在解释每个元素时,会将理论与实例并行使用,以加深对使用场景中每个元素概念的理解。

00-1010

1.4.目的

在UML的用例图中,我们通常将系统边界视为我们构建的软件系统。可以是网站、软件组件、业务流程、App等应用,也可以是你想开发的任何东西。作为用例图中的一个元素,系统边界可以用一个矩形,来表示,它的名字位于矩形的顶部。系统的边界使用矩形元素,实际上只是一种表示,在某些应用场景下甚至是看不到的。从概念上讲,它属于一种分析方法,通过边界可以决定看待系统的抽象层次和视角,进而排除边界外大量的杂音来降低复杂程度,从而界定系统的范围,知道系统能干什么,系统不能干什么。.

确定一个边界,就像你决定用什么方式引入某个东西一样。人体大约有315个器官。不设界限,引入器官时就会杂乱无章,无拘无束。在介绍内脏器官(心、肝)时,我们跳到介绍外器官(耳、鼻)。说到底,听你说话的人根本不知道你在说什么重点。所以我们需要通过设置边界,把我们说的东西定义在同一个域内,东西的粒度要保持体积不变。让我们回到人体器官。如果设定的边界是内脏,我们的视角此时一定在身体内部。从抽象出来的所有东西都属于同样大小的器官(心脏、肝脏、肺等。)在边界内;如果设定的边界是一个外部器官,那么我们的视角一定在身体之外,抽象出来的一切都属于同粒度的器官(眼、耳、鼻、口等。)在边界内;

没有边界的地方将会是混沌的,举例说,如果你去一所学校找一个人,如果学校没有设定界限,那么找一个人就像大海捞针,因为每个人都是交织在一起的。如果学校按照不同的领域设定界限,那么学校内部就会被规划成教室、办公室、图书馆等等。这个时候,你不会在茫茫人海中找人,但是你可以有针对性的找人。比如学生可以去教室,老师可以去办公室。一个全新的软件项目对我们来说也是混乱的,我们需要设定界限,从混乱走向清晰。

一般来说,划分边界会影响到我们观察的事物,决定了抽象的层次和视角,这样可以保持分析事物的粒度一致,使系统的范围更加清晰。边界和面向对象都是软件设计领域的内功,不能指望一蹴而就。我们应该先有一个初步的认识,然后在以后的实践中继续感受和学习。

00-1010本文用于解释用例图所使用的应用场景,该用例图来自人们每天通勤的自行车共享。本文将以自行车共享软件系统为例,绘制用例图。根据用例图中元素的使用特点,我会选择常用的功能(扫码用车、锁车、支付和押金退还)作为素材。在画之前,我希望你能对自行车共享中通勤的场景下定决心,这有助于你理解业务需求,以便我们画出相应的用例图。由于这是根据现实生活中已有的应用逆向推导相应用例图的情况,我们可以直接将共享单车的软件视为系统边界命名为“自行车共享骑行系统”。

c="https://image.z.itpub.net/zitpub.net/image/2022-09-23/GIF/4AD9514C9C25F749264213B765A6B2BD/4AD9514C9C25F749264213B765A6B2BD.gif">


3.参与者

3.1.概述

参与者在UML用例图中是由一个“火柴人”来表示。UML官方对其的定义是:“参与者是在系统之外与系统交互的某人或某事物”。参与者不是系统的组成部分,所以它处于系统的外部。参与者通常是一个使用系统的人,但有时也可以是一个外部系统或外部因素、时间等外部事物。参与者对系统有着明确的目标/愿望,并且希望通过与系统交互所产生的结果,可以它的实现目标/愿望。由于参与者必须与系统进行交互,因此可以从这个角度去分析获取那些候选的参与者。

具体来说,识别参与者可以参考以下几个思路:

  • 系统会被哪些部门使用。这些使用系统的部门用户,可以根据共同的职责提炼出一个参与者。
  • 谁向系统提供信息、使用或删除信息。对系统信息进行管理的人员也会作为参与者与系统交互。
  • 谁与系统的需求有关联。因关联被动参与到需求的事物,也可能会作为参与者使用到系统中的相关功能。
  • 谁对系统进行维护。日常的维护业务也需要参与者与系统进行交互来完成。
  • 与外部系统是否有交互。这些外部系统往往会成为参与者。
  • 时间参与者,如一些具备定时功能的组件,它会激活哪些系统定期的、自动执行的业务。

在参与者当中还会分为主要和次要的参与者,主要参与者是主动发起了对系统的使用,通常绘制在边界的左侧;次要参与者与系统的交互是被动的,通常绘制在边界的右侧。例如对于某公司的工资管理系统,公司财务负责人会主动发起工资的发放操作,但实际的资金转移需要银行来介入完成,这其中财务负责人就是主要参与者,而银行由于工资的发放从而介入系统的交互,所以银行属于次要参与者。

参与者代表的是特定类型,而不是代表的具体的人或物,参与者相当于根据人或物共同职责提炼出的某类角色。所以在为参与者命名时需要注意,不要定义为某个具体的人或物(张三、发财银行),而是应当定义具有代表性的名称(客户、银行)。

3.2.示例

当我们去分析一个系统时,不应直接从系统本身具备的功能开始思考,我们应当先思考系统会为谁提供哪些价值,有哪些参与者会与这个系统进行交互来实现目标,因为系统的价值就体现在为参与者实现目标上。对于本示例的“共享单车骑行系统”而言,它可以提供单车的使用为人们带来交通的便利。作为使用者,他能够通过系统得到单车的使用。在这个分析中,很明显,骑行者是对该系统有着明确目标的人,并且他属于系统外部。所以可以将骑行者定义为“共享单车骑行系统”的参与者。

为了引出主要和次要参与者的使用场景,我们来思考下退押金这个业务。共享单车公司通过缴纳押金的手段保证单车在一定程度的安全,作为骑行者而言,在没有单车使用需求的情况下,可以要求公司退押金。由于“共享单车骑行系统”中没有包含公司的资金业务,所以该系统想要实现骑行者退押金的目标,必须依靠公司另外的财务系统。当骑行者发起退押金的操作时,“共享单车骑行系统”会向外部的财务系统发送申请,押金最终会由财务系统打到骑行者的银行卡上。

对于这个退押金业务场景而言,骑行者是主动发起对系统的使用,而财务系统与系统的交互是被动的。只有骑行者做了一些事之后,财务系统才会参与到系统中来采取相应行动。综上所述,该业务其中的主要参与者是骑行者,次要参与者是财务系统。下面将这两个参与者补充到本示例的用例图中。


4.用例

4.1.概述

在系统的角度上看,用例是它对外向参与者提供的价值。在参与者的角度上看,用例是参与者对系统寄予的目标。参与者通过系统内部提供的用例与之交互,从而根据交互产生的结果达到参与者的目标。分析用例的主要作用是捕捉功能性需求,一个系统的功能性需求就是由参与者对系统各种各样的目标构成的,当全部参与者的所有目标,都能够通过系统提供的用例来达到时,那么这个系统就被确定下来了。用例的提出和定义都是从参与者的角度来考虑的,通过分析参与者使用系统实现的目标来获取相应的用例。

具体来说,识别用例的思路可以参考以下几点:

  • 参与者的日常工作处理的业务流程有哪些?可以从这些流程中概况出用例(流程处理什么事)。
  • 参与者在业务中承担哪些职责、起到什么作用?业务中承担的职责或起到的作用可能存在用例。
  • 参与者是否会生成、使用或删除与系统相关的信息?系统需要提供相应的用例给参与者进行管理和维护。
  • 参与者是否需要把外部变更通知给系统?通常系统的过程也需要用例支持。
  • 系统是否需要把内部事情通知给参与者?通知参与者的过程就是系统用例的行为。
  • 是否存在进行系统维护的用例?相关的维护用例也会在系统中存在。

确定了用例后就需要定义用例的名称,通常用例的名称的结果应该是:<状语>动词+<形容词>宾语。其中状语和形容词可以根据情况修饰,而动宾则是必须的主体结构。名称的结构也可以作为衡量用例准确性的标准,通常参与者和用例名称在一起是“主谓宾”的结构,例如会员订购商品。

在分析用例是还需要注意粒度的问题,应当避免出现以下几种过分细化的情况:

  • 不要把完成一个用例需要的步骤当成单个用例;
  • 不要把实现用例的手段分解成多个用例;
  • 不建议把常规维护性操作(增删改查)拆分成单个用例;

4.2.示例

在基本概述用例之后,接下来我们将针对本示例“共享单车骑行系统”的应用场景,分析并获取其中的用例。有效识别用例最基本的就是站在参与者的角度来考虑,你可以思考下你作为骑行者对一款“共享单车骑行系统”会有哪些期望或目标。

根据日常的使用场景并结合作为示例的素材考虑,骑行者比较普遍的目标一般包含:扫码用车、锁车、付款、退押金。另外需要强调的是,系统能够为参与者实现目标是系统的基本原则,参与者的目标也不能天马行空,参与者的目标应当是系统力所能及的,在系统边界内的。接下来,我们将以上提到的骑行者的目标作为用例,并将其补充到当前示例的用例图中。用例对应的符合是椭圆形,并且用例需要包含在系统边界的矩形之中。


5.关系

5.1.关联

在识别并绘制参与者和用例之后,在图中它们还处于相互独立的状态,实际上参与者和用例之间还存在着某种关系,称之为关联。这里的关联和类之间的关联有所不同,它表示参与者和用例之间存在信息交互,象征两者之间有基本的交流或者互动。关联采用一条“实线”表示,这条线可以在指向用例的方向带上箭头,也可以不带箭头。这个箭头并不代表数据流或业务流的方向,因为参与者和用例之间是双向交互信息的,所以这里的箭头表示由通信的主动方(参与者)启动被动方(用例)。为了避免箭头带来的逻辑混淆,建议不带箭头。

接下来,我们将针对“共享单车骑行系统”用例图中的参与者和用例,通过绘制实线建立关联关系。在绘制中请注意,在本文讲解参与者的段落中,关于退押金的业务场景,我们分析出了主要和次要的参与者。所以对于这个情况,次要的参与者(财务系统)也需要和参与的用例(退押金)建立关联关系。

请记住,所有的参与者,都必须至少与一个用例产生关联并与之交互,不存在没有参与者的用例,也不存在没有用例的参与者,否则请检查用例和参与者的分析结果。下面将本示例中参与者和用例之间的关联关系,将其补充到用例图中。

5.2.包含

简介:

包含关系提供了从多个用例中提取公共部分的能力,把公共部分作为单独的用例,系统可以通过包含关系对其进行引用。因此,包含关系的提出一般是基于用例行为复用的考虑,这意味着被包含的用例往往被多个基本用例引用。对其的使用标准总结为:如果在两个或更多的基本用例中存在类似的行为,并且这些类似的行为又可独立地构成一个用例,那么就可以把这些行为提炼出来构成一个被包含的用例。包含用例与衍生它的多个基本用例之间就属于包含关系,包含关系在用例图中的表示:使用一条带箭头的虚线,并在虚线附近加上<<include>>,箭头的方向由基本用例指向包含用例。

基用例和包含用例:

包含用例的执行并不是由参与者直接发起的,而是由基础用例执行时触发的,基本用例一旦执行,对应的包含用例就必须会执行。另外,基本用例想要完整的执行,就必须执行它所包含的用例。从这点可以看出,包含用例对基本用例而言相当于一种“必须品”,没有包含用例,基本用例是不完整的。而对于包含用例而言,如果没有基本用例,包含用例是不能单独存在的。两者的关系就像是“有你才有我”一样。

示例:

让我们回到“共享单车骑行系统”中来思考其中是否存在包含关系。基于包含关系是对行为复用的考量,我发现可以在付款和退押金这个两个用例中,找到公共的部分,并且属于必须执行的行为。 付款时,系统必须会检查你上一次的付款情况,避免过度透支使用;退押金时,系统也会检查你的付款情况,避免出现错误的免单情况;因此,这两个用例中就可以抽取公共行为“检查未付款”,而这个公共行为即可构成一个单独的被包含用例。下面将用例补充到当前示例的用例图中,并建立包含关系。

5.3.扩展

简介

扩展表示的意思是:在基本用例的基础上,思考基本用例在处理自身行为之外,还能做什么有易于业务需求的事情,如果存在,那么就把这个事情委托给其他用例(扩展用例),表示该事情被扩展了,以此在基本用例和扩展用例之间就形成了扩展关系。在扩展关系中,基本用例自身是独立完整的,不受扩展用例影响,不需要扩展用例也能够向参与者提供价值。但是扩展用例的存在将由基本用例决定。扩展关系在用例图中,是用一条带箭头的虚线并在线上加<<extend>>来表示的,箭头方向指向基本用例,表示扩展用例是根据基本用例进行扩展的。

扩展点

为了表面扩展用例在基本用例中是基于什么情况扩展的,需要在基本用例中定义扩展点,扩展用例只能在它与之对应的扩展点上进行扩展。扩展点是指在基本用例中定义的特定条件,每个扩展用例都至少与一个扩展点相关联。当基本用例满足扩展点的特定条件后,就会触发相应的扩展用例的执行,从而为基本用例提供附加行为。需要注意,有些工具可能在绘图上并不会将扩展点显示出来,但无论显示与否,只要存在扩展关系,基本用例中就存在与之对应的扩展点。

示例

我们将扩展关系的特点投射到本示例的“共享单车骑行系统”中来,思考分析下哪些用例可以进行扩展。我个人作为共享单车的常用者,我觉得每当骑行到达目的地离开单车后,总是会担心自己因为没有将单车锁上,导致无限扣费的情况。我觉得要是在锁车后要是能够向我发送一条确认信息,我将会安心许多。基于这个痛点,实际上我们可以在锁车的用例上进行扩展,扩展一个在锁车后向骑行者发送锁车消息的用例,并且发送锁车消息的扩展用例还不会影响到锁车,仅作为一个辅助性质。下面我们将这个扩展用例补充到示例的用例图中看看效果吧。

5.4.包含和扩展的对比

包含关系和扩展关系是在用例建模中比较常用的关系,也是初学者容易混淆的两种关系。从表面上来看,它们都是使用虚线箭头作为表达关系的符合,只是箭头方向和虚线上的标识不同而已。所以,如果我们想要清晰、正确的使用这两种关系,就必须通过对比分析,来理解这两种关系的使用场合和所解决的问题。下面通过表格对这两种关系进行了详细的对比,在实际应用中可以进行参考,并结合具体情况选择合适的关系。

5.5.用例的泛化

简介

泛化关系相当于面向对象三大特征之一的继承,该关系可以用于在用例之间或参与者之间。用例和参与者之间的泛化都表面了一种继承层次,通过继承层次,继承派生出的子项可以获得上层项中全部属性和行为,并参与上层项中的各种关系。因此,通过泛化关系可以在用例图中达到更大范围、高层次的需求复用。

在用例之间的泛化关系当中,父类称为泛化用例,子类被称为特化用例。泛化用例中描述通用行为,而在特化用例中继承这些通用行为,并在适当地方进行特化。在实际中,泛化用例往往作为抽象用例,这代表它不会产生任何具体的场景实例,仅作为抽象标准(类似接口),参与者只会通过执行特化用例来实现目标。

在实际中,包含关系在用例之间的关系中应用的最多,再者是继承关系,而泛化关系用的最少。因为对于客户而言,由于它们往往缺少面向对象的知识,所以难以理解其中的概念。如果仅仅为了将用例之间的可复用部分或用例的可扩展部分描述出来,那么使用包含关系和扩展关系就足够了,使用用例的泛化很可能增加用例图的理解成本。

示例

在本示例“共享单车骑行系统”中,我们可以发现付款用例实际上是很宽泛的,因为付款的方式有很多,可以是:账户余额、支付宝、微信、花呗等等方式。所以付款用例代表了一般情况,我们可以将其作为抽象用例,从它身上特化出具体的付款用例。泛化关系是用一条带空心箭头的直线表示的,箭头的方向由特化用例执行泛化用例。下面我们将这个用例的泛化补充到当前实例的用例图中。

5.6.参与者的泛化

在上文介绍用例泛化的基础上,在来介绍下参与者之间的泛化是如何运用的。与用例的泛化一样,参与者之间的泛化也是属于一种继承层次,同样是满足于更高层次的需求复用,只不过参与者的泛化在实际中使用的更多些。

我们针对本示例的“共享单车骑行系统”,思考这样一个情况:如果系统要在普通用户的基础上推出一个VIP用户,并且VIP用户具备普通用户所有的行为能力,那么在绘图时,VIP用户是不是要将普通用户的用例和关系都重复画一遍呢?如果是,那么后面如果有N个高层级用户加入,是不是都需要将普通用户所有的用例都要重复画一遍呢?显然这种重复性会让用例图的重复度和复杂度会大大提示,从而不堪入目。

对于上面的情况,就属于我们在参与者中使用泛化关系的场景。通过建立普通用户和VIP用户之间的泛化关系,VIP用户将基础普通用户的所有行为,所以在将VIP用户作为参与者绘制到图中时,就无需重复的绘制他和普通用户之间存在的共同用例和关系。

在实际的应用中,我们也应当对所有参与者进行共同性的分析,共同性体现为,多个参与者存在相同的用例。如果存在共同性,我们应当抽象出一个“父类”参与者,其参与者都直接或间接基础这个“父类”参与者。参与者之间的泛化关系也是使用带空心箭头的直线表示的,下面我们将VIP用户和它特有的用例补充到图中。


6.实践建议

  1. 在客户能准确全面的基础上,用例越精简越好。
  2. 用例应使用客户的语言,需保证客户能看懂,而不应参与技术性的描述。
  3. 在表达用例时要注意轻重之分,对于重点难点用例可通过注释加以详述,对于“常识”的用例则可简言。
  4. 用例的粒度应当在同一个系统边界中保持相同的体量。
  5. 不应盲目地从客户无边界的想法中直接获取用例,用例更多地是从客户对系统的目标中推导,且在系统边界之内。
  6. 用例图只是一种表现形式,掌握用例图所承载的需求分析方法才是关键。

7.结语

绘制用例图其实是件很容易的事情,只要你知道每个元素代表的符合,就能照葫芦画瓢的绘制出来。但是难点在于其中每个元素都蕴藏着很多复杂的概念,如识别参与者、分析系统边界、分析用例、定义关系等,这些往往是需要经过一定的系统学习和掌握其中的概念才能做好的事情。所以比起绘制方式而言,更重要的是分析能力和实践运用能力。

用例图的构建,对于获取需求而言,是非常有效的手段。而清晰明确的需求对于一个软件项目的重要性,毋庸置疑。所以学会用例图将会是你在获取需求道路上披荆斩棘的利器。

dotnet7 aot编译实战
« 上一篇 2022-09-24
  • dotnet7 aot编译实战
    0阅读 0条评论 个赞
    0起因#这段日子看到dotnet7-rc1发布,我对NativeAot功能比较感兴趣,如果aot成功,这意味了我们的dotnet程序在防破解的上直接指数级提高。我随手使用asp.netcore-7.……
  • 了解更多关于k8s中Pod的详细信息
    0阅读 0条评论 个赞
    k8s中Pod的理解基本概念k8s为什么使用Pod作为最小的管理单元如何使用Pod1、自主式Pod2、控制器管理的Pod静态PodPod的生命周期Pod如何直接暴露服务hostNetw……
  • 2流高手速成记(之二):跳羚之基础网开发
    0阅读 0条评论 个赞
    现在,我们已经能自行完成SpringBoot的初级项目搭建了,接下来看如何实现一些Web开发中的基础功能。先看项目完整的目录结构:1.返回Json数据创建model文件夹,并新建Person类,代码……
  • Lua脚本在Redis交易中的应用实践
    0阅读 0条评论 个赞
    使用过Redis事务的应该清楚,Redis事务实现是通过打包多条命令,单独的隔离操作,事务中的所有命令都会按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。事务中的命令要么全部……
  • IDEA远程部署项目到Docker
    0阅读 0条评论 个赞
    前言最近在写东西部署到服务器,结构是springboot工程配合docker部署。但是每次部署都3个步骤:本地构建jar复制jar到远程服务器用DockerFile构建镜像部署次数一多,我就怀疑人生了……
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
  • Hadoop JMX监控和预警
    0阅读 0条评论 个赞
    .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
  • 国产核心板全志T507助力消防系统升级
    8阅读 0条评论 个赞
    9月16日下午,位于湖南长沙市区内的中国电信大楼发生火灾,建筑高度218米,现场浓烟滚滚,数十层楼体燃烧剧烈。消防救援人员赶到现场后很快将火势控制住,目前大楼火势已被扑灭,所幸未发现人员伤亡。湖南电信……
  • sql server索引I摘要
    0阅读 0条评论 个赞
    一、存储结构在SQLServer中,有许多不同的可用排列规则选项。二进制:按字符的数字表示形式排序(ASCII码中,用数字32表示空格,用68表示字母"D")。因为所有内容都表示为数字,所以……
  • 前端必读:如何用JavaScript中的SpreadJS导入导出Excel文件
    0阅读 0条评论 个赞
    JavaScript在前端领域占据着绝对的统治地位,目前更是从浏览器到服务端,移动端,嵌入式,几乎所有的所有的应用领域都可以使用它。技术圈有一句很经典的话“凡是能用JavaScript实现的东西,最后……
  • springboot集成docsify实现可移植文档
    0阅读 0条评论 个赞
    需求分析文档可以和项目一起进行版本管理文档可以在线访问文档可以与springboot项目集成,不需要分开部署MarkDown支持文档跟随,打包jar也可以访问技术选型对于网上已有的方案,大致分为如下几……
  • 基于Flyway的数据库版本控制实践
    0阅读 0条评论 个赞
    背景大家平时在开发过程中,会用Git来进行我们的代码管理。如Git这些,使用这些版本控制系统能轻松的帮我们解决不同开发人员之间的代码冲突处理版本回退实现软件代码的CI/CD等那大家考虑过么,针对数据库……
  • c#异步高级————通道[1]
    0阅读 0条评论 个赞
    前言该系列为异步编程的进阶篇,其实也不能这么讲。世界上本没有进阶篇,只能说是高级篇(高级篇不能说多高级,是对底层的封装的意思),只要是加深理解都是进阶。本章先介绍一下channel。正文下面没什么好说……
  • [设计模式] Java设计模式-工厂模式
    9阅读 0条评论 个赞
    目录【设计模式】Java设计模式-工厂模式简介1、普通工厂(SimpleFactory)模式①、定义类②、定义简单的工厂类③、实例2、抽象工厂(AbstractFactory)模式①、定义类②、……
  • 面试官:谈谈你对mysql事务的认识?
    0阅读 0条评论 个赞
    引言今天回头继续讲讲数据库系列的文章。这篇文章属于mysql数据库系列,我们来谈谈事务方面的常见面试题。那么,具体题目有下面这些:1、讲讲为什么用事务?事务的四大特性?事务的隔离级别知道吧,你们生产……
  • k8s网络持久存储的StorageClass(如何一步步实现动态持久存储)
    0阅读 0条评论 个赞
    StorageClass的作用:创建pv时,先要创建各种固定大小的PV,而这些PV都是手动创建的,当业务量上来时,需要创建很多的PV,过程非常麻烦。而且开发人员在申请PVC资源时,还不一定有匹配条件的……
  • Java开发学习- SpringBoot快速入门和启动依赖分析
    0阅读 0条评论 个赞
    一、SpringBoot简介SpringBoot是由Pivotal团队提供的全新框架,其设计目的是用来简化Spring应用的初始搭建以及开发过程。使用了Spring框架后已经简化了我们的开发。而Spr……
  • 与docker卷一起安装的注意事项
    0阅读 0条评论 个赞
    目录Content使用数据卷(volume)使用挂载点(共享宿主目录,bindmount)目录兼容性可移植性目录替代相关指定位置--volume与--mount区别镜像保存docker-compos……
  • Sql Server系列:分区表操作
    0阅读 0条评论 个赞
    1.分区表简介分区表在逻辑上是一个表,而物理上是多个表。从用户角度来看,分区表和普通表是一样的。使用分区表的主要目的是为改善大型表以及具有多个访问模式的表的可伸缩性和可管理性。分区表是把数据……
  • MySQL查询性能优化指数下推的七大武器
    0阅读 0条评论 个赞
    前面已经讲了MySQL的其他查询性能优化方式,没看过可以去了解一下:MySQL查询性能优化七种武器之索引潜水MySQL查询性能优化七种武器之链路追踪今天要讲的是MySQL的另一种查询性能优化方式—索……
  • 举例说明库伯内特公司的豆荚核心资源
    3阅读 0条评论 个赞
    目录一、Pod定义二、Pod入门yaml描述文件三、共享NetworkNamespace四、共享PID五、容器生命周期六、初始化容器6.1、简介6.2、与普通容器的区别6.3、实验七、Pod探针7.1……
  • 如何在Ubuntu中保留文件系统并备份当前开发板镜像
    1阅读 0条评论 个赞
    在Ubuntu保留文件系统或者说备份当前开发板镜像的需求在不断增加。比如Ubuntu文件系统需要安装库文件的话直接使用apt-get工具就可以下载,但由于需要下载的核心板较多,比较费时间,这时需要将安……
  • 转:Java老了 科特林会取而代之吗?
    0阅读 0条评论 个赞
    .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
  • 企业操作和维护实践-丢弃docker构建
    15阅读 0条评论 个赞
    本章目录目录0x00前言简述快速介绍什么是Kaniko?为啥用Kaniko?Kaniko是如何工作的?Kaniko已知功能问题kaniko构建上下文kaniko缓存构建0x01部署使用环境……
  • Java接口自动测试框架系列(1)自动测试框架
    0阅读 0条评论 个赞
    一、什么是自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例一步步执行测试,得到实际结果与期望结果的比较。为了节省人力、……
  • 谈谈我是如何学习SQL Server的
    0阅读 0条评论 个赞
    谈谈我是如何学习SQLServer的相信很多人都想做大牛,但是你们知道这些大牛是怎样炼成的吗?我的一个同事做了差不多10年的.NET开发,算得上是大牛了吧?如果他遇到他熟悉的项目很快就能手到拿来,立……
最近发布资讯
更多