一、 分析员要用到五种图：
1. 类图
2. 用例图
目的是识别新系统的“使用”，或用例，换句话说，就是识别如何使用系统。用例图是一个记录系统必须支持功能的简便方法。有时可以用一个综合用例图来描述整个系统。在其他情况下，一些小型的用例图组成用例模型。
3. 协作图
目的是识别协作完成给定业务功能的对象。一个单一的协作图用以识别对象，并展示这些对象的相互作用及对象之间发送用于执行功能的消息。通常来说，我们会用到许多协作图。
4. 顺序图
与协作图表达的信息是一样的，只是显示方式有些差异。顺序图以图形化的方式强调消息间的顺序，而非协作对象间的顺序。画顺序图的目的是为了通过页面上的位置，图形化地表示消息的顺序。执行次序从上到下进行。协作图和顺序图都统称作交互图。
5. 状态图
用以描述应用需求的图。它描述了每个对象的状态和行为。每个对象类都含有一个状态图。在状态图的内部是动作陈述，这些动作陈述在最终系统中变成了逻辑。每个类中的逻辑组件称为方法。
二、 建立关系数据库模式，可以采取以下步骤：
1. 为每个实体类型建立一张表。
2. 为每个表选择一个主键（可以自定义一个）。
3. 增加外键以表示一对多关系。
4. 建立几个新表来表示多对多关系。
5. 定义参照完整性约束。
6. 评价模式质量，并进行必要的改进。
7. 为每个字段选择适当的数据类型和取值约束。
三、 界面设计指导原则：
1. 可视性：控件对用户来讲是可用的，并且控件在用户动作之后应提供及时的反馈以示响应。
2. 可供性：所有控件的外观都要体现其功能，即控件的使用方式。
八条黄金规则：
1. 尽量保持一致性。
2. 为老用户提供快捷键。
3. 提供有效反馈。
4. 设计完整的对话过程
5. 提供简单的错误处理机制。
6. 允许撤销动作。
7. 提供控制的内部轨迹。
有经验的用户希望有控制感觉，而不是感觉被系统所控制。系统应该让用户觉得是由用户在做决定。设计者可以通过提示字符和提示消息的方式使用户产生这种感觉。
8. 减轻短期记忆负担。
四、 系统开发中的当前趋势：
1. 快速应用开发：
影响大多数工程进度的三大类原因：
A. 返工
避免返工需要做两件事：
a) 好的软件（并且只有合适的软件）必须是可构造的或可获得的。
b) 开发过程生产的软件必须至少满足最低的质量标准。
保证构造好的软件的惟一方法是保证在设计和构造开始之前就要充分地了解系统需求和全面的设计限制条件。目前有许多确保软件质量的方法，其中一些更加有效的方法要求在构造之前完全规定好重要的设计参数，要求委派训练有素的、有创造力的人完成构造任务，并且为系统建造者提供很好的辅助工具。
B. 需求的变化
用户通常在工程开始时不能确定他们想要的是什么，快速变化的环境使系统在没有开发完成前就出现改动的情况成为必然。忽略重要的需求发动只能使软件在将会使用时达不到用户要求。为了避免工程延期并且满足用户需求，开发者必须要预期需求的变化并将改动结合到开发过程中去。
C. 开发工具和技术的不足或不正确
没有哪一组工具和技术能够很好地适用于所有的开发工程。系统需求、系统开发方法和最终操作环境的差异可能要求不同的分析、设计和构造工具。用不恰当的工具和技术可能会降低工程质量或增加开发时间，或者时间和质量都受影响。
快速应用开发（RAD）是已被证实了的在某些情况下可以缩短开发进程的开发方法、技巧、工具和技术的总和。
RAD不是对缩短任何项目开发进程都适用的。没有通用的RAD开发方法可以缩短所有项目的开发进程，也没有任何一种技巧、工具或者技术对所有项目都适用，仅仅只靠一种方法或技巧是不够的，而且它们也不能对每一个项目都适用。
缩短开发过程的关键是确定整体的开发方法，以及适用于特定的方法和特定项目的开发技术、工具和技术集合。对于一些项目，RAD可能需要使用一些非传统的开发方式和一些更新的方法。对另外的一些项目，传统的开发方式辅以一些特定的方法和工具为补充就可以缩短开发进程。要记住方法、工具、技巧和技术可能要被混合使用才可以满足特定项目的要求。
顺序开发适用的条件：系统相对简单、容易分析和建模，因此有理由相信在设计和构造活动开始之前，需求能够被充分和正确地界定。在设计和构造之前进行分析不仅是合理的而且在经济上也是必需的。
需求的改变通常是由于外部环境发生改变或项目开始时候不能明确确定。这种情景下，没有理由认为在系统设计和构造之前就可以完全正确地确定所有需求，而且技术方面、实施方面、经济方面的可行性也不能在开始的时候被完全确定。因此顺序型的开发方法对此非常不适合。而那种通过经验和学习，循序渐进的开发方法可能要更适合一些。这样的方法逐渐发现和提炼需求，也可以使使用者和开发者的工作能够渐渐跟上新技术的学习曲线。
不建议完全抛弃顺序型或传统的开发方式，在适合它们的特点的情况下，它们是最快的途径。
2. 原型化开发方法：一种基于使用发展型原型反复精练的开发方式。
通常在软件开发中使用两类原型系统：
发现型原型：用来发现或明确系统需求或者系统参数的原型系统。通常用在分析阶段，偶尔也会用在设计阶段。
发展型原型：被反复开发直到成为最终系统的原型系统。是那种不准备抛弃的原型系统，它将会变成最终系统的全部或一部分。
下列条件下，使用原型化开发方法通常比传统折开发方法快：
ü 一部分需求不能独立于体系结构或者详细设计而单独被确定；
ü 一些系统功能的技术可行性不可知或者不确定；
ü 原型化的开发工具有足够的能力去构造一个功能完备的系统。
原型化方法是明确不确定需求的很好的途径。通过检验原型系统，使用者通常可以提供比检验图形或文本模型更好的反馈。一个原型化的方法可以明确地定义那些与设计和实现密切相关的需求。有些需求可能要花更多的时间去确定，它们可以被原型化，以便避免实现整个系统时延期。然而，如果大部分需求在事先都确定的情况下，使用原型化方法以就能做得最好。对于一个项目，如果存在着重要的不确定需求，其他的技术和开发方法也许对它更合适。
当怀疑设计技术的可行性的时候，原型化的开发方法也会很实用。开发和测试早先的原型，可以帮助找出设计和实现中的问题。那些不正确的想法会被轻而易举地抛弃，然后重新使用一些不同的参数集合。一旦成功，开发者就能够重新审视系统体系结构设计并修订后续原型的开发计划。在符合需求的同时，成功地进行原型化设计需要体系结构的大多数方面和技术可行性事被确定。否则，初始的原型就可能太大，从而可能不利于快速开发和测试。
一些功能和需求可能不适合原型化方法：
ü 没有交互性
ü 内部复杂
ü 有严格的性能要求和安全需要
3. 螺旋式开发方法：一种循环反复的开发方法，其中每一次都由规划、分析、设计或实现等几步构成。
螺旋式开发方法的步骤：
从最初的规划阶段开始，目的是收集足够的信息以进行初步的原型开发。计划阶段的活动有可行性研究、高层用户需求调查，备选实现方案产生、全局设计和实现策略的选择等几个部分。螺旋式开发方法和原型化开发方法的主要不同之处在于用户需求和软件分析的细节部分。螺旋式的开发方法比原型化的方法使用更少的细节。
和原型化开发方法一样，螺旋式开发方法对一系列原型的最初计划也是要开发的，而且这些规划一定要具有很好的适应性，这是因为分析和设计是非常有限的。又因为很多分析和设计的细节都被忽略了，所以在项目中规划经常要被修改。因此 我们就要避免对将来的原型进行过多的细节设计。
当初始的规划完成后，就可以认真地开始构造第一个原型。对于每一个原型，顺序的开发过程都包括分析、设计、构建、测试、集成原有的原型组件，以及规划下一个原型。当下一个原型的规划完成后，新的循环就开始了。
在每一个循环中实现哪些特性是一个重要的决定。开发者应该怎样选择这些特性要依据一定的准则，包括：
ü 用户有优先级
ü 不确定的需求
ü 功能重用
ü 实施风险
怎样评估这些标准对于每个项目都是不一样的。
可以将系统需求的优先级典型地分为几类：
ü 必须有的
ü 应该有的
ü 最好有的
一个最小化开发周期的方法就是在最初的原型设计时包括“必须有的”和“应该有的”这两部分需求。这样可以在缩短开发时间的情况下，大大提高为用户提供有用系统的可能性。如果工作比预期进展得要慢，低优先级的需求就可以推迟到进一步进行系统升级的时候实现，或者在安装以后再添加，或者完全忽略。
如前所述，原型化的方法对于明确不确定的或定义错误的用户需求是一种很好的工具。在早期原型中把这些用户需求包含进去可以使它们尽快地被探究和明确。这样得到的信息可以用来指导以后的原型开发。推迟确定系统中没有明确的需求，如果到时候这些需求与已经完成的部分发生冲突的话，就可能导致意想不到的返工。
把需要多次重复使用的功能包含在早先原型中将是很好的选择。
螺旋式开发相对传统的开发方法和原型化的开发方法的益处：
ü 高度的并行性：在各个原型循环之中和循环之间，有许多进行重叠活动的机会。
ü 高度的用户参与性：使用者可以参与每一个规划、分析和测试阶段。用户不断和持续的参与可能开发出更好的系统并获得更高的用户满意程度。
ü 循序渐进的资源负担：使用螺旋式的开发循环将可以使资源的消耗更平缓。这可以更有效率地利用资源。然而，整个的开发费用通常要高一些。
ü 频繁地产品交付：每一个原型都是一个可以独立工作的系统。通过充分地规划，这些原型可以立即投入使用。频繁的产品交付将导致更多的测试，因此可以修补更多的漏洞，改善产品质量。
螺旋式开发的缺点，就是管理和设计的复杂性。它比传统方式管理复杂主要是因为使用这种方法的时候有更多的活动要进行，而且在早期阶段有更多的人要更早地服务于项目；其次是因为在构建之前没有进行完整的分析和设计，所以返工的可能性很高。
一个采用螺旋式设计方法的设计者要冒更大的风险进行决策，因为这种决策可能是全局次优的，可能导致低性能、大量错误、安装后维护困难。
ü 当使用螺旋式设计方法的时候，具有高度相互依赖功能的系统要冒更大的设计风险，一个系统功能的设计决定会影响系统其他部分。这样，在随后的循环中所构建的那部分系统分继承大量的设计限制，这种限制是很难或者是不可能被解决的。
ü 预期生命期长的系统要比短的系统需要更加仔细和周密的设计。这是因为所有的信息系统在它的生命周期内都会被修改。生命期越长的系统，需要修改的数量就越大。修改对于软件质量来讲具有积累的影响。随着越来越多的特性加入系统，系统的效率就要变差，可靠性下降，而且更加难以维护。最后，问题积累到一定程度，系统就必须被重新构造。
ü 既然没有人可以预测未来所有的需求，就允许设计者将来修改和增强系统。系统可以根据快速开发原则来设计，也可以依照最容易修改原则来设计，或者两者兼顾。但是，针对升级和灵活性的设计最好在一个完整的系统中进行，而不要在子系统中循环进行。与循环反复的开发相比，因为设计工作在项目开发周期的早期完成，所以其他的方法可以在设计中提供更大的灵活性。
ü 很难确定有多少分析和设计工作该在初始设计阶段完成，多少这样的工作要留待以后完成，并且项目组分析和设计的经验与技术也对这个决定至关重要。当然，运气也是一个因素。有时，甚至大多数技艺娴熟、经验丰富的软件开发人员也会出现错误的分析和设计。这样，最后的结果往往是发现已经完成的工作需要返工甚至完全抛弃。
4. 极限编程：一种快速开发方法，其重点侧重于创建用户经历（用例）、系统发布和快速测试。
一个系统以多阶段形式交付给用户被称为发布。
用户经历：用例。
系统隐喻：类图。
每次发布的系统是一个能完成系统用户需求子集的完全功能系统。多个发布系统被分到多个循环反复过程中。在每一次循环中，开发者编写代码并测试一个发布系统的某一特定功能子集。开发者和用户为每个用户经历创建一组验收测试。只有经过相应用户经历验收测试的发布系统才被认为是完成了的。最后的系统级活动是创建以一系列发布系统为中心的开发计划。
XP原则和技术
ü 连续自动测试：在XP方法中每天都发生测试活动。当实现软件模块或系统功能的工作开始时，与该模块或功能相关的测试将被增加到永久测试组中，并且所有的循环和发布系统都要利用这个永久的测试组来测试。
ü 连续集成。一旦软件模块通过单元测试，该模块就与其他模块联合起来接受测试。这样做会很快发现错误。直到发现的问题得到解决才能继续进行附加模块、循环和发布系统的开发工作。
ü 大量用户参与：一直有一个或多个用户参与到开发组中来。如果使用系统的机构不愿意这样做，那么该项目的重要性可能就会受到质疑。用户要参与所有的重要决定，包括技术方面的决定。
ü 团体程序设计：两个程序员坐在工作站前面，共用显示器和键盘来开发所有软件。这种方法被称为成对程序设计。还有，程序员定期互相检查对方的工作。允许任何一个程序员任意时候改变程序。
ü 特别注意人机交互和限制：整个开发组在同一个房间内工作，大小按需要而定。程序设计工作站被安置在中央，周围设置一圈小房间作为工作间。每个小组成员都能够看到其他人员并能与之通信。工作时间标准是每周四十小时。加班是被禁止的，这样可以避免因疲劳、超时工作等而导致的额外错误。
5. 统一过程开发方法
UP方法采用了原型化开发方法和螺旋式开发方法中使用的最重要的迭代原则。开发过程通过一系列迭代进行，每步迭代过程都结合了计划、分析、设计和构造活动。每步迭代都产生有意义但又不完全的最终系统的子集，用每次迭代增加或修改前次迭代的输出结果，使模型和工作软件趋向完善直至完成。
UP方法和其他开发方法的主要区别在于UP方法对面向对象模型和工具的排他依赖，以及对迭代长度和活动的特定限制。用例是对需求进行存档的主要方式，其他面向对象分析和设计模型只提供了必要但辅助性的角色。UP方法对的数字和所开发模型的种类并不教条，相反，他们会根据特定的项目特征选择混合模型。
和XP相比较，UP是更标准化的过程，通常包括更前沿的计划、分析和设计活动，并且总是在预先定义好的迭代过程中执行。如同在XP中一样，开发模型只是构建有用软件的一个必要的过程，模型本身并不是最终被开发的产品。尽管UP和XP方法在对备用模型的使用上很相似，但XP比UP方法在在程度上尽量避免模型化。本质上讲，XP和UP方法是原型化开发与螺旋式开发略微不同的两个派生方法，一个强调用严密的组织开发来加快进度，而另一个则倾向于将较大的项目形式化。
UP方法如何组织软件开发：
UP方法同过去的顺序开发方法明显不同，UP方法的SDLC包括四个高级活动：
ü 起始：UP系统开发生命周期中的早期活动，包括战略计划。
ü 细化：UP系统开发生命周期第二层活动，包含系统最高风险部分的计划、分析、设计和构造。
ü 构造：UP系统开发生命周期的第三层活动，包含系统低风险和较简单部分的程序设计、安装和测试。
ü 交付：UP系统开发生命周期的第三层活动，将系统从开发转入产品。
扫一扫
946
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
