软件设计师知识点.docx

软件设计师知识点.docx

《软件设计师知识点.docx》由会员分享，可在线阅读，更多相关《软件设计师知识点.docx（22页珍藏版）》请在冰豆网上搜索。

软件设计师知识点

2011软件设计师知识点：

设计模式与Java、基于工作流协同软件、简易应用规格说明技术、工程辅导浅谈架构、如何控制需求变更、构建完整的解决方案、数据结构知识概述、JavaEE开发四大常用框架、多媒体深入讲解。

目录：

2011软件设计师知识点：

设计模式与Java2

什么是设计模式2

Java中的设计模式2

J2SE与设计模式2

J2EE与设计模式3

J2ME与设计模式4

2011软设知识点：

基于工作流协同软件4

2011软设知识点：

简易应用规格说明技术8

2011软件设计师知识点：

工程辅导浅谈架构9

2011软件设计师知识点：

如何控制需求变更10

2011软设知识点：

构建完整的解决方案11

序言11

维护需求12

升级需求12

易用性需求13

性能需求14

日志需求14

2011软件设计师知识点：

数据结构知识概述14

2011软设知识点：

JavaEE开发四大常用框架16

Struts16

Spring17

Hibernate19

Swing20

2011软件设计师知识点：

多媒体深入讲解21

1、多媒体知识概述21

基本概念21

2、图形和图像22

基本原理22

2011软件设计师知识点：

设计模式与Java

什么是设计模式

   20世纪60年代的软件危机使得人们开始重视软件工程的研究。

起初，人们把软件设计的重点放在数据结构和算法的选择上。

随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明也显得越来越重要。

面对日益复杂的软件系统，人们开始认识到，要真正实现软件的工业化生产方式，达到软件产业发展所需要的软件生产率和质量，软件复用是一条现实可行的途径。

   1995年，《DesignPattern》（中译“设计模式”）一书问世，成为面向对象编程中使用模式化方法的开创性著作。

这本书对于软件实践中的一些不断变换面孔重复出现、但特征和解决方案的本质却十分类似的问题进行了总结归纳，提炼出23个具有代表性的模式。

设计模式本身并不是一种具体的“技术”，它讲述的是思想。

它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧，还让开发人员能够真正掌握接口或抽象类的应用。

更重要的是，该书提炼的这些设计模式反复强调的宗旨是尽量提高程序的使用率，让程序尽可能的可重用。

Java中的设计模式

    Java语言作为面向对象编程语言的优秀代表，它拥有简单易用的特性，以及强大的功能，非常有利于设计模式的实施。

Java发展到现在，按应用主要分为三大块：

J2SE、J2ME和J2EE，这也就是SunONE（OpenNetEnvironment）体系。

J2SE就是Java2的标准版，主要用于桌面应用软件的编程；J2ME主要应用于嵌入式系统开发，如手机和PDA的编程；J2EE是Java2的企业版，主要用于大型分布式网络程序的开发，如电子商务网站和ERP系统。

Java技术已经逐渐成为电子商务主流技术之一。

在Java的各个平台中，设计模式有很多精彩的应用，而且随着Java技术的不断发展，设计模式也在不断丰富。

J2SE与设计模式

   早期发布的设计模式主要来自桌面应用软件的开发经验。

在《DesignPattern》一书中，所有的模式都是通过面向桌面应用的窗口程序来举例说明的。

相应的在J2SE中，贯穿了设计模式的思想，尤其是大量运用了MVC模式。

所谓MVC模式，是指模型（Model）、视图（View）和控制（Control）相分离的设计方案。

模型（Model）是执行某些任务的代码。

至于这些任务以什么形式显示给用户，却并不是模型所关注的问题。

模型只有纯粹的功能性的接口，也就是一系列的公开方法。

这些方法有的是取值方法，让系统其它部分可以得到模型端的内部状态参数；有的是改值方法，允许外部修改模型的内部状态。

   视图决定模型以什么样的方式显示给用户。

一个模型可以对应多个视图，那么对于视图而言，模型就是可重用的代码。

一般来说，模型内部必须留下所有对应视图的记录，以便在模型的状态发生改变的时候，可以通知视图。

模型的状态一旦发生改变，所有对应的视图都能够得到更新。

   控制是和视图联合使用的。

用户在与视图发生交互的时候，是通过控制器来操纵模型，从而向模型传递数据、更新模型的状态。

   例如，一个表格数据体可以看作是一个模型，它可以对应成为多种视图，比如饼图、棒图或者直接显示成为一个表格。

用户通过键盘和鼠标与视图进行交互，从而激发相应的控制器改变表格数据。

一旦表格数据发生变化，视图会得到通知，进而更新显示的形式。

   MVC模式是最著名的模式之一。

J2SE中一些复杂的显示控件（如表格、列表、树等），都使用了这种模式，从而使得设计结构非常清晰而且灵活。

当然，也有人提出，MVC模式不应当被称为“设计模式”，而应当属于“架构模式”。

它可以看作若干个设计模式的组合，并且在不同的应用环境中衍生出了其它的一些设计模式。

但是在各种讨论中，MVC模式还是常常被当作设计模式。

    J2EE与设计模式

   J2EE属于一种框架软件。

什么是框架软件？

它不同于以前接触的Java API等，那些API属于Toolkit（工具箱）。

而J2EE不再被动地被使用、被调用，而是深刻地介入到一个领域中去。

J2EE设计的目的是将企业计算应用领域中不变的东西先定义好，比如整体结构和一些主要职责（如数据库操作、事务跟踪和安全等），剩余的就是变化的东西，即针对这个领域中具体应用所产生的不同的变化需求，而这些变化的东西就是J2EE程序员所要做的。

因此，设计模式和J2EE在思想和动机上是一脉相承的。

只不过设计模式更抽象，几乎可以用于任何应用；J2EE则是适合企业计算应用的框架软件，而设计模式是它的重要的理论基础之一。

与此同时，在J2EE的框架下，一些应用级的设计模式也逐步积累了起来，关于设计模式在J2EE中的应用已成为许多论坛讨论的热点之一。

其中，J2EE Web应用的架构设计引起了高度的关注。

J2EE体系包括JSP、Servlet、EJB、Web服务等多项技术。

这些技术的出现给电子商务时代的Web应用开发提供了一个非常有竞争力的选择。

怎样把这些技术组合起来，形成一个适应项目需要的稳定架构是项目开发过程中非常重要的步骤。

此步骤一般由架构设计师完成，设计师根据项目需求，对J2EE体系中的各种技术进行筛选取舍，并考虑到开发过程中的角色分工、后期的运行维护，以及系统扩展性等诸多因素建立系统的架构。

一个成功的软件需要有一个成功的架构，但软件架构的建立是一个复杂而又持续改进的过程，软件开发者们不可能对每个不同的项目做不同的架构，而总是尽量重用以前的架构，或开发出尽量通用的架构方案。

   在当前的J2EEWeb应用中，Apache Struts是最流行的架构方案之一。

它实现了MVC模式的概念，并将这些概念映射到Web应用程序的构件和概念中。

Struts这个名字来源于在建筑和旧式飞机中使用的支持金属架，其目的是帮助开发人员减少在运用MVC设计模型开发Web应用的时间。

   ApacheStruts有以下的优点：

一些开发商开始采用并推广这个框架；作为开源项目，有很多先进的实现思想；对大型应用支持的较好；有集中的网页导航定义。

ApacheStruts正在获得越来越多的关注与支持。

    J2ME与设计模式

   J2ME标准为消费类产品（例如移动电话、双向传呼机和无线个人信息管理器）的应用开发提供支持。

这一类产品的特点是，显示能力和存储能力有限，计算能力和网络访问能力不够强大。

因此，J2ME设计模式就有了它所独特的问题领域。

比如，如果需要显示比较大的数据集合，那么应该采取什么样的解决方案，才能适应狭小的显示区域？

又比如，如果需要实现类似桌面软件的选单选择的功能，那么应该如何设计才能够足够简练和便于重用？

J2ME的设计模式正在逐步的积累过程中，我们相信随着J2ME的推广J2ME设计模式的讨论也将逐步成为一大关注热点。

    Java与设计模式的结合，为Java的发展带来了更大的活力，也为设计模式提供了一个宽阔的舞台。

在这些技术的共同推动下，软件产业将以坚实的步伐走进工业化时代。

2011软设知识点：

基于工作流协同软件

 工作流管理系统是“一种在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统”，其主要目标是对业务过程中各活动发生的先后次序及同活动相关的相应人力或信息资源的调用，进行管理而实现业务过程的自动化。

   在企业的日常工作中，绝大多数属于流程类工作，比如业务的分级审批工作、各类申请表单、公文签审、业务处理等。

通过现代的技术手段将企业内诸多繁琐复杂的业务流程自动化，并对其进行有效地管理便是工作流需要解决的问题。

   传统的系统设计方式将业务流程以编码的方式固化在应用系统中，在业务流程和组织结构发生改变的情况下，需要将系统进行重大修改，甚至重新设计。

实际上，业务流程的改变是导致许多应用系统失败的最主要的原因。

   工作流管理系统的出现使得上述情况发生了改变。

应用系统的开发人员通过可视化的方式分析和设计业务流程，并将各个应用模块联接在一起。

在组织结构和业务流程发生变化的时候，能够在很少修改甚至不修改原来应用的情况下，仅仅通过适当调整或重新定义工作流程就能适应变化了的情况。

   采用工作流管理系统有以下优点：

   提高系统的柔性，适应业务流程的变化，建设各类信息系统的重要工作之一就是发现用户的工作流程，进行分析建模，并把它体现到信息系统的设计中。

   企业都在随着时间不断地改革工作流程，使企业各部门能够更好地发挥服务职能、提高工作效率。

   提高企业工作效率，企业许多流程在自动化过程中会省去一些不必要的步骤

   较好的流程控制，通过标准的工作方法和跟踪审计，提高了业务流程的管理

 跨越流程的软件控制，使流程可以按照业务的灵活设计。

   业务流程的改进，对流程的关注，使它们趋向于流畅和简单。

   企业建立以工作流为基础的协同软件的必要性

   1、从IT规划出发

   企业信息化建设已经逐步从以前的以业务部门推动IT部门的被动式建设方式，逐渐向IT部门从整个企业的角度对IT进行主动规划的方式转变。

被动的信息化建设方式导致的结果是在企业内部产生大量的“梅花桩”，成为企业内部的信息孤岛。

而主动规划则大大改观了这种局面，通过主动规划，各个业务系统之间不再各自为阵，彼此孤立，互不相通，甚至重复建设了。

   对于流程企业的建设，在IT规划过程中，一个重要的目标就是“企业流程整合”，为了达到这个目标，“工作流平台”可以说是不可或缺的。

那么从IT规划的角度，如何选择一个适合您的工作流平台呢？

   1）是否符合短期与长期规划的需求

   由于IT规划一般至少是对信息化进行3～5年的规划，因此现在工作流产品时，既要考虑工作流产品是否符合短期内的业务需求，又要考虑工作流产品是否能够满足企业业务发展的长期需求。

   短期的业务需求一般都是比较明确的，这些系统，往往都是由于企业业务发展的需要而要求必须马上进行建设的，因此对IT系统提出的要求都非常具体。

   对于IT规划中，未来的业务需求，往往是不容易预测的。

但是对于选择工作流产品来说，这又是至关重要的。

   2）支撑整个流程企业的IT运行的工作流

目前市场上的工作流产品鱼目混珠，其中大部分都是一些做行业应用软件的集成商为了自用而开发的。

这一类工作流产品大多都是专门针对某一类业务系统而开发的（比如OA类），无法应用在其它业务系统。

并且这类工作流产品的易用性、功能完备性等等都得不到保证。

因此这类专用的工作流是不能支撑整个流程企业的IT运行的。

   而作为一个要运行在整个企业IT系统的工作流平台，必须具有很好通用性和适应性，比如工作流平台不仅仅能够用于支持企业内部的OA系统运行，还要能支撑企业的业务系统。

   2、从业务需求出发

   工作流平台一个非常重要的依据就是是否能够满足业务系统本身的需求，现代企业的业务需求有以下特点：

   1）新产品新业务推出频繁

   市场是一个竞争异常激烈的市场，随着竞争的加剧，新产品推出的频度也越来越高。

   这些新产品、新业务的频繁推出，需要IT系统能够以更快的速度来响应，以提高业务的敏捷性。

而对于以流程为主的系统来说，工作流产品的灵活性、适应性显得尤为重要。

如果工作流平台不能支持这种业务的快速变化，则将极大的影响企业新业务的推出，从而最终影响企业在市场的竞争力。

   2）海量数据、高并发

   3）业务流程跨组织

   由于企业很多都是矩阵式的组织机构，因此在企业内部的公文处理流程中常常需要在不同部门之间跨部部门（包括平级和上下级部位之间）交叉、往复流转。

甚至很多行文是在不同部门的彼此独立的系统之间进行交互的。

   4）流程的灵活性要求高

企业的流程对灵活性要求非常高，同一个流程往往需要往复运行很多轮才能结束。

有时在流程未能固化之前，甚至要求流程按照任意顺序流转，而不受流程本身的逻辑控制（即所谓的自由流）。

   另外，对于公文审批规则、会签、退回、批阅、督查督办、机构的岗位设置等等都有比较灵活的要求。

   5）严格的权限控制

   企业的行文，每一步的公文处理都有严格的权限控制。

比如同一个流程中不同的公文有的人只能看，不能审批签字；同一个处理人员在不同的流程环节中对公文的权限也不相同。

有的甚至要求某些公文只能查阅，但是不能复制到本地保留副本。

这些需求都是在选择一个工作流引擎时需要重点考察的。

   6）安全保密要求高

   企业中的公文流转，由于涉及到企业机密，因此要求公文在流转过程中，必须保证绝对的安全，不能出现被黑客非法窃取的情况。

   易协智能协同管理软件实现了业务流程的管理、控制和过程的自动化，并具有以下特点：

   通过将一个具体的工作分解成多个任务、角色，通过一定的规则和过程，约束这些任务的执行和监控，以达到提高企业生产经营管理水平。

   完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。

   本系统有与同类软件相媲美的先进功能，并且具有一些符合中国国情的显著特点，具体如下：

   1）强大的工作流引擎

   工作流引擎是工作流管理软件的核心功能，主要用于负责解释、执行各种工作流程，调度、分发和管理任务。

   引擎不仅支持顺序流程的流转，而且还支持分支、并发、循环、子过程（同步、异步）、活动集等，在分支上可以定义条件，实现按条件自动流转，条件转移之间还可设置逻辑关系；在并发流转中，多个活动节点可以同时激活；在某些活动节点上，也可以通过创建子过程来完成任务。

易协智能协同管理还提供自由流，并且自由流支持异步流转。

   2）工作流程的自由定义

   流程编辑器提供的图形化过程定义工具简单、易用，使用户在简单的拖拽中即可轻松地完成过程定义工作，过程定义中还可以使用已经定义好的部件快速完成业务过程的定义。

   易协智能协同管理已经做到任意定义单个员工、部门、事务的工作流程，并且可以定义群组的工作流程。

采用流程代码的设定方式，使系统的灵活性和扩展性大大加强。

工作流程步骤不受限制，工作流程的事务不受限制。

   3）表单自由定义

   易协智能协同管理已经做到对任意工作流程所涉及到的表单用户可以自己进行设计，使系统的灵活性和扩展性大大加强。

   4）业务实时监控

   针对业务流转过程中的审批情况，具有相关权限的用户可以实时进行监控。

   5）灵活的组织、员工设定和权限管理

   工作流管理WFM结合用户管理模块，可以快速定义和修改企业的组织结构、人员协作关系，并设定用户的角色和权限。

   6）以任务为管理线索

   所有的工作，都可以分解为单项或者组合任务，每一任务可以自由设定内容。

工作流管理WFM用户只需打开事件任务中心，就可以查看、管理所有的待办事宜。

根据任务的执行情况，可以对任务的责任部分和个人，进行绩效考评和过程改进建议。

   7）多种消息提醒方式

   工作流管理WFM中的相关消息，包括待办任务、请示批复等消息，可以采用在线系统短消息、脱机提醒等，并将提醒和处理结果自动反馈到工作流管理数据中去。

2011软设知识点：

简易应用规格说明技术

使用传统的访谈技术定义需求时，用户和开发者往往有意无意地区分“我们和他们”。

由于不能做到像同一个团队的人那样同心协力地识别和精化需求。

这种方法的效果有时并不理想（经常发生误解，还可能遗漏重要的信息）。

   为了解决上述问题，人们研究出了一种面向团队的需求收集法，称为简易的应用规格说明技术。

这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求。

今天，简易的应用规格说明技术已经成为信息系统界使用的主流技术。

   尽管存在许多不同的简易应用规格说明方法，但是它们遵循的基本准则是相同的。

   ·在中立地点举行由开发者和用户双方出席的会议。

   ·制定准备会议和参加会议的规则。

   ·提出一个议事日程，这个日程应该足够正式以便能够涵盖所有要点，同时这个日程又应该足够非正式，以便鼓劢自由思维。

   ·由一个“协调人”来主持会议，他既可以是用户也可以是开发者还可以是从外面请来的人。

   ·使用一种“定义机制”（例如，工作表、图表等）。

   ·目标是标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求。

   通常，首先进行初步的访谈，通过用户对基本问题的回答，对待解决的问题的范围和解决方案有了总体认识，然后开发者和用户都写出“产品需求”。

选定会议地点、日期和时间，并选举一个协调人。

邀请开发者和用户双方组织的代表出席会议，在会议日期之前把写好的产品需求分发给每位与会者。

要求每位与会者在开会的前几天认真复审产品需求，并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。

此外，还要求每位与会者列出操作这些对象或与这些对象交互的服务（即处理或功能）。

最后，还应该列出约束条件（例如成本、规模、完成日期）和性能标准（例如速度、精度）。

并不期望每位与会者列出的内容都是毫无遗漏的，但是，希望能准确表达出每个人对目标系统的认识。

    会议开始之后，讨论的第一个议题是是否需要这个新产品，一旦大家都同意确实需要这个新产品，每位与会者就应该展示他们在会前准备好的列表供大家讨论。

可以把这些列表抄写在大纸上钉在墙上，或者写在白板上挂在墙上。

理想的情况是，表中每一项都能单独移动，这样就能删除或增添表项，或组合不同的列表。

在这个阶段，严格禁止批评与争论。

   在展示了每个人针对某个议题的列表之后，小组共同创建一张组合列表。

在组合列表中消去了冗余项，加入了在展示过程中产生的新想法，但是并不删除任何实质性内容。

在针对每个议题的组合列表都建立起来之后，由协调人主持讨论。

组合列表将被缩短、加长或重新措辞，以便更恰当地描述将被开发的产品。

讨论的目标是，针对每个议题（对象、服务、约束和性能）都创建出一张意见一致的列表。

   一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的一个或多个项目制定出小型规格说明。

小型规格说明是对列表中包含的单词或短语的准确说明。

   然后，每个小组都向全体与会者展示他们制定出的小型规格说明供大家讨论。

通过讨论可能会增加或删除一些内容，也可能做一螋进一步的精化工作。

在讨论过程中还可能提出一些无法在这次会议中解决的问题，应该保存问题清单，以便这些想法在以后的活动中起作用。

   在完成了小型规格说明之后，每个与会者都制定出产品的一整套确认标准，并把自己制定的列表提交会议讨论，以创建出意见…一致的确认标准列表。

最后，由一名或多名与会者根据会议成果起草完整的规格说明。

   简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是，这种面向团队的需求收集方法确实有许多突出的优点：

开发者与用户不分彼此，集思广益，益密切合作；即时讨论和求精；有能导出规格说明的具体步骤。

2011软件设计师知识点：

工程辅导浅谈架构

不得不说的就是规范性的东西，我认为规范是个很重要的东西，当然，规范不只是说大家统一用某种形式命名变量，方法等等，这只是对程序员而言的规范，如果这个划做横向规范的话，那么纵向规范就是面对客户的规范。

对程序员的规范，我不想多说了，注释，变量，方法，文档。

当然未必每个人都做到了这些。

我想说的是对客户的规范问题。

   对客户的规范有很多中，比如小细节CS系统中的Anchor怎么设置，Dock怎么设置，如何让页面看起来更加让用户舒心，如何做焦点设置。

大到如何给客户做培训，如何防止用户看到不友好页面，如何简化用户操作等等，这些都是属于规范性范畴。

对于焦点设置，我有深刻体会，前段时间找工作，某网站输入搜索条件以后，按钮回车老是达不到焦点上去，非要我去移下鼠标点击，很不爽。

   第一点，对于一个完善的架构，日志处理机制是必须做好的，日志处理不只是简单的说输出完成这么简单。

首先，必须要通过配置控制在什么时候输出，在什么地方输出，如何输出，怎么记录，是记录数据库还是日志文件中。

如何灵活让用户控制日志输出方式。

   第二点，对于一个完善的架构，异常处理机制也是一个重点。

异常怎么处理，如何记录，是记录到系统中，还是异常文件，还是数据库异常表，或者发给技术部邮件等等，如何做异常记录，在产生异常以后更容易让用户，技术人员看到异常产生的原因，这个是一个比较重要的模块。

   第三点，对于一个完善的架构，配置文件是必须的，有些项目只是简单的对web.confg里加些配置，我认为这根本不够完善，对于配置而言，有很多需要配置的内容，比如系统连接哪种数据库，客户信息，再比如是否记录日志，异常等，是否允许用户注册等等灵活功能的控制完全可以在配置中实现。

   第四点，对于一个完善的架构，如何做好权限是很重要的一块内容，比如权限如何控制，怎么处理用户，组，模块，部门等等之间的关系，工作流如何做，如何让权限与工作流做良好匹配，比如某审批人员出差了，如何处理其审批流程等等，虽然这点，我自己也在不断研究，但我想这一块非常重要。

   第五点，对于一个完善的架构，流水号生成功能也相当重要，任何一种系统，不管是信息管理系统还是电子商务平台，一定都会要求按一定格式生成某套流水号，流水号也必须有灵活性，这点非常重要。

   第六点，对于一个完善的架构，必须要有代码生成功能，比如基础业务类生成，实体类生成，最好可以控制数据库主外键关系等等，这样能减少程序员的很多无趣的工作量。

   这是我目前总结的几个重要点，另外当然包括多语言，多皮肤等等，我想这些目前来说还未必非常重要。

2011软件设计师知识点：

如何控制需求变更

 按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。

需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。

为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。

综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。

   进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。

（1）项目启动阶段的变更预防

   对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。

对一个需求分析做得很好的项目来说，基准文件