目录
1、语法和语义规则
2、UML中的公共机制
（1）规约
（2）修饰
（3）通用分别
（4）扩展机制
衍型/版型/类型（stereotype）
标记值 （tagged value）
束缚（constraint）
3、体系的体系结构建模
用例视图 （use case view）
设计视图 （design view）
交互视图 （interaction view）
实现视图 （implementation view）
部署视图 （deployment view）
4、软件开辟的生命周期
4.1、初始 （inception）
4.2、细化 （elaboration）
4.3、构造 （construction）
4.4、移交 （transition）
1、语法和语义规则
定名——为事物、关系和图起的名字；
范围——使名字具有特定含义的语境；
可见性——这些名字如何让其他成分看见和利用；
完备性——事物如何正确、划一地相互联系；
实行——运行或模拟一个动态模型意味着什么。
2、UML中的公共机制
（1）规约
UML 不仅仅是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个规约，这个规约提供了对构造块的语法和语义的文字叙述。
（2）修饰
UML中的大多数元素都有唯一而直接的图形表示符号，这些图形符号对元素的最重要的方面提供了可视化表示。
图中表明这个类是一个抽象类，
有两个公共操纵、一个受保护操纵和一个私有操纵。
（3）通用分别
第一种方式是对类和对象的分别。类是一种抽象，对象是这种抽象的一个具体表现。
在图形上，UML是如许区分对象的：采取与类同样的图形符号来表示对象，而且在对象名的下面画一道线
有一个名称为Customer的类，它有3个对象，分别为
Jan（它被明确地标记为Customer的对象）
:Customer（匿名的Customer对象）
Elyse（它在规约中被说明为一种Customer对象，尽管在这里没有明确地表示出来）。
第二种方式是接口和实现的分离。接口声明白一个合约，而实现则表示了对该合约的具体实施，它负责如实地实现接口的完备语义。
在这个图中，有一个名称为SpellingWizard.dll的构件，
它实现了接口IUnknown和接口ISpelling，
而且还必要利用一个由其他构件提供的名为IDictionary的接口。
第三种方式是类型和脚色的分离。类型声明白实体的种类（如对象、属性或参数），脚色形貌了实体在语境中的含义（如类、构件或协作等）。
任何作为其他实体结构中的一部分的实体（例如属性）都具有两个特性：
从它固有的类型派生出一些含义
从它在语境中的脚色派生出一些含义
（4）扩展机制
衍型/版型/类型（stereotype）
扩展了UML的词汇，可以用来创造新的构造块，这个新构造块既是从现有的构造块派生的，但是针对专门的标题。
例如，假设正在利用一种编程语言，如Java或C++，经常要对“异常事件”建模。在这些语言里，“异常事件”就是类，只是用很特殊的方法进行了处理。通常大概只想允许抛出和捕捉异常事件，没有其他要求。
此时可以让异常事件在模型中成为“一等公民”——可以像对待基本构造块一样对待它们，只要用一个得当的衍型来标记它们即可。
标记值 （tagged value）
扩展了UML衍型的特性，可以用来创建衍型规约的新信息。
例如，如果在制作以盒装形式销售的产品，随着时间的推移，它经过了多次发行，那么经常会想要跟踪产品的版本和对产品做关键摘要的作者。
版本和作者不是UML的基本概念，通过引入新的标记值，可以把它们加到像类那样的任何构造块中去。例如，在图中，在类EventQueue上明确标记了版本和作者，如许就对该类进行了扩展。
束缚（constraint）
扩展了UML构造块的语义，可以用来增加新的规则或修改现有的规则。例如，大概想束缚类 EventQueue，以使全部的增加都按序排列。如上图，对操纵 add增加了一个束缚，即{ordered}，以明确标示这一规则。
3、体系的体系结构建模
不同人员关注各自的标题
用况：用例
用例视图 （use case view）
由形貌可被终极用户、分析人员和测试人员看到的体系行为的用例组成。用例视图实际上没有形貌软件体系的组织，而是形貌了形成体系体系结构的动力。
在UML中，该视图的静态方面由用例图表现；动态方面由交互图、状态图和运动图表现
设计视图 （design view）
包罗了类、接口和协作，它们形成了标题及其解决方案的词汇。这种视图主要支持体系的功能需求，即体系应该提供给终极用户的服务。
在UML中，该视图的静态方面由类图和对象图表现；动态方面由交互图、状态图和运动图表现。类的内部结构图特别有用。
交互视图 （interaction view）
展示了体系的不同部分之间的控制流，包括大概的并发和同步机制。该视图主要针对性能、可伸缩性和体系的吞吐量。
在UML中，对该视图的静态方面和动态方面的表现与设计视图雷同，但偏重于控制体系的自动类和在它们之间流动的消息
实现视图 （implementation view）
包罗了用于装配与发布物理体系的制品。这种视图主要针对体系发布的设置管理，它由一些独立的文件组成；这些文件可以用各种方法装配，以产生运行体系。它也关注从逻辑的类和构件到物理制品的映射。
在UML中，该视图的静态方面由构件图表现，动态方面由交互图、状态图和运动图表现。
部署视图 （deployment view）
包罗了形成体系硬件拓扑结构的结点（体系在其上运行）。这种视图主要形貌组成物理体系的部件的分布、交付和安装。
在UML中，该视图的静态方面由部署图表现，动态方面由交互图、状态图和运动图表现。
4、软件开辟的生命周期
1）用例驱动
把用例作为一种基本的制品，用于建立所要求的体系行为、验证和确认体系的体系结构、测试以及在项目组成员间进行交流。
2）以体系结构为中心
以体系的体系结构作为一种基本制品，对被开辟的体系进行概念化、构造、管理和演化。
3）迭代的和增量
迭代：涉及到对一连串可实行的发布的管理。
增量：涉及到体系体系结构的持续集成，以产生各种发布，每个新发布都比上一个发布有所改善
总的来讲，迭代和增量的过程是风险驱动的（risk-driven），每个新的发布都致力于处理和低沉对于项目成功影响最为明显的风险。
RUP四个阶段，即软件开辟生命周期
4.1、初始 （inception）
在此阶段，萌发的开辟想法经过培育要到达如许一个目标：至少要在内部奠基足够的基础，以包管能够进入到细化阶段。
4.2、细化 （elaboration）
在此阶段界说产品需求和体系结构。在这个阶段，将明确体系需求，按其重要性排序并规定基线。可以按一样平常的形貌，也可以按精确的评价准则来排列体系的需求，每个需求都说明白特定的功能或非功能的行为，并为测试提供了基础。
4.3、构造 （construction）
在此阶段软件从可实行的体系结构基线发展到预备移交给用户。针对项目标贸易必要，这里也要不断地对体系的需求，特别是对体系的评价准则进行查抄，并要适本地分配资源，以自动地低沉项目标风险。
4.4、移交 （transition）
在此阶段把软件交付给用户。在这个阶段，软件开辟过程很少能竣事，还要继续改善体系，根除错误，增加早期发布未能实现的特性。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
