|
|||
随笔分类 - Software Engineering
摘要：RUP是一套管理方法，用于项目从需求到发布的管理而敏捷则是一种思想，一种价值观：价值迭代交付，以人为本有一些基于敏捷思想的实践比如Scrum、XP等也都是管理方法或开发方法层面的内容RUP可以与敏捷的思想结合，可以在敏捷思想指导下进行管理，那就是敏捷的RUPXP 与CMM 、RUP 的比较CMM 告诉组织为了系统化地建立、实施和改进软件开发过程应该做些什么，但没有说明如何去做以及采用哪些具体的技术、策略和方法。CMM 是一套通用的过程实践标准，适用面很广。实施CMM 要求组织在过程的制度化建设上付出大量努力，通常被认为是重载（heavy-weight）的模型。XP 是一个针对某种特定环境（需求
阅读全文
posted @ 2011-06-06 20:23
摘要：简介：敏捷架构设计一文到目前已经全部结束，由于架构设计是一个很大的话题，要在一篇文章中完全把架构设计讲清楚是很难的。因此本文的最后一个章节中提供了一组书籍和文章，这些资料都和架构设计有关，本文的写作过程也从中获益良多，故而推荐给有兴趣的读者。Refactoring To Patterns（Joshua Kerievsky）勿庸置疑，模式是软件设计的一种有效的工具。但是在将模式和现实中的软件设计关联起来时，很多人往往迷惑于模式到底是如何应用的。结果是表现出两种极端：一是用不好模式，二是过度的滥用模式。模式是他人设计经验的总结，但是它在提供优秀的设计思路的同时也会增加一定的复杂性。因此，不了解模式
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：敏捷方法的兴起对设计提出了新的要求，其最核心的一点是针对无法在项目一开始就固化的需求进行演进型的设计。在项目一开始就进行细致、准确的架构设计变得越来越难，因此，架构设计在项目的进展中被不断的改进，这相应导致了编码、测试等活动的不稳定。但是，软件最终必须是以稳定的代码形式交付的。因此，架构设计必须要经历从不稳定到稳定的过程。而架构设计能够稳定的前提就是需求的稳定。需求冻结敏捷方法和传统方法的区别在于对待变化的态度。传统的做法是在编码活动开始之前进行充分、细致的需求调研和设计工作，并签署合同。确保所有的前期工作都已经完成之后，才开始编码、测试等工作。如果发生需求变化的情况，则需要进行严格的控
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：要保证架构的稳定和成功，利用代码对架构进行验证是一种实用的手段。代码验证的核心是测试，特别是单元测试。而测试的基本操作思路是测试优先，它是敏捷方法中非常重要的一项实践，是重构和稳定核模式的重要保障。面向对象体系中的代码验证代码验证是保证优秀的架构设计的一种方法，同时也是避免出现象牙塔式架构设计的一种措施。我们在上一篇稳定化中提到说架构设计最终将会体现为代码的形式，因此使用形式化的代码来对架构进行验证是最有效的。由于是代码验证，因此就离不开编写代码，而代码总是和具体的语言、编译环境息息相关的。在这里我们主要讨论面向对象语言，代码示例采用的Java语言。利用面向对象语言来进行架构设计有很多的
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：对于一个已经初步建立好的模型（分析模型或是设计模型）来说，对其进行精化和合并是必要的步骤。Context建立架构愿景，为架构的设计定义了主要的设计策略和实现思路。应用分层的原则则对整个的软件进行了结构上的划分，并定义了结构的不同部分的职责。而现在，我们需要对初步完成的模型进行必要的改进。Problem我们如何对初始架构模型进行改进？Solution对模型进行改进的活动可以分为精化和合并两种。我们先从精化开始。首先，我们手头上的初始架构模型已经包括了总原则（参见架构愿景模式）和层结构（参见分层模式）两部分的内容。现在我们要做的工作是根据需求和架构原则来划分不同的粗粒度组件。粗粒度组件来源于
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：当架构模型进行迭代的过程中，必然伴随着对模型进行修改和改进。我们如何防止对模型的修改，又如何保证对模型进行正确的改进？Context架构模型通过精化、合并等活动之后，将会直接用于指导代码。而这个时候，往往就会暴露出一些问题出来，通常在实际编码中，发现架构存在或大或小的问题和错误，导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计的过程本身是一个迭代的过程，这就意味着在每一次的迭代周期中，都需要对架构进行改进。Problem我们如何避免对架构模型进行修改？又如何保证架构进行正确的改进？Solution我们从XP中借用了一个词来形容架构模型的修改过程――Refactori
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：上篇我们用了大量的篇幅来观察了一个实际的例子，相信大家已经对分层有了一个比较具体的概念了。在这一篇中我们就对分层在实践中可能会遇到的问题做一个讨论。分层在架构设计中是一种非常常见的，但是又很不容易用好的技术。因此我们这里花了很大的气力来讨论它。由于这是一篇介绍软件设计技术的文章，为了尽可能让更多的人理解，本应该尽可能不涉及到过于具体的技术或平台。但是这个目标可能很难实现，因为软件设计是没办法脱离具体的实现技术的。因此本文能够做到的是尽可能的不涉及具体的编码细节。何时使用分层技术？分层技术实际上是把技术复杂化了。和以往简单的CS结构的系统不同，分层往往需要使用特定的技术平台来实现。当然，不
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：从这一篇开始，我们将会进入另一个不同的主题，和前面所讨论的模式专注于组织、过程、方法不同，以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。Context在单次的迭代开始阶段，我们已经收集好了单次迭代的需求。Problem架构和分析设计是密不可分的，有时候很难说得清楚架构的定义，但架构应该能够描述软件的整体。架构包括了软件的各个方面，但是每一个设计细节总是需要单独考虑，这时候就会出现设计细节之间、以及设计细节和架构之间的不一致。架构设计的
阅读全文
posted @ 2011-06-06 20:20
摘要：简介：在定义了架构愿景之后，团队中的所有人员应该对待开发的软件有一定的了解了。但是，面对一个庞大的软件系统，接下来要做些什么呢？分而治之的思想是计算机领域非常重要的思想，因此我们也从这里开始入手。要进行应用软件的设计，分层是非常重要的思想，掌握好分层的思想，设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性，本章的内容分为上下两节，并不采取模式描述语言的方式。分层只是将系统进行有效组织的方式。本章特别针对于企业应用进行讨论，但其中大部分的内容都可以应用在其它的系统中，或为其它的系统所参考。在企业应用中，有两个非常重要的概念：业务逻辑和持久性。可以说，企业应用是围绕着业务逻辑进行开展的
阅读全文
posted @ 2011-06-06 20:20
摘要：简介：迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。Context在软件生命周期中，我们如何对待架构设计的发展？Problem架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？我们在简单设计模式中简单提到了"Planned Design"和"Evolutionary Design"的区别。XP社团的人们推崇使用"Evolutionary Design"的方式，在外人看来，似乎拥护者们从
阅读全文
posted @ 2011-06-06 20:19
摘要：简介：我们已经讨论了敏捷架构设计的4种过程模式，在这一章中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。四种模式的着重点我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清：架构设计的框架并不是说你要严格的按照文中介绍的内容来进行架构设计，在文章的一开始我们就指出，模式能够激发思考。因此，这一框架是需要结合实际，进行改造的。实际，我们在这一个部分中介绍的，比较偏向于原则，我们花了很大的时间来讨论原则的来龙
阅读全文
posted @ 2011-06-06 20:19
摘要：简介：团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。Context谁来负责架构的设计？Problem在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码，就能够设计出理论上尽善尽美的架构，配有精美的图例。问题1：理论上设计近乎完
阅读全文
posted @ 2011-06-06 20:18
摘要：简介：XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这一章，我们就对简单性做一个全面的了解。Context架构应该设计到什么程度？Problem软件的架构都是非常的复杂的，带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中，我们提到了一些反对象牙塔式架构的一个原因，而其中的一个原因就是象牙塔式架构的设计者往往在设计时参杂进过多的自身经验，而不是严格的按照需求来进行设计。在软件开发领域，最为常见的设计就是"Code and Fix"方式的设计，设计随着软件开发过程而增
阅读全文
posted @ 2011-06-06 20:18
摘要：简介：我们说，和重型方法偏重于计划、过程和中间产物不同，敏捷方法更加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产物，那只是保证沟通、实现目标的手段。这并不是说计划、过程、中间产物不重要，只是不能够本末倒置 注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模型、代码。例如设计文档、数据模型等。参考RUP的Artifact。 评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需求。做好需求的方法有很多（参见拙作需求的实践），但这并不是我们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发来设计架构，
阅读全文
posted @ 2011-06-06 20:17
摘要：简介：通过上一章的介绍，我们对敏捷和方法有了一个大致的了解，从这一章起，我们开始对软件开发过程中架构设计的研究。记住一点，我们并不是为了架构设计而研究架构设计，我们的目的在于敏捷方法学的应用。架构设计是一种权衡（trade-off）。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复
阅读全文
posted @ 2011-06-06 20:17
摘要：简介：方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。在第一篇文章中，我们来了解标题中的一些词的含义。方法学是什么？ 敏捷是什么？ 为什么讨论架构？ 方法论方法论的英文为Methodology，词典中的解释为"A series of related methods or techniques"我们可以把它定义为软件开发（针对软件开发）的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题，我很赞同Alistair Cockburn的一句话，"方法论源于恐惧。"出
阅读全文
posted @ 2011-06-06 20:16
摘要：说到源码管理，CVS,VSS,SVN,TFS大家在公司可能都用的比较多了。但是在公司的环境基本都是在局域网中或者是专线连结到远程服务器来使用。平时自己在家和朋友一些写一些代码的时候都苦于没有代码管理工具，没有网络环境，而不能不把代码传来传去，很是麻烦。不过Google code提供了免费的SVN空间，主要注册了GMAIL，然后就可以使用SVN进行源码管理，和其他人共同开发了。一 访问Google codeGoogle code的地址是 http://code.google.com/，如果使用cn去访问好像访问不了，我这里是一片空白。管理项目的话可以直接使用http://code.google.
阅读全文
posted @ 2011-03-19 19:36
|
|||
