uml读书笔记Word文档格式.docx

uml读书笔记Word文档格式.docx

《uml读书笔记Word文档格式.docx》由会员分享，可在线阅读，更多相关《uml读书笔记Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

动态模型：

在状态图、顺序图、协作图以及活动图中描述。

3、组件视图（componentview）：

显示代码组件的组织结构。

描述系统中实现的模

块以及它们之间的依赖关系。

开发人员

4、并发视图（concurrencyview）：

显示系统的并发性，解决在并发系统中存在的

通信和同步问题。

将系统划分为进程和处理器，处理其中的通信和同步问题。

5、部署视图（deploymentview）：

显示系统的具体部署，即将系统部署到由计算

机和节点（设备）组成的物理结构上，显示个设备的链接方式，以及组件在那

个节点上运行。

九种图：

1、用例图（use-casediagram）

：

显示外部参与者与用例（用例是一种建模技

术，用于描述系统的功能）之间的联系。

2、类图（classdiagram）：

显示系统中各类的静态结构，类代表系统内处理的

事物。

相互连接的方式有：

关联（相互连接）、依赖（一个类依赖另一个

类）泛化（继承）或者打包（多个类组成一个单元）。

一般一个系统有多

个类图----并不是所有的类都放在一个类图中，且一个类可以参与多个类图

中。

因为类所描述的结构在系统生命周期任何时期都有效，所以通常认为

类图是静子的，类的属性和操作表示了类的内部结构。

两个类的关系：

设

a是基类，b是子类。

特殊化（specialize）：

a可以特殊化为b；

一般化

（generalize）b可以一般化为a；

泛化（generalization）：

a是b的泛化；

特化（specialization）：

b可以特化为a。

////////关联符号

3、对象图（objectdiagram）：

是类图的一个例子，用于显示类的多个对象的

实例，而不是实际的类。

显示系统某一时刻可能呈现的样子。

与类的不同：

对象名称带下划线、显示类的多个对象的实例（不能省略）。

对象图也作

为协作图的一部分被使用，显示一群对象之间的动态协作关系。

//////////////////////////////画类图和对象图

4、状态图（statediagram）：

是对类描述的补充。

显示对象可能具有的属性，

以及引起状态改变的事件（不是所有的类都需要绘制状态图）另外可以为

系统绘制整体状态图。

5、顺序图（sequencediagram）：

显示多个对象之间的动态协作。

显示特定时

间对象之间的交互。

6、协作图（collaborationdiagram）：

像顺序图一样显示动态协作，而且还显示

对象之间的关系（有时指上下文）；

一般时间顺序是重点，选择顺序图；

上下文需要强调选择协作图。

7、活动图（activitydiagram）：

用于显示一系列顺序的活动，尽管活动图也可

以描述像用例或交互这类的活动流程，但是一般来说它主要还是用于描述

在一个操作内执行的那些活动。

8、组件图（componentdiagram）：

是用代码组件来显示物理结构的。

因为一

个组件包含它所实现的一个或多个逻辑类的相关信息，于是就创建了一个

从逻辑视图到组件视图的映射。

9、部署图（deploymentdiagram）：

显示系统中硬件和软件的物理结构，节点

之间的必要连接，及连接的类型。

显示节点内部分配的组件和对象，以及

一些节点上运行的软件单元。

另外，部署图也可以显示组件之间的依赖关

系。

描述图的附加信息：

1、修饰（adornment）：

例如（图形符号中，粗体字代表类，加下划线的代表对象）

2、注释（note）：

一般用一条虚线连接到要解释的元素上。

3、规格说明

扩展uml：

1、构造型：

基于一个已有的模型元素构造一个新的模型元素。

两种描述方法：

在原元

素邻近加上加括号括的构造型名称；

在原元素邻近加上相应的图标。

2、标记值：

元素包含的“名称—值”特性称为标记值

3、约束：

是施加在某个元素上的限制。

//////////画图

用例建模：

用例建模是一项用于描述系统功能需求的技术。

uml中的用例模型定义：

在经过开发人员系统开发人员和客户反复讨论后，确定双方都同意的系统规格说明，在此基础上，建模人员建立系统的用例模型。

用例模型在uml中由用例图来描述，并且用例模型可以划分为多个用例图。

用例模型的组件：

1、用例（指定一个完整的功能）

2、参与者（actor）：

与该系统打交道的人或其他系统，是一个类型（类）而不是一个实例，每个参与者都有一个名称，反应出参与者的角色，而不应该反映出参与者的特定实例和功能。

在用例图中仅使用了泛化（继承）关系来描述参与者之间的公共行为。

3、被建模系统：

不一定非得是软件系统，可以是一项业务或一台机器。

在用例图中用一个“黑盒子”来描述。

名称放在“盒子”上方或内部。

///画图

创建用例模型的过程：

定义系统，发现参与者和用例，描述用例、定义用例之间的关系，并且最终对这些模型进行确认。

用例模型表示了用例视图，影响着系统中所有其他视图。

用例是根据外部参与者，用例和被建模的系统来描述的。

uml中的用例定义：

系统执行一组动作序列，产生一个特定的参与者可以观察的数值结果，这些动作会涉及与多个参与者的通信，以及在系统内部执行的计算和任务。

特征：

总是由参与者启动（必须有参与者）、为参与者提供结果、描述的功能必须是完整的一部分。

用例是一个类，而不是一个实例，描述了系统的总体功能，他的一个示例称为场景，代表系统的一个实际情景。

uml中的用例是用包含名称的椭圆表示，并放置在系统边界的内部。

//画图用例之间的关系：

扩展关系（extendsrelationship）：

有继承的味道，一个在另一个上加一些动作。

并不完全包含另一个的所有。

（属于泛化）

使用关系（usesrelationship）：

一个使用另一个，相当于组合。

分组关系（groupingrelationship）：

功能相近的用例捆绑到一个包内。

实现用例：

描述用例：

通常是用普通文本来实现的，是一个简单的，一致参与者与用例如何交互的规格说明。

内容：

用例目标、如何被启动、参与者和用例之间的消息、用例的其他流程、结束返回的数值。

在协作中实现用例：

一个协作由多个图表示，这些图显示了协作的参与者之间的上下文（各类和对象之间的相互关系称为上下文context）和交互。

这些图有：

协作图、顺序图、活动图。

实现一个用例就是将该用例描述中的那些不同步骤和动作转换为各个类、类的操作以及这些类的之间的关系。

实现用例的三种构造型对象：

边界对象（接口对象）、控制对象、实体对象，用来描述实现一个用例的协作。

【篇二：

uml学习笔记】

1.uml（unifiedmodelinglanguage）统一建模语言

（1）.uml为面向对象开发系统的产品进行描述、构造、和编制文档的一种可视化语言。

（2）.分析和设计：

?

分析（analysis）：

对问题和需求的调查研究,而不是解决方案，即应该如何使用系统，系统应该具有哪些功能设计（design）：

满足需求的概念上的解决方案,而不是其实现。

最终，分析可以实现，而实现则表达了真实和完整的设计

（3）.ooa和ood：

ooa:

面向对象分析（object-oriented-analysis）:

在问题域内发现和描述对象,如，明确一些概念，这些概念也许对应着一些对象

ps：

在软件工程中，问题域是指被开发系统的应用领域，即在客观世界中由该系统处理的业务范围

领域模型：

对领域内的概念类或现实世界中对象的可视化表示

?

ood:

面向对象的设计（object-oriented-design）:

如何定义软件对象以及他们之间如何协

作以实现需求;

如，明确类的属性和方法

（4）.uml的语义和表示法：

uml语义描述基于uml的精确元模型定义。

ps:

元模型为uml的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。

此外uml还支持对元模型的扩展定义uml表示法定义uml符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为

系统建模提供了标准。

这些图形符号和文字所表达的是应用级的模型,在语义上它是uml元模型的实例

（5）.uml的五类图

第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。

第二类是静态图（staticdiagram）,包括类图、对象图和包图。

其中类图描述系统中类的静

态结构。

不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构（类的属性和操作）。

类图描述的是一种静态关系,在系统的整个生命周期都是有效的。

对象图是类图的实例,几乎使用与类图完全相同的标识。

他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。

一个对象图是类图的一个实例。

由于对象存在生命周期,因此对象图只能在系统某一时间段存在。

包由包或类组成,表示包与包之间的关系。

包图用于描述系统的分层结构。

第三类是行为图（behaviordiagram）,描述系统的动态模型和组成对象间的交互关系。

其中

状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。

通常,状态图是对类图的补充。

在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。

而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。

第四类是交互图（interactivediagram）,描述对象间的交互关系。

其中顺序图显示对象之

间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;

合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。

除显示信息交换外,合作图还显示对象以及它们之间的关系。

如果强调时间和顺序,则使用顺序图;

如果强调上下级关系,则选择合作图。

这两种图合称为交互图。

第五类是实现图（implementationdiagram）。

其中构件图描述代码部件的物理结构及各

部件之间的依赖关系。

一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。

它包含逻辑类或实现类的有关信息。

部件图有助于分析和理解部件之间的相互影响程度。

配置图定义系统中软硬件的物理体系结构。

它可以显示实际的计算机和设备（用节点表示）以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。

在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

（6）.

（7）.从应用的角度看,当采用面向对象技术设计系统时,第一步是描述需求;

第二步是根据需求建立

系统的静态模型,以构造系统的结构;

第三步是描述系统的行为。

其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图（包含包）、对象图、组件图和配置图等五个图形,是标准建模语言uml的静态建模机制。

其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。

它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言uml的动态建模机制。

因此,标准建模语言uml

的主要内容也可以归纳为静态建模机制和动态建模机制两大类

2.静态视图

（1）.类元:

是描述事物的建模元素

（2）.关系的种类

（3）.用例之间的关系

（4）.状态的种类

【篇三：

《uml和模式应用》读书笔记】

《uml和模式应用》读书笔记

第一部分绪论

1、在oo开发中，至关重要的能力是熟练地为软件对象分配职责；

个人认为将对象进行抽象的能力也相当重要。

2、分析（analysis）强调的是对问题和需求的调查研究，而不是解决方案；

设计（design）强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。

有益的分析和设计可以概括为：

做正确的事（分析）和正确地做事（设计）。

3、需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例（usecase）。

4、面向对象分析关注从对象的角度创建领域描述，面向对象分析需要鉴别重要的概念、属性和关联。

面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。

5、面向对象设计关注软件对象的定义-它们的职责和协作。

6、与领域模型表示的是真实世界的类，设计类图表示的是软件类。

7、敏捷建模（agilemodeling）强调了uml作为草图的方式，这也是适用uml的普通方式，而且通常对时间投入具有高回报（一般费时较短）。

8、迭代开发（iterativedevelopment）是up和大多数其他现代方法中的关键实践。

在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代（iteration），每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试活动。

9、迭代开发的优点包括：

减少项目失败可能性，提高生产率，降低缺陷率。

在早期缓解高风险（技术、需求、目标、可用性等等）。

早期可见的进展。

早期反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。

可控复杂性；

团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。

一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。

10、在复杂、变更系统中（如大多数软件项目），反馈和调整是成功的关键要素。

11、如何进行迭代和进化式分析和设计：

1）在第1次迭代之前，召开第一个时间定量的需求工作会议，例如确切地定义为两天时间，业务和开发人员（包括首席架构师）需要出席。

在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。

这种

分析不可能是完美的。

通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项，这些项目具备以下三种性质：

1，具

有重要的架构意义；

2，具有高业务价值；

3，具有高风险。

在剩下的一天半内，对这三个用例的功能和非功能性需求进行详细的分析。

完成这一过程后，对10%

进行了深入分析，90%进行了高阶分析。

2）在第1次迭代之前，召开迭代计划会议，选择上述三种用例的子集，在特定时间内（例如，四周的时间定量迭代）进行设计、构造和测试。

3）在三到四周内完成第1次迭代（选择时间定量，并严格遵守时间）：

在开始的两天内，开发者和其他成员分组进行建模和设计工作，在首席架构师的带领和指导下，于“公

共作战室”的众多白板上，画出uml的草图（及其他的模型）。

然后，开发者摘掉其“建模帽子”并戴上“编程帽子”，开始编程、测试和集成工作并且剩余的时间均用

于完成这项工作。

进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。

在结束前的一周，检查是否能够完成初始的迭代目标；

如果不能，则缩小迭代的范围，将次要目标置

回任务列表中。

在最后一周的星期二，冻结代码。

必须检入、集成和测试所有代码，以建立迭代的基线。

在星期三的上午，向外部涉众演示此局部系统，展示早期可视进展，同时要求反馈。

4）在第1次迭代即将结束时（如最后一周的星期三和星期四），召开第二次需求工作会，对上一次会议的所有材料进行复查和精化，然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析。

5）于周五上午，举行下一迭代的迭代计划会议。

6）以相同步骤进行第2次迭代。

7）反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能已经详细记录了大约80%-90%的需求。

8）我们大概推进了整个项目过程的20%。

此时，可以估计这些精化的、高质量的需求所需工作量和时间。

因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试，因此估计能够做什么和需要多长时间的结果会更为可靠。

9）此后，一般不需要再召开需求工作会；

需求已经稳定了（尽管需求永远不会被冻结）。

接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会上选择适宜的下一步工作，每次迭代都要反复询问：

“就我们现在所知，下一个三周应该完成的、最关键的技术和业务特性是什么？

”

利用这种方式，经过早期探索式开发的几次迭代之后，团队将能够更准确地回答“什么、多少、何时”。

12、建模（构建uml草图……）的目的主要是为理解，而非文档。

第二部分初始阶段

1、用一句话来概括初始阶段：

预见项目的范围、设想和业务案例。

用一句话来概括初始阶段要解决的主要问题：

涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

2、需求分析的最大挑战是寻找、沟通和记住（通常是指记录）什么是真正需要的，并能够清楚地讲解给客户和开发团队的成员。

3、在统一过程中，需求按照“furps+”模型进行分类，这是一种有效的记忆方法，其含义如下：

功能性（funcational）：

特性、功能、安全性。

可靠性（reliability）：

故障频率、可恢复性、可预测性。

性能（performance）：

响应时间、吞吐量、准确性、有效性、资源利用率。

可支持性（supportability）：

适用性

、可维护性、国际化、可配制性。

”furps+“中的”+“是指一些辅助性的和次要的因素，比如：

实现（implementation）：

资源闲置、语言和工具、硬件等。

接口（interface）：

强加于外部系统接口之上的约束。

操作（operation）：

对其操作设置的系统管理。

包装（packaging）：

例如无力的包装盒。

授权（legal）：

许可证或其他方式。

若想从生活中得到什么，必不可少的第一步就是：

决定想要什么。

-本。

斯坦（benstein）

4、用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。

5、用例是一种优秀的方法，使领域专家或需求提供者自己编写（或参与编写）用例成为可能，并使这项工作难度降低。

第三部分细化迭代1基础

1、细化（elaboration）是一般项目中最初的一系列迭代，其中包括：

对核心、有风险的软件架构进行编程和测试。

发现并稳定需求的主体部分。

规避主要风险。

细化阶段是最初的一系列迭代，在这一阶段，小组进行细致的调查、实现（编程和测试）核心架构、澄清大多数需求和应对高风险问题。

2、在细化阶段可能出现的一些关键思想和最佳实践包括：

实行短时间定量、风险驱动的迭代。

及早开始编程。

尽早、频繁、实际地测试。

基于来自测试、用户、开发者的反馈进行调整。

通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。

3、通过关联而不是属性来表示概念类之间的关系。

4、没有所谓唯一正确的领域模型。

所有模型都是对我们试图要理解的领域的近似。

领域模型主要是在特定群体中用于理解和沟通的工具。

5、在同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责则不应该混淆。

6、需要哪些对象，它们如何通过消息和方法进行协作，通过动态对象建模（例如绘制顺序图）才能真正落实这些准确和详细的结论。

7、应该把时间花费在交互图（顺序图或通信图），而不仅是类图上。

8、任何顺序图都可以使用sd图框围绕起来，并对其命名。

当你想要引用相应名字的sd图框时，可以使用ref图框。

9、在类图中，使用依赖线描述对象之间的全局变量、参数变量、局部变量和静态方法（对其他类的静态方法加以调用）的依赖。

10、grasp是通用职责分配软件模式（generalresponsibilityassignmentsoftwarepatterns）的缩写。

grasp的9个模式如下所示：

创建者（creator）

如果以下的条件之一（越多越好）为真时，将创建类a实例的职责分配给类b：

b“包含”或组成聚集a。

b记录a。

b直接使用a。

b具有a的初始化数据，并且在创建a时会将这些数据传递给a。

因此对于a的创建而言，b是

专家。