摘要：cpn tools 's introduction and guid.from http://wiki.daimi.au.dk/cpntools-help/getting_started_with_cpn_.wiki
阅读全文
posted @ 2008-03-29 11:32
随笔分类 - 软件工程，开发过程（RUP，GRAPPLE），UML
开发过程，软件工程技术
摘要：J2EE开发中大量的专业缩略语很是让人迷惑，尤其是跟一些高手讨论问题的时候，三分钟就被人家满口的专业术语喷晕了，PO VO BO DTO POJO DAO，一大堆的就来了（听过老罗对这种现象的批判的朋友会会心一笑）。
首先声明偶也不是什么高手，以下总结都是自己的体会。不对之处请您多指教。
PO：
persistant object持久对象
最形象的理解就是一个PO就是数据库中的一条记录。
好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
BO：
business object业务对象
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。
阅读全文
posted @ 2008-01-21 19:11
摘要： Microsoft引入了SDLC（软件/系统开发生命周期）类型的四步一致的过程来创建新模型。如下所示：
用例模型
域模型
设计模型
实现模型
域模型阶段集中于域的理解，在此域中我们建立一个系统。这是一个分析阶段，在此阶段中我们考虑现实世界中的对象和关系，而不是程序设计。在域模型中我们将建立概念化的静态结构、程序包图和顺序图。
设计阶段做编程的工作。
实现阶段建立部署图和组件图。
阅读全文
posted @ 2007-12-25 15:16
摘要：Ｃ＃的接口与抽象类非常类似：
在使用上，一个没有提供非抽象方法的抽象类与一个接口是类似的．然而，我们需要注意以下几点：
一个类可以实现任意多个接口，但只能对一个抽象类进行子类化．
一个抽象类可以包括非抽象方法，而一个接口的所有方法在效果上都是抽象的。
一个抽象类可以声明并使用变量，而一个接口不行。
一个抽象类中的方法的访问修饰符可以是public、internal、protected internal或者是private，而接口成员的访问修饰符默认情况下都是public，而且，在声明接口成员时，不允许使用访问修饰符（甚至不允许用public修饰符）。
一个抽象类可以定义构造函数，一个接口不行。
阅读全文
posted @ 2007-11-02 19:37
摘要：１，ＵＭＬ是什么？
用于收集概念和表述概念，基目的是对系统进行建模；它以可视化的图形方式建立模型的文档；能产生一组用于交付的制品；有其它编程语言的广泛支持．
２，ＵＭＬ中关系的表述
关联关系用于表述一个类的对象和另一个类的对象之间的关系．
聚合：表示类和对象之间是整体和部分之间的关系．
组合：是一种简单的聚合关系，表示整体拥有部分，整体不存在部分也不存在。
依赖：表示使用关系。
泛化：表示继承关系。
３，活动图
活动图进行动态建模，从语义和实际上讲就是流程图。
阅读全文
posted @ 2007-10-29 16:43
摘要：程序中对象的概念自然对应真实世界的对象。例如：订单中加入产品。
Encapsulation：只公布模块和系统的部分内容。
分析：研究、定义所要解决的问题的过程，发现系统必须执行的需求。它必须符合的基本假设及判断成功（失败）的标准。
OOA：根据对象定义问题。对象必须是系统与真实世界交互的对象及用于研究多种可选方案的候选软件对象。
设计：定义解决方案。
OOD：定义组件、接口、对象、类、属性和操作。以在分析期间定义的候选对象作为开始。
大型系统设计发生在两个范围内：体系结构的设计（定义组成系统的组件）及组件设计（定义组件中的类和接口）。
模型：OOAD过程的中心产物。
分析模型：需求。
体系结构模型：解决方案的组件、接口和结构，该结构在多个结点间的布署。
组件设计模型：描述体系结构模型中各部分的内部结构的模型。（基本每个组件一个模型）。关注于组件类结构的细节。允许团队指定类属性、操作、依赖关系和行为。
ＵＭＬ图：
UseCa
阅读全文
posted @ 2007-09-08 16:20
摘要：假设：
如何知道哪些任务要回收呢？人工传递信息吗？
目标：
把组员不能完成的任务会受益后重新再分派，保证能顺利完成工作。
如何被启动：
通过选择需要回收的任务，执行回收任务的命令来启动。
角色和用例间的信息：
回收任务以后，相应的信息项在浏览列表要做上需重新分派的标记
回收的任务要及时进行重新分派
用例执行方案：
选择要回收的任务，可以批量选择。
执行回收任务命令， 在列表上做上标记
刷新信息列表
阅读全文
posted @ 2007-05-17 14:26
摘要：为什么需要一个过程
首先，我们希望改进自己的工作方法，那么我们就要知道我们是如何工作的，采集工作的数据。
其次，为了完成分配的任务，你需要一个工作计划。
最后，为了应对复杂的大项目中的工作也需要一个过程。
过程就是计划如何工作的定义。
什么是过程
过程是做一项工作的步骤序列。过程定义就是该过程的描述。
为了将一些方法、工具和人应用于软件任务中，软件过程建立了一个技术和管理框架。过程定义识别了角色、指定任务、建立试题以及主要步骤的入口和出口准则。
一个已定义的过程：标识了一项工作的主要步骤、度量、为项目管理提供了基础、为过程管理和改进提供了基础。
定义自己的过程
当定义自己的过程时，那些抽象的任务变成结构化的和分析的对象。然而只有把任务分解到足够细的情况下才能够对它进行改进。
基线过程（PSP0）的内容
主要目标是提供一个框架，这个框架帮助人们编写第一
阅读全文
posted @ 2007-04-26 19:45
摘要： 当在连需求也不知道的情况下，就会不知道如何去做计划。用下面的这句话来说服自己吧，“也许现在制定的计划很不准确，但是现在是你最需要一个你能控制的计划的时候。为此你必须有一个详尽的计划。”
PSP的目的
帮助控制、管理和改进自己的工作方式。是一个结构化的框架，包括软件开发中使用的表格、准则和规程。如果使用得当，PSP将提供所需的数据来帮助软件工程师做出承诺并实现它，同时它可以让个人的工作变得更加有效和可预测。唯一目的帮助个人提高其软件工程水平。
PSP不是所有软件工程问题的万能答案，但是它能帮助识别哪些地方可以改进及如何改进。无论如何你都必须自我改进。
软件工程规范的逻辑
提高软件工程师的实践技能。一个有规范的软件工程组织都会有良好定义的实践。
使用规范的开发实践
我们需要符合我们项目的需要且容易使用的已定义和试题的过程的指南。
可操作的过程
要做什么和怎么样去做。学习如何定义并且遵循你选择的可操作的过程。
阅读全文
posted @ 2007-04-25 16:16
摘要：The Personal Software Process (PSP) shows engineers how to
manage the quality of their projects
make commitments they can meet
improve estimating and planning
reduce defects in their products
Because personnel costs constitute 70 percent of the cost of software development, the skills and work habits of engineers largely determine the results of the software development process.The PSP can be used by engineers as a guide to a disciplined and structured approach
阅读全文
posted @ 2007-04-24 10:36
摘要：用例模式
业务规则：大多数企业或组织的规则、规范、政策以及公司遵循的最佳经验。
模式
静态定义：业务规则在系统中硬编码。
动态修改：包含一个在系统升级和运行过程中改变规则的用例。
用例描述：
首先，不再在系统流程描述中描述各业务决策，而是在流程描述中引用业务规则集合来组成决策。
其次，业务规则描述与用例描述不出现在同一份文档中，而是用单独的文档或知识库来描述各个规则。
业务规则的实现：独立组件、知识库、已有的规则产品、数据库。
业务规则的分析模型：
具体各类意义参见fivestepsModel（在我的分析模型中）。
阅读全文
posted @ 2007-04-23 20:02
摘要： Use cases can capture the funtion requirements of your systems and definate the border of the system.
One use case can simulate one of the using ways of your system,that is,the event that triggered by users from outer system what sequence actions will be adpted.
每个用例都是系统的一种完整的使用方法。包括由用户输入和系统对这些输入的响应所引起的内部事件的描述，还可以包括内部计算以及给用户的一些输出。用例实例即场景（scenario)：用实际的值描述用例的一个执行路径。
每个用例都有一个目的，并且为涉众提供一个值。用例的名字是一个从系统观点以主动现在时态给定的动词短语，通常包括几个单词。
有些时候将用例根据其对系统的重要性分类
阅读全文
posted @ 2007-04-20 21:34
摘要：The Open-Closed Principle
Calsses should be open for extension,but closed for modification.
Our goal is to allow classes to be easily extended to incorperate new behavior without modifying exsiting code.Following the Open-Closed Principle usually introduces new levels of abstraction,which adds complexity to our code.You want to concentrate on those areas that are most likely to change in your designs and apply the principles there.Experience in designing OO systems and a matt
阅读全文
posted @ 2007-04-19 15:16
摘要：系统分析员涉及的领域：
系统分析是指理解九详细说明信息系统应该做什么。
系统设计是指详细说明许多信息系统的组件在物理上怎样实施的。
系统分析员是一个商业专业人员，利用分析与设计技术解决商业问题。
利用信息系统来解决商业问题，即解决商业任务。
信息系统
系统是一组为实现某些结果相互联系、相互作用的部件。
信息系统是一组完成收集、处理、存储和以输出完成商业任务所需信息作为提交的相互联系、相互作用的部件。
理解系统的方法：按功能分解；列出相互作用的各种事件类型，如一个系统包括硬件、软件、Ｉ／Ｏ、数据、人和过程。
系统边界：系统在它与它的环境之间有个边界，通过人分界。
自动化边界：一个系统自动部分和手动部分之间的分界。
信息系统类型：
决策支持系统（ＤＳＳ）：允许用户探索有效可选项或决策的影响的支持系统。
br
阅读全文
posted @ 2007-04-18 11:10
摘要：１、定义角色
从查阅需求来源开始，比如功能说明。
一种方法是寻找句子的主语。另一种方法是查阅规格说明书中的术语表。
为了对图形进行组织，可以按以下两种方法来做：
添加一些原形（stereotype），对角色分类。
运用角色分层模式，将角色组织到包中。
阅读全文
posted @ 2007-04-10 20:05
摘要： 程序中对象的概念自然对应于真实世界的对象．例如：订单中加入产品。
Encapsulation：只公布模块和子系统的部分内容。
分析：研究、定义要解决问题的过程；发现系统必须执行的需求，它必须符合的基本假设及判断成功（失败）的标准。
OOA：根据对象定义问题。对象必须是与系统交互的真实世界中的对象，以及用于研究的多种可选方案的候选软件对象。
设计：定义解决方案。
OOD：定义组件、接口、对象、类、属性和操作。以在分析期间定义的候选对象作为开始。大型系统，设计发生在两个范围内：体系结构的设计（定义组成系统的组件）及组件设计（定义组件中的类和接口）。
模型：OOAD过程的中心产物。
分析模型：需求。
体系结构模型：解决方案的组件、接口和结构。该结构在多个结点间的部署。
组件设计模型：描述体系结构模型中的各部分的内部结构的模型（基本每个组件一个模型）。
阅读全文
posted @ 2007-04-10 16:38
摘要：１、确定组织和角色
确定角色的时候要从查阅需求来源开始。角色可能是人或物。寻找句子的主语；查阅规格说明书的术语表；简单阅读规格说明和建立“名单”：做与系统相关工作的人员和事件的列表。好的检查程序和健全的原则：
在最终分析中如果候选角色没有任何用例，那他根本不可能是角色；并且如果在用例中也没有任何交流，也显示不是角色；
如果候选角色没有做任何事情，但是拥有信息，那他可能是候选对象，而不是角色；
如果角色名称太过特殊，应该设法确定名字背后的角色；
如果角色名称太过普通，应该将这些角色在各自特殊角色的基础上划分为更为详细的角色名。
阅读全文
posted @ 2007-03-28 16:01
摘要：收集、分类、绘图、评审需求。
1、收集需求
需求的来源
蓝图(外貌）文档（vision document)。这个文档描述了业务需求和开发一个成功的系统需要蓝图。
预排文档（walkthrough document)。这些文档是各种用户如何与系统交互式的一组“每日生活”的描述。
域术语表。这是终端用户所用语言的指导。
域专家和终端用户会谈。
功能规范和工作陈述。
需求分类
阅读全文
posted @ 2007-03-27 21:15
摘要：关联：表示一个类的对象利用另一个类的对象。在.NET中实现为一个类包含另一个类的引用。
依赖关系：表示一个类的对象利用或以某种方式“了解”另一个类的对象；介理，和关联不同的是，依赖关系是临时的关系。在.NET中接近的表示为using指示和程序集引用。
因此在类图中大部分的都实现为关联。
阅读全文
posted @ 2007-03-26 15:23
摘要：系统架构师的任务
软件系统架构师在整个项目中领导并协调与技术相关的活动和制品。从技术、结构、软件系统的组织结构角度调整一些主要设计决定。与RUP中其它角色相比，软件系统架构师更注重广度，而不是深度。
软件系统架构师要能够在信息不完整的情况下把握问题的本质，并作出合理、关键的决定。
经验、领导能力（Architect负责技术方面的问题，项目经理负责商业和管理方面的问题）、沟通能力（不能被法规所领导，要由其余团队的意见所领导）、面向目标的工作态度（必须一切以结果为中心，对问题精益法求精的完美主义者不适合担当这个角色）。
交流：
在项目经理和开发团队之间建立联系
在内部成员和涉众之间建立联系（系统体系结构小组和项目小组）
在不同开发小组之间建立联系（保证架构完整性）
系统架构（Architecture)
（1）定义
组成系统的结构元素及它们的接口、元素之
阅读全文
posted @ 2007-03-24 10:55