面向对象的uml与java总chapter

1、Software Development with UML Copyright Ken Lunn 2003开发过程管理杨天剑Software Development with UML Copyright Ken Lunn 2003组织机构在不同软件开发中所扮演的角色组织机构是软件开发的基础。好的组织机构无论应用什么工具和技术，都会使开发获得成功；有问题的组织机构，即使使用最好的工具也会将事情弄糟。这并不意味着有一种特殊类型的组织机构注定会取得成功。没有完美的组织机构，对于同样的任务，完全不同的组织机构能够同样获得成功。事实上，不同的技术，不同的管理方法和不同的技能特点适合不同的组织和环境 这一

2、点并不难理解，但可悲的是还需要明确地指出来。我们将从不同的组织类型开始，接下来，将讨论一些典型的角色。至于每种组织的类型是怎样使用每种角色的，并不是简短的介绍文字所能包含的。最后，我们会着眼于一个实例的研究，看一下它们在软件生产中是如何进行组织的。Software Development with UML Copyright Ken Lunn 2003组织机构的类型Charles Handy ，在“Gods of Management” ( Handy , 1995 ）一书中描述了四种典型的组织文化。每一种都有自己的成功之处，并且每一种都会在一些任务中比其他几种有优势。这些文化容易吸引特定类型

3、的人。在开始时，文化并不总是明显的，在现实中，真实的组织结构将是多种文化的混合。理解文化的类型有助于合适的与可接受类型的开发。在一个实行俱乐部文化的公司中，设立较强的基于角色的软件开发组织是没有什么益处的 这不会取得成功。认识你周围的文化类型能有助于实现目标并且避免不必要的冲突。Software Development with UML Copyright Ken Lunn 2003基于角色的文化基于角色的文化倾向于大的有良好规范的组织机构。人们把过程分成几个组成部分，并且根据这些部分规划工作。人员和小组是专业化的。遵循正式的工作方式，进行定期的办公会议并在组织机构的不同部分之间采用标准的信息

4、交流方法。这些组织机构善于完成重复的任务。许多成熟的IT系统以这种方式进行管理。团队是明确定义的，并且工作按照时间表来执行。不利的方面是，分等级的组织结构不擅长开始新的和创造性的冒险，也不擅长在压力下进行快速生产。基于角色的文化喜欢“组织图表”，如图所示。在基于角色文化的组织中，管理人员在说明其角色时，首先要给出组织图表，指出他的位置、老板是谁以及谁向他报告。基于角色的文化会把开发排列成定义明确的部分。会有一个项目办公室负责规划和提供资源，还有业务分析部、系统设计部、设计人员、开发人员或编程人员、数据库小组、测试小组以及帮助台。每一个重要角色区域都会有管理人员和在各阶段把握项目方向的项目管理人

5、员。统一过程看起来鼓励这种组织类型，统一过程定义的角色不只适合于统一过程，也能够应用在其他类型的组织中。Software Development with UML Copyright Ken Lunn 2003Figure 6.1 A typical organization chart in a role-based companySoftware Development with UML Copyright Ken Lunn 2003俱乐部文化俱乐部文化中有一个很强的中心人物，这个人与和他志趣相投的人在一起，并让他们担任很强的责任，但也期待结果与忠诚。任何与这种文化有冲突的人都会很快离开或

6、导致组织解散。优点：俱乐部文化几乎没有正式的管理机制，信息的相互沟通是直接的，小的软件公司倾向于这样的运作方式。这样的组织能对形势做出快速的反应，并能很快地将想像付诸实施。缺点：他们被中心人物的想法所左右，一旦组织的核心瓦解，他们将很快失去方向。你可以通过管理者介绍他们团队的方式来了解俱乐部文化。俱乐部文化强调个体与个性，使用名字而不是角色的称谓，即用名字称呼高级员工。在员工的名片上常常有重要的头衔，但主要说明他们是谁，而不是他们的职位高低。基于俱乐部的文化不像基于角色文化那样严格进行控制。在 IT 开发中，个体可以有许多角色。不会有正式的文档生成，并且，需要快速得出结论。在俱乐部文化中，你必

7、须在给定的时间内拿出问题的解决方案，如果是因为需要了解系统的所有阶段和修正所有的分析与设计的模型而不能完成任务将不被认可；你要么在这里修改代码，要么另找一份工作。Software Development with UML Copyright Ken Lunn 2003任务文化任务文化集中在特殊的任务上。任务文化关注于结果，并且，为了完成目标，会改变其内部的组织结构。其中，没有明确的角色划分。一旦任务完成，这些人员就会离开。任务文化是能够在团队中工作的有很高技能的那些个人的充分体现。他们工资很高，而又十分高效。 lT 顾问和研究机构倾向于任务文化，他们常应邀解决一些特殊的问题。任务文化的不利方面

8、是，当问题得以解决，以及生产或服务从创造性阶段转向维护阶段之后，任务文化也就失去了意义。由于职员以及管理人员经常讨论问题及其解决方法，因此，你能够识别出这是一个基于任务的文化。他们通常快速地了解新的形势，并且提出观点。任务文化不如俱乐部文化那样看重个性，也不看重角色。基于任务的文化使用所有有用的方法。如果利用 UML 建模有助于得到更好的解决方法，任务文化也会使用。如果直接租用代码工作最好，他们同样将那样做。结论产生于过程之前，由于任务文化招募新成员是面向那些有成就的，有很高技能的人，因此他们通常会做出很好的结果，但却疏于形成正式的文档，并且难以维护。Software Development

9、with UML Copyright Ken Lunn 2003存在的文化存在的文化主要是由以个体工作的专业人士构成。典型的例子有初级律师、高级律师和医生。具有专门技能的个体是受推崇的，并且，在这里组织机构给予个体相应的支持。这些环境中的管理人员比他们管理的个体的地位要低。尽管现代社会的压力把大学推向基于角色的文化，但还是与存在的文化很相似。很少有 IT 组织是基于这种模型的。存在的文化不倾向于开发软件，除非作为一种扩展专业技能的手段。如果你正在攻读阵博士学位，会发现自己就处在这种文化之中。但是，大多数情况下你会以个人的身份工作，磨练自己的才能，而不只是制造出产品团队中的一个成员。对于还没有毕

10、业的大学生，当他们走进一个行业会碰到的一个问题是，他们成长时所处的文化在很大程度卜是存在的文化，并且，他们儿乎没有参与其他类型文化的亲身经验。作为学生，他们主要以个体行动，并且，他们承担的绝大多数工作是针对个人而不是针对一个团队的。一些教育环境设法在他们的环节中增加一些团队的观念，但是对于大部分学生而言，教育环境却力图发展并证明个人的才能，至少在 lT 学科方面是这样。Software Development with UML Copyright Ken Lunn 2003混合文化很少有组织在文化上是单纯的。基于角色的组织常常允许甚至促进不同形式的亚文化群。例如，常常会建立一个基于任务的研究小

11、组，以及基于俱乐部文化的商品销售部门。在组织发展中，俱乐部文化常会充分发展到角色文化。有时候俱乐部文化设立基于角色的亚文化群来管理例行的长期工作。对于软件开发来说，哪种文化是适当的呢？首先，不同的文化使用其特殊的方式来解决软件开发这个问题。它们不回避基本的软件开发过程，但是，在具体操作上，却有相当大的区别。知道你工作所处的文化和你的偏好是十分重要的。我的绝大部分工作经历是基于任务文化的（研究和开发，以及咨询），它是大型的并且基于角色文化的一部分。我同样花费了相当多的时间在存在的文化上（大学研究）。最近，我加人了俱乐部文化，在开始时我并没有认清这种种文化。很快，我就与高级经理一起工作了，但是我怀

12、疑我认为仓促的且高风险决策的正确性。对这些决策的反对使我很快离开中心，在俱乐部文化中，我仅仅工作两年就被淘汰出局。Software Development with UML Copyright Ken Lunn 2003混合文化对文化的理解对我们在方法的选择方面确实有所帮助。与其他形式的组织相比，统一过程更适合于基于角色的组织机构。事实上，大部分模型驱动的方法论都可能在这种形式的文化中找到根源。基于任务的文化挑选一些模型和方法论的某些部分。俱乐部文化会采用所有他们喜欢的方法，但是，过于正式的形式是不受欢迎的。极限编程和许多轻量级的方法将目标对准那些更看重交付成果的组织机构，它们似乎更适合俱乐部

13、文化和基于任务的文化，而不是基于角色的文化。Software Development with UML Copyright Ken Lunn 2003项目的主要角色1、指导小组对于大规模软件开发来说，需要有一些高水平的团队负责设定项目的目标并提供经费通常称之为指导小组。对于一些项目和一些组织，指导小组是现有的一组管理人员 不是公司的董事会，就是某些正式的管理委员会。有时候，对于特殊类型的项目，要建立专门的指导小组。指导小组制定项目的主要目标。这些目标可能会随着时间改变，可能因为市场发生变化也可能因为项目开发中的实际情况而出现不同的局限性或可能性。关于目标的对一话将在小组与项目的管理层的内部进行

14、。指导小组掌握着项目经费。通常是根据定期进度报告，阶段性地发放经费。资金的发放要取得预计的目标。在第 7 章讨论的成本效益模型对于项目的批准和进度跟踪是十分重要的。指导小组对项目中的高级别风险进行监控。项目失败是软件开发生命期的一种实际情况。有时候这是项目的内在原因引起的，源于糟糕的管理或技术的固有风险。有时候，原因在项目之外，比如业务活动的衰退或组织目标的改变。指导小组要负责终止那些不再具有可行性的项目。Software Development with UML Copyright Ken Lunn 2003不同文化组织中的指导小组基于角色的组织通常会建立管理和委员会机构来履行指导小组的职责

15、。委员的选择要取决于项目的规模和重要性。对于 ICANDO 化学制品这种重要的项目，作为指导委员会的是 ICANDo 化学制品董事会。俱乐部文化有起指导小组作用的中心人物，或者，中心人物将建立由选出的个体组成的指导小组。对于 ICANDO UK零售交易，市场经理建立了一个包括他本人、他的财政经理、他的 IT 经理以及零售促销业务经理在内的指导团队。基于任务的文化不倾向于建立他们自己的正式指导小组，但是，他们通常是一个大规模文化的一部分（或是为其工作），而这个大规模文化将会建立一个指导小组。给客户的咨询将报告给客户设立的指导小组。对于 ICANDO 的储站安全应用，研究机构举办6个月一次的会议。

16、这个会议是在研究部门和业务执行部门高级经理间进行的，用来检查项目的进展情况。Software Development with UML Copyright Ken Lunn 2003项目中的主要角色2、项目经理通常是指派一个个体担当管理项目的角色。项目经理向指导小组报告，并且负责协调项目中的各个部分。项目经理的关键任务是确保项目按计划进行、实施项目的资源就绪、识别并指出风险和项目按时交付。项目管理是一个需要不断进行协商的角色。基于角色的组织比较正统，包括了常规的计划和不同团队的管理人员参与的进度会议。一些独立的小组有可能同时针对多个项目工作，不时也会有一些资源上的冲突。同样，这些工作需要有规划

17、并进行冲突处理。在基于任务的组织中，项目管理人员更愿意参与到过程中，可能会从中直接收集到许多信息。在俱乐部文化中，项目经理可能是核心的一部分，并且可以自由地按他或她认为适合的方式组织项目。Software Development with UML Copyright Ken Lunn 2003其他角色在所有的组织中，指导小组和项目经理可能以某些不同的形式出现。对基于角色的组织机构来说，接下来的角色是具有代表性的。在基于任务或基于俱乐部的组织机构中，这些角色可能会合并在一起，或者在某些不常见的实例中被去掉。Software Development with UML Copyright Ken L

18、unn 2003编程人员编程人员使用多种开发工具和语言，像 Java 或 visual Basic，他们按照设计构建部分系统。他们的工作主要是从类图、顺序图和已设计出的接口原型开始的。他们发现，查阅用例文档是很有用的。数据库设计师数据库设计师负责下层的数据库表，以及所有与维护一个安全可靠数据库有关的事情。这是一个从设计组中单独分离出来的关键的专门领域。他们使用设计组的输出，并且与编程人员紧密合作。他们关心形式化，确保事务得到可靠处理，确保有适当的数据备份和恢复的过程。Software Development with UML Copyright Ken Lunn 2003系统工程师当系统构建完

19、成之后需要被部署，首先在测试环境中部署并最终进入到用户环境中。在系统部署过程中，系统工程师由构架师（architect）、编程人员和数据库设计师指导。他们负责系统运行的可靠性，系统整体的安全性，以及日常的管理任务，比如数据库备份等。测试人员通常编程人员会对自己的工作进行“单元测试”。也就是说，他们确定自己的那部分工作可靠并符合要求。然而，依赖开发人员对系统进行测试并不是好的习惯。测试人员会通过业务过程定义和用例定义来构建一个测试策略，按实际中的使用方式来测试系统。他们执行测试，并且生成出错报告。Software Development with UML Copyright Ken Lunn 2

20、003帮助台操作员一旦系统运行起来，不可避免会有错误产生。可能从简单的问题，如用户忘记密码，到程序给出错误结果，甚至是系统根本不能工作。通常，组织机构有一个帮助台作为第一个呼叫点。帮助台操作员记录报告的问题，然后找一些人解决问题，对问题进行追踪直到完全解决。中间管理大型项目被分成若干个小组，由管理人员管理。这些管理者负责项目的一部分，例如业务分析或设计、实现。他们关心自己小组日常的问题，并与其他小组协作。他们与项目经理们一起合作，确定工作时间表与同意交付的决策。在同一时间，一个小组常常可能有很多项目，管理者将会根据优先权进行资源分配。Software Development with UML

21、Copyright Ken Lunn 2003构架师构架师负责系统的整体结构，以及构建系统使 JIJ 的一具他们与设计者进行大员的讨论，确保各部分恰当结合。在构建系统方面，构架师通常是具备相当才能并且经验丰富的设计者。一般说来，他们会是设计小组的一部分，在项目设计中起到领导作用，并且对设讨一的质量进行监控。 业务分析者业务分析者通过与人们合作来理解业务是怎样运作的。他们生成过程图来概括一个业务领域，用剧本分析来确定业务过程中的主要路径和替代路径。他们还使用活动图来提供过程的工作流描述。他们将识别支持现有业务过程的用例，或者待开发的业务过程用例。业务分析者经常给出系统的测试方案。Software

22、 Development with UML Copyright Ken Lunn 2003系统分析者系统分析者关心一个系统是怎样在业务内部运作的。他们设计出用例的细节，使用剧本分析决定系统运作的主要路径和替代路径。他们将勾画接口，并且很可能与开发者合作完成接口原型。系统分析者将会经常参与决定系统需求的数据，并且得出一些高层次的类图。 设计人员设计人员负责使用系统分析者的工作成果，并且把它们映射到系统的构架上。他们决定驱动这个系统的对象类和屏幕细节，与构架师一起对系统构架做出调整。设计人员的输出是一个关于系统要构建什么的规范说明书Software Development with UML Cop

23、yright Ken Lunn 2003风险管理正如我们之前所讨论的，软件开发是一项有风险的活动。需要在项目的所有层次上承认风险，并且必须要有风险处理程序。从项目小组最高级成员到最低级成员，在风险发生的时候，大家必须共同来关注风险，并且，要迅速采取行动来消除风险。处理风险的现代方法是迭代方法。某些应用程序在短的阶段中开发，定期整合成完整的产品。只要有可能，就部署中间产品。这对于彻底快速解决问题很有效，而不是成年累月地把问题积攒下来。我们先前讨论的另一种方法是风险登记。风险登记允许所有项目组成员提出他们识别的风险。需要按照他们提出的严重程度来评估风险，并指派一些人采取行动将风险减到最小，或者，最

24、理想地消除风险。风险需要提交到项目会议的议程中来。推迟处理风险是不可取的。取决于严重性，管理人员可能要跟踪风险。Software Development with UML Copyright Ken Lunn 2003进度与资源的计划为一个项目组织资源是一项复杂的活动。通常使用一个做计划的工具。理解一个项目中的依赖关系是必要的。开发的任何部分都需要经历开发过程的所有阶段。良好的计划依赖于精确的评估。在一个项目的初期阶段，这是一定有问题的。因为在没有经验的情况下，我们没有基础来估计需要多久才能构建软件的一个部分。开发常会遇到无法预料的障碍。迭代方法能对项目下一个阶段的评估给出参考。制订计划时需要考虑资源冲突。小组中进入和发出的工作流程不可能是平衡的。分析资料将会成批到达。测试小组在项目上将有一段虽短但却密集的工作时期。通常，如果把所有的活动按发生顺序设置成首尾相连，花费的时间会相当长，因为中间阶段人们都在从事不同的工作。项目规模越大，评估就越困难。没有计划，项目就像是一艘小船在广阔的充满危险的海洋上漂泊。小组中的每一个成员都要清楚整个计划，以及他们在计划中充当的角色。项目经理根据计划来定期检