搜索
经典的软件工程思想将软件开发分成5个阶段:需求分析\系统分析与设计;系统实现\测试及维护五个阶段。序言如果想搭一个狗窝，备好木料、钉子和一些基本工具（如锤子、锯和卷尺）之后，就可以开始工作了。从制定一点初步计划到完成一个满足适当功能的狗窝，可能不用别人帮助，在几个小时内就能够实现。只要狗窝够大且不太漏水，狗就可以安居。如果未能达到希望的效果，返工总是可以的，无非是让狗受点委屈。如果你要建造一座高层办公大厦，若还是先备好木料、钉子和一些基本工具就开始工作，那将是非常愚蠢的。因为你所使用的资金可能是别人的，他们会对建筑物的规模、形状和风格做出要求。同时，他们经常会改变想法，甚至是在工程已经开工之后。由于失败的代价太高了，因此必须要做详尽的计划。负责建筑物设计和施工的是一个庞大的组织机构，你只是其中的一部分。这个组织将需要各种各样的设计图和模型，以供各方相互沟通。只要得到了合适的人员和工具，并对把建筑概念转换为实际建筑的过程进行积极的管理，将会建成这座满足使用要求的大厦。如果想继续从事建筑工作，那么一定要在使用要求和实际的建筑技术之间做好平衡，并且处理好建筑团队成员们的休息问题，既不能把他们置于风险之中，也不能驱使他们过分辛苦地工作以至于精疲力尽。奇怪的是，很多软件开发组织开始想建造一座大厦式的软件，而在动手处理时却好像他们正在仓促地造一个狗窝。有时你是幸运的。如果在恰当的时间有足够的合适人员，并且其他一切事情都很如意，你的团队有可能（仅是可能）推出一个令用户眼花缭乱的软件产品。然而，一般的情况下，不可能所有人员都合适（合适的人员经常供不应求），时间并不总是恰当的（昨天总是更好），其他的事情也并不尽如人意（常常由不得自己）。现在对软件开发的要求正在日益增加，而开发团队却还是经常单纯地依靠他们唯一真正知道如何做好的一件事——编写程序代码。英雄式的编程工作成为这一行业的传奇，人们似乎经常认为更努力地工作是面对开发中出现的各种危机的正常反应。然而，这未必能产生正确的程序代码，而且一些项目是非常巨大的，无论怎样延长工作时间，也不足以完成所需的工作。如果真正想建造一个相当于房子或大厦类的软件系统，问题可不是仅仅编写许多软件。事实上，关键是要编出正确的软件，并考虑如何少写软件。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。即使如此，很多项目开始看起来像狗窝，但随后发展得像大厦，原因很简单，它们是自己成就的牺牲品。如果对体系结构、过程或工具的规范没有作任何考虑，总有一天狗窝会膨胀成大厦，并会由于其自身的重量而倒塌。狗窝的倒塌可能使你的狗恼怒；同理，不成功的大厦则将对大厦的租户造成严重的影响。不成功的软件项目失败的原因各不相同，而所有成功的项目在很多方面都是相似的。成功的软件组织有很多成功的因素，其中共同的一点就是对建模的采用。一、项目开发中模型是什么以及建模的重要性。那么，模型是什么？简单地说：模型是对现实的简化。模型提供了系统的蓝图。模型既可以包括详细的计划，也可以包括从很高的层次考虑系统的总体计划。一个好的模型包括那些有广泛影响的主要元素，而忽略那些与给定的抽象水平不相关的次要元素。每个系统都可以从不同的方面用不同的模型来描述，因而每个模型都是一个在语义上闭合的系统抽象。模型可以是结构性的，强调系统的组织。它也可以是行为性的，强调系统的动态方面。为什么要建模？一个基本理由是：建模是为了能够更好地理解正在开发的系统。通过建模，要达到4个目的：（1）模型有助于按照实际情况或按照所需要的样式对系统进行可视化。（2）模型能够规约系统的结构或行为。（3）模型给出了指导构造系统的模板。（4）模型对做出的决策进行文档化。建模并不只是针对大的系统。甚至像狗窝那样的软件也能从一些建模中受益。然而，可以明确地讲，系统越大、越复杂，建模的重要性就越大，一个很简单的原因是：因为不能完整地理解一个复杂的系统，所以要对它建模。人对复杂问题的理解能力是有限的。通过建模，缩小所研究问题的范围，一次只着重研究它的一个方面，即把一个困难问题划分成一系列能够解决的小问题；解决了这些小问题也就解决了这个难题。此外，通过建模可以增强人的智力。一个适当选择的模型可以使建模人员在较高的抽象层次上工作。每个项目都能从一些建模中受益。即使在一次性的软件开发中——由于可视化编程语言的支持，可以轻而易举地扔掉不适合的软件。建模也能帮助开发组更好地对系统计划进行可视化，并帮助他们正确地进行构造，使开发工作进展得更快。如果根本不建模，项目越复杂，就越有可能失败或者构造出错误的东西。所有实用系统都有一个自然趋势：随着时间的推移变得越来越复杂。虽然今天可能认为不需要建模，但随着系统的演化，终将会对这个决定感到后悔，但那时为时已晚。在项目开发中如何建模，接下来我将详细讲解一下建模工具UML。二、UML介绍UML(UnifiedModelingLanguage)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。UML是一种功能强大的,面向对象的可视化系统分析的建模语言,它的各个模型可以帮助开发人员更好地理解业务流程,建立更可靠,更完善的系统模型.从而使用户和开发人员对问题的描述达到相同的理解,以减少语义差异,保障分析的正确性。UML建模分为需求建模和设计建模，需求建模的目的是确定系统边界并明确系统需要实现的功能。而设计建模主要目的是用于开发团队中的设计思想交流；以及后续程序设计的依据；后续测试和验收程序的依据。）三、UML应用领域UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。为实现用例，类之间需要协作，这可以用UML动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。总之，标准建模语言UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。四、UML图形种类介绍UML从考虑系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图，按其特点可分成五大类，1.用例图；2.静态图：（类图、对象图）；3.行为图：（活动图、状态图）；4.交互图：（顺序图、协作图）；5.实现图：（构件图、部署图）。这些图从不同的侧面对系统进行描述。系统模型将这些不同的侧面综合成一致的整体，便于系统的分析和构造。1、用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。7、协作图和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。9、部署图（配置图）是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。以上图形中由于类图之间的关系相对比较复杂，所以对于类图之间的关系进行一个大致的讲解。其关系种类有关联、聚合、组合、泛化、依赖。1.泛化（Generalization）【泛化关系】：是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为.例如：老虎是动物的一种,即有老虎的特性也有动物的共性.【箭头指向】：带三角箭头的实线，箭头指向父类2.实现（Realization）【实现关系】：是一种类与接口的关系,表示类是接口所有特征和行为的实现.【箭头指向】：带三角箭头的虚线，箭头指向接口3.关联（Association)【关联关系】：是一种拥有的关系,它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。【代码体现】：成员变量【箭头及指向】：带普通箭头（或实心三角形箭头）的实心线，指向被拥有者上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。4.聚合（Aggregation）【聚合关系】：是整体与部分的关系,且部分可以离开整体而单独存在.如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在.聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。【代码体现】：成员变量【箭头及指向】：带空心菱形的实心线，菱形指向整体5.组合(Composition)【组合关系】：是整体与部分的关系,但部分不能离开整体而单独存在.如