精华内容
下载资源
问答
  • 将图论中完整度的概念推广到组织网络中用以研究组织系统的核心元素,针对组织系统元素个数、元素间互动关系已知构成的连通组织网络图,在完整数给定的情况下,论证了组织网络图最小完整度的数目,给出了完整度最小组织...
  • UML核心元素

    千次阅读 2014-03-10 10:04:37
    捕获现实世界的需求的方法,一个系统由世界上的各种各样的愿望组成,如果要描述系统 的功能,就应该找到对这个系统愿望的人,让他们来说明他们会在这个系统里做什么事情,想要什么结果。如果所有对系统愿望的人...

    1.版型

    也称为类型,构造型。是对一个元素基础定义的扩展,在同一个元素基础定义的基础上赋予特别的含义,以适应特定场合。可自己根据项目需求定义。它只是UML的一种扩展手段。

    2.参与者

    准确定义参与者,是寻找抽象角度的开始,是系统之外与系统交互的人或事物。

    因此,寻找参与者可通过下面两点来找出参与者从而确定系统边界:

    a.谁对系统有着明确的目标和需求并且主动发出动作。

    b.系统为谁服务

    如何发现参与者:

    1>.涉众分析

    2>.客户的岗位设置

    3>.与客户代表访谈

    参与者的其他版型:

    业务主角,特别用于定义业务的参与者,在需求阶段使用。它的特殊性在于,它针对的是业务人员而非计算机用户。在查找业务主角是必须抛开计算机,没有计算机这些业务人员也客观存在,因为在初始需求阶段,我们需要获得的是客户的业务模型,根据业务模型才能建立计算机系统模型。如果在了解业务的阶段就引入计算机系统,会混淆现有业务和将来有计算机参与时的业务。切记:要建立一个客户需要的计算机系统,首要条件是彻底搞清楚客户的业务,而不是预先假设一个计算机系统,让客户假象该系统能帮客户做什么。

    业务主角非常重要,建立业务模型,查找业务用例,都必须使用业务主角。需求分析人员不能一开始就加入自己的主观判断,假设了业务在计算机里的实现方式,而没有真正去理解客户的实际业务。

    因此,在初始需求阶段,请必须使用业务主角。牢记业务主角是客户实际业务里的参与者,没有计算机系统,没有抽象的计算机角色。业务主角必须能在实际业务里找到对应的岗位或者人。如果你对业务主角不是那么自信,请回答以下几个问题:

    1.业务主角的名称是否是客户的业务术语

    2.业务主角的职责是否在客户的岗位手册里有对应的定义

    3.业务主角的业务用例是否都是客户的业务术语

    4.客户是否对业务主角能顺利理解

    业务工人

    在系统内,参与业务过程,其工作是完成主角的业务目标,因此不需要为他们建立业务模型,他们只在主角的业务模型中出现,他们经常出现的地方是领域模型和用例场景。

    涉众

    与系统有利益关系的,都是涉众,又叫干系人。

    用户

    系统的使用者,是参与者的代表,或者说是参与者的实例或代理

    角色

    参与者职责的抽象,从众多参与者的职责当中抽象出相同的那部分,并命名为角色。代表了系统中的一类职责,一般在概念阶段的模型里,以表达业务的逻辑理解。

    3.用例

    捕获现实世界的需求的方法,一个系统由世界上的各种各样的愿望组成,如果要描述系统 的功能,就应该找到对这个系统有愿望的人,让他们来说明他们会在这个系统里做什么事情,想要什么结果。如果所有对系统有愿望的人要做的事情都找全了。那这个系统的功能性就确定下来了。

    官方定义:用例定义了一组用例实例,其中每个实例都是系统所执行的一系列操作,这些操作可生成特定主角可观测的值。

    也就是说,用例其实是与参与者交互的,给参与者提供可观测的有意义的结果的一系列活动的集合。用例其实就是一件事情,要完成这件事情,要做一些列活动,而做一件事情又有不同的方法和步骤,也可能遇到各种意外的事情,这在UML中称之为场景,一个场景就是一个用例的实例。

    用例由参与者,前置条件,场景,后置条件构成。

    用例特征:

    相对独立,也就是说,他独立完成参与者的目的。

    执行结果对参与者来说是可观测的和有意义的。

    必须由参与者发起,不存在没有参与者的用例,用例不应该自动启动,也不应该主动启动另外一个用例。

    以动宾短语出现

    一个用例就是一个需求单元,分析单元,设计单元,开发单元,测试单元,部署单元

    用例以行业术语定义,不应该以计算机术语定义。

    用例粒度:

    在项目的不同阶段,使用不同的粒度。

    在业务建模阶段,用例能够说明一个完整的事情为宜。即一个用例可以描述一个完整的业务流程。也就是不需要详细到业务中的步骤。

    在业务分析阶段,即概念模型阶段,以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。

    在系统建模阶段,描述操作者与计算机的一次完整交互为宜。在RUP中,项目计划要依据系统模型编写,一个用例的开发工作量在一周左右。

    用例的粒度大小不是从用例包含的多少步骤来判定的。

    一般来说,一个系统的业务用例定义在10~50个之间。对粒度的选择本质上还是因为边界认定不停而造成的。因此首先要确定边界。

    用例的获取

    发现主角,然后对业务代表进行访谈,只针对他自己的本质工作来谈谈他的期望,千万不要涉及到业务细节,业务规则,业务流程,更不要让代表理解将来的计算机系统如何工作。

    千万不要把用例理解为功能的划分和描述。请注意,用例是捕获功能性需求的,但这个需求是从参与者角度出发的,用例并不是功能。

    从功能的角度出发,由于缺少上下文,采用功能分解的方式来获取需求,功能可能变成对使用者无用的,或者使用者不知道怎么用的东西。因此,从使用者的角度来描述软件,是非常合适的,使用者的观点实际上是用例的观点。

    也就是说,功能是脱离使用者愿望的,功能也是孤立的,有输入,固定输出,用例则是系统性的,该系统非常明确额去达成一个目标。

    用例粒度的误区

    产生这个误区的原因首先是分不清目标和步骤,用步骤划分用例会导致不准确的需求获取,分不清目标和步骤的另一个后果是用例的粒度过于细小,使得系统没有抽象的余地。

    另外一个误区是在同一个需求阶段的用例粒度大小不一。这个问题产生的本质是因为建模者心中没有一个清楚的边界,没有时时检查现阶段处于那个抽象层次而造成的。


    业务用例

    业务用例是专门用于需求阶段的业务建模的用例的版型,它面对的问题领域就是没有将来计算机系统参与的,目前客观存在的业务领域。相对的,它的参与者就是业务主角。站在业务主角的角度去看的边界是业务边界,而不是系统边界。业务范围也不等于系统范围。

    业务用例实现

    也称业务用例实例,专门用于需求阶段的业务建模,也是用例版型的一种,一个业务用例,可以有不同的实现方式,也就有了不同的业务用例实例。它表达了同一种业务的不同实现方式。

    概念用例

    用于概念建模,用来获取业务模型中的关键概念,分析出业务模型中的核心业务结构以得到一个易于理解的业务框架。它用来获取业务用例中的核心业务逻辑,这些核心逻辑揭示了业务模式,成为业务架构的重要指导。同时它还是从业务用例到系统用例过度时非常重要的指导。

    系统用例

    实际就是用例,用来定义系统范围,获取功能性需求的。也就是软件系统开发的全部范围,是我们得到的最终需求。


    4.业务实体

    是类的一种版型,特别用于在业务建模阶段建立领域模型,它代表业务角色执行业务用例时所处理的和所使用的“事物”。一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物。

    如何获取业务实体?

    首先,我们要建立业务用例场景,即参与者实现其业务目标的过程描述。从业务场景中每个过程的动词后面的名词,就是业务实体的备选对象。在经过筛选后,分析这些业务实体之间的关系,并决定哪些应该单独建模,哪些应该作为属性。通过得到的这些业务实体,代表了该业务场景中的关键概念,再进一步,如果为这些业务实体之间的关系建模,为他们的交互建模,就得到了该问题领域的领域模型。

    5.包

    分包的好坏,是由包之间的依赖关系来评判的,事实上,UML中包之间的关系,只有依赖关系,UML认为好的分包,必须是高内聚,低耦合的性质。尽量避免双向,循环依赖关系。

    包最主要的用途就是分类元素,常见的包的版型定义:

    领域包,子系统,组织结构,层


    6.分析类

    用于获取系统中的主要职责簇,代表系统的原型类,是系统必须处理的主要抽象概念的第一个关口。其实,分析类就是跨越需求到设计实现的桥梁。分析类,包含边界类,控制类,实体类。它是从业务需求到系统设计转换的主要元素,他们在高层次抽象出系统实现业务需求的原型,业务需求通过分析类逻辑化,被计算机所理解。虽然UP过程中,将分析类定义为一种 过度类型,而非强制过程,但建立花大量时间维护分析类。

    三高:

    高于设计实现,即在为需求考虑系统实现的时候,可以不理会复杂的设计要求,例如框架,设计模式的要求等。

    高于语言实现,即在为需求考虑系统实现的时候,可以不理会使用哪种语言实现。

    高于实现方式。即在为需求考虑系统实现的时候,可以不理会用哪种实现方式。

    边界类:用于对系统外部环境和其内部运作之间交互进行建模的类。任何两个有交互的关键对象都应该考虑边界类。常用场景:

    参与者与用例

    即用例提供给参与者的操作,可以用边界类。

    用例与用例之间的交互,为了防止耦合的发生,采用边界类来隔离这种直接访问。

    用例与系统之外非人对象的交互,例如第三方系统,应当为其建立边界类。

    在相关联的业务对象有明显的独立性要求,他们可能在各自的领域内发展和变化,但又不希望互相影响时,也应该为他们建立边界类。

    从架构角度讲,边界类主要位于展现层。

    一个好的边界类有如下特点:

    边界类应该有助于提高系统的可用性。

    边界类应该尽可能的保持在较高的层次上,如概念层次

    边界类应该合理封装介于系统与主角之间的交互。

    如果主角改变他们为系统提供输入的方式,边界类就应该是唯一需要改变的对象。

    如果系统改变他们为主角提供的输出的方式,边界类就应该是唯一需要改变的对象。

    边界类必须知道其他对象类型的需求,如实体对,控制对象,以便他们能够得以实施,并相对于系统内部元素保持其可用性和有效性。

    控制类

    从架构角度讲,控制类属于业务逻辑层,它用于对一个或多个用例特有的控制行为进行建模,控制对象通常控制其他对象,因此他们的行为有协调性。来源于对用例场景中行为的定义。

    实体类

    用于对必须存储的信息和相关行为建模的类,实体对象用于保存和更新一些现象的有关信息,例如事件,人员或者一些现实生活中的对象,实体类通常是永久性的,他们所具有的属性和关系是长期的,甚至维系在系统的整个生命周期。其源于业务实体。

    从架构角度讲,实体类属于数据持久层。

    以上可以看出,由于分析类的抽象层次高,概括能力强,也就比设计和实现要稳定。也不用投入太多的精力维护。

    7.设计类

    设计类已经直接映射到实现代码了,依赖于实施语言。用于设计模型中。由于设计类与实现语言有密切关系,因此设计类加上特定的版型,来说明该设计类对应的实现体。

    8.关系

    关联:一段时间内,多个类的实例链接在一起,通俗的讲,就表示一段时间内,一个对象知道另外一个对象。例如A对象保存了B对象的ID,表示A对象知道B对象。

    依赖:临时,同时,修改一个对象,会导致另外一个对象的修改。即,除了知道对象,还会使用其他对象的属性和方法。尽量避免双向依赖关系。

    扩展:用于用例模型中说明在基本用例中的某个扩展点插入扩展用例。即分支,它是可选的,而不是必需的。

              表明用例是系统可选的行为。

              特定条件下的执行分流

              根据基本用例与主角的交互插入的一组行为段。

              多个用例中都有可能触发一个可选的分支流。即可复用部分。

    包含:用于说明在执行基本用例的用例实现过程中插入的行为段。要注意的是,基本用例和包含用例都不能访问对方的属性。

    包含用例表示的是必需的,而非可选。

              对于基本用例不是必需的,只有执行结果才重要。

              分解出多个用例的共有行为

    实现:连接用例和用例实现

    精化:用例模型中,一个用例分解出许多更小的关键精华用例,更细致的展现了基本用例的核心业务。

    泛化:用于两个对象之间的继承关系。

    精化与泛化关系的区别:

    精化关系分解出的子对象,并不会改变和增加减少基本对象的行为和属性,泛化关系的子对象可以增加,修改基本对象的属性和行为。

    精化关系仅仅用于建模阶段,在实现语言中,并没有。泛化则等同于实现语言中的继承。

    聚合:整体由部分构成,整体消失,部分还存在。

    组合:强聚合

    
    展开全文
  • UML 核心元素之 参与者

    千次阅读 2010-04-09 23:24:00
    参与者(actor)在建模过程中是处于核心地位的。UML官方文档对actor的定义为:参与者(actor)是在系统之外与系统交互的某人或某事物。“系统之外”的定义说明在参与者和系统之间一个明显的边界,参与者(actor)...

    参与者(actor)在建模过程中是处于核心地位的。UML官方文档对actor的定义为:参与者(actor)是在系统之外与系统交互的某人或某事物。“系统之外”的定义说明在参与者和系统之间有一个明显的边界,参与者(actor)只可能存在于边界之外,边界之内的所有人或者事物都不是参与者。

    参与者(actor)还有另外一种叫法:主角。主角这一叫法则很明确的说明了只有主动启动了业务的,才是参与者。 

    发现参与者

    首先了解一个概念:涉众(stakeholder),也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。参与者的一个重要来源是涉众,从涉众中找出那些直接对系统发出动作,或者直接从系统中接受反馈的涉众。参与者是涉众代表,参与者对系统的要求直接影响系统的建设,他们的要求就是系统需求的来源,参与者通过对系统提出要求来获得他所代表的涉众的利益。参与者的另一个来源是客户的岗位设置。

    在查找参与者的过程中,尝试寻找一下问题的答案有助于你确定参与者:

    1、谁负责提供、使用或者删除信息?

    2、谁将使用此功能?

    3、谁对某个特定功能感兴趣?

    4、在组织中的什么地方使用系统?

    5、谁负责支持和维护系统?

    6、系统有那些外部资源?

    7、其他还有那些系统将需要与该系统进行交互?

    参与者一定是直接并且主动向系统发出动作并获得反馈的,否则就不是参与者。

     

    业务主角(business actor

           业务主角是参与者的一个版型,特别用于定义业务的参与者,在需求阶段使用。业务主角是与业务系统有着交互的人和事物,他们用来确定业务范围。业务主角的特殊性在于,它针对的是业务人员而非计算机用户。要建设一个符合客户需要的计算机系统,首要条件是完全彻底地搞清楚客户的业务,而不是预想已经有了一个计算机系统,再让客户来假设需要计算机系统帮助他们完成什么。

           所以在初始需求阶段,请务必使用业务主角,时时牢记业务主角是客户实际业务里的参与者,没有计算机系统,没有抽象的计算机角色。业务主角必须在实际的业务里能找到对应的岗位或人员。

    业务工人(business worker

       在建模过程中,有些人员虽然参与了业务,但是身份很尴尬,因为他们是被动参与业务的,不好确定其目的是什么,但是又确确实实在业务过程中做了事情。出现这种困扰的原因是打破了对边界的定义,这样的人员实际上应该是边界内的人员,被称为业务工人(business worker)。

        如何区分参与者和业务工人呢?最直接的方法是判断他是出现在系统边界之内还是在边界之外。如果边界不清楚,可以通过以下三个问题来澄清。

    1、 他是主动向系统发出动作的吗?

    2、 他有完整的业务目标吗?

    3、 系统是为他服务的吗?

    如果以上三个问题的答案都是否定的,那么他一定是业务工人。

     

    参与者与用户和角色的关系

           用户(user)是指系统的使用者,通俗一点说就是系统的操作员。用户是参与者的代表,或者说是参与者的实例或者代理。并非所有参与者都是用户,但是一个参与者可以代理多个参与者。

           角色(role)是参与者的职责。角色是一个抽象概念,从众多参与者的职责中抽象出来相同的那一部分,将其命名为角色。一个角色代表了系统中的一类职责。 

    参与者的核心地位

           参与者是涉众的代表,它代表涉众对系统的利益要求,并向系统提出建设要求;参与者通过代理给其他用户或者将自身实例化成为用户来使用系统;参与者的职责可以用角色来归纳,用户被指定扮演哪个或哪些角色因此来获得参与者的职责。

           同时,系统是以参与者的观点来决定的。参与者对系统的要求对系统的表述完全决定了系统的功能。

    展开全文
  • 版型是由UML里的元素扩展而来,每个元模型都很多版型,比如用例“业务用例”、“业务用例实现”等版型。当我们需要时候我们也可以根据UML里的元素自定义版型来辅助建模。二、参与者参与者(actor)是在系统之外...
    一、版型

    在UML里有一个概念叫版型(stereotype),也被称为类型、构造型。

    版型是由UML里的元素扩展而来,每个元模型都有很多版型,比如用例有“业务用例”、“业务用例实现”等版型。当我们需要时候我们也可以根据UML里的元素自定义版型来辅助建模。

    二、参与者

    参与者(actor)是在系统之外与系统交互的某人或某事物,在建模过程中处于核心地位。
    参与者和系统之间有一个明确的边界,参与者只能存在于边界之外,边界之内的所有人和事物都不是参与者。



    每个用例都必须有参与者,参与者可以非人,但一定是启动业务的主角。

    三、业务主角和业务工人

    业务主角(business actor)是参与者的一个版型,用于定义业务的参与者。业务主角是与业务系统有着交互的人和事物,他们用来确定业务范围。

    业务范围:项目所涉及的所有客户业务,有没有计算机系统参与都客观存在;
    系统范围:软件将要实现对应业务的系统功能。

    业务主角是针对业务范围来说的,是客观存在的,考虑业务主角时候需要抛开计算机的概念,这样才能彻底搞清楚客户的业务。

    接下来这段完全就是我的亲身经历,所以贴上来以作鞭策。



    业务工人(business worker)是指的系统边界内,被动参与了业务的执行过程的人。

    四、参与者相关关系

    涉众(stakeholder),也称为干系人,是与要建设的这个系统有利益相关的一切人和事。参与者就是涉众代表,对系统提出要求来获得他所代表的涉众的利益。

    用户(user),指的是系统的使用者,是参与者的代表,一个用户可以代理多个参与者。

    角色(role),指的是参与者的职责,一个角色代表了系统中的一类职责。



    五、用例

    用例的基本概念

    用例(Use case)是一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例,其中每个实例都是系统所执行的一系列操作,这些操作生成特定主角可以观测的值。

    在UML里,除了用例之外,所有其他元素都是封装独立的。用例推动这些UML元素关联起来,从而实现某个功能。所以说用例是UML建模中最重要的一个元素。

    一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如下图所示:



    一个系统的功能性是有一些对系统有愿望的参与者要做的一些事情构成的,事情完成后就达成了参与者的一个愿望,当全部参与者的所有愿望都能够通过用例来达到,那么这个系统就被确定下来了。

    用例的特征

    用例是相对独立的。

    用例的执行结果对参与者来说是可观测和有意义的。



    这件事必须由一个参与者发起。不存在没有参与者的用例,用例不应该自动启动,也不应该主动启动另一个用例。



    用例必然是以动宾短语形式出现的。



    一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元,甚至部署单元。



    用例的粒度

    用例的粒度是指的一个用例所描述事件的大小。

    在业务建模阶段,用例的粒度以每个用例能够说明一件完整的事情为宜,即一个用例可以描述一项完整的业务流程。

    在系统建模阶段,用例视角是针对计算机的,因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。

    现实情况中,根据系统的大小选择不同用例粒度,可以更好适应其需求范围。

    不论粒度如何选择,必须把握的原则是在同一个需求阶段,所有用例的粒度应该是同一个量级的。

    用例的获得

    用例的来源就是参与者对系统的期望。

    一个明确的有效的目标才是一个用力的来源。

    一个真实的目标应当完备地表达主角的期望。

    一个有效的目标应当在系统边界内,由主角发动,并具有明确的后果。

    六、用例相关的误区

    用例和功能的误区

    用例需要从使用者的观点出发来描述软件;功能是脱离使用者的愿望而客观存在的。

    用例是系统性的,以开灯为例,需要描述谁在什么情况下通过什么方式开灯结果是什么;功能是孤立的,只要按下开关灯就亮。

    用例可以解释为一系列完成一个特定目标的功能的组合,针对不同的应用场景,这些功能体现不同的组合方式。

    目标和步骤的误区

    一个用例是参与者对目标系统的一个愿望,一个完整的事件,为了完成这个事件需要经由很多步骤,但这些步骤不能够完整地反映参与者的目标,不能够作为用例。

    用例粒度的误区

    用例的粒度不是越小越好,太小了会使建模无比繁琐且没意义;

    一个系统里用例粒度如果不一,会使系统边界不确定,从而系统结构混乱。

    七、业务用例和业务用例实现

    业务用例(business use case)是用例版型中的一种,专门用于需求阶段的业务建模



    业务模型是针对客户业务的模型,与计算机系统建模无关,只是业务领域的一个模型。

    业务用例的参与者是业务主角,如果说用例是用来获取功能性需求,那么业务用例用来获取功能性业务。

    业务用例实现(business use case realization)是用例版型中的一种,专门用于需求阶段的业务建模。



    业务用例实现是业务用例的一种实现方式,表达了同一项业务的不同实现方式。

    业务用例和业务用例实现的关系举例如图







    展开全文
  •  仅和两个元素元素的直接子元素。 2.、 标签:所有其他头元素的容器,紧跟在起始标签之后。  标签应当包含一个标签以指示文档的标题。此外,还可以以任意顺序包含如下元素的任意组合:  :用于包含与文档...

    一、html页面的核心元素。

    1、<html>标签:整个HTML文档的包含元素。

          仅有<head>和<body>两个元素是<html>元素的直接子元素。

    2.、 <head>标签:所有其他头元素的容器,紧跟在起始标签<html>之后。

           <head>标签应当包含一个<title>标签以指示文档的标题。此外,还可以以任意顺序包含如下元素的任意组合:

               <meta>:用于包含与文档相关的信息。

               <script>:用于在文档中包含脚本。

               <style>:用于在文档中包含CSS规则。

               <link>:用于链接到外部文件。

            等标签。

    3、 <title>标签:给页面指定一个标题。实际描述站点内容的标题是非常重要。

            <title>标签中只能包含关于页面标题的文本,而不能包含其他任何元素。

    4、<body>标签:HTML文档的主体内容。用户能够在浏览器主窗口中看到的部分Web页面内容。

    这四个标签是一个HTML页面所必不可少的。可以说,只要有这四个元素,基本就算是一个完整的HTML页面了。对与这四个标签,还有好多内容要了解,这里不再多说了。在以后的应用中会不停地遇到他们。相信残缺的知识点会不断完善的。


    二、标签的基本属性。

    这里只是说大部分标签都会有的属性,也是一些比较重要的属性。这些最好都记下来,因为它指不定什么时候就派上用场了。

    1、 id属性:用于唯一标识页面内的任何元素。

             id属性的值存在的一些规则:

                 1)、必须以字母(A-Z或a-z)开头,然后可以跟上任意数量的字母、数字(0-9)、连字符、下划线、冒号和句号。
                 2)、在某个文档中保持唯一;在同一个XHTML文档中,任意两个id属性不能具有相同的值。

    2、class属性:指定某个元素属于特定的元素类。

           class属性通常用于CSS。

    3、 title属性 :给出元素的建议标题。

           常显示为加载元素时的工具提示。

    4. style属性:指定元素中的CSS规则。

          由于在使用时,不便于后续修改,先已渐渐被抛弃了。

    5、dir属性:指定文本在浏览器中的显示方向。

          它的值可以为:“ltr” 从左到右(默认值) 与 “rtl“ 从右到左。

    6、 lang属性:指示文档中使用的主要语言。

           lang 属性用于<html>标签中时,它将作用于整个文档;而在用于其他标签中时,它将仅作用于这些标签的内容。

    7、一些通用的UI事件:

           onclick, ondoubleclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout,

           onkeypress, onkeydown, onkeyup 这10个事件,是比较通用的。这里只是说一下,具体的用法有在以后的学习中肯定还是要接触

           的。再这里就不去在查找了。

    三、文档的注释方式:

           用“<!--"和“-->”来完成,例如:<!-- <h2>基础标签</h2> -->

           “<!--"和“-->”之间的任何内容都不会在浏览器中显示,但是可以在文档的源代码中看到它们。

    本篇文章是应该放在前边的,刚刚整理时忽略了,在此补上。全是些基础的,常用的东西,便于以后学习查阅。

    展开全文
  • 一、关系关系抽象出对象之间的联系,让对象构成某个特定的结构。关联关系(association)关联关系是一条直线表示的,描述不同类的的对象之间的结构关系。单向关联关系是一条带剪头的...依赖关系也单向依赖和双向
  • 在UML中,需求模型又称为用例模型,它主要用于描述系统的功能性需求,即软件可以实现的功能,如登录、注册、入库、出库、查看库存报表、增加员工...常规的用例建模一般包括两个组成部分:绘制例图和编写用例文档。
  • CSS浮动为什么不会遮盖同级元素

    千次阅读 2015-09-17 23:05:14
    在W3CSchool学习web前端时,看完CSS定位-浮动这一节后,感觉没有什么问题。但是在CSS高级-分类这一节的中进行实践时,遇到了如下问题
  • 在阿里巴巴Java开发手册中,这样一条规定:  但是手册中并没有给出具体原因,本文就来深入分析一下该规定背后的思考。 foreach循环 Foreach循环(Foreach loop)是计算机编程语言中的一种控制流程语句,通常用来...
  • 程序员必知的 89 个操作系统核心概念

    万次阅读 多人点赞 2020-03-31 19:13:39
    在电子或电脑系统中,通常以存储不需经常变更的程序或数据。 EEPROM (Electrically Erasable PROM):电可擦除可编程只读存储器,是一种可以通过电子方式多次复写的半导体存储设备。 闪存(flash memory): 是一种...
  • Maven 核心原理

    万次阅读 多人点赞 2016-11-05 11:18:38
    Maven 是每一位Java工程师每天都会接触的工具, 但据我所知其实很多人对Maven理解的并不深, 只把它当做一个依赖管理工具(下载依赖、打包), Maven很多核心的功能反而没用上.
  • 图解Transformer(完整版)

    万次阅读 多人点赞 2019-01-17 23:45:25
    接下来我们看看Transformer的一个核心特性,在这里输入序列中每个位置的单词都自己独特的路径流入编码器。在自注意力层中,这些路径之间存在依赖关系。而前馈(feed-forward)层没有这些依赖关系。因此在前馈...
  • 例图例图采用参与者和用例作为基本元素,以不同的视角展现系统的功能性需求。对客户来说,例图是他们业务领域的逻辑化表达;对建设单位来说,例图是系统蓝图和开发的依据。业务用例视图业务用例视图需要从...
  • 讲解增删改查等核心功能的前端实现,至此项目基本成型。
  • 编程语言的基本元素

    千次阅读 2019-06-10 22:56:41
    △向上生长, TO BE TO UP. 程序员成长充电站△计算机基础课第28期分享转载请联系授权(微信ID:qianpangzi0206)上节讲到机器码写程序,还要...
  • UML核心模型

    千次阅读 2014-03-13 12:41:52
    实际上,通过这几天对核心元素核心视图,核心模型的学习,UML告诉你的,实际上关键是在你清楚的知道你要做什么,你的软件决定你的模型,你的模型决定你的视图,而你的视图又决定你的元素。  
  • 我们在webpack打包我们的代码的时候,提供了两个入口文件: ...client entry :主要是将我们的vue 实例挂载到我们的指定元素上; 通过webpack build 打包完成以后: 会生成server bundle 和 c...
  • Flink中的一些核心概念

    万次阅读 2016-05-02 22:46:23
    Flink中的一些基础而又关键的核心概念。了解这些概念助于更进一步理解Flink的设计。
  • Vue的核心思想

    千次阅读 2017-01-12 10:31:02
    Vue的核心思想
  • OpenGL核心技术之GPU编程

    万次阅读 2017-02-17 11:41:16
    已出版书籍:《手把手教你架构3D游戏引擎》电子工业出版社和《Unity3D实战核心技术详解》电子工业出版社等。CSDN视频网址:http://edu.csdn.net/lecturer/144 3D游戏引擎的核心是渲染,游戏品质的提升需要通过Shader...
  • 顺序表所有元素逆置

    千次阅读 2017-07-14 18:14:38
    题目:设计一个高效的算法,将顺序表的所有元素逆置,要求算法的空间复杂度为O(1)。 算法思想:扫描顺序表的前半部分元素,对于元素L.data[i] (0 空间复杂度:  算法的空间复杂度S(n),定义为该算法所耗费的...
  • Vue的核心思想是什么..........

    万次阅读 2019-05-30 16:11:49
    Vue核心思想:数据驱动、组件化 一,数据驱动 传统的前端数据交互是Ajax从服务端获取数据,然后操作DOM来改变视图;或者前端交互要改变数据时,又要再来一次上述步骤,而手动操作DOM是一个繁琐的过程且易出错。 Vue...
  • Java2核心技术第7版全两卷.pdf中文高清

    千次下载 热门讨论 2012-09-14 14:22:28
    本资源内两本书《Java2核心技术卷I:基础知识(第7版)》和《JAVA2核心技术,卷II:高级特性(第7版)》,大小分别为 88MB 和 112 BM,均为 PDF 格式,高清影印版。两本书分别介绍如下: 《Java2核心技术卷I:基础知识...
  • 接下来我将写一系列文章,回顾区块链核心技术演进之路。包括算法演进,挖矿演进,共识机制演进,代币演进,隐私的演进,以及容量和速率的演进等。题目比较大,抛砖引玉,望读者指正和补充。 算法演进 关于...
  • 二、访问GpuMat的每个元素 一、CUDA极简入门教程 本部分只是CUDA 的一个超级简单且不完整的内容,关于CUDA配置和编程,请参考官方文档或其他教程。 1、Kernel Kernel是在GPU上执行的函数,访问的数据都应该在...
  • Maven-12可继承的POM元素

    千次阅读 2011-08-30 20:18:27
    可继承的POM元素完整列表 groupId:项目组ID,项目坐标的核心元素;version:项目版本,项目坐标的核心元素;description:项目的描述信息;organization:项目的组织信息;inceptionYear:项目的创始年份;url:...
  • OPNET核心函数

    千次阅读 2014-06-29 19:36:20
    OPNET Modeler 核心函数 1. 核心函数简介 1.1 命名规则 OPNET 中的核心函数具有非常标准的命名规则,以增强函数在 C/C++代码中的可视... 函数名的第二部分为函数集名,小写字母表示,通常是函数所处理对象的名称缩写
  • 元素问题_奇妙的思维

    千次阅读 2018-02-13 12:00:20
    总而言之 主元素问题是一种很简单的思维启发问题 方法很多 可是你想到了最简单的方法吗 主元素问题 什么是主元素问题? 已知一个数组的大小,并且其中存在一个数,出现的频率大于50%,则称其为该...
  • 数组被定义时,同时元素个数信息。使用这个信息可以对数组进行操作。但是在将数组作为一个参数传递给某个函数时,只能以指针形式传递,这就是数组退化。为了正确把握数组的大小一般需要同时传递数组的大小信息。...
  • 课程背景 又逢“金九银十”,年轻的毕业生们满怀希望与忐忑,去寻找、竞争一个工作机会。已经在职的开发同学,也想通过社会招聘或者内推的时机争取到更好的待遇、...长期筹谋——巩固核心技能。 面试题怎么刷?刷高...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 158,938
精华内容 63,575
关键字:

完整的元素核心有什么用