摘要：划分子系统、接口——《一线架构师实践指南》笔记之三2010-11-12 15:52:18|分类：架构|举报|字号订阅提纲：划分子系统遵循四个原则的相关：职责、通用性、开发技能、工作量。协作决定接口。如何划分子系统下面是分层的细化、分区的引入、机制的提取这3种策略背后的4个通用设计原则：职责不同的单元划归不同子系统。通用性不同的单元划归不同子系统。需要不同开发技能的单元划归不同子系统。兼顾工作量的相对均衡，进一步切分太大的子系统。如图13-11所示，子系统的每种划分策略，都是一到多个原则综合作用的结果。498)this.style.width=498;" height=437<接 阅读全文

摘要：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://zorro.blog.51cto.com/2139862/8046921. 什么是概要设计？为什么要进行概要设计？白话解释：概要设计，顾名思意，大概简要的设计，大概简要是从整体来说，不是说不准确含糊之意。设计什么呢？前面我们进行了系统的需求分析，有两个成果--1--.系统用例图--2--.类图集合，所以我们的概要设计要在1.2的基础上进行，我们要让系统的功能在对象的交互过程中活动起来，这样模拟了客观，再现了系统，我们称之为领域建模。我们要进一步描述明确系统中的类，可能概要设计要 阅读全文

摘要：原文：http://hi.baidu.com/ztf704/blog/item/275581444e4c6548500ffe7b.html概说概要设计怎么做 - 结构化设计方法与面向对象设计方法摘要：本文是在概要设计实践和学习中的一些心得与学习笔记，希望与大家分享，如有不妥之处欢迎指正。关键字：概要设计，结构化，ood正文：在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。一、问题的提出概要设计写什么？概要设计怎么 阅读全文

摘要：先贴一篇具有指导意义的ppt，百度文库的http://wenku.baidu.com/view/841675eee009581b6bd9eb50.html============================概要设计怎么写做软件到一定层次了，就要考虑到设计了，设计了很久，就是不系统，系统的设计需要一个记录，记录就用文档，那么对项目所有包括技术上的设计都记录下来，我们就可以理解为软件的概要设计了。 设计规范以做参考在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对 阅读全文

摘要：这一篇讲软件架构和软件框架在UML设计过程中所起的作用。本系列文章不是专门讨论软件架构和软件框架的，所以不会深入讲怎么做软件架构和软件框架。另一个原因是笔者尚无这个自信能够在这里班门弄斧讲软件架构。之所以要讲，是因为在设计过程中，设计类必然会受到软件架构和框架的约束。从分析类到设计类，软件架构和框架是不得不考虑的一个重要因素。软件架构和软件框架是一回事儿吗？相信有相当一部分人搞不清楚这个问题，也会有相当一部分人认为是一回事儿，只是不同的叫法而已。架构的英文原文是Architecture,而框架呢，则是Framwork。显然这是两个完全不同的词儿。从技术上讲，IT有一个职业是架构师，架构师代表了 阅读全文

摘要：这一篇拖了很长时间，除了懒之外，另一个主要原因是一直找不到思路。想归纳一下自己的设计经验，找到一个相对容易学习的办法，结果总是不得要领。终于不得不承认设计工作是一项创造性的工作，是没有办法用什么固定的流程，普适的方法来完成的。除了知识和经验之外，个人的悟性恐怕也是影响设计好坏的原因之一。这篇文章写得很费劲，发现归纳出与具体需求无关的通用的一些方法真的很困难。相信对读者来说这篇恐怕是到目前为止最难懂的一篇了，因为太多的东西是只可意会不可言传的。如果让读者觉得困难了，只能说声抱歉，我已经尽力了。市面上所有有关设计的书目，无非是讲UML，讲OO原则，讲设计模式..这些要不就是理论，要不就是方法论，要 阅读全文

摘要：上一篇笔者阐述了什么是分析模型，我们为什么要使用分析模型，分析模型能给我们带来什么。这一篇来讨论怎么做分析模型。开篇之前先说点题外话。笔者不厌其烦地一次次提到需求的可追溯性，是因为软件工程比UML更重要更本质。笔者自己在学习UML过程中，曾经也非常迷惑而不得要领，这么多UML元素，每个都有其特定的含义，RUP中定义了更多更复杂的流程，模板，工具...虽然读了很多资料，却始终感觉UML信息太过于分散，不能很好的把UML应用到实际的项目中去。直到有一天突然转变了思维，不是从UML的定义中去思考如何做软件，而是站在软件工程的角度，去UML中找寻需要的工具。正是这一转变使我对UML的认识茅塞顿开。我想 阅读全文

摘要：析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。（让关心OO之路列的朋友们久等了，今天正式开始推出之路系列的第二部，OO系统设计师之路。在第一部OO系统分析员之路中，我们始于什么是用例，结束于需求规格说明书。我们还记得在第一部中，最后的结果是系统用例。系统用例规定了系统范围，通过用例场景，规定了系统蓝图，让我们知道了系统将如何实现业务用例中规定的业务。这些工作，是由系统分析员来完成的。到这里为止，我们还不知道如何让计算机来执行这些业务。大家都知道，在需求过程结束后，即将进行的是分析设计过程，这是系统设计师的职责。OO之路第二部正是针对系统设计师的，笔者将试图在接下来的文章里 阅读全文

摘要：先说说业务规则。笔者习惯将业务规则分为三种。一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。关于用例补充规约以后再讨论。第二种是交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP定单进入特 阅读全文

摘要：上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文 阅读全文

摘要：很久没有动笔了，这期间承蒙许多朋友的喜欢和鼓励，再不写点东西就对不住这些朋友了。写点什么呢？按照原先的设想，应该开始动手写如何从业务用例转化到概念用例和系统用例，不过老实说这一步需要的是经验居多，而很难找出一个普适的步骤来。先暂时放一放吧，以后一定会写到的。上一篇讲到用例分析的一般步骤和方法，也给出了一个实例，不过没有做更进一步的说明，所以这一篇，笔者决定先罗嗦罗嗦之前的内容，说说业务建模中各种图的用法，以及它们对需求的贡献。在说明实例之前，再重复一下的需求，并提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。好了，让我们先回头看看需求吧，图书馆主任是这么 阅读全文

摘要：本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML 阅读全文

摘要：从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：发现和定义涉众画定业务边界获取用例绘制用例场景图绘制业务实体模型（领域模型）编制词汇表下面笔者开始就一个事例来说明如何完成这些工作，这只是一个虚拟的事例，它的合理性和真实性请读者不必追究。现在我们接到一个项目，是一个网上图书借阅 阅读全文

摘要：在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。先说说用例类型的问题。用例类型，有的资料翻译为版型，英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realization和use case realization三种。相应的，就是指业务用例：业务用例实现：用例实现：若不指定类型，则它就是通常意义上的use case ：Rose中定义了上述默认类型，但是也可以自定义用例类 阅读全文

摘要：我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。好了，今天是第一篇。想得很远，真希望我能坚持下去，呵呵用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例 阅读全文