周末参加了公司组织的“面向对象设计与分析基础”的培训，感觉获益良多。有些比较好的东西摘出来，标记！【用户需求观】        这个名称说起来容易，一切从用户出发，用户的需求决定我们的产品，从用户的角度去考虑问题。但是实践时，我总会考虑这个需求如何对应，那个需求如何实现。这样做不是很好，容易考虑的太多，注意力偏离了正轨，用个大家常说的词就是“不上道”。        需求分析阶段，应该把系统当成一

子系统和框架出现的动机：分离关注点，或者叫封装变化点。如何分离关注点？1.       可以通过职责划分来分离。2.       可以利用软件系统各部分通用性的不同来划分。3.       可以先考虑大粒度的子系统，而暂时忽略子系统是如何通过更小粒度的模块和类组成。架构的分离：1.       按照职责划分，可以分为表现层、业务层和数据层。2.       按照通用性划分，可以分为特定应用部分、领

一个软件设计的全过程(基于UML)blueski推荐 [2006-4-21]出处：www.chengang.com.cn作者：陈刚 前段时间把一个界面框架完成了，今天基于这个框架开发一个小模块，在这里把这个模块设计的全过程记录下来，希望大家讨论并指正。一、起因公司交给我一个任务，为测试员写一个手机模拟界面，以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行

怎样成为优秀的软件模型设计者？                    来自：blog　  雪茶技术我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？将下列原则应用到你的软件工程中，你会获得立杆见影的成果。1. 人远比技术重要你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们 那时侯将主要

熟练人员经过多年的积累加上自己的CodeSnip的总结，基本不用额外再查找资料。而一般的开发人员在开发过程中会花掉10-20%时间去查找资料。熟练人员注意代码复用，并且时刻注意重构和抽取公用代码。一般开发人员是代码拷来拷去完成功能。熟练人员非常注意查找，定位，标签等各种快捷键的使用，定位查找方便快捷，IDE环境也根据习惯定义到最方便状态。熟练人员编码前先思考清楚整个流程，在头脑或纸张上规划好整个实

key words: 如何做设计 设计步骤转自robin一。需求分析(抽象Use case + 分析Use case之间的关系)分析软件需求，以用户的角度来使用软件，找出发生的scenerio，抽象成为一个一个Use Case，分析出Use Case之间的关系，这一步是非常重要的，这一步做好了，设计就成功了一半。Use Case的抽象有一些可以遵循的原则，这里不详细谈。然后用语言描述每一个Use

OOA面向对象分析面向对象分析产生三种分析模型 功能模型(即用例模型à作为输入) 对象模型:对用例模型进行分析,把系统分解成互相协作的分析类,通过类图/对象图描述对象/对象的属性/对象间的关系,是系统的静态模型 动态模型:描述系统的动态行为,通过时序图/协作图描述对象的交互,以揭示对象间如何协作来完成每个具体的用例,单个对象的状态变化/动态行为可以通过状态图来表达OOD面向对象的设计OOD

key words:软件架构师转自here现在软件架构师满天飞，是个写代码的都称自己为软件架构师，就象开个公司管上四五号人就给自己按个CEO头衔一样，着实让人好笑。于是到网上GOOGLE了一下看看软件构架师具体是个啥东东，有想做货真价实的构架师，就朝着那方向努力吧。网摘如下：软件架构师的职责：将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。软件架构师

UML中类有三种主要的版型：边界类、控制类和实体类。引入边界类、控制类及实体类的概念有助于分析和设计人员确定系统中的类。边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。通过用例图可以确定需要的边界类，每个Actor/Use Case对至少要一个边界类，但并非每个Actor/Use Case对要唯一的边界类。实体类保存要放进

定义系统边界      goldway 发表于 2006-8-13 9:22:00 在定义需求时，必须定义要开发的计算机系统的边界，即确定哪些是系统需求，哪些是和系统相关的操作过程的需求，哪些是在系统范围之外的需求。    需求提供者经常不大了解系统应该包含哪些内容，因此他们可能会提出不恰当的需求。需要通过系统边界定义初步剔除那些明显在系统范围之外的需求，以免这些需求干扰后续的分析过程。    检

 评估需求风险      goldway 发表于 2006-8-13 10:36:00   对每一项需求或者一系列相关的需求进行风险分析，指出在实现需求过程中可能会发生的问题、这些问题发生的几率及其影响。风险评估是标记那些可能会对系统开发者造成特殊困难的需求，如果在这个阶段就可以将其标记出来，就可以修改需求以降低开发过程中的风险。    定义需求风险经常会暴露出需求相关信息不足的问题，因此应当从需

定量描述需求      goldway 发表于 2006-8-13 11:01:00   特别是对于非功能需求，更应该尽可能地用定量的数据来描述，定量描述可以避免需求的二义性，同时也提供了可测试的依据。  为定量地描述系统需求，首先必须定义表达这些属性的合适的度量，然后为这些属性决定一个合适的值。在某些情况下，这可能是很难的，需要从业务人员和系统相关人员处获取更多的信息，同时还需要了解业界目前的常

 软件的主要任务软件的核心任务不外乎是收集和整理数据，然后以用户需要的形式表现给他们而已，此外还有数据的存储，数据的传输等外围任务。数据的收集，整理，表现，存储和传输就是软件的主要任务，它们也是程序员的主要工作内容，也是程序员编写代码的最终目的。那么该如何编写代码让软件完成它的主要任务呢？编写代码的过程是否有规律可循？编写代码需要注意那些方面的问题？本人想就这些问题罗列自己一些粗浅的看法，并大家进

这段时间在想关于软件工程的问题。记得以前看过软件工程方面的书，但是很多东西都已经忘了，所以我也就从自己的实际出发来思考软件工程的问题。首先，从最近的北京报表之行吧，记得大/r 约两三周前，我数了一下我那时已完成的工作。因为我习惯会给自己列一个详细的功能点，完成了就打个勾。结果我数了一下，并按照实际完成情况，发现我大约也 就是一天完成一两个功能点左右，也就是我一个月下来大约30-40个点。我自己定义

　　中图法分类号：TP311.52      文献标识码: A　　虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行……因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》1、估算前的规划　　当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于

从顶部向底部填写用例模版。从用例图（如果有的话）获得用例和参与者的名称。该试探法确保用例图和用例描述的一致性。使那些需要完成用例任务的风险承担者作为用例的人类参与者。以主动说现成话编写简单的说明性的句子。注重易于理解。使参与者或产品本身作为各个步骤描述的主语。用3到9步编写基本流程。避免参与者或产品招待连续的步骤。不要指定物理细节。做到点到为止。指定最低限度的活动顺序。校对用例描述。所有的方法都不

以名词短语命名类、属性和角色。以动词命名操作和联系。以大写字母开头书写类名，但属性、操作、联系和角色名不这样写。类名和隔间名居中书写。但其它隔间的内容应左对齐。坚持使用二元联系。优先使用联系名而非角色名。把联系名、角色名和多重性写在联系线的相对两侧。对于类图，说明的资料也比较多。在此不冗言。这部分内容是在《软件工程设计导论--过程、原理和模式（UML2.0版）》时感觉不错的东西，保留下来的。

在下列试探法的指导下，可以创建出适当的用例图：不能使用开发中的产品成为参与者。只有在产品外部、直接与产品交互的主题才是参与者。其实这交不是真正意义上的试探法的一部分。用名词短语命名参与者。在用例中实现风险承担者的某个目标。如果用例不能实现风险承担者的某个目标,那么可能太小.但有时若用例是许多用例的前提条件或者很多用例都会使用到某个用例.这时可能此用例没有实现风险承担者的某个目标,不过这时仍然应该把

用例分析技术：确定系统边界确定系统边界非常重要，是使用用例技术的基础，小记下！1、找出系统有什么；系统外有什么；确定项目规模，定义要创建系统那些部分。2、通过确定执行者和用例来确定系统边界。3、确定执行者：谁使用这个系统，谁安装这个系统,谁启动这个系统，谁维护这个系统，谁关闭这个系统，那些系统使用这个系统，谁从这个系统获取信息，系统为谁提供信息，是否有事情在预计时间自动发生？.....提问的方式最

 关于产品和项目的需求分析差异问题，和西宁私下沟通了过，明晰了一些。其实，我的回答并没有多少集中在差异上，而是对需求应该包含什么提出看法。主要观点是，需求应该包括对系统边界的描述，不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝

使用多维方法进行需求分类      goldway 发表于 2006-8-13 10:16:00   为了便于整理、分析和管理需求，通常都是将需求分类，但完全没有必要将单个需求只归到一个类中，而应该通过分析派生出几种不同的分类方法，这就叫做多维分类。因而每一项需求都可能归到几个不同的类中。需求多维分类可以帮助你：发现需求重叠和冲突；发现需求之间的共性和例外关系；提高需求的跟踪能力；找到遗漏的需求于

Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。 　　如果需求经常改动，很可能是你没有

(转)什么才是软件开发的葵花宝典？中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为"不败"。 但什么才是软件开发的葵花宝典？ 让我们先从一些现象出发。我们的前提是，软件开发是一项智力密集型劳动。对于智力密集型劳动，我们观察到的现象是，个体的表现差异很大，团队的表现差异很大，组织的表现差异很大，国家的表现差异很大。这不象体力占主要的劳

http://www.blogjava.net/songfei/articles/53256.html微软公司软件开发模式简介 Smalllamb

工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP考试中，工作分解结构(WBS)都是最重要的内容。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础

一般来说，建立用例模型的步骤为： 　　（1）确定谁会直接使用该系统，即参与者（Actor），为了发现参与者，我们可以尝试问如下问题：　　a. 谁/什么使用系统？　　b. 谁/什么从系统获得信息？　　c. 谁/什么向系统提供信息？　　d. 谁/什么支持、维护系统？　　e. 哪些其它系统使用此系统？　　f. 公司的哪个部门使用系统？　　…　　（2）选取其中一个参与者；　　（3）定义该参与者希望系统做什

   摘要：  本文是在概要设计实践和学习中的一些心得与学习笔记，希望与大家分享，如有不妥之处欢迎指正。  关键字：  概要设计，结构化，OOD  正文：  在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。  一、问

1.建模      1.1 为什么要建模      建立大厦和建立狗窝的区别是建设狗窝不需要设计。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。      建模的定义：建模是对现实的简化。      建模的目标：   1）模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。   2）模型允许我们详细说明系统的结构和行为。   3）模型给出一个知道我们构造系统的模板。   4

 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：

前言　　DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的开发包，与DirectX开发包一起发布。DirectShow为多媒体流的捕捉和回放提供了强有力的支持。用DirectShow开发应用程序，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。　　DirectShow是基于COM的，为了编写DirectShow应用程序，需

本文网上看到觉得好就转过来了http://www.mscenter.edu.cn/blog/k_eckel/articles/1750.html0 引言0.1 目的       本文档给出设计模式之——Flyweight模式的简化诠释，并给出其C++实现。0.2 说明ProjectDesign Pattern Explanation（By K_Eckel）AuthorizationFree Dis

       在网上看见了这篇文章，作者以轻松的语言比喻了java的23种模式，有很好的启发作用。         创建型模式                 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory            

  在实施计划的基础上，更进一步地将每项工作细化。经过细化的工作分别落实到某一个项目团队成员，落实到每一天，这种方法就叫工作分解结构（WBS）法。WBS由最低级的工作任务组成，它是项目每一个阶段的时间表和路标。WBS可以将项目分解为一些更小和可操作的部分。WBS的每个阶段就好像是夹在起始日期和结束之内三明治，开始和结束日期的确定使项目的其他阶段可以按计划进行。每个阶段的起止日期明确也能保证项目经理

我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？ 将下列原则应用到你的软件工程中，你会获得立杆见影的成果。 1. 人远比技术重要 你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（ components ）， EJB （

面向对象的设计原则摘要 The principles of class design: SRP(Single Responsibility Principle)单一职责原则: 一个类应该有且仅有一个职责。所谓一个类的职责是指引起该类变化的原因，如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，其实就是耦合了多个互不相关的职责，就会降低这个类的内聚性。  

 Singleton模式是一种非常简单的设计模式，这种模式很常用也很容易被滥用。当你设计应用程序的时候，经常会遇到某些对象在整个程序的生命周期应该仅有一个实例的情况，比如File System，Graphic System，Logging Utility，这时候就可以用到Singleton模式。Singleton模式在GOF中描述如下：       Ensure a class only

 第一个步骤：承认自己有问题Goldman说：“你想单凭自己设计出可用性良好的软件是不可能的。”他们主张借助人物角色，设计这种虚构人物是为了模拟目标用户群当中可能使用网站或者产品的不同类型的用户。增强可用性的“非正式”方法可能也管用，比如非正规的客户访谈以及与技术支持人员一起合作。 第二个步骤：要认识到用户比你自己还重要 Crow在会上放了几张幻灯片，上面显示的是三种不同类型的用于

　　前段时间，团队开始实施一个新项目。这个项目有着中国IT行业的三个共同特点：需求繁、工期紧、资源缺。 项目管理者联盟，项目管理问题。http://bbs.mypm.net　　虽然从目前情况来看，它还有希望不会沦为“死亡项目”，但如果实施过程中不小心翼翼、步步为营，结局就很难预料了。 　　虽然有着诸多不利因素，但是我们团队也还有一些有利因素，也许可以主宰项目的命运： 　　1）开明的领导。俺们的各级

一　引言渐近明细是项目的特点，但这并不意味着不需要计划。 没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法。即根据总体阶段划分的总体WBS和专门针对详细设计或编码阶段的二次WBS。这其中部分的原因是需求的颗