软件开发环境

软件开发环境(huánjìng)主讲人:邵堃共一百三十四页软件开发环境(huánjìng)讲授内容：

软件开发环境重点教授面向软件开发过程(guòchéng)的各类软件开发工具和使用方法。

讲述重点：1.了解软件工程中方法，工具和过程之间的基本概念，及其相互关系（讲述为主）；2.了解当前的主要软件开发方法，结构化开发、面向对象开发、面向方面开发和面向组件的开发等（学生自己查找资料，然后做报告）；共一百三十四页软件开发环境(huánjìng)讲授内容：

3.了解(liǎojiě)针对这些开发方法的主要工具软件（学生自己查找资料，然后做报告），重点介绍面向对象开发方法UML，及其开发工具RationalRose(讲述为主)。软件开发工具、软件测试工具和软件开发过程项目管理工具；共一百三十四页软件开发环境(huánjìng)的背景软件工程化的背景(bèijǐng)；软件规模化的背景；软件产业化的背景；共一百三十四页软件开发环境(huánjìng)的定义软件开发环境(SoftwareDevelopmentEnvironment)是指在基本硬件和宿至软件的基础上，为支持系统软件和应用软件的工程化开发和维护而使用的一组软件，简称SDE。它由软件工具和环境集成(jíchénɡ)机制构成，前者用以支持软件开发的相关过程、活动和任务，后者为工具集成(jíchénɡ)和软件的开发、维护及治理提供统一的支持。

共一百三十四页软件开发环境(huánjìng)中各类元素之间的关系SoftwareEngineeringa“quality”focusprocessmodelmethodstools注：软件工程的三个基本要素：方法、工具和过程 过程：规定了完成各项任务的过程； 方法：完成软件开发的各项任务的技术(jìshù)方法； 工具：软件工程的支撑环境；

共一百三十四页软件开发环境的分类-按开发(kāifā)模型和开发(kāifā)方法分支持瀑布(pùbù)模型、演化模型、螺旋模型、喷泉模型以及结构化方法、信息模型方法、面向对象方法等不同模型及方法的软件开发环境。

共一百三十四页软件开发环境的分类-按功能及结构(jiégòu)特点分类有单体型、协同(xiétóng)型、分散型和并发型等多种类型的软件开发环境。

共一百三十四页软件开发环境(huánjìng)的分类-按开发阶段分类前端开发环境(huánjìng)(支持系统规划、分析、设计等阶段的活动)；后端开发环境(支持编程、测试等阶段的活动)；软件维护环境；逆向工程环境；

此类环境往往可通过对功能较全的环境进行剪裁而得到。共一百三十四页软件开发环境的分类(fēnlèi)-按应用范围分类

有通用型和专用型软件开发环境。其中(qízhōng)专用型软件开发环境与应用领域有关；

共一百三十四页软件开发环境(huánjìng)的构造

软件开发环境由工具集和集成(jíchénɡ)机制两部分构成，工具集和集成(jíchénɡ)机制间的关系如同“插件”和“插槽”间的关系。

共一百三十四页工具集软件开发环境中的工具可包括：

支持特定过程模型和开发方法的工具，如支持瀑布(pùbù)模型及数据流方法的分析工具、设计工具、编码工具、测试工具、维护工具，支持面向对象方法的OOA工具、OOD工具和OOP工具等；

独立于模型和方法的工具，如界面辅助生成工具和文档出版工具；

亦可包括管理类工具和针对特定领域的应用类工具。

共一百三十四页集成(jíchénɡ)机制

对工具的集成及用户软件的开发、维护及管理提供统一的支持。按功能(gōngnéng)可划分为环境信息库、过程控制及消息服务器、环境用户界面三个部分。共一百三十四页环境(huánjìng)信息库是软件开发环境的核心，用以储存与系统开发有关的信息并支持(zhīchí)信息的交流与共享。库中储存两类信息，一类是开发过程中产生的有关被开发系统的信息，如分析文档、设计文档、测试报告等；另一类是环境提供的支持(zhīchí)信息，如文档模板、系统配置、过程模型、可复用构件等。共一百三十四页过程(guòchéng)控制和消息服务器是实现过程集成及控制集成的基础。过程集成是按照具体软件开发过程的要求进行工具(gōngjù)的选择与组合，控制集成并行工具(gōngjù)之间的通信和协同工作。共一百三十四页环境(huánjìng)用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致视感(Look&Feel)的用户界面是软件开发环境的重要(zhòngyào)特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。共一百三十四页完善(wánshàn)的软件开发环境通常具有如下：(1)软件开发的一致性及完整性维护；

(2)配置管理及版本控制；

(3)数据的多种表示形式及其在不同形式之间自动转换(zhuǎnhuàn)；

(4)信息的自动检索及更新；

(5)项目控制和管理；

(6)对方法学的支持；共一百三十四页软件开发环境(huánjìng)与软件开发方法软件开发方法(SoftwareDevelopmentMethod)是指软件开发过程所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物，也就是一个(yīɡè)运行的系统及其支持文档，并且满足有关的质量要求。软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是软件开发方法学，指的是规则、方法和工具的集成，既支持开发，也支持以后的演变过程(交付运行后，系统还会变化，或是为了改错，或是为了功能的增减)。共一百三十四页典型(diǎnxíng)的软件开发和系统演化的活动分析、设计、实现、确认(测试验收)、演化(yǎnhuà)(维护)共一百三十四页①覆盖开发全过程，并且便于在各阶段间的过渡；②便于在开发各阶段中有关人员之间的通信；③支持有效的解决问题的技术；④支持系统设计和开发的各种不同(bùtónɡ)途径；⑤在开发过程中支持软件正确性的校验和验证；软件开发方法(fāngfǎ)应该考虑的一般因素共一百三十四页软件开发方法(fāngfǎ)应该考虑的一般因素⑥便于在系统需求中列入设计、实际和性能的约束；⑦支持(zhīchí)设计师和其他技术人员的智力劳动；⑧在系统的整个生存周期都支持它的演化；⑨受自动化工具的支持。此外，在开发的所有阶段，有关的软件产物都应该是可见和可控的；软件开发方法应该可教学、可转移，还应该是开放的，即可以容纳新的技术、治理方法和新工具，并且与已有的标准相适应可称为应用型软件开发环境。共一百三十四页主要(zhǔyào)的面向对象软件工程方法CRC卡UML共一百三十四页CRC卡一种(yīzhǒnɡ)简单的面向对象建模方法CRC（Class-Responsibility-Collaborator)卡建模是一种简单且有效(yǒuxiào)的面向对象的分析技术。它由三部分组成：

1.类(Class)

2.职责(Responsibility)

3.协作(Collaborator)共一百三十四页CRC卡的类一个类代表许多(xǔduō)类似的对象。而对象是系统模型化中关注的事物。他们可以是一个人、地方、事情、或任何对系统有重要性的概念。类名一般列在CRC卡的顶部。

共一百三十四页CRC卡的职责(zhízé)职责是类需要知道或做的任何事物。这些职责是类自身(zìshēn)所知的知识，或类在执行时所需的知识。共一百三十四页CRC卡的协作(xiézuò)协作是指为获取消息，或协助执行活动(huódòng)的其他类。在特定情形下，与指定的类按一个设想共同完成一个(或许多)步骤。协作的类顺着CRC卡的右边排列。

共一百三十四页CRC模型(móxíng)CRC模型(móxíng)是CRC卡的集合，它代表一个应用域或问题域的全部或一部分。共一百三十四页CRC范例(fànlì)CRC模型是最普遍(pǔbiàn)的用户。图中展示了一个航运/存货控制系统的CRC模型例子，展示的CRC卡将被放在一张书桌或工作桌上。注意卡的放置：相互协作的卡是彼此接近的，无关系的卡不能放在附近。共一百三十四页CRC卡的构建(ɡòujiàn)步骤一1、CRC模型组一起加入(模型组包括相关的客户领域人员、设计者、记录员、系统分析员等)。

2、安排模型房间。

3、进行集体自由(zìyóu)讨论

内容根据此CRC模型的系统目标进行，如系统是为谁开发的？那些商业业务需要这个系统的何种支持？工作时需要什么信息？……总之尽量按能达到系统要求实现的目标进行,包括进行活动时对资源、条件、活动及人员的要求。

共一百三十四页CRC卡构建(ɡòujiàn)步骤二4、讲解(jiǎngjiě)CRC模型技术(完成集体讨论后，设计者将描述CRC模型过程。通常需要花费十至十五分钟，该过程包括创造几个CRC卡范例,范例参考上图)。

5、重复地执行CRC模型步骤。

6、执行用例情景试验

用户情景试验是一个任务过程模式，其中用户们将积极地参与以保证需求是准确的。基本的思想是一组商业领域专家（也就是客户方），设计者，系统分析员一步步通过一系列的用例证实CRC模能准确地反映出用户的需求。共一百三十四页CRC模型(móxíng)的优点CRC模型就是一种沟通方式，客户方与开发方如何通过这种有效的、易实现、易操作的方式建立一个能描述准确的、双方达成共识(ɡònɡshí)的系统需求。CRC建模因为用户积极参与到模型的定义中，他们对工作的满意度就会增加，并与开发者们并肩创造这个CRC模型，通过这个一连串的模型卡，双方对待建的系统需求目标达成共识。共一百三十四页CRC卡的缺点(quēdiǎn)CRC模型只是一个面向对象应用的用户需求定义的一部分。你也应该考虑到用例，原型，和正式的需求文档。是否要使用(shǐyòng)CRC建模，就根据项目、企业、客户自身存在和所需的条件而定了

共一百三十四页面向对象的软件过程(guòchéng)-喷泉模型需求(xūqiú)阶段面向对象分析阶段面向对象设计阶段编码阶段集成和测试阶段运行状态进一步开发维护期喷泉模型的生命周期与结构化方法的生命周期是一致的，但喷泉模型的各个阶段是迭代和无缝的。共一百三十四页面向对象的软件(ruǎnjiàn)过程-RUPRUP的二维开发(kāifā)模型横轴是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；

纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。共一百三十四页RUP的各个(gègè)阶段和里程碑-横向RUP中的软件生命周期在时间(shíjiān)上被分解为四个顺序的阶段

初始阶段(Inception)

（生命周期目标里程碑）

前景文档：对核心项目要求、关键性质、主要限制的一般性的前景说明；初始的用例模型（完成10％－20％）；初始的项目术语表；初始的商业用例，包括商业环境、验收规范以及成本预测；初始的风险评估；项目规划，其中明确阶段和迭代；商业模型，根据需要可选；一个或多个原型；细化阶段(Elaboration)（生命周期结构里程碑）

构造阶段(Construction)（初始运行能力）交付阶段(Transition)（产品发布里程碑）

用例模型（至少完成80％）：识别出了所有的用例和角色，以及大多数用例的描述；调整一些增加的需求，包括非功能性需求以及任何与特定用例无关的需求；

软件体系结构描述；可执行的体系结构原型；修订后的风险表和商业用例；整个项目的开发计划，包括粗略项目规划，显示迭代过程以及相应的评估准则；更新的开发用例，指定要使用的过程；初步的用户手册（可选）；

在特定平台上集成的软件产品；用户手册；

对当前版本的描述；beta测试确认新系统达到用户的预期；与被取代的旧系统并行操作；功能性数据库的转换；用户和维护人员培训；

向市场、分销商和销售人员进行新产品的展示；共一百三十四页RUP的核心(héxīn)工作流-纵向

描述如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象(duìxiàng)模型中定义组织的过程，角色和责任。

描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化。分析设计的结果是一个设计模型和一个可选的分析模型。

目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

目的是验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。

目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。同时也阐述了对产品修改原因、时间、人员保持审计记录。

平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。

目的是向软件开发组织提供软件开发环境，包括过程和工具。共一百三十四页UML语言(yǔyán)JimRumbaughGradyBoochIvarJacobson共一百三十四页UML的简介(jiǎnjiè)UML(UnifiedModelingLanguage)是一种构建软件系统和文档的通用可视化建模语言。UML能与所有的开发方法一同使用，可用于软件开发的整个生命周期。UML能表达系统的静态(jìngtài)结构和动态信息，并能管理复杂的系统模型，便于软件团队之间的合作开发。UML不是编程语言，但支持UML语言的工具可以提供从UML到各种编程语言的代码生成，也可以提供从现有程序逆向构建UML模型。UML并不是万能的，它是一种离散的建模语言，对于特定的领域，比如：GUI、VLSI电路设计或基于规则的人工智能，用特定的语言和工具可能更合适。共一百三十四页最重要目标：UML是所有建模人员可以使用的通用建模语言。它包含主流建模方法的概念，从而可以替代现有的软件分析和设计方法，比如：OMT,Booch,OOSE等。UML不是完整的开发方法，它不包括逐步的开发流程，但它提供所有必要的概念，具备足够的表达能力。UML的另一个目标是：能尽量简洁地表达系统(xìtǒng)的模型。UML的目标(mùbiāo)共一百三十四页UML概念可以划分为以下范围(fànwéi)：系统需求静态结构动态行为交互行为物理实现各种图之间的关系模型组织扩展机制UML的主要(zhǔyào)概念共一百三十四页用例视图(UseCasesView)从外部用户的角度来描述系统的行为，它将系统功能划分为对用户有意义的事务，这些事务被称为用例，用户被称为执行者，用例视图也就是描述活动者在各个用例中的参与情况，它指导(zhǐdǎo)所有的行为视图。系统(xìtǒng)需求共一百三十四页静态视图(StaticView)，一个模型必须首先定义各种事物的内部特征(tèzhēng)和相互之间的关系，应用概念建模成类，类描述事物的属性和以及在这些属性上的操作。类之间可以存在不同的关系，比如泛化（继承）、关联和依赖等，静态视图表示成类图，静态视图在某一时刻的快照称为对象图。静态(jìngtài)结构共一百三十四页状态机视图(StateMachineView)，通过对每个类的对象的生命周期进行建模，描述了对象时间上的动态行为。状态机是由状态和迁移组成的图，状态机通常附属于类，描述类实例对接受事件的响应。活动视图(ActivityView)是利用状态机对运算和工作(gōngzuò)流进行建模的特殊形式。活动图的状态代表了运算执行的状态，而非一般对象的状态，活动图和流程图很相似，不过它支持并发。动态(dòngtài)行为共一百三十四页交互视图(InteractionView)，对象通过交互来实现行为(xíngwéi)，交互视图通过协作来进行建模，协作具有结构和行为两个方面，结构包含为行为方面而定义的一系列角色和关系，行为方面是绑定于角色的对象间的一系列交换的消息，这些消息在协作中称为交互，消息序列可用两种图来表示：顺序图（重点在消息的时间顺序）和协作图（重点在交换消息的对象间的关系）。交互(jiāohù)行为共一百三十四页物理视图(PhysicalView)，许多系统模型独立于最终的实现，在实现方面，必须充分考虑系统的重用性和性能。UML有两种视图来表示系统的实现：实现视图和部署视图，实现视图将可重用的系统片段打包成组件(zǔjiàn)，部署视图描述系统运行时资源的物理分布，这些资源称为结点。物理(wùlǐ)实现共一百三十四页静态视图（类图，对象图），物理视图（实现视图，部署视图）是描述系统的静态结构。用例图是描述系统的外部视图。活动图描述系统的外部/内部视图。交互视图（顺序图，协作图）描述系统的内部视图。状态图描述单个类的动态(dòngtài)行为。各种(ɡèzhǒnɡ)图之间的关系共一百三十四页模型管理视图(ModelManagementView)，任何大系统必须划分为较小的单元，以使人们能在某一时刻只接触有限(yǒuxiàn)的信息，不影响团队间的并行工作。模型是利用包(Package)和包的依赖来进行管理的。包是UML模型中通用的层次组织结构，包上的依赖总结了包内容的依赖关系。模型(móxíng)组织共一百三十四页扩展机制(ExtensionMechanisms)，UML能满足绝大部分系统建模的需要，但任何语言都不是(bùshi)万能的，它必须考虑一定的扩展机制，UML的扩展机制包括约束、标签值和原型。这些扩展机制可以用来为特定领域剪裁UML的配置，这样带来一些好处：根据自身需要来使用建模语言。扩展(kuòzhǎn)机制共一百三十四页一个模型必须首先(shǒuxiān)定义各种事物的内部特征和相互之间的关系，下面介绍一些基本的模型元素：分类(fēnlèi)：类（Class）接口（Interface）子系统（SubSystem）执行者（Actor）用例（UseCases）组件（Component）结点（Node）注释（Comment)关系：关联（Association）泛化（Generalization）依赖（Dependency）实现（Realization）约束（Constraint)静态视图：类图对象图静态建模共一百三十四页类是具有相同属性、操作和关系的对象集合的总称。通常在UML中类被画成矩形，包括三个部分：名称、属性和操作。名称：每个类都必须有一个名字，用来区分其它的类。类名(lèimínɡ)是一个字符串，称为简单名字。路径名字是在类名(lèimínɡ)前加包含类的包名为前缀。例如Wall、java::awt::Wall都是合法的类名。属性：类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了，也可以在属性名后跟上类型甚至缺省取值。

操作：操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。

静态(jìngtài)建模-类共一百三十四页类名(lèimínɡ)属性(shǔxìng)操作共一百三十四页接口是未给出实现的对象行为的描述(miáoshù)，接口包含操作，但没有属性，一个或多个类可以实现接口，每个类实现接口的操作。StringisEqual(String):BooleanHash():Integer…HashableComparable接口(jiēkǒu)标记静态建模-接口共一百三十四页任何大系统都必须划分为较小的单元，以便人们在某一时刻可以和有限的信息工作，使团队的工作不相互影响。包可以包含各种模型(móxíng)元素和其它的包，包之间还可能存在一定的依赖。<<subsystem>>Finances<<subsystem>>Credits<<subsystem>>Accounts<<subsystem>>BankInterface静态(jìngtài)建模-子系统（包）共一百三十四页执行者是与系统、子系统或类交互的外部人员(rényuán)，进程或事务。在运行时，具体人员(rényuán)会充当系统的多个执行者，不同用户可能会成为一个执行者。StudentProfessorBillingSystemRegistrar静态(jìngtài)建模-执行者共一百三十四页用例是系统提供的外部可感知的功能单元，用例的目的是定义清晰的系统行为，但不解释系统的内部结构。用例可以与执行者关联，也可以参与(cānyù)其他的多种关系，比如扩展、泛化和包含等。用户的动态部分用交互视图来描述，比如顺序图、协作图。用例用椭圆来表示，用例名标在椭圆下方，用实线与同自身通信的用户相连。MaintainCurriculum静态(jìngtài)建模-用例共一百三十四页Registrar--maintainthecurriculumProfessor--requestrosterStudent--maintainscheduleBillingSystem--receivebillinginformationfromregistrationMaintainScheduleMaintainCurriculumRequestCourseRoster静态(jìngtài)建模-用例共一百三十四页用例图描述执行者在各个用例中的参与(cānyù)情况。StudentRegistrarProfessorMaintainScheduleMaintainCurriculumRequestCourseRosterBillingSystem静态(jìngtài)建模-用例图共一百三十四页组件是可重用的系统片段，具有良好定义接口的物理实现单元。每个组件包含了系统设计中某些类的实现。组件设计的原则：良好的组件不直接依赖于其它组件，而是依赖于其它组件所支持的接口。这样的好处是系统中的组件可以被支持相同接口的组件所取代(qǔdài)。一个组件可能是源代码、可执行程序或动态库。Student静态(jìngtài)建模-组件共一百三十四页结点代表系统运行时的物理对象，结点通常拥有运算能力，它可以容纳对象和组件(zǔjiàn)实例。RegistrationDatabaseLibraryDormMainBuilding静态(jìngtài)建模-结点共一百三十四页注释用于解释设计的思路，便于理解。一个好的模型应该(yīnggāi)有详尽的注释。RepresentsanincorporatedentityCompany…注释(zhùshì)静态建模-注释共一百三十四页关联描述了系统中对象和其它实例之间的离散(lísàn)的连接，关联是有序的，它允许重复，关联的实例是链。关联至对象的连接点称为关联端点，很多信息被附在关联端点上，它拥有角色名、重数（多少个类的实例可以关联于另一个类的实例），可见性等。关联有自己的名称，可以拥有自己的属性，这时关联本身也是类，称为关联类。静态(jìngtài)建模关系－关联共一百三十四页ManagesJobbossworkeremployeeemployer1..***0..1CompanyPersonJobSalary角色(juésè)名重数(zhònɡshù)关联名称关联类二元关联自关联共一百三十四页聚集(jùjí)（Aggregation）用来表达整体－部分关系的关联。组合（Composition）是一种聚集，是关联更强的形式。PolygonPoint13..*pointsContainsPolygonWindowSlider12ScrollbarHeader1Title11Panel1Body聚集(jùjí)组合静态建模关系－聚合和组合共一百三十四页泛化是一般化和具体化之间的一种关系。继承就是一种泛化关系，更一般化的描述称为双亲，双亲的双亲称为祖先，更具体化的描述称为孩子，在类的范畴(fànchóu)，双亲对应超类，孩子对应子类。TreeOakElmBirch孩子(háizi)双亲PersonStudentGraduate祖先静态建模关系－泛化共一百三十四页多重继承：一个孩子可以从多个双亲继承属性和方法。多重继承可能存在冲突，因为(yīnwèi)被继承的双亲可能存在相同的类声明，这时，最好显式解决冲突问题。AssistantTeacherStudent静态(jìngtài)建模关系－多重继承共一百三十四页依赖指明两个或两个以上(yǐshàng)模型元素之间的关系。依赖有很多种类，比如：实现（realize）、使用、（usage）、实例化（instantiate）、调用（call），派生（derive）、访问（access）、引入（import）、友元（friend）等等。<<subsystem>>ApplicationServer<<subsystem>>DataBase<<usage>>依赖(yīlài)类型静态建模关系－依赖共一百三十四页实现是依赖的一种，但由于它具有特殊意义，所以将它独立讲述。实现是连接(liánjiē)说明和实现之间的关系。StringisEqual(String):BooleanHash():Integer…Comparable<<interface>>ComparableisEqual(String):BooleanHash():Integer…实现(shíxiàn)特殊的实现标记静态建模关系－实现共一百三十四页约束用来(yònɡlái)表示各种限制，如关联路径上的限制，和属性特征检测（存在、所有）。PersonCommitteeMember-of约束(yuēshù)Chair-of{subset}静态建模关系－约束共一百三十四页静态视图是UML的基础，静态视图表示(biǎoshì)为类图，主要是描述类和类之间的关系。继承(jìchéng)关联PersonHouseresidence0..*owner0..*Financial

Institutionclientcreditor0..*0..*Mortgageprincipalrateterm关联类{ordered}0..*1BankTrust

Company静态建模－类图共一百三十四页对象(duìxiàng)图是系统在某一时刻的快照。Smith:Personcottage:Househome:Housefirst:Mortgagesecond:MortgageRoyalBank:Bank链静态(jìngtài)建模－对象图共一百三十四页状态机图用例图活动(huódòng)图顺序图协作图动态(dòngtài)建模共一百三十四页状态机图是对单个类的对象的生命周期进行建模，描述了对象时间上的动态行为，每个对象被认为是事件驱动的孤立实体。状态机图是由状态和跃迁组成的图，通常状态机附属于类，描述类实例对接受(jiēshòu)事件的响应。事件表达对象间的调用、显式信号、值的改变或时间的推移。调用事件、变更事件、信号事件、时间事件状态描述对象生命周期的一段时间，可以是等待其它事件时所处的时间，或是执行某一活动时所处的时间，状态分为简单状态和复合状态。动态(dòngtài)建模-状态机图共一百三十四页跃迁定义对象对某一事件发生的反应，通常，迁移具有触发事件、跃迁条件、动作和目标状态。跃迁的种类有外部跃迁和内部跃迁。外部跃迁是最普通的跃迁，会发生状态改变；内部跃迁不发生状态改变。跃迁有两个隐式动作：进入动作和退出动作。无论何时进入和退出时都要执行，这方便(fāngbiàn)进入时进行初始化工作，退出时进行资源的释放工作。动态(dòngtài)建模-状态机图共一百三十四页createdreadyHandle

EventInitialize

ObjectTerminate

ObjectWaitfor

Eventstart/^master.ready()poll/^master.ack()stop/初始状态结束(jiéshù)状态状态机状态(zhuàngtài)触发事件动作表达式跃迁共一百三十四页用例图描述各个执行者在各个用例中的参与情况，描述系统为用户所感知的外部视图。用例图的功能：捕获系统用户需求描述系统边界指明系统外部行为(xíngwéi)指导系统开发者的功能开发系统建模的起点，指导所有的类图和交互图的设计产生测试用例，用户文档估计项目大小和进度。动态(dòngtài)建模-用例图共一百三十四页CustomerSalesmanSupplierSupervisorSaleManagementSupply执行者用例系统(xìtǒng)边界共一百三十四页活动图是用状态机对工作流进行建模的特殊形式，它和流程图很类似，不过它支持并发控制。活动图一般不描述所有的运算细节，它显示活动的流，但不显示执行活动的对象。活动图处于系统的外部和内部视图之间，所以它可以作为设计的起点，为了完成设计，每个活动必须扩展成一个和多个操作，每个操作被指派给特定的对象来实现。将商业组织控制的活动划分在一起，这类划分可以通过分隔的区域来表达，由于它们的外观，每个区域称为(chēnɡwéi)泳道（swimlane）。动态(dòngtài)建模-活动图共一百三十四页CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道(yǒnɡdào)共一百三十四页带有对象(duìxiàng)流的活动图CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道(yǒnɡdào)Order[Placed]Order[Entered]Order[Filled]Order[Delivered]对象共一百三十四页对象行为是通过交互来实现的，交互是对象间为完成某一目的而进行的一系列消息交换。消息是对象间的单向(dānxiànɡ)通信，从发送者到接受者的携带信息的控制流。消息可能带有值参。消息序列可用两种图表示：顺序图（重点在消息的时间顺序）和协作图（重点在交换消息的对象间的关系）。对协作图来说，时间顺序可以从顺序号获得。动态(dòngtài)建模-交互视图共一百三十四页顺序图用二维表来表示交互，纵向是时间轴，横向是参与的角色以及(yǐjí)它们交换的消息。角色的生命周期表现为生命线，一条垂直的线，在激活的时间段里是双线，在状态保持的时间里是虚线。消息表示为从一条生命线出发到另一条生命线的有向线，从上而下，表示消息的时间顺序。动态(dòngtài)建模-顺序图共一百三十四页CallerOperatorCallee时间轴callacknumbercallacktalktransfer顺序(shùnxù)图生命线激活(jīhuó)状态保持角色共一百三十四页协作图包含分类角色和关联角色，当它实例化时，对象被绑定到分类角色，链被绑定到关联角色.关联角色还可能被各种暂时性的链来充当，如过程参数(cānshù)和局部过程变量，链可以指定暂时性的原型：<<parameter>>、<<local>>或自身调用<<self>>。协作图对实现协作的对象和链进行建模，而忽略其他对象。动态(dòngtài)建模-协作图共一百三十四页StudentRegistrationFormRegistrationManager1:fillininfo2:submit3:add(smith,math)math4:add(smith)共一百三十四页通常在一个协作图中每个对象(duìxiàng)分配一个符号，然而有时不同状态的对象(duìxiàng)需要显式指出，流将同一个对象的不同状态版本关系在一起，使用<<become>>原型。流的<<copy>>原型不太常用。:Controller:Directory[closed]:Directory[open]1:expand()2:sort()1.1<<become>>流共一百三十四页物理架构-实现(shíxiàn)视图实现视图描述可重用的系统组件(zǔjiàn)以及组件(zǔjiàn)之间的依赖。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem共一百三十四页部署视图描述系统资源在运行时的物理分布(fēnbù)，系统资源成为结点。RegistrationDatabaseLibraryDormMainBuilding物理架构-部署(bùshǔ)视图共一百三十四页UML是一种建模语言而不是方法，这是因为UML中没有过程的概念，而过程正是方法的一个重要组成部分。UML本身独立于过程，这意味着用户在使用UML进行建模时，可以选用任何适合的过程。一般采用(cǎiyòng)的建模过程有：喷泉模型、迭代递增开发模型。UML建模过程(guòchéng)共一百三十四页UML建模过程-瀑布(pùbù)开发模型需求阶段面向对象分析阶段面向对象设计阶段编码阶段集成和测试阶段运行状态进一步开发维护期共一百三十四页设计编码测试更多需求与分析迭代(diédài)递增开发模型最初需求(xūqiú)与分析产品维护请求共一百三十四页[1]需求最初需求规格说明应当由代表系统最终用户的人员提供，内容包括系统基本功能需求和对计算机系统的要求。[2]分析分析的任务是找出系统的所有需求并加以描述，同时建立模型，以定义系统中的关键领域类，应由系统用户和开发人员合作完成。分析的第一步是定义用例，以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明，此时需要(xūyào)与系统的潜在用户进行讨论。迭代(diédài)递增开发模型共一百三十四页[3]设计设计阶段的任务是通过综合考虑所有的技术限制，以扩展和细化分析阶段的模型。设计阶段可以分为两个部分：结构设计是高层设计，其任务是定义包（子系统），包括包间的依赖性和主要通信机制。我们希望(xīwàng)得到尽可能简单和清晰的结构，各部分之间的依赖尽可能的少，并尽可能的减少双向的依赖关系。第二部分是详细设计，细化包的内容，使编程人员得到所有类的一个足够清晰的描述。共一百三十四页结构设计一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离(fēnlí)出应用逻辑（领域类），从而减少它们之间的依赖性。详细设计详细设计的目的是通过创建新的类图、状态图和动态图（顺序图、协作图和活动图），描述新的技术类，并扩展和细化分析阶段的对象类。共一百三十四页[4]实现构造或实现阶段是对类进行编程的过程。可以(kěyǐ)选择某种面向对象对象编程语言（如Java）作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射，因为类到Java代码文件之间是一一映射关系。在实现阶段中，可以选取各种图的说明来辅助编程，比如：类图，状态图和动态图等。共一百三十四页[5]测试和配置完成系统编码后，需要对系统进行测试，它通常包括：单元测试、集成测试、系统测试和验收测试。

在单元测试中使用类图和类的规格说明，对单独的类或一组类进行测试；在集成测试中，使用组件图和合作图，对各组件的合作情况进行测试；在系统测试中，使用用例图，以检验所开发的系统是否满足例图所描述的需求(xūqiú)。系统的配置是实际地交付系统，包括文档和组成模型等。共一百三十四页ROSE是美国Rational公司的面向对象建模工具，利用这个工具，我们可以建立用UML描述的软件系统的模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。ROSE的界面分为三个部分——Browser窗口、Diagram窗口和Document窗口。Browser窗口用来浏览、创建、删除(shānchú)和修改模型中的模型元素；Diagram窗口用来显示和创作模型的各种图；而Document窗口则是用来显示和书写各个模型元素的文档注释。Rose的使用(shǐyòng)共一百三十四页Browser窗口(chuāngkǒu)Diagram窗口(chuāngkǒu)Document窗口Specification对话框工具栏工具箱共一百三十四页Browser窗口(chuāngkǒu)有四个视图:UseCaseLogicalComponentDeployment共一百三十四页在UseCase视图(shìtú)的图的类型有：用例图、顺序图、协作图和活动图。共一百三十四页在Logical视图(shìtú)中的类型有：类图和状态图。共一百三十四页在Component视图(shìtú)的图的类型有：组件图。共一百三十四页在Deployment视图的图的类型(lèixíng)有：部署图。共一百三十四页用例图共一百三十四页顺序(shùnxù)图共一百三十四页协作(xiézuò)图共一百三十四页活动(huódòng)图共一百三十四页类图共一百三十四页状态图共一百三十四页组件(zǔjiàn)图共一百三十四页部署(bùshǔ)图共一百三十四页很多教科书上的第一个程序就是(jiùshì)Helloworld，一个在屏幕上简单地打印出“Helloworld!”语句的例子。在java中一个在浏览器中显示“HelloWorld!”的Applet的代码如下：

importjava.awt.Graphics;classHelloWorldextendsjava.applet.Applet{ publicvoidpaint(Graphicsg){g.drawString("HelloWorld!",10,10); }}实例(shílì)一－HelloWorld共一百三十四页用例图HelloWorld共一百三十四页HelloWorld类HelloWorldPaint()g.drawString("HelloWorld!",10,10)

注释(zhùshì)共一百三十四页类图HelloWorldPaint()AppletGraphics

继承(jìchéng)使用(shǐyòng)依赖共一百三十四页顺序(shùnxù)图:Thread:Toolkit:ComponentPeertarget:HelloWorldruncallbackLoophandleExposepaint共一百三十四页执行者读者(dúzhě)图书馆员管理员用例图书馆管理实例(shílì)二－图书馆系统用例图共一百三十四页读者(dúzhě)用例图共一百三十四页图书馆员用例图共一百三十四页管理员用例图共一百三十四页下载网站(wǎnɡzhàn)：/down/soft/100.htmUML技术网站：/别人(biérén)的ROSE建模演示共一百三十四页软件开发环境中的一些(yīxiē)工具软件建模工具：1.UML建模工具：ROSE;2.UML2.x建模工具TrufunPlato2008;3.开源(kāiyuán)UML建模工具StarUMLv5.0.24.UML设计测试工具5.数据库建模工具：PowerDesigner共一百三十四页软件开发环境(huánjìng)中的一些工具软件测试工具：1.AutoRunner自动化软件测试工具，是一种黑盒测试工具，对.NET类型的应用软件进行功能测试,支持标准Windows应用程序测试和.NET应用程序测试。对B/S系统进行功能测试，支持各种B/S应用(yìngyòng)和网站。共一百三十四页2.WinRunner：Mercury公司，用于功能性测试；

Winrunner最主要的功能是自动重复执行某一固定的测试过程，它以脚本的形式记录下手工测试的一系列操作，在环境相同的情况下重放，检查其在相同的环境中有无异常的现象或与实际结果不符的地方。可以减少由于人为因素造成结果错误，同时也可以节省测试人员大量测试时间和精力来做别的事情。功能模块主要包括：GUImap、检查点、TSL脚本编程、批量测试、数据驱动(qūdònɡ)等几部分软件开发环境(huánjìng)中测试工具共一百三十四页3.LoadRunner：Mercury公司，性能与负载压力；

LoadRunner®是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，还能支持广范的协议和技术(jìshù)，为您的特殊环境提供特殊的解决方案。软件开发环境(huánjìng)中测试工具共一百三十四页4.QuickTestPro：Mercury公司，功能测试和回归测试；

QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTestProfessional，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。MercuryQuickTestPro是一款先进(xiānjìn)的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。MercuryQuickTestPro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。软件开发环境(huánjìng)中测试工具共一百三十四页5.TestDirector：Mercury公司，测试管理；基于WEB的测试管理工具，他能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单(jiǎndān)和有组织。他能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。T