
架构设计
honkerhero
回答问题只说思路。代码自己写去。
有了思路还定不出代码来的,劝尔别做程序员了。
展开
-
软件详细设计说明书
详细设计说明书 1.引言 1.1编写目的【阐明编写详细设计说明书的目的,指明读者对象。】 1.2项目背景【应包括项目的来源和主管部门等。】 1,3定义【列出文档中所用到的专门术语的定义和缩写词的原意。】 1.4参考资料【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:a.项目的计划任务书、合同或批文;b.项目开发原创 2007-01-05 08:43:00 · 2653 阅读 · 2 评论 -
OO系统分析员之路--用例分析系列(3)--业务建模之涉众1
OO系统分析员之路--用例分析系列(3)--业务建模之涉众1从这一篇开始,笔者将借助一个虚拟的实例来阐述获取用例的方法,以及如何判断用例获取是否完备,粒度选择是否合适。事实上,在做这些工作时,我们正在进行需求分析的第一个阶段,即业务建模阶段。借助这个例子,笔者同样会阐述业务建模到底应该做什么,做到什么地步才能说明业务需求已经完整,可以称为一份完整的需求规格说明书了。 一般来说,只有当以原创 2007-03-01 14:30:00 · 1045 阅读 · 2 评论 -
OO系统分析员之路--用例分析系列(4)--业务建模一般步骤和方法
OO系统分析员之路--用例分析系列(4)--业务建模一般步骤和方法本篇开始之前先扯点闲话,商业应用系统开发经历了三个阶段,第一个阶段以计算为中心,分析设计围绕程序的运行效率,算法优劣,存贮优化来进行。90年代的大学课程讲的都是这些。第二阶段以数据为中心,分析设计围绕数据流进行,以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。第三阶段以人为中心,分析设计围绕人的业务需求,使用要求,感受要原创 2007-03-01 14:31:00 · 1143 阅读 · 0 评论 -
系统分析员试题(摘1)
试题一 论软件质量保证 影响软件质量的因素很多,软件质量的优劣直接关系到软件项目的成败。在软件开发过程中为保证软件的质量,采用了许多有关的技术、策略和方法。 请围绕“软件质量保证”论题,依次对以下三个方面进行论述。 1.概要叙述你参与分析和开发的应用项目以及你所担任的主要工作。 2.具体讨论你在软件开发中为保证软件的质量所采用的主要技术及方案,详细叙述你为保证软件质量在你的组织内部实施的方法和策略原创 2007-03-02 10:01:00 · 544 阅读 · 0 评论 -
用例建模指南
用例建模指南程序设计 /我想我是海 发表于2005-03-19 23:43用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的,后来被综合到UML规范之中,成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至,整个RUP流程都被称作是"用例驱动"(Use-Case Drive原创 2007-03-01 14:17:00 · 551 阅读 · 0 评论 -
如何分析问题和需求
如何分析问题和需求Java程序设计 /我想我是海 发表于2005-03-19 23:47如何分析问题和需求 一、提出问题 1.树状遍历式寻找问题 每个问题都不是单一存在的,它都有相关问题,犹如一棵树一样,主问题就是主树杆,主问题伴随的其他问题,就是支树杆,以次类推。首先不要怕麻烦,每当一个问题提出,必须提出尽量多的相关新问题。提出问题的方法:顺藤摸瓜。 比如:原创 2007-03-01 14:20:00 · 607 阅读 · 0 评论 -
OO系统分析员之路--用例分析系列(1)--什么是用例
OO系统分析员之路--用例分析系列(1)--什么是用例我发现,在OO和UML几乎一统天下的今天,仍有很多系统分析员对OO和UML一知半解,甚至包括很多已经使用了很久UML的系统分析员。于是打算写一个系列文章,将多年来的工作经验做一个总结。对初学者起个启蒙作用,也希望抛砖引喻,与各路大虾共同探讨,共同提高。这个系列文章将以我对OO和系统分析的理解为主,从UML基础开始,阐述面向对象的需原创 2007-03-01 14:24:00 · 1325 阅读 · 1 评论 -
系统分析员试题(摘2)
试题一 阅读以下关于应用服务器业务对象管理的叙述,回答问题 1 和问题 2; 某软件公司最近接到一个电信局的计费项目,该电信局要求计费系统支持实时出帐( 如用户可随时通过诸如电话、上网等方式查询当前的话费情况 )、实时划价( 如新增业务或改变的记费规则能实时的添加到计费系统中 )。鉴于该项目的实时性要求较高,难度较大,为此,张工召开了一次课题组会议,会上项目组成员的意见分为两大派;一派坚持使用磁原创 2007-03-02 10:02:00 · 518 阅读 · 0 评论 -
数据访问层设计(多库操作)(2)
3、自定义配置节处理using System;using System.Xml;using System.Configuration;using HKH.DataBase.Type;namespace HKH.DataBase.Config{ /// /// 数据库参数配置节处理程序 /// public class clsDbSettingSectionHandler : IConf原创 2007-03-14 09:48:00 · 608 阅读 · 0 评论 -
数据访问层设计(多库操作)(3)
5、数据库配置,可写在WEB》CONFIG或APP》CONFIG中 default="true"> dbAccess="HKH.DataBase.OleDb.clsOleDbDBAccess,HKHDBAccess">原创 2007-03-14 10:57:00 · 614 阅读 · 0 评论 -
数据访问层设计(多库操作)(1)
以前设计,无法实现多数据库操作,本次修改做了部分改动,尤其配置文件,加了自定义配置节来处理多数据库 只贴出修改的关键代码,及配置处理,配置样式关于接口设计等其它相关代码,请参见以前写的〈数据访问层设计〉1/数据库配置类,管理参数等using System;using System.Collections;namespace HKH.DataBase.Type{ /// ///原创 2007-03-14 09:46:00 · 984 阅读 · 0 评论 -
HKH 实用小类库
我的一系列类库包括HKH.Common 通用类(多LIST链接,人民币中英文转换,IP操作和加密算法)HKH.DataProvider系列,基于接口的数据库访问,可以通过配置简单切换数据库,并且对新数据库的扩展极为方便,已实现的数据库有SqlServer, OleDb, ODbc, Oracle, MySqlHKH.Dat原创 2010-03-12 10:31:00 · 500 阅读 · 0 评论 -
OO系统分析员之路--用例分析系列(2)--用例的类型与粒度
OO系统分析员之路--用例分析系列(2)--用例的类型与粒度在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。先说说用例类型的问题。用例类型,有的资料翻译为版型,英文原文是stereotype。在Rose中默认的类型有business useca原创 2007-03-01 14:28:00 · 1196 阅读 · 0 评论 -
用例文档
文档中应包括哪些部分,为什么要包括这些部分Scott W. AmblerRonin International 总裁2000 年 10 月 5 日 内容:原创 2007-03-02 09:43:00 · 856 阅读 · 0 评论 -
概要设计说明书(实例)
概要设计说明书 一. 引言 1. 编写目的 500){this.resized=原创 2007-02-07 11:15:00 · 11865 阅读 · 3 评论 -
架构设计中的方法学(一)
架构设计中的方法学 一、从方法论看架构设计 方法论对软件开发而言意味着什么?我们如何看待软件开发中的方法论?方法论能够成为软件开发的救命稻草吗?在读过此文后,这些疑惑就会得到解答。 在第一篇文章中,我们来了解标题中的一些词的含义。 ·方法学是什么? ·敏捷是什么? ·为什么讨论架构? 方法论原创 2007-02-07 11:26:00 · 951 阅读 · 1 评论 -
架构设计中的方法学(二)
三、源自需求 我们可以了解到在图的背后隐藏着的需求:系统需要支持多种用户界面,包括为普通用户提供的HTML界面,为无线用户提供的WML界面,为管理员提供的Swing界面,以及为B2B业务设计的WebService界面。这是系统最重要的需求,因此,系统的设计者就需要确定一个稳定的架构,以解决多界面的问题。相对于多界面的问题,后端的业务处理逻辑都是一致的。比如HTML界面和WM原创 2007-02-07 11:33:00 · 713 阅读 · 0 评论 -
架构设计中的方法学(三)
五、简单设计 XP非常强调简单的设计原则:能够用数组实现的功能决不用链表。在其它Agile方法中,简单的原则也被反复的强调。在这一章,我们就对简单性做一个全面的了解。 Context 架构应该设计到什么程度? Problem 软件的架构都是非常的复杂的,带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中,我们提到了一些反对象牙塔式架构原创 2007-02-07 11:35:00 · 660 阅读 · 0 评论 -
架构设计中的方法学(四)
七、组合使用模式 我们已经讨论了敏捷架构设计的4种过程模式,在这一章中,我们对这四种过程模式做一个小结,并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述,大家能够对前面的内容有更进一步的了解。 四种模式的着重点 我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次,这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清:架构设计原创 2007-02-07 11:37:00 · 691 阅读 · 0 评论 -
架构设计中的方法学(五)
在定义了架构愿景之后,团队中的所有人员应该对待开发的软件有一定的了解了。但是,面对一个庞大的软件系统,接下来要做些什么呢?分而治之的思想是计算机领域非常重要的思想,因此我们也从这里开始入手。 要进行应用软件的设计,分层是非常重要的思想,掌握好分层的思想,设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性,本章的内容分为上下两节,并不采取模式描述语言的方式。 分层只是将系统进行有效原创 2007-02-07 11:41:00 · 823 阅读 · 0 评论 -
架构设计中的方法学(六)
十一、Refactoring 当架构模型进行迭代的过程中,必然伴随着对模型进行修改和改进。我们如何防止对模型的修改,又如何保证对模型进行正确的改进? Context 架构模型通过精化、合并等活动之后,将会直接用于指导代码。而这个时候,往往就会暴露出一些问题出来,通常在实际编码中,发现架构存在或大或小的问题和错误,导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计原创 2007-02-07 11:42:00 · 628 阅读 · 0 评论 -
架构设计中的方法学(七)
十三、代码验证 要保证架构的稳定和成功,利用代码对架构进行验证是一种实用的手段。代码验证的核心是测试,特别是单元测试。而测试的基本操作思路是测试优先,它是敏捷方法中非常重要的一项实践,是重构和稳定核模式的重要保障。 面向对象体系中的代码验证 代码验证是保证优秀的架构设计的一种方法,同时也是避免出现象牙塔式架构设计的一种措施。我们在上一篇稳定化中提到说架构设计最终将会体现为代码的形式,原创 2007-02-07 11:45:00 · 801 阅读 · 0 评论 -
软件设计原则总结
软件设计原则总结 ——成,2006-10-04==============================理论篇:=============================1.问题界定。 问题的界定,对于软件开发来说是直观重要的.因为任何一个软件都不是单纯的独立服务的.必原创 2007-02-07 11:47:00 · 2537 阅读 · 0 评论 -
概要设计说明书(结构)
概要设计说明书1,引言 1。1编学目的 1。2背景 1。3定义 1。4参考资料2,总体设计 2,1需求规定 2,2运行环境 2,3基本设计概念和处理流程原创 2007-02-07 11:16:00 · 899 阅读 · 0 评论 -
软件分层必须遵守的原则
软件分层必须遵守的原则巴黎 发表于 2006-3-3 15:51:00原创 2007-03-01 14:38:00 · 1159 阅读 · 0 评论 -
HKH小类库系列文章(一、二、三)
在博客园写过了,这只加链接 一、数据库访问层设计思路及实现与使用 二、验证码控件,实现一拖即可 三、实体框架与MVC之小框架原创 2010-03-19 16:00:00 · 502 阅读 · 0 评论