我的javaIT

摘要： 系统架构与软件架构 再深一层分析，无论是建筑工程领域，还是其他工程领域（包括计算机科学），从它们的演化历史来看，直觉上我们似乎能够发现其共同点：即从哲学的角度上来说，它们都是人类为了克服与生俱来的恐惧而进行的创造、演化和发展。人类到底恐惧什么呢？ 我们可以注意到，人类本能当中有这样一个重要的共同点：对不确定的、感觉到威胁的事物具有强烈的不安全感。这就激发了人类尽量把这些恐惧的因素控制在最小范围内的愿望。这也就是各个工程学科（包括系统及软件工程领域）在日积月累的发展历程中，逐步规范化、科学化、系列化以及统一化，最终保证人类在复杂环境中，当不确定的因素存在时，依然能够进行有效的控制和协调。 基于同 阅读全文

摘要： 架构的源起 “架构（Architecture）”一词，其实来自于建筑行业。本源自拉丁语的“Architectura”，而最早的词源是来自希腊语的“Arkitekton”一词。“Arkitekton”或者“αρχιτεκτων”都是主建筑师的意思，“Αρχι”是“主要的、首要的”意思，而“τεκτων”是建筑师或工匠的意思。 架构与建筑的关系，使得它与人类社会文明的发展紧密关联在一起。当我们翻开各地存在过的文明社会的历史长卷时，首先映入眼帘的是那些留给我们数不胜数的精湛建筑遗迹。无论是埃及人、中国人、印度人、巴比伦人，还是玛雅人、希腊人、苏美尔人、印加人、波斯人等，都是人类文明的伟大创造者，他们 阅读全文

摘要： 由塔科马大桥事件 谈软件架构 经常，我们会涉及系统架构、面向对象的架构（SOA）、软件架构等词，那么到底什么是“架构”？什么是“软件架构”？“系统架构”与“软件架构”有着怎样的区别和联系？“系统架构构建”和“系统设计”之间有什么区别和联系？ 本章带着这些问题，追本溯源，对于架构及软件架构的一些基本概念及发展历程做一番说明。同时对一些人们认识上的误区进行分析，以还原事物的真实面目。1.1 引子 时间就像一条奔腾不息的大河，大浪淘沙，方显金石。翻开人类的建筑工程史，遍布世界各地，跨越几千年的时空，我们可以看到许多辉煌成功的工程。但是，人们往往最容易遗忘那些被历史长河所淹没的惨痛失败。而实际上，人类 阅读全文

摘要： 开发好的项目必须要有好的需求 好的开始是成功的一半，要充分认识需求分析对项目过程的重要意义。需求分析是项目的开始，其质量如何对整个项目的进展与最终结局都会起到重要作用。这里介绍的只是需求分析过程中一些常见的应对策略，正确理解与恰当运用这些经验将会有助于效率的提高与质量的改善。 这部分内容与本书后续内容存在着必然的内在联系。对于需求的研究不仅在项目中如此，对于控件对象的设计与封装也是异曲同工。我们基于项目的普遍性应用，从中构造基于应用的基础控件是有效提升设计生产能力的一个重要途径，也是面向对象理念的一种具体实践。 由于控件的应用范围更加广阔，所以在封装的过程中对经验的依赖性更强，需要更加透彻的分 阅读全文

摘要： 提升需求分析的能力 采取面向对象的理念需要战略性的决策、合适的人才与适当的成本，需要的是相对长期的积累与磨合，同时需要技术与经验的有机结合。天上不会掉馅饼，核心技术的竞争力只有通过不懈的努力才有可能逐渐形成。 基于对象的需求分析是更加具备挑战性的分析过程，它的存在强化了需求分析在项目前端的作用与地位，要求需求分析人员能够在需求阶段初步判定业务对象的性质、作用、作用空间、对业务系统的影响等问题。 如果有一个人能够兼顾需求分析与系统架构设计，就能减少设计过程中的障碍，对成功率也会有更多的保证。如果缺少一个能够纵观整个过程的角色，理解与认识上的差别将会延长设计过程，也会影响到设计质量。 先进的开发理 阅读全文

摘要： 细节也可以决定网站中交互设计的成败 2009年4月23日，外面的天气虽然是烟雨濛濛，但是在电子工业出版社博文视点公司的会议室里充满了阳光与热情，因为今天我们邀请到了《细节决定交互设计的成败》的作者 张亮老师给我们的团队进行了很好的交流，让我们对网站在设计和用户体验方面有了更多、更深的感受。与张亮老师交谈的主要内容有：用户识别 网站的目标用户都有哪些呢？用户目标及任务分析 用户想到网站上来完成什么任务，获取什么信息？ 他们使用网站的目的是什么呢？竞争性分析 拿来主义 可以向哪些网站参考或学习呢？可用性测试 可以用出版社内部员工做测试对象 选择典型任务 其他浏览器测试网站信息导航 超链接的设计问题 阅读全文

摘要： 需求与项目风险 从定制一个软件项目到最终的实现不仅是个漫长的过程，也是充满变数的过程，全面理解与正确领悟用户需求演变的本质与应对的策略应当是需求分析人员所要具备的素质。有理由认为面向对象的理念降低了开发过程的难度，但却强化了需求分析在项目过程中的地位与作用。需求分析人员是否具备、是否能够驾驭面向对象的概念对项目的成功率关系会更加重大。下面就说明一下需求分析与项目风险的关系。1.5.1 来自用户的风险 投资者总是在摸索的过程中不断调整自己的实现目标，尽管软件开发商使尽浑身解数也跟不上用户需求的变化，最终只能是疲于应付敷衍了事。投资方的感觉是上当受骗却又无可奈何，开发商则抱怨用户需求漫无边界、任意 阅读全文

摘要： 需求规格 为设计过程中的需要而撰写的需求规格说明书是三种文体中要求最高的一种，因为它的用途在于为设计实现提供一个可以用来作为参照的基本约束。在有些情况下，它可能会包括需求报告的全部内容，并在此基础上进行扩充。 在这里有一个职责上的划分，原则上来说，需求分析只对用户需求的真实性负责，并不需要考虑数据设计与功能框架，后续工作会由专职的数据库工程师与架构设计师来完成。这种说法只有在具备规模的软件企业中才有可能做得到，对于中小企业的有限投资这并不是一个能够付诸实现的操作过程。从需求到实现设计到代码实现大约是这类项目的基本过程，有些项目干脆就是从需求直接到设计实现。 基于这种客观的项目状况，要求需求分析 阅读全文

摘要： 需求方案撰写之售前方案 需求素材调研与需求分析都是报告撰写的必然过程，在这里重点强调三种不同用途的需求文档在表述内容、表述方式上的差别与各自的特点。最全面的报告并不一定就是最合适的报告，尽可能采取相对简单的方式应当是基本策略，以满足特定的用途为出发点。1.4.1 售前方案 如果你所面对的需求分析是个相对标准的操作过程，大体上可以按照专业书籍提供的方法与步骤进行。但在中小企业的项目中，能够采取这种经典操作模式的项目并不多，所以就要研究中小企业项目过程中的需求所体现的特点与规律。 原则上来讲，需求分析应当是在项目签约之后进行。因为软件工程是个事前很难描述清楚的命题，开发商为了适应用户的心理，经常以 阅读全文

摘要： 需求分析样例 完整系统的需求分析太庞大了，很难说清楚。我们不妨从中找出一个节点，目的是说明在需求判别研究的过程中大体应当怎样对待各种管理目标的演变。限于篇幅我们只能以命题框架的构造为基点讨论问题，而不可深入到应用功能的内部细节。我们可以设想一个用户提供的《设备故障维修单》。它必然要包括设备名称、维修内容、维修人员、时间、地点、结果等基本信息，就简单管理过程而言不过如此。在不使用信息系统的情况下，这种管理手段只是一种责任性的记录，很难发挥更大的信息应用价值。 在这些数据被纳入系统之后，立刻会衍生一系列全新的应用课题。反过来对原始数据的采集过程又会带来一系列的变化与影响。我们给出与该业务相关的各种 阅读全文